ソフトウェア開発の “見積り” と “計画” を混同するから話が噛み合わない
“見積り” を作成した開発チームと、それを確認したビジネス担当者や経営者が、その内容を巡って対立することがあります。「見積りが大き過ぎる」「いや、これぐらいはかかりますよ」といったあのやり取りです。
これはおそらく、両者がともに “見積り” と “計画” を区別せず、混同しているから発生しています。見積り依頼を受けた時、開発チームが提出するものは、おそらく “見積り” です。しかし、ビジネス担当者や経営者が期待するアウトプットは “計画” なのです。
こうして “見積り依頼” という名のもとに、ソフトウェア組織に対立が日々生じているのではないでしょうか。
“見積り” と “計画” は別物
見積り結果の「30人月」という数字（①）は、計画ではなく見積り工数です。そんなことは当たり前ですよね。
それでは、30人月の開発を5人でこなすから「6か月」かかる（②）、というのはどうでしょうか。これもまだ見積り？
さらに開始日と終了日も加え、「5月1日に開始」して6か月後の「10月31日に終了」する（③）、と言えば、計画っぽくなってきます。
これでも不十分なら、ガントチャートを描くことでクリティカルパスを明らかにしたらどうでしょうか？で、「5月1日に開始」して7か月後の「11月30日に終了」する（④）、と伝えたなら、益々、計画っぽさが醸し出されます。
しかし、おそらくこれら①から④までのいずれも、見積もり依頼者の期待するアウトプットにはなり得ません。
①から④までの結果は、要求を実現するために必要な労力や規模、期間を見積っただけに過ぎないのです。
もちろん、期日ばかりを気にして、コストやリスク、体制、諸々が欠けていると言えばそのとおりです。しかし、本記事ではそれが揃っていないことが「計画として不十分」であると言いたいわけではありません。
見積り依頼者からすると、「9月にリリースしたい」のに、「10月や11月にリリースできる」と言われても困るのです。あるいは、「1,000万円の予算におさめたい」のに、「2,000万円のコストを要する」と言われても同様に困る。見積もり依頼者は、9月にリリースするための計画や、1,000万円の予算に収まる計画を期待しているからです。
こういったズレが生じると、「エンジニアはビジネスを理解しない」とか、「ビジネス担当者は現実を分かっていない」といった対立が起こり始めます。両者ともに、“見積り” と “計画” を混同していると、このような悲劇に見舞われることになるのです。
※①から③のようなアウトプットは、“人” と “月” を交換する文化を生みます（人月の神話）
※④のようなガントチャートを描いても、プロジェクトは大抵、その通りに進みません
計画は “ターゲット” を見据える、そして見積りは “プレーン” に
計画は、“ターゲット” を見据えてつくるものです。
ターゲットとは、「12月のクリスマス商戦に向けて、この新機能をリリースする」とか、「法改正対応バージョンを施行までにリリースする」や、「予算の範囲内で業務システムを構築する」といったものです。ソフトウェアプロジェクトを立ち上げるうえでのビジネス上の目標や制約だと言えるでしょう。
つまり、ターゲットが明らかでなければ、計画を作ることができないのです。計画づくりの前に、開発チームと関係者の間で、十分に認識を合わせておく必要があります。
逆に、見積りにターゲットはありません。見積りは、要求の実現に必要な労力や規模を算定するものです。
それゆえに、見積りを歪ませるバイアスは可能な限り排除しなければなりません。見積り結果は、“プレーン” であるべきです。
もし、見積りを計画と混同してしまうと、算出された工数や理想時間、ストーリーポイントは、ターゲットの影響を受けてしまうでしょう。予算や期日にあわせるように過小に見積ってしまうかもしれません。逆に、リスクに過敏になって、過剰なバッファを追加してしまうかもしれません。
こうして作られたプレーンな見積りと、ターゲットを比較することではじめて、その差分に基づいて適切な計画づくりが進められるのです。
プレーンな見積りと、ターゲットの “ギャップ” に基づいて計画を立てる
計画づくりは、見積りとターゲットの “ギャップ” を解決する活動です。見積り結果として算出されたコストや開発期間などが、ターゲットの範囲内に収まらない可能性があるからです。
ターゲットに対してネガティブなギャップがあるなら、トレードオフの発動です。QCDS（Quality, Cost, Delivery, Scope）といったパラメータのうち、ターゲットの重視するものを考慮して調整し、計画に落とし込みます。
とは言え、ギャップが大きすぎるなら、ターゲットを見直すことも視野に、関係者と話し合うことになるでしょう。トレードオフだけでは調整しきれないからです。開発に「1年を要する」ものを「2週間で作りあげる」ことはできませんからね。
計画には “バッファ” を組み込みます。100パーセント正確な見積りなど作れないのだから、それに基づく計画も完全にはなりません。だから、計画には幅を持たせる必要があるのです。それがバッファです。
バッファには、時間に対するものもあれば、スコープに対するものもあります。前者をスケジュールバッファ、後者をフィーチャバッファと呼びます。コストに対してバッファを設けることもできるかもしれません。どのタイプのバッファを用いるかは、ターゲットに応じて決定することになるでしょう。
アジャイルプロジェクトは計画づくりを繰り返す
アジャイルプロジェクトでは、イテレーションが終了するたびに計画を見直します。それまでの実績に基づいて、プロジェクトの着地点の予測を立て直すのです。
プロジェクトの初期は、不確実性が高く、それ故に見積りの正確性や精度も低くなるからです。プロジェクト開始前は8回のイテレーションで終了する計画であったとしても、最終的には10回分を消費するかもしれません。実際にプロジェクトを開始してみると、予想より手こずることだってあります。
これは、不確実性コーンからも明らかです。初期の見積りのばらつきは、大きくて4倍、小さくて0.25倍、全体で16倍の差があると言われています。これが、プロジェクトの不確実性です。そしてこの不確実性は、プロジェクトが進むにつれて収束していきます。
また、アジャイルなプロジェクトは、「変化」を前提としています。変化を受け入れたなら、見積りやターゲットが変わります。そうすると、計画が変わるのは必然です。
さらに、プロジェクト初期には分からなかったことが、少しずつ明らかになることで、計画が変わることだってあります。不確実性が削減され、予測可能性が高まるのです。
アジャイルはプロジェクトの計画性やコントロールを放棄しているわけではなく、現状に常に適応しているのです。
イテレーションごとに、それまでの実績を踏まえて予測を立てれば、早い段階で正確な着地点を知ることができます。残ポイント（残工数）を、実績に基づいて算出し直したチームのベロシティで割れば、あと何回のイテレーションが必要であるかが分かります。これをバーンダウンチャートなどで可視化しておくのです。
アウトプットではなく “アウトカム” や “インパクト” をターゲットにする
ここまでで述べた ターゲットとは、あくまでもプロジェクトによる “アウトプット” に対するものですが、“アウトカム” や “インパクト” をターゲットにすることもできます。特に、自社プロダクトの内製プロジェクトでは、この観点が求められます。
新しいプロダクトや機能をリリースすることは、あくまでもアウトプットです。それが、期待した通りのユーザー価値やビジネス価値を生み出すとは限りません。むしろ、期待を下回ることの方が多いでしょう。時には、今ある価値を毀損してしまうことだってあり得ます。
アウトカムやインパクトとは、アウトプットによって得られるユーザー価値やビジネス価値のことです。こちらのほうが、ターゲット、すなわち “ビジネス目標” として相応しいでしょう。「第3四半期中にユーザー数を20%増やす」といったものです。
こうしたターゲットを採用すると、アウトプットは、アウトカムやインパクトを得る “施策” としてとらえることができます。施策は、想定通りの結果を生むこともあれば、そうでないこともあります。したがって、その計画は、目標とするアウトカムやインパクトを得るまで、様々な施策を繰り返す枠組みとなるでしょう。
アウトカムやインパクトをターゲットとする計画と、アウトプットをターゲットとする計画は、排他的なものではありません。前者はプロダクトやサービスのロードマップレベルの計画として描きます。後者はその施策となる “開発計画” として用いるのが良いでしょう。
参考文献
スティーブ マコネル (著), 溝口 真理子 (翻訳), 田沢 恵 (翻訳), "ソフトウェア見積り 人月の暗黙知を解き明かす", 日経BP, 2006
マイク コーン (著), 安井 力 (翻訳), 角谷 信太郎 (翻訳), "アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~", 毎日コミュニケーションズ, 2009