「前回うまくいった記憶」と「今回への楽観」


「この規模なら、だいたい3ヶ月ですね」

この一言が、後の炎上の起点になる。見積もりは「経験に基づいた自信」であるほど危険だ。なぜなら、その自信の正体は「前回うまくいった記憶」と「今回への楽観」という、2つの認知バイアスの合成物だからだ。

過去プロジェクトの規模をそのまま当てはめ、依存関係を感覚で引き、バッファの出し方に悩み、手法の使い分けを誤り、進捗のポイントを水増しする。見積もりと計画の精度が低いプロジェクトは、どんなに優秀なチームでも最初から崩壊のレールに乗っている。

本稿では、見積もりと計画精度における5つの罠を、行動経済学・認知科学・成功するPMの実践知・AI活用の4軸で徹底解剖する。「なんとなくの見積もり」を「構造化された予測」に変える具体策を提示する。


罠⑥ 「前回と同じ規模」の罠――記憶は最高の教師で、最悪の詐欺師

なぜ起きるのか:「代表性ヒューリスティック」と「コンテキストの無視」

「前回の似たプロジェクトが3ヶ月だったから、今回も3ヶ月」という見積もりは、一見合理的に見える。過去の実績(外部視点)を参照するのは正しいアプローチだ。しかし問題は、「似ている」という判断が表面的な特徴だけで行われる点にある。

行動経済学の「代表性ヒューリスティック(Representativeness Heuristic)」が働く。人間は「似ているものは同じ結果になる」と直感的に判断するが、その「似ている」の根拠は表面的な特徴(機能数・画面数・見た目)にすぎない。実際のプロジェクトの難易度を決めるのは、チームの習熟度・技術の新しさ・ステークホルダーの複雑さ・要件の曖昧さといった「見えないコンテキスト」だ。これらが違えば、同じ規模でも工数は2倍・3倍に変わる。

図1|「同じ規模」に見えても、隠れた難易度要因で工数は激変する

👀 表面的に見える指標(似ている)

画面数:約20画面
機能数:約15機能
チーム人数:5名
見た目の複雑さ:中程度

🔍 見えない難易度要因(実は違う)

チームの技術習熟度(初めての技術か)
要件の確定度(曖昧さの残存)
ステークホルダーの数と対立
既存システムとの連携の複雑さ

左が同じでも、右が違えば工数は倍以上変わる。見積もりで見るべきは「見える指標」より「見えない要因」

具体的な実践策

【「差分リスト」で前回との違いを明文化する】
過去プロジェクトを参照するときは、「似ている点」ではなく「違う点」を意図的に列挙する。「前回と違うのは:①今回は新しいフレームワークを使う②クライアントの決裁者が3人いる③既存の基幹システムと連携が必要」のように差分を明文化し、各差分が工数に与える影響を個別に見積もる。「同じ」の錯覚を「違いの積み上げ」で打ち消す。

【「3点見積もり」で幅を持たせる】
単一の数字(3ヶ月)で見積もるのをやめ、「楽観値・最可能値・悲観値」の3点で見積もる。PERT法の計算式(楽観 + 4×最可能 + 悲観)÷ 6を使えば、リスクを織り込んだ加重平均が得られる。単一見積もりの「自信」は、幅を持った予測に置き換えるべきだ。

【AIによる「見落とし要因」の洗い出し】
今回のプロジェクト概要と過去の類似プロジェクトの情報をAIに入力し、「これら2つのプロジェクトの違いを分析し、今回の見積もりで見落とされがちな難易度要因を列挙してください。それぞれが工数に与える影響も推定してください」とプロンプトを投げる。人間が「似ている」と思い込んでいる部分の、隠れた違いをAIが客観的に浮かび上がらせる。


罠⑦ クリティカルパスを「感覚」で引く問題――どこが本当のボトルネックか

なぜ起きるのか:「依存関係の複雑性」と「線形思考の限界」

クリティカルパス(Critical Path)とは、プロジェクト全体の所要期間を決定する「最も時間のかかる作業の連鎖」だ。この経路上のタスクが1日遅れれば、プロジェクト全体が1日遅れる。逆に言えば、クリティカルパス以外のタスクには「余裕(フロート)」があり、多少遅れても全体に影響しない。

問題は、多くのPMがこのクリティカルパスを「感覚」で引いていることだ。人間の認知は「線形思考」に偏っており、「Aが終わったらB、Bが終わったらC」という一本道の流れは理解できても、複数のタスクが並行し、複雑に依存し合う構造を頭の中で正確に把握することは、認知容量の限界を超える。結果、「実は違うタスクがボトルネックだった」ことに、遅延が起きて初めて気づく。

図2|「目立つタスク」と「本当のボトルネック」は別物

経路A(目立つ・大きく見える作業)

設計 5日

UI実装 8日

テスト 3日

計16日

経路B(地味だが実はクリティカルパス)

外部API調整 10日

連携実装 7日

結合テスト 5日

計22日 ⚠

PMは「大きく見えるUI実装(経路A)」に注意を集中しがちだが、実際に全体を遅らせるのは「地味な外部API調整(経路B)」。ここを見誤ると、UIを急いでも全体は縮まらない。

具体的な実践策

【依存関係を「図」にして頭の外に出す】
すべてのタスクとその依存関係を、頭の中ではなく図(ネットワーク図・ガントチャート)に書き出す。MiroやMermaid、あるいはプロジェクト管理ツールの依存関係機能を使い、「どのタスクがどのタスクの完了を待っているか」を視覚化する。頭の中で処理しきれない複雑性を、視覚化によって外部化する。書き出すことで初めて「本当のボトルネック」が見える。

【クリティカルパス上のタスクに「重点監視」を設定】
クリティカルパスを特定したら、その経路上のタスクを「重点監視タスク」として明示的にマークする。日次または隔日で進捗を確認し、遅延の兆候を早期にキャッチする。逆に、フロート(余裕)のあるタスクには過剰なリソースを割かない。「どこに注意を集中すべきか」を構造的に決める。

【AIによる依存関係の分析とクリティカルパス特定】
タスクリストと各タスクの所要日数・依存関係をAIに入力し、「これらのタスクの依存関係を分析し、クリティカルパス(全体を決定する最長経路)を特定してください。また、リソースを追加投入すれば全体を短縮できるタスクと、短縮しても効果がないタスクを区別してください」とプロンプトを投げる。人間が感覚で見誤りやすいボトルネックを、AIが構造的に計算する。


罠⑧ バッファの「見せ方」と「隠し方」――正直に出すと削られ、隠すと説明できない

なぜ起きるのか:「パーキンソンの法則」と「バッファ削減のゲーム」

見積もりにバッファ(余裕)を入れるのは正しい。しかしバッファを正直に「バッファ」として提示すると、上司やクライアントに「そこは削れるだろう」と削られる。かといってバッファを各タスクに隠し込むと、「パーキンソンの法則(仕事は与えられた時間をすべて使い切るまで膨張する)」により、余裕があるタスクほどダラダラと時間を消費し、結局バッファが機能しない。

さらに、各担当者が自分のタスクに個別にバッファを隠すと、「学生症候群(締め切り直前まで着手しない)」と組み合わさって、バッファは着手の遅れに吸収されてしまう。バッファの管理は、心理と組織政治が絡む、見積もりの中で最も繊細な技術だ。

図3|バッファの持ち方 3方式の比較

方式 やり方 問題点
❌ 各タスクに
隠し込む
全タスクに20%ずつ余裕を上乗せ パーキンソンの法則で全部消費される
△ 正直に
バッファ表示
「バッファ2週間」と明示 「削れる」と判断され真っ先にカット
✅ プロジェクト
バッファに集約
各タスクは最短で見積もり、余裕を末尾に集約 最も合理的。CCPMの手法

推奨は3番目。各タスクの余裕を剥がして「プロジェクト全体のバッファ」として末尾に集約する(クリティカルチェーン法)

具体的な実践策

【「プロジェクトバッファ」への集約(クリティカルチェーン法)】
各タスクは「余裕のない最短見積もり(50%の確率で終わる時間)」で設定し、剥がしたバッファをプロジェクト全体の末尾に「プロジェクトバッファ」として集約する。これにより、個別タスクの遅れは全体のバッファで吸収でき、パーキンソンの法則も回避できる。エリヤフ・ゴールドラットが提唱したクリティカルチェーン・プロジェクトマネジメント(CCPM)の中核的な考え方だ。

【バッファを「消費率」で管理する】
プロジェクトバッファを「残り何%」という形で可視化し、進捗と照らし合わせる。「工程の50%が完了した時点で、バッファを30%しか消費していなければ健全」「工程30%でバッファ60%消費なら危険信号」というように、バッファの消費ペースをKPIとして管理する。バッファを「削られる対象」ではなく「健全性の計測器」として位置付ける。

【AIによるバッファ配分の最適化提案】
各タスクの見積もりとリスク要因をAIに入力し、「各タスクのリスクの高さに応じて、プロジェクトバッファをどう配分・監視すべきか提案してください。特にリスクの高いタスクと、バッファ消費を注視すべきポイントを教えてください」とプロンプトを投げる。リスクの偏りに応じたバッファ設計を、データに基づいて行う。


罠⑨ アジャイルとウォーターフォールの「混在」問題

なぜ起きるのか:「手法の宗教戦争」と「工程特性の無視」

「うちはアジャイルでやる」「いや、ウォーターフォールの方が確実だ」――この議論は、しばしば「手法の宗教戦争」に発展する。しかし成功するPMは、この二項対立の問いそのものが間違っていることを知っている。正しい問いは「どちらの手法を使うか」ではなく、「どの工程に、どちらの手法が適しているか」だ。

認知科学的に言えば、これは「二分法的思考(Dichotomous Thinking)」の罠だ。人間は複雑な選択を「AかBか」の単純な二択に還元したがる。しかし現実のプロジェクトには、要件が固まっていて変更が少ない工程(ウォーターフォール向き)と、探索的で頻繁にフィードバックが必要な工程(アジャイル向き)が混在している。一律にどちらかを適用すると、必ずどこかで無理が生じる。

図4|工程ごとに「向いている手法」は異なる

要件定義・基盤設計
ウォーターフォール向き:一度決めたら大きく変わらない土台。確実に固める

UI・機能開発
アジャイル向き:ユーザーの反応を見ながら反復的に改善する

セキュリティ・法対応
ウォーターフォール向き:抜け漏れが許されない。計画的に網羅する

新機能の検証・改善
アジャイル向き:試して学ぶことが価値。短いサイクルで回す

「プロジェクト全体をどちらにするか」ではなく「各工程に適した手法を割り当てる」ハイブリッド設計が現実解

具体的な実践策

【工程を「確実性」で仕分けてから手法を割り当てる】
プロジェクトの各工程を「要件の確実性が高い(変更が少ない)」か「探索的(変更が多い)」かで仕分ける。確実性が高い工程(基盤設計・セキュリティ・法対応)はウォーターフォール的に計画通り進め、探索的な工程(UI・新機能・ユーザー体験)はアジャイル的に反復する。手法を先に決めるのではなく、工程特性から手法を導く。

【混在の「境界」を明示的に設計する】
ハイブリッド運用の最大の落とし穴は「境界の曖昧さ」だ。ウォーターフォール工程とアジャイル工程の接続点(どこでウォーターフォールの成果物がアジャイルの入力になるか)を明示的に定義する。「基盤設計が完了してからUI開発のスプリントを開始する」といった境界とハンドオフのルールを事前に決める。

【AIによる「工程別手法マッピング」の支援】
プロジェクトの工程一覧と各工程の性質をAIに入力し、「各工程について、要件の確実性・変更頻度・フィードバックの必要性を評価し、ウォーターフォールとアジャイルのどちらが適しているか、その理由とともに提案してください。また手法が切り替わる境界での注意点も教えてください」とプロンプトを投げる。手法選択を「好み」ではなく「工程特性の分析」に基づいて行う。


罠⑩ ベロシティの「水増し」――進捗の数字が信用できなくなる

なぜ起きるのか:「測定対象への最適化」と「見栄えの圧力」

アジャイル開発では「ベロシティ(1スプリントで消化するストーリーポイントの量)」を計測し、計画に使う。しかしこのベロシティが実態より高く報告され続ける問題が頻発する。「今スプリントは40ポイント消化しました」と報告されるが、実際には未完了のタスクを「ほぼ終わり」として計上していたり、ポイントの見積もりが甘くなっていたりする。

行動経済学の「グッドハートの法則(測定基準が目標になると、それは良い測定基準でなくなる)」が働く。ベロシティが「評価される数字」になった瞬間、チームは無意識に「数字を良く見せる」方向に最適化する。悪意はない。「進んでいるように見せたい」という見栄えの圧力が、少しずつ数字を膨らませる。結果、ベロシティに基づく計画が実態から乖離し、「順調なはずなのに終わらない」状態が生まれる。

図5|「報告ベロシティ」と「実質ベロシティ」の乖離が広がる

スプリント1-3
スプリント4-6
スプリント7-9
報告ベロシティ(見かけ上は上昇)

報告上のベロシティは上昇しているように見えるが、「未完了を完了扱い」した分が積み上がり、実質的な完成度は伴っていない。ある時点で「積み残し」が一気に表面化し、計画が破綻する。

具体的な実践策

【「完了の定義(DoD)」を厳格化してポイント計上を客観化】
「ほぼ完了」をポイントに計上できないよう、完了の定義(Definition of Done)を厳格に設定する。「コードレビュー承認済み・テスト通過・ドキュメント更新済み・本番デプロイ可能」の全条件を満たしたものだけをベロシティに計上する。「ほぼ終わり」を「完了」とみなす余地をなくすことで、数字の水増しを構造的に防ぐ。

【ベロシティを「評価指標」にしない】
ベロシティは「計画のための予測ツール」であって「チームの成績表」ではない。ベロシティを個人評価やチーム間比較に使った瞬間、水増しのインセンティブが生まれる。「ベロシティは高ければ良いのではなく、安定して予測可能であることが良い」という文化をチームに浸透させる。グッドハートの法則を回避する最も本質的な対策だ。

【AIによる「ベロシティと実成果の乖離」検知】
スプリントごとのベロシティ報告と、実際の成果物(マージされたPR・クローズされたissue・デプロイ履歴)のデータをAIに照合させ、「報告されたベロシティと実際の完成成果物の間に乖離がないか分析してください。未完了が繰り越されているパターンや、ポイント見積もりが甘くなっている兆候があれば指摘してください」とプロンプトを投げる。報告と実態のズレを、データで早期に発見する。


5つの罠に共通する原則――「主観的な自信」を「構造化された予測」に変える

「前回と同じ」「感覚でこのタスクが重要」「バッファはこれくらい」「うちはアジャイル」「順調に進んでいる」――これら5つの罠に共通するのは、すべて「主観的な自信」に基づいている点だ。

見積もりと計画の失敗は、能力不足ではない。人間の認知が本質的に「複雑性の処理」と「客観的な自己評価」を苦手とすることから生まれる、構造的な問題だ。代表性ヒューリスティック、線形思考、パーキンソンの法則、二分法的思考、グッドハートの法則――これらはすべて、努力や気合いでは克服できない認知の設計上の限界だ。

だからこそ、成功するPMは「自信」に頼らない。差分の明文化、依存関係の視覚化、バッファの集約管理、工程特性による手法選択、完了の定義の厳格化――これらはすべて、主観を構造化されたプロセスに置き換える技術だ。

そしてAIは、この「構造化」を強力に支援する。見落とした難易度要因を洗い出し、複雑な依存関係からクリティカルパスを計算し、バッファ配分を最適化し、工程に適した手法を提案し、報告と実態の乖離を検知する。人間の認知が苦手とする「複雑性の処理」と「客観的評価」こそ、AIが最も力を発揮する領域だ。見積もりと計画のフェーズにAIを組み込むことが、精度を根本から変える。


まとめ:見積もりと計画の5つの罠と打ち手

根本原因(認知バイアス) 今日から始める打ち手 AIの活用法
⑥前回と同じ規模 代表性ヒューリスティック 差分リストの明文化+3点見積もり 見落とした難易度要因を洗い出す
⑦感覚のクリティカルパス 線形思考の限界 依存関係を図にして外部化+重点監視 依存関係を分析しクリティカルパスを特定
⑧バッファの見せ方 パーキンソンの法則・学生症候群 プロジェクトバッファへの集約+消費率管理 リスクに応じたバッファ配分を提案
⑨手法の混在 二分法的思考 工程を確実性で仕分けてから手法を割り当てる 工程別の手法マッピングを支援
⑩ベロシティ水増し グッドハートの法則・見栄えの圧力 DoDの厳格化+ベロシティを評価指標にしない 報告と実成果の乖離を検知

今日から一つだけ始めるとすれば、次の見積もりで「前回と違う点」を3つ書き出すことを勧める。「似ている」という直感を「違いの明文化」で打ち消すだけで、見積もりの精度は大きく変わる。計画の質は才能ではなく、「主観を構造に変える習慣」の積み重ねで決まる。


コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です