「アジャイルな見積りと計画づくり」から、個人的にためになった部分
やすとも計画の目的
見積もりや計画づくりの本質
期日・スケジュールを決定するためだけといったように消極的な理由だけで見積もりを行うわけではない。とりわけソフトウェアのにおける計画づくりとは、価値の探究。つまり「何を作るべきか？」ということを継続的に繰り返し探る試みが計画づくり。
とはいえ、この問いには急に答えられない。よって、今ある情報で出した答えをできるだけゴールに近づけること(インクリメンタルに)。そしてそれを繰り返す(イテレーティブに)ことが大切。
よい計画とは何なのか
よい計画とは、ステークホルダーが信頼して、意思決定ができる計画である。
なにを持って「信頼ができる」かは、状況によって異なる。プロジェクト初期であれば、第二四半期には無理だが、第三四半期には可能といったレベルの荒いものでよいかもしれないが、プロジェクト後期になると、もっと正確な情報を出す必要がある。
また、良い計画づくりとは、以下のような特徴をもったプロセスのことを指す。
- ①リスクを軽減する
- ② 不確実性を減らす
- ③ 意思決定を支援する
- ④ 信頼を確立する
- ⑤ 情報を伝達する
①リスクを軽減する
事前に計画づくりをすることで、プロジェクトを進める上でのリスクを発見できることがある。リスクがあまりにも高い場合は、プロジェクトを中止にするかもしれないし、早い段階でリスクに気づき、重点的にリスクを取り払えば許容範囲内なリスクとして扱えるかもしれない。どちらにしても、リスクの早期発見は、プロジェクトの成功確立を上げてくれる。
②不確実性を減らす
プロジェクトを進めていく上で、チームが生み出すのは、新しいプロダクトのフィーチャーだけではない。新しい知識を手に入れられる。さらに触れているプロダクトについても知れるし、触れている技術や、自分たちについてまでももっとよく知ることができる。
計画づくりは繰り返し行われるものなので、このような新しく手に入れた知識を使ってより洗練された計画づくり、ひいてはプロダクトのあるべき姿までアップデートすることが可能。
逆に、プロジェクト開始時に定義したゴール状態をそのまま達成することは(アジャイルの文脈では）、プロジェクトの成功とは呼べない。筆者によると、「最初に定義した要求よりも良いアイデアを、最後まで誰も思いつかなかった」プロジェクトは失敗である。プロジェクトの途中で思いついたアイデアが、最初の計画に入っていなかったという理由だけで却下されるようでは、決してユーザーに満足してもらえるようなプロダクトを作ることは難しい。
③意思決定を支援する
プロジェクトはトレードオフの意思決定の連続である。その意思決定をするためには、適切な見積もりと計画があって初めて可能になる。どんなプロジェクトでも開発期間とコストのトレードオフを判断している。
④信頼を確立する
約束通りのフィーチャを安定して(期日通りに)、頻繁にリリースできることは、顧客との間に信頼関係が生まれる。また、見積もりが正確にできるようになると、開発者自身にもメリットがある。自身の仕事を持続可能なペースで行うことができるようになるからだ。見積もりが不安定だと、期日に間に合わせるため無理をして稼働することもあるかもしれない。さらに、持続可能なペースで仕事を続けられると結果として、コードの品質があがり、バグも少なくすることも可能。
⑤情報を伝達する
計画とは、期待と可能性を伝達するためのもの。計画に描くものはプロジェクトがたどる可能性のある道筋であり、計画から寸分違わないコスト、期日、品質で提供することを約束するものではない。計画は、プロジェクトに対する期待を共有するための基盤(情報材料)として使用されるべきで、本来は単なるリリース日だけに落とし込まれるだけの情報ではない(が、そのようなケースが非常に多い)。リリース日という単一の情報だけに注目してしまうと、その計画を立てる際に考慮したさまざまな前提や期待が崩れてしまう。
アジャイルな計画づくりとは
計画とは、プロジェクトの一部分のスナップショットであり、あくまで図表やドキュメントのこと。しかし、計画づくりとは、活動のことである。アジャイルな計画づくりにおいて重視するのは、計画づくりのアウトプットとして生まれた計画ではなく、その計画づくりの過程の方である。
アジャイルな計画づくりにおいて、計画は積極的に変更することをよしとする。なぜなら、変更があったということは、プロジェクトの途中で何か学びがあったことを意味するからである。想定よりもボリュームの大きい開発であったり、想定よりもユーザービリティの考慮が必要であることに気づいたりした際には、素早く計画に変更を反映することが重要である。
しかし、必ずしも計画の変更＝予定日の変更というわけではない。フィーチャーの優先順位を落としたり、実装範囲を狭めたり、人員を増やすなどをすれば予定日を動かさずにすることは可能である。
アジャイルな計画づくりでは、プロジェクトの着手段階ですべてを計画することは無理というスタンス。よって、着手段階ですべて予想して計画するのではなく、プロジェクトの全期間で計画づくりを分散させることが大切。
やすともなぜ計画が失敗するのか
作業で計画を立てるから
従来の計画づくりではフィーチャでなく作業の計画していた。
作業を基準に計画を立てると、計画が遅延しがち。その理由は3つ
- ①作業は早く終わらない
- ②スケジュールの遅れは先の予定に伝播する
- ③作業は独立していない
①作業は早く終わらない
そもそも人間は、作業完了までの時間(期限)を与えられると、例えその仕事が与えられた時間いっぱいかからないようなものでも、時間いっぱい使って終わらせてしまう生き物。
②スケジュールの遅れは先の予定に伝播する
作業を基準にして計画を行うと、計画全体が作業間の依存関係を重視したものになる。
以下のような例があった場合、タスクA, B, Cの1つでも計画通り進まなかった場合に、タスクDの開始が遅れてしまう。
- タスクA
- タスクB(タスクAの完了が必要)
- タスクC
- タスクD (タスクBとタスクCの完了が必要)
③作業は独立していない
ソフトウェア開発の作業は独立していないパターンが多い。似たような作業があるタスクの場合、ある作業が予定よりも長くかかったら、他の似たような作業も同様に予定よりも長くかかる可能性が高いということを気づくべき。
優先順位順に開発していないから
従来型のプロジェクトの進め方では、フィーチャは最初に計画したすべてのものを実装する前提になっている。これでは、プロジェクトを進める当事者にとって都合の良い順番で実装が行われる。つまり、顧客にとってはデタラメな順序で進められることも多い。
そして、プロジェクトの納期が迫ってくると、なんとしても納期に間に合わせるために、フィーチャを削らねばならないことも多くなる。削るフィーチャの中には、顧客にとって大事なフィーチャが含まれてしまうことも起こり得る。
見積もりがコミットメントになっているから
見積もりとは、あくまで見積もった時間内に完了する確立のこと。
従来型の計画づくりの問題点は、見積もった数字をステークホルダーやプロジェクト関係者にコミットメントとして捉えられてしまうこと。見積もりは確立であるが、コミットメントは確立ではない。コミットメントは日付で表される。そしてその日付は通常その日に完了する確立が100%に満たない日付に決定されることが多い。そのような日付に対してコミットメントするためには、チームはさまざまなビジネス上の要素やリスクを考慮する必要があり、チームにはその機会が与えられるべき。絶対にいかなる見積もりも暗黙のコミットメントになってはいけない。
やすとも規模を見積もる
アジャイルチームでは、見積もりを行う際に、「規模」によって見積もりを行う。
「規模」の考え方は、「ストーリーポイント」と「理想日」の2種類存在する。(筆者はストーリーポイントによる見積もりを行う方法を推奨している。)どちらの考え方を採用したとしても、まずは要求されるフィーチャに対して規模を見積もり、そこから期間を算出する。フィーチャに対していきなり「何日かかる実装であるか」という考え方はしない。
ストーリーポイントで規模を見積もる
ストーリーポイントとは、フィーチャ・ユーザーストーリー・その他タスクなどに対してつける相対的な規模を表す数値である。大事なのは、他のタスクに対する相対的な規模を表す数値であること。ストーリーポイントが3であれば、ストーリーポイントが1のタスクの3倍の規模のタスク、ストーリーポイントが8であれば、ストーリーポイントが1のタスクの8倍の規模、ストーリーポイントが4のタスクの2倍の規模をあることを表す。何を持って規模とするかは、ストーリーポイントの割り振り時にはそこまで気にする必要はなく、既にストーリーポイントを算出したタスクと比べてどれほど複雑か、必要な作業量、内在するリスクなどを考慮して割り出せば良い。筆者が推奨している方法として、すべてのタスクを割り出した上で、その中で一番修正規模の小さなものをストーリーポイント1とし、他のタスクのストーリーポイントを算出する方法がある。そして、ストーリーポイントを算出する際にも、できるだけストーリーポイント1~10の間で収まるように、ストーリーポイントを算出する(タスク分解するなりして)方法も推奨している。人間は10倍のものまでならある程度正確に見積もることができるからだ。
ベロシティで期間を算出する
タスクに対してストーリーポイントをつけるだけでは、規模を見積もっただけで、期間までは見積もれていない。ここで、「ベロシティ」という新しいコンセプトが必要になる。ベロシティはチームの進む速度を意味する。例えば、1イテレーションでチームが完了したストーリーポイントの総計が15であれば、そのイテレーションのベロシティは15ポイントということになる。そして、次のイテレーションも稼働日数等諸々の条件が同じであれば、15ポイントのベロシティを期待できるという計算になる。
プロジェクトの中のすべてのタスクのストーリーポイントの総計は、そのプロジェクトの規模の大きさということなり、その総計をベロシティで割れば、そのプロジェクトを完了するのに必要な期間が割り出せる。
ベロシティには、見積もりのミスが起きた時に再見積もりの手間を減らしてくれる効果もある。例えば、最初にストーリーポイント総計が200ポイントのプロジェクトがあったとして、当初の予定では、ベロシティが10ポイント出る想定であった。(つまり、20イテレーションで完了する想定。)しかし、実際に何度かイテレーションを回してみると、ベロシティが8にしかならなかった場合、完了までは少なくとも25イテレーション必要であるという計算がいとも簡単にできるようになる。
ストーリーポイントで見積もる具体的な方法論
やりすぎな見積もりはしない
大原則として筆者は、アジャイルチームは、見積もりを過度にやりすぎてはいけないというスタンスをとっている。見積もりはやればやるほど精度が高くなるというわけではなく、一定以上のコストをかけすぎると、コストに見合うような精度にはならないもの。最低限のコスト(時間)をかけ、できる限り大きな精度を出すという意識が大切。もちろんプロジェクトのフェーズによって求められる見積もりも違うため、フェーズによってかけるコストには注意をする必要がある。求められていないタイミングで正確に見積もりを出そうとして、コストをかけすぎても問題(そして、このようなタイミングでは見積もりの精度も思ったように上がらないはず)である。
大事なのは、 見積もりを正確に出そうとしすぎて多大なコストをかけても、労力に合った正確さは得られない。見積もりはどれだけコストをかけても(徐々に完璧には近づくかもしれないが、)完璧にはならない。 ということである
見積もりは一人で行わない
本来アジャイルチームにおいて、見積もりは一人で行うことを推奨していない。理由は、アジャイルなプロジェクトでは、誰がどの作業をするのか事前に決まっていないことが多いからだ。その作業に関与する可能性のある全員が見積もりに参加するべきという考え方である。また、誰か独断で見積もりを決めてしまうと、その見積もりに対して、意見を出しにくくなってしまう。見積もりを出す際に必要な意見な意見は取り込んだほうが良いはずである。
ストーリーポイントで使用する数値
筆者はストーリーポイントの数字を使用する上で下記２つの数列を紹介している。いずれの方法も、(上述したようにできるだけ)10以下の数字に収まるように推奨している。
- ① フィボナッチ数列 (1, 2, 3, 5, 8)
- ② 前の数値の倍数を使用した数列 (1, 2, 4, 8)
ストーリーポイントの数値が増えるほど、不確実性が大きくなるという見積もりの実態にも合っていることからもこれらの数値は扱いやすいと筆者は指摘している。
また、場合によってはストーリーポイントの数値に0を使用することも推奨している。イテレーションを進めていく中で、極めて小さい修正をする可能性も出てくる。極めて小さい修正でもポイントを1にしてしまうと、修正を行ったイテレーションのベロシティが不用意に上がってしまい、次移行のイテレーションでのベロシティに影響が出てしまうからである。そのような場合には、ポイントを0を使用することを推奨している。
さらに、筆者はストーリーポイントを割り振る時の考え方として、「ストーリーポイントは土を入れるためのバケツ」として考えると良いとしている。例えば、ストーリーポイントの数値として、フィボナッチ数列を使用するとする。そして、5よりは少しだけ大きいが、8には満たないといいった(体感6くらいの)もののポイント付けを行う際には、5をつけることを推奨している。バケツに土を入れる場合、少しくらい溢れても、バケツからこぼれ落ちることは無いからだ。一方で、7程度のストーリーポイントで考えた場合は、ストーリーポイントは8として考えることを推奨している。5のバケツに、7の砂は入らないはずだからである。
また、筆者はこれらの数値をチームで議論する際にはプランニングポーカーを推奨している。
やすとも再見積もりのタイミング
再見積もりしてはいけないケース
例として、ストーリーポイントが1のユーザーストーリーが50個あると考える。
「イテレーション開始時にベロシティが10を出せる想定(イテレーションの中で10個のストーリを消化予定)であったが、タスクに着手してみると想定より進捗が無く、ベロシティが5しか出なかった(5つのストーリしか消化できなかった)」場合はよくあるケースだ。この場合、「着手したフィーチャは、想定の2倍の規模があった」と考えて、5つのユーザーストーリのストーリーポイントを2倍してしまうことがある。これにより、ストーリーポイントを2倍したことによってチームの期待するベロシティは満たせたことになる。
しかし、残りのユーザーストーリーが消化したユーザーストーリーと複雑度の認識が変わっていないのなら、消化したユーザーストーリーと同じように、残りのユーザーストーリーのストーリーポイントも2倍にする必要がある。なぜなら、ストーリーポイントの考え方は、「タスクの相対的な大きさ」だからである。思うように進捗しなっかったからといって、ストーリーポイントを変更しても、結局すべてのストーリーポイントを消化できる予定日は、2倍する前と2倍する後で変わらない。
大切なのは、すべて正しく見積もることではなく、つけたポイントどうしの相対関係が一貫していること。
正確でも不正確でも著しく不正確であっても、構わないのである。
再見積もりしても良いケース
再見積もりしても良いケースは簡単で、相対的大きさにずれが生じた場合のみである。ストーリーポイントが1のユーザーストーリーが50個ある上記の例だと、「着手後に想定の2倍のサイズであったことがわかったが、それらのタスクは、残り未着手の他のどのタスクとくらべても独立したものであり、2倍のサイズはありそうだ」と判断したもののみ、2倍として再見積もりしてよいという考え方である。もちろん着手したタスクと似ている作業が発生するタスクが未着手の中にもある場合、それらも再見積を行う対象である。