第7回 “相対見積もり”でストーリの規模を効率よく見積もる---TRICHORDの開発現場から

2006.04.21

　前回は，ソフトウエアのリリース間隔などを考慮してタイム・ボックスを決めるところまでを紹介した。タイム・ボックスを決めたら，次はその中に入れるフィーチャ（機能）を決定する。もちろんフィーチャ・リストを作成しておくことが前提だ。フィーチャ・リストは，内容とその依存関係を考慮して優先度をつけておくことが重要である。

　TRICHORDの開発では，フィーチャをさらに「ユーザー・ストーリ」（以下ストーリと呼ぶ）という形に分割している。ストーリは，基本的に「ユーザーが○○できる」というシンプルな形の記述になる。非常に単純だが，実はこの記述には大きな意味がある。「ユーザーが○○できる」ということは，このストーリを実現すれば，直接ユーザーができることが増え，ユーザー価値につながるということだ。言い換えれば，ストーリはユーザーに価値を与える単位で切り出すのが基本である。

　開発が進むにつれて顕在化してくる課題に対応する場合は，課題自体をストーリとしてイテレーションに組み込んでいく。このときの記述は「ユーザーが○○できる」という形には必ずしもならないため，「＜課題をクリアした状態＞になっている」という記述にする。例えば「ランタイム・エラー発生時にエラー・ダイアログが表示されている」といった形である。「○○の課題に対応する」という，開発者の行為を記述するのではないことに注意したい。ストーリは「行為（～をする）」ではなく「結果（～できる，～になっている）」を記述するものであるという意味だ。

　課題は直接ユーザーに価値を与えることはないものの，その課題を達成しなければユーザーに価値を届けられないケースも多々ある。そのような場合は，課題をこなすストーリの優先度を上げておく。

　各ストーリは，B6や葉書大のカードに記述して管理する（図1[拡大表示]）。これをストーリ・カードと呼ぶ。TRICHORD開発チームでは，「情報カード」として販売されているカードを使用している。メーカーや大きさなどは好みのものを選べばよい。

図1 ストーリ・カードの例
[画像のクリックで拡大表示]

　ストーリの記述にカードを使う理由はいくつかある。一つは，優先度を決めるために並び替えたり，広げて全体を見渡したりする際に便利なことだ。こうした情報は，Excelの表などに記述して管理するのが一般的だろう。しかし，表形式は一覧するには便利だが，自由度があるようで無い。そのため，優先順位をつけたり，補足事項を記述したりするには扱いにくい。カードなら手で並び変えたり，余白に書き込んだりするだけで済む。また，カードをそのまま壁に張っておくことで「何をすべきか」の見える化を実現できるのも便利だ。

　気をつけてほしいのは，ストーリ・カードには最低限の情報しか記述しないように心がける点である。カードには，あくまで実現したいことだけを記録しておくようにする。詳細は実際にストーリをタスクに分割する際に明かにすればよいからだ。物理的なサイズに制限があるカードを使うことで，この点が自然に守られるのもカードを使うメリットと言える。

ストーリのサイズを見積もる

　ストーリを抽出する段階で，個々のストーリに対して見積もりを実施する。これには様々なやり方がある。一般に，見積もりは「月」や「日」のような時間の単位を使って見積もることが多いだろう。しかし，TRICHORDチームでは「ストーリ・サイズ」と呼ぶ単位で見積もりをしている。「ストーリ・サイズ」は時間と直接関係のない，「ストーリの規模がどのくらいか」を表現する値である。

　ストーリ・サイズの見積もりには「相対見積もり」と呼ぶ手法を採用した。相対見積もりは，基準となるストーリに対して，ほかのストーリがどれくらい“大きい”かを相対的に見積もる手法だ。「ストーリAのサイズを1とした場合，ストーリBのサイズはどれくらい？」といった具合である。

　この手法の効用は，数多くの部屋がある家を掃除するのに要する時間を見積もる場合を考えると分かりやすい（図2[拡大表示]）。各部屋は，広さや調度品の数などが異なるとする。このようなケースでは，一つひとつの部屋について個別に見積もっていくのは大変だ。それよりも，基準となる部屋を細かく見積もり，残りの部屋は「基準となる部屋と比べてどのくらい？」という考え方をしたほうが何倍も早く見積もることができる。

図2 相対見積もりによる部屋の掃除時間の見積もり
基準となる部屋（A）を細かく見積もり，残りの部屋はその部屋の何倍くらい時間がかかりそうかを考えることで，数多くの部屋の掃除時間を素早く見積もることができる。
[画像のクリックで拡大表示]

　相対見積もりを推奨している書籍「Agile Estimating And Planning」（Mike Cohn著，Prentice Hall発行）では，フィボナッチ数列で見積もると経験上うまくいくと述べている。つまり，1，2，3，5，8，13，...のいずれかにするということになる。この意図は，サイズをあまり正確に見積もろうとすると時間がかかってしまうため，誤差は無視して，決まった数値で収めてしまおうというものだ。

　5，8，13，...と値の間隔が徐々に増えているのは，サイズが大きくなるに従って見積もりが不正確になることを意味している。言い換えれば，サイズが大きいときはより具体的に開発者がイメージできるサイズにストーリを分割してから見積もるのが望ましい。TRICHORDの場合，当初はストーリ・サイズとして8以上は明かに大きいとみなし，分割できないか検討するようにしていた。現在は5以上も分割検討の対象にしている。

　ストーリ・サイズによる相対見積もりは，見積もりを素早く大量に実施して規模を知ることができるという特徴がある。タイム・ボックスに収まるかどうかを見極めるには大変有用な手法と言える。見積もりはあくまでも見積もりであって，正確さを求めて時間をかけすぎてはいけない。見積もりに時間をかけるよりも，頻繁なフィードバックやチームの学習によって精度を上げていくという思想に基づいているのだ。