「今回こそ予定どおり」を卒業する。過去案件の実績で納期の約束を点検する方法

「今回は要件が明確です」「今回は経験者を入れます」。計画会議で説明を聞くと、前の遅延は繰り返さないように思える。しかし、要件確認、外部接続、利用部門の受入れまで含めると、今回も終了日は後ろへずれる。作業を積み上げた見積もりには、なぜこうしたずれが残るのだろうか。

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

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

作業の説明が詳しくても、予測が正確とは限らない

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

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

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

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

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

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

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

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

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

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

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

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

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

期限が固定なら、確率の低さを根性で埋めない

仮に、同じ条件で終わった過去案件が十件あり、四週間以内に完了したのは三件だったとする。今回も四週間と約束するなら、過去と何が違うのかを確かめる必要がある。ただし十件は小さな集団であり、「今回の成功確率は30％」と断定するための例ではない。

完了期間を並べると、最短だけでなく、どのあたりへ集中し、どこまで長引いたかが見える。予定する日付がその分布のどこにあるかを示せば、経営は早い約束に伴うリスクを読みやすくなる。

発売日が動かせないなら、全機能の納期をその日に押し込む以外の案を出す。必要な機能を絞る、既存手段を一部残す、段階的に顧客へ提供する。その際、外した機能がなければ事業目的を果たせないなら、範囲削減で解決したふりはできない。

計画上の目標と、外部へ約束する日付を区別することも大切だ。目標は挑戦的でよい場合があるが、そのまま確実な予測として取引先へ伝えると、別の会社の人員や販売計画まで巻き込む。数字の用途を明記することが責任ある見積もりにつながる。

今回だけ速くなると、何を根拠に言えるか

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

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

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

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

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

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

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

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

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