見積もりの基礎知識と「ストーリーポイント vs 理想日」の考察

昨年の10月頃から締め切りのある大きなプロジェクトに参加し、部分的にではありますがプロジェクトマネジメントを担当しました。この記事では、その業務を通して得た見積もりに関する知見をまとめます。教科書的な知識は「アジャイルな見積もりと計画づくり」に依りますので、詳しくはそちらをご参照ください。

見積もりの基礎知識

見積もりは、提供したい機能をどれくらいの期間で実装できるかを予想し、計画について議論をするために行います。見積もりを行うことによって、全くアタリがつかない状態から、「プロジェクトのフェーズがこの辺りなので、平均で N 週間、最悪で 2N 週間くらいかかる可能性があります」などと答えられるようになります。さらに、プロジェクトのフェーズが進んで不確実性が減少すれば「平均で M 週間、最悪で M+1 週間くらいかかります」と答えを正確にできるかもしれません。まさにこれが「アジャイルな計画づくり」です。

見積もりのベストプラクティスは「期間ではなく規模を見積もること」であると言われています。ある機能があったときに、直接「2週間くらいかかります」と答えるかわりに、機能の大きさを表す数字（ポイント）を答えるのです（例えば「5くらいです」と）。この数字は相対的な値です。どういうことか理解するために、試しに4つほどタスクを見積もってみましょう。世界で最初の機能A は、比較対象がないので、ひとまず「2」という適当な値を与えておきます。次の機能B は、Aと似ていますが、Aに比べると倍ぐらいの画面が必要そうです。よって倍の「4」を与えます。次の機能Cは、Aよりは大変そうですが、Bよりは簡単そうです。間の数字である「3」を与えましょう。最後の機能Dは、Aと同じような機能です。Aと同じ「2」を与えましょう。‥‥このくらいやれば、お分かりいただけたのではないでしょうか。ある機能の見積もりは、過去に見積もった機能と比較した相対的な大きさによって決めるのです。

このように規模の見積もりを行った状態で1ヶ月ほど開発を進めれば、チームが単位期間（例えば1週間）あたりに完了できるポイント数を予想できます。これをベロシティと呼びます。あとは簡単で、提供したい機能の総ポイント数をベロシティで割ると、プロジェクトの完了にどのくらいの期間が必要か予想することができます。規模の見積もりを期間の見積もりに変換することができました。

なぜこんな回りくどいことをするのでしょうか。いくつか理由はあります。ひとつは、期間の見積もりをベロシティという実績値から導出することで、見積もりのミスが自動的に補正されるメリットがあります。実際にかかる期間がわからなくても、機能の相対的な規模さえ正しく認識できていれば、自動的に信頼できる期間の見積もりを得られるのが優れたポイントです。もうひとつ理由をあげるなら「期間の見積もりは人によって違う」からです。「〇〇さんがやるとしたら1週間ですね」「□□さんがやるなら2週間ですね」といった意見が乱立してしまっては、話をまとめることができません。仮にある人にアサインする想定で期間の見積もりを与えたとして、実際に着手するときにその人の手が空いているとも限りません。その度に見積もりが更新され、全体のスケジュールも目まぐるしく前後するようでは、経営陣や顧客からの信頼も損なうでしょう。規模の見積もりは、そうした人による差を吸収し、機能の相対的な大きさとチームとしての生産力にフォーカスした議論を可能にします。

ストーリーポイント vs 理想日

規模の見積もりに使う代表的な単位として、ストーリーポイントと理想日というものがあります。ストーリーポイントは、まさに前の節で「2」とか「4」とか言っていた、機能の規模を表す相対的な値のことです。「ストーリー」は「ユーザーストーリー」から来ています。一方、理想日は「その機能の開発だけに取り組んだとしてかかる日数」のことです。純粋な規模の見積もりではありませんが、説明・導入のしやすさから使われることがあります。

「アジャイルな見積もりと計画」8章によれば、理想日には次のようなデメリットがあるとされています。

議論が職能別の詳細に入り込んでしまいチームとしての働き方を阻害する
メンバーの能力が向上するにつれて見積もりが変化し、ベロシティが信頼できなくなる
理想日を現実時間と比べてしまって規模の見積もりができない
具体的な作業による見積もりになり、見積もり自体に時間がかかる傾向がある
人によって理想日は違う

逆にいえば、ストーリーポイントは以上の問題を解決します。理論の上ではストーリーポイントのほうが望ましいのは明らかでしょう。そのようにする具体的なメリットがあります。

しかし、現実問題として、チームメンバー全員にストーリーポイントという概念を導入するにはかなりの慣れやリーダーシップが必要とされるように感じます。単に説明するだけなら理想日のほうが格段に簡単です。そこで私が提起したいのは、仮に理想日のデメリットを低コストでコントロールできたとしたら、そちらのほうが良い場合もあるのではないか、ということです。実際、私が参加したプロジェクトでは見積もりの単位として理想日を用いましたが、上で述べたようなデメリットを感じることはなく、スケジュールを議論する材料としてプロジェクトの終盤まで活躍してくれました。以下では、理想日が機能した事例を掘り下げることで、見積もりと計画に関する考察を深めようと思います。

理想日が機能した事例

私がプロジェクトマネジメントを担当したのは、とあるプロジェクトのWebアプリケーション開発セクションです。プロジェクトのために一気に人が集められ、エンジニアはそのセクションだけで最大8人稼働、しかも社内で採用事例の少ないモダンな技術スタックで開発を進める、というかなり挑戦的なセッティングでした。プロジェクトの序盤に、全タスクの洗い出しと見積もりを行うことになり、その際、見積もりの値として理想日を用いることにしました。ストーリーポイントを使うかどうかを議論しましたが、チームへの導入のしやすさから、理想日を導入することになりました。すぐにエンジニアを集めて「このタスクだけをするとしたら何日かかるか、フィボナッチ数列で出してください」というふうに見積もり会を行いました。この会はスムーズに進行し、結局プロジェクト終盤まで同じ見積もりの仕組みが機能しました。

ここからは理想日見積もりのデメリットをひとつずつ見ていき、いかにしてそれをかいくぐったかを紹介します。

議論が職能別の詳細に入り込んでしまいチームとしての働き方を阻害する
- これはそもそも、プログラマ、DBアーキテクト、テスター、デバッガーなどといったようにロールが細分化されていることを前提とした議論で、今回のチームにはあてはまりませんでした。全員がDBからフロントエンドまで一気通貫で作業する前提で議論をしたので、問題になりませんでした
メンバーの能力が向上するにつれて見積もりが変化し、ベロシティが信頼できなくなる
- これを感じる場面は、わずかですがありました。しかし、以下の2点によって最後まで安定したベロシティを得ることができたと感じます
  - 大部分の見積もりはプロジェクト序盤の見積もり会で一気に終わらせた
  - その後の追加タスクについては、理想日が相対ポイントであることを知っているメンバーが中心になって見積もりを行っていた。実際「このタスクは前に見積もった〇〇とほとんど同じなので2理想日は少ないと思います」といったように軌道修正をする場面があった
理想日を現実時間と比べてしまって規模の見積もりができない
- これは上で述べたとおり、理想日が相対ポイントであることを知っているメンバーが軌道修正することで、かなり終盤まで秩序を保つことができました
具体的な作業による見積もりになり時間がかかる傾向がある
- これについては、実際に具体的な作業に関する議論になることがあり、時間がかかったのは事実だと思います。しかし、プロジェクトのフェーズ的に、全員が具体的な作業をイメージできるくらいタスクを掘り下げて知識を展開することにもメリットはあり、始めからある程度は具体的な議論をするつもりでした。理想日だから時間がかかった、そしてそれが悪かった、という印象は全くありませんでした
人によって理想日は違う
- これは、以下のような要因によって問題にならなかったと感じています。
  - 最初の見積もり会にエンジニアが10人近く参加しており平均化が容易であった
  - 社内で例の少ない技術スタックを採用したこと、また新規参加のエンジニアが多かったことで、スタート時点の能力のバラツキが抑えられていた

以上をまとめると、理想日を相対ポイントとして運用する明確な力が働いていたこと、期間に対する認識を平均化しやすい状態で大部分の見積もりを行ったこと、この2点が、理想日を機能させた大きな要因であったと思います。特に前者については、見積もりのベストプラクティスを理解していたからこそできたことで、仮にストーリーポイントを採用しないにしても、知識として知っておく価値のある概念だと感じます。

どちらを採用するべきか

今回の事例から考えると、最初から全ての要件が明らかになっているウォータフォール的な開発や、チームメンバーの能力が平均化される大規模な開発では、理想日のデメリットが少なく、ストーリーポイントを頑張って導入するよりも理想日を運用でコントロールする方が簡単というケースがあるかもしれません。一方で、技術力に差がある少人数チームや、アジャイルな開発での理想日見積もりは難しそうです。3人で見積もりをしたとして、あるタスクについて「1日」「3日」「5日」というようにバラけ続けたり、時期によって感覚が変わっていくのをまとめるのは大変そうです。ストーリーポイントのような、より相対感のある指標を使うことによって、議論を「見積もり済みのタスクと比べてどうか」という方向に導けるとしたら、そちらを導入するメリットはあるように感じます。どちらにせよ、最も重要なのは「期間ではなく規模を見積もる」ことで、それを簡単に実現できる仕組みを、チームの状況や自分のスキルにあわせて設計していくことが良い計画を作る近道なのではないかというのが、この半年の経験に基づく自分なりの結論です。