プロジェクトの納期をどう見積もる？ 過去実績と今回の条件を比べる

今回は六週間で終える。そう約束する前に、似た案件が実際に何週かかったかを並べてみます。過去の平均へ合わせれば正解というわけでも、経験者を入れる予定だけで短くできるわけでもない。十案件の仮の実績から、比較の範囲、今回の改善、兼務や試験の待ちを考えます。

一つの理由は、これからどう進めるかという筋書きに比べ、似た仕事が実際にどう終わったかを弱く扱うことだ。ただし、過去の平均を持ってくれば正解になるわけでもない。比較する案件の条件が違えば、その数字も判断を誤らせる。

本稿の提案は、同じ開始・完了条件を持つ過去案件の実績を、積上げ見積もりと並べることである。今回が実績より速いとするなら、違いを具体的な証拠で説明する。説明できなければ、約束する範囲、日付、体制のいずれかを選び直す。

六週間の約束を、過去十案件と比べる

方法を示すため、範囲と稼働条件がそろった10案件の完了週数を、3、4、4、5、5、6、6、8、9、12週と仮定する。平均は6.2週、中央値は5.5週。6週以内に終わったのは7件、8週以内は8件だ。「平均6.2週なので6週間で終える」と約束すると、元の標本でも3件が間に合っていない。

この7／10や8／10は、仮定した標本内の割合であり、次の案件の納期達成確率ではない。案件が独立で同じ条件から来たか、打ち切り案件を除いていないか、範囲変更をどう扱ったかで意味が変わる。少数の過去案件から、細かい確率まで確定したように書かない。

今回の期限が6週なら、12週の案件を「例外」として捨てる前に、その遅れが外部承認、兼務、追加範囲のどれで起きたかを見る。今回も残る条件なら比較へ含め、今回に存在しない条件なら除外理由を残す。工程改善を主張する場合は、改善した工程の時間だけを置き換え、審査や顧客の返答待ちまで短くなったことにしない。

「同じような案件」を、都合よく選ばない

英国政府の楽観バイアスに関する補足指針は、費用、便益、期間の見積もりへ、過去や類似案件のデータを使い、今回の固有条件を踏まえた調整を行う考え方を示す。公共投資の評価指針であり、掲載された補正を日本の開発案件へそのまま適用する根拠ではない。GOV.UK「Green Book supplementary guidance: optimism bias」

これを使う前に決めたいのは、比較集団の条件だ。画面数が近くても、社内だけで完結する変更と、外部企業の接続試験が必要な変更は違う。実装終了までを数える案件と、利用部門の受入れまでを数える案件も、同じ期間として混ぜられない。

まず開始と完了をそろえる。開始は企画承認なのか開発着手なのか。完了はコード完成なのか、実運用を引き渡した時点なのか。そのうえで依存先、変更規模、利用部門の数、検証の機会など、時間に効きそうな条件を記録する。

速く終わった案件だけを「よく似ている」と選ぶなら、過去実績を使っても楽観は残る。反対に、例外的に長かった案件だけで全件を見積もれば、必要以上に遅い計画になる。選んだ理由と除外した理由を、結果を見る前に定める姿勢が重要になる。

今回変わった条件と、残る待ちを確かめる

過去には接続試験の待ちが長かったが、今回は試験環境と担当者を確保し、実際の接続も一度成功したとする。この変化は、待ちを短く見積もる材料になる。過去の中央値をそのまま使う必要はない。

反対に、「新しい道具を使う予定」「ベテランが助言する予定」だけで、実作業や待ちがどれくらい変わるか未確認なら、過去より短い約束の根拠としては弱い。小さな試行で速度と手直しを確かめ、確認できた部分だけ調整する案が妥当になる。

さらに、今回だけ外部認証が増えたなら、過去より遅くなる理由も同じ表に載せる。改善要因だけを足し、悪化要因を注記へ追いやると、実績を使っても結論は楽観へ戻る。上にも下にも動かす見積もりにしたい。

余裕時間の二重計上にも気を付けたい。過去の経過日数に通常の確認待ちが含まれるのに、同じ待ち時間を別枠で足せば、その理由だけで見積もりが長くなる。過去に含まれていない今回固有の待ちなら、追加する理由がある。これは一律に余裕を削る提案ではなく、何の不確実性をどこで見込んだかを追えるようにする整理である。

担当者へ短い数字を要求する代わりに、経営側も条件を引き受ける。専任化で短縮するなら他業務を誰へ移すのか、範囲を絞るなら何を後回しにするのかを決める。条件を変えずに数字だけ合意しても、実行可能性を高めたことにはならない。

共通の待ちと、同じ資源を取り合う待ちを分ける

GAOのSchedule Assessment Guide・事例8（印刷57頁）は、米国の国境監視計画で、担当者が専任になると仮定した工程表に対し、実際には契約担当者などを複数事業で共有し、一部の工程が遅れた例を報告する。同じ人を各案件で「使える」と置くだけでは、同時に仕事を進められるとは限らない。これは公的事業の監査事例であり、日本の開発案件の遅延日数を推定する材料ではない。

仕組みを分けるための仮定を置く。二つの実装A・Bが同時に始まり、Aは4営業日、Bは6営業日で完成する。両方が完成した後に共通の試験枠まで3営業日待ち、まとめて1営業日で試験するなら、最短の経過日数は長い方の6＋3＋1＝10営業日だ。共通待ちをA・Bそれぞれの余裕として、6＋3＋3＋1＝13日と足すのは、同じ待ちの二重計上になる。

ところが、同じ設備でA・Bを順番に1日ずつ試験する必要があり、両方の完成後にしか試験を始めない条件なら、6＋3＋1＋1＝11営業日になる。後者の追加1日は二重計上ではなく、設備の占有による順番待ちだ。設備をもう一つ確保する案、先に完成したAから試す案、二つを一括で試せる設計へ変える案では、変える前提が違う。いずれも不具合・休日・再試験を含まない仮想計算で、約束できる納期ではない。

また、同じ接続先の仕様変更が両方の実装を遅らせる場合は、遅れを独立に扱えない。同指針の相関の説明（印刷115～117頁）は、共通の要因が複数工程を一緒に長くする関係を扱う。共通待ちを一度だけ置くことは、全工程のリスクを一度だけ足せばよいという意味ではない。作業の前後関係、設備の利用順、共通要因が及ぶ工程を確かめてから、必要な余裕を見積もる。関係も所要時間も未確認なら、この例の10日や11日を借りず、まず試験枠と担当者の利用条件を確定する。

工数と経過日数を、同じ欄に入れない

開発に必要な作業が十人日でも、十営業日で終わるとは限らない。担当者が一日に使える時間、他の案件、外部の確認待ちによって経過日数は変わる。以下の数字は説明用の仮定であり、標準工数ではない。

例えば実装に十人日かかり、担当者は別業務と半分ずつ兼務しているなら、実装だけでも単純には二十営業日を要する。さらに接続試験の予約が翌月なら、実装を早めただけでは利用開始日は同じかもしれない。

この場合、見積もりを短くする案は、実装の作業量を減らすことだけではない。担当者の専任時間を確保する、接続試験を先に予約する、外部接続を含まない範囲で先に利用する、といった選択肢がある。ただし、それぞれ何を犠牲にするかを示す。

過去案件のデータにも、実作業と待ちを分けて残したい。平均期間に余裕を足すだけでは、遅れを縮めるために何を変えればよいかが分からない。実績は約束を長くするためだけでなく、改善できる制約を探す材料でもある。

詳しい計画でも、今回の期間は別に検証する

Buehler、Griffin、Rossの1994年の研究は、学生の学業や日常の課題などを通じ、完了までの時間を過小に予測する傾向を検討した。予定の進行へ注目し、関連する過去の経験を十分に使わないことが論点になっている。カナダの大学を中心とする研究で、日本のシステム開発の遅延率を測ったものではない。Exploring the “Planning Fallacy”・原論文・大学サイト掲載PDF

この研究を「人間は必ず楽観する」と読むのは強すぎる。同じ論文には、他者の所要時間を見積もる側が逆に長く予測した結果もある。第三者を呼べば正確になる、厳しい数字へ変えればよい、という単純な解決策ではない。

実務で重要なのは、計画の説明と予測の検証を分けることだ。作業一覧は、何をするかを明らかにする。その一覧から出た期間が妥当かは、実績や今回の制約を使って別に確かめる。手順を細かく書いたこと自体を、納期の裏付けにしない。

期限が動かせないとき、何を選び直すか

期限が固定なら、先に見た過去実績と今回変えられる条件を比べる。小さな標本内の割合を今回の成功確率とせず、範囲を絞る・既存手段を残す・段階提供する案を出す。外した機能なしでは事業目的を果たせないなら、範囲削減で解決したとは扱わない。挑戦する目標と、外部の人員や販売計画を動かす約束の日付を区別する。

見積もりの改善は、外れ方を残すところから

見積もった後に遅れが見え、増員を検討する場面は別の判断です。プロジェクトの遅れと増員の記事では、追加する人の時間だけでなく、引き継ぎや連携の負担も含めて考えています。

Homes Englandの2024年の研究報告は、類似案件の実績を用いる参照クラス予測を、費用の楽観バイアスや予備費の検討に使っている。住宅・土地関連の投資を背景とする費用分析で、ソフトウェアの完了期間を直接推定した研究ではない。Optimism Bias and Contingency at Homes England

本稿では特定の補正率を借りず、案件を集めて見積もりと実績を比較するという設計を参照する。完了後は、いつの見積もりだったか、途中の追加範囲、待ち時間、変更した前提を残す。最新の修正版だけを保存すれば、当初の予測がどこで外れたかを検証できなくなる。

少数の案件しかない組織なら、立派な確率曲線を作るより、一件ずつ違いを説明できる表から始められる。過去より速いと約束するなら、速くなる仕組みを確かめる。確かめられないなら日付・範囲・体制を変える。 それが、見積もりを願望の表明から、実行条件を選ぶ判断へ変える。