良いユーザーストーリーの条件として、よくINVESTが挙げられます。(参考: https://blog.guildworks.jp/2015/06/03/how_to_deal_with_invest_of_userstory/ )
- Independent 独立している
- Negotiable 交渉可能である
- Valueble 価値がある
- Estimable 見積り可能である
- Sized Right (Small) 適切な大きさである(小さい)
- Testable テスト可能である
この中のValuableについて考えてみます。ユーザーストーリーは価値がなければいけない。1個1個のユーザーストーリーに価値があれば、プロダクトオーナーは依存関係を意識せず並べられ、開発者はテストを含め完全に完成させられ、顧客は毎スプリント価値あるアウトプットを受け取れます。価値があるユーザーストーリーとは素晴らしい。
本当でしょうか。本当に、ユーザーストーリーは「価値があるべき」であり、「価値を持てる」のでしょうか。
ユーザーストーリーを扱う上で、よくある悩みは「1スプリントで完成できない」というものです。スクラムマスターは「それではストーリーを分割しましょう」と言います。Richard Lawrenceによればストーリー分割には以下のようなパターンを使えます。
- 原則
- 優先順位が違うものを分ける
- だいたい同じ大きさ(小ささ)に分ける
- パターン
- ワークフローのステップごとに分ける
- ビジネスルールのバリエーションで分ける
- 最初の1個目で基本形ができるように分ける
- シンプルな部分と複雑な部分に分ける
- データのバリエーションで分ける
- データ入力の方法で分ける
- パフォーマンスを別に切り出す
- 操作(CRUD)で分ける
- スパイクを切り出す
いずれももっともですし、効果的な分割ができそうです。でも分割したものには価値があるのか？あるとしてどのくらいなのか？測る方法はあるのか？
そもそも価値とはなんなのか。
エクストリームプログラミング入門の第1版で、ケント・ベックはこう書いています。
第15章 計画戦略 計画ゲーム (p.89):
計画ゲームのゴールはチームが生産するソフトウェアの価値を最大化することである。
計画ゲームは3週間ごとにおこなうとされています。常に、ソフトウェアの価値を最大化するよう計画すると述べているものの、ストーリー1つひとつに価値があるという言及は、この本には見つかりません。
アジャイルマニフェストのアジャイル宣言の背後にある原則の1番目は「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」とあります。ここにも、継続的に提供するのは価値のあるソフトウェアであって、ストーリーとか、機能とか、フィーチャーとかPBIとかいったものが個々に価値があるとは言っていません。
エクストリームプログラミング(第2版)では、こうなっています。(訳は筆者)
Chapter 7. Primary Practices - Stories
顧客が理解できる機能の単位を使って計画する。……見積りにより、ビジネス側と技術側の観点から相互に対話する機会が生まれ、そのおかげで価値を早期に、一番ポテンシャルが高い時期に作り出せる。コストがわかれば、その機能の価値を鑑みながら分割したり、結合、拡張することもできるようになる。
ここでは、ストーリーは相互の対話、インタラクションのためにあると言っています。ユーザーストーリーの3Cにもあるように、ストーリーに会話は不可欠です。
ここに、ストーリーが「価値がある」意味が出てきます。価値とは、それがなんであれ、誰のためであれ、ストーリーに背景を与えます。技術側はその背景を理解して初めて、ソフトウェアの価値に貢献できるようになります。技術側は正しいものを作るために、ビジネス側の観点を持たなければならない、そのための「ストーリーの価値」です。
アジャイルマニフェストの原則ではまた、「できるだけ短い時間間隔でリリースします」「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」とあります。ここから、ビジネス側の人、ひいては顧客側は開発者にフィードバックをするチャンスが得られます。ストーリーに価値があれば、その部分をさわって、満足か不満か、直すべき点はどこかという情報を開発側は受け取れます。開発者の知識とソフトウェアの実装は一致しています。そこにビジネス観点から見て間違いがあれば、開発者の知識を修正でき、ソフトウェアも正しくなります。そして「チームが生産するソフトウェアの価値を最大化する」ことに近づきます。
以上から、ユーザーストーリーが価値があるのは、正しいもの、価値あるソフトウェアを作るためと言えます。そうなる確率を上げるために、作る前の会話を効果的にし、作った後の確認も容易になります。これはすなわちリスクマネジメントの手法と言えます。価値があるユーザーストーリーを書くと、ソフトウェアが失敗するリスクを下げられる。
ストーリーに価値があるのは、実現したらソフトウェアの価値がそのぶん増すというような、単純なものではないのです。リスクマネジメントの手法なので、どんなリスクを想定するか、どんな情報を得たいか、そのうえでどれを優先すべきか、考えるための道具として使うものです。「間違ったものを正しく作る」事態を避ける道具のひとつなのです。
(まだ十分に考えが整理されていないのですが、いったんまとめるために本稿を書きました。観点の不足もあると思うのですが、コメントなどで突っ込んでもらえると嬉しいです。)
