多くのプロジェクト計画書には、開始の条件と成功の定義は書かれています。一方で、どうなったら中止するのかという条件はほとんど書かれていません。この欠落があるため、遅延や予算超過が起きたときに議論の論点が「止めるかどうか」ではなく「どう挽回するか」に固定されます。本記事では、計画書に撤退基準を組み込むための具体的な記載項目と、それをキックオフ会議で合意するまでの手順を扱います。

「予定どおり完了」は10年間下がり続けています

日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査2025」は、4,500社を対象に実施され981社から回答を得た調査です。この調査は、システム開発のQCD（品質・コスト・納期）について、2015年度から2024年度までの10年間の推移では、すべてのプロジェクト規模において「予定どおり完了」の割合が低下傾向にあると報告しています。同調査は、2024年度においても改善の兆候は見られないとしています。

同調査では、品質が予定どおりにならなかった要因として「計画時の考慮不足」を挙げた企業が39.1%（2024年度、回答169社）あり、要因の上位に入っています。実行段階の努力ではなく、計画そのものの作り方が結果を左右していることを示す数字です。

計画が実態から離れる理由には、よく知られた認知の傾きがあります。ダニエル・カーネマンとエイモス・トベルスキーが1979年に名付けた「計画錯誤（planning fallacy）」です。米国のSociety for Personality and Social Psychology（SPSP）の解説によれば、人は目の前の仕事に固有の事情へ注意を向ける「内側の視点（inside view）」を取りやすく、過去の経験に基づいて予測する「外側の視点（outside view）」を取ったほうが現実的な見通しになるとされています。計画書が担当者の意気込みで作られると、必ず内側の視点に寄ります。

そしてもう一つ、投じた費用が判断を歪めます。ハル・アークスとキャサリン・ブルーマーが1985年に発表した「The psychology of sunk cost」（Organizational Behavior and Human Decision Processes 35巻1号、124〜140頁）は、金銭・労力・時間を投じた後ほどその取り組みを継続する傾向が強まることを報告しています。同論文は、この行動が「無駄にしたと見られたくない」という動機に支えられていることを示しています。走り出した後に中止条件を決めようとしても遅い理由が、ここにあります。

計画書の3つの欄で、自社の計画の性質が分かります

計画書が意思決定の道具になっているかどうかは、次の3点を見れば判別できます。

項目承認を得るための計画書意思決定のための計画書
稼働率の前提担当者の稼働を100%として割り当てる割込み業務と会議の実績分を差し引いた稼働で割り当てる
見積もりの根拠担当者の感覚と最良のケース過去の類似案件の所要実績（外側の視点）
中止の条件記載なし、または「状況を見て判断」予算・期間・中間成果の数値と、抵触時の扱い

3列目が空欄の計画書は、承認のための資料としては通っても、判断のための資料にはなりません。特に「状況を見て判断」という記載は、判断を将来の自分に押し付ける表現であり、実際には判断されないまま期間が過ぎます。

自社の計画書を1本開いて、次の問いに答えられるか確かめてください。

  • このプロジェクトは、何をどれだけ下回ったら中止と判断しますか。
  • その判断は誰が下しますか。推進の責任者と同じ人ではありませんか。
  • 中止と判断する時点は、いつ来ますか。日付で答えられますか。

計画書に書く4つの項目

1. 見積もりの根拠を、過去の実績に置き換えます

工数と期間の欄には、担当者の見積もりに加えて、過去の類似案件で実際にかかった値を並記します。差が大きい場合、その差を説明できるかを承認の条件にします。説明できない差は、そのまま計画錯誤の分量です。

2. 稼働率の前提を明示します

要員の稼働率を何%で計算したかを計画書に書きます。100%で計算している場合、割込み対応と会議が発生した時点で計画は崩れます。差し引く時間は、過去の実績から出すのが最も争いが少ない方法です。

3. 撤退トリガーを3系統で決めます

数値で書けない条件は運用されません。次の3つを、それぞれ1つずつ決めます。

  • 予算：承認額を一定割合超過した時点で、追加支出を止めて継続可否を判断します。
  • 期間：クリティカルパス上のタスクが一定日数遅延した時点で、同じ判断に入ります。
  • 中間成果：フェーズごとに置いた中間指標が目標を下回った時点で、同じ判断に入ります。

割合や日数は事業の性質で変わりますが、重要なのは水準そのものではなく、計画時に決めて後から動かさないことです。

4. 判断の場と担い手を指定します

トリガーに抵触したときに、誰がどの会議で判断するかを計画書に書きます。推進の責任者が判断者を兼ねる構造では、判断は自己評価になります。段階ごとに予算を刻んで承認する設計は、システム開発を中止できない罠を防ぐ段階的予算承認で扱っています。全社の事業単位で同じ考え方を使う場合は、経営戦略に撤退基準を組み込む方法を参照してください。

キックオフ会議は、撤退基準を合意する場です

キックオフ会議を士気を高める場として設計すると、悪い前提の話ができなくなります。開始前は、まだ誰も費用を投じていないため、最も冷静に中止の条件を話せる時点です。議題には次の3つを入れます。

  1. 成功の定義：何がどうなれば完了と判断するかを、数値で読み上げます。
  2. 撤退トリガーの読み合わせ：3系統の数値を関係者全員が同じ場で確認します。
  3. 判断の日付：ゲートを置く日をカレンダーに入れ、その日に判断者が出席することを合意します。

会議の記録には、合意した数値と判断の日付を残します。後から「そんな基準は聞いていない」という反論が出る余地をなくすためです。

運用でつまずく3つの箇所

抵触した後にトリガーを書き換える。 予算を20%超過した時点で判断すると決めたのに、超過した月に30%へ引き上げる運用は、基準が無い状態と同じです。変更する場合は、個別案件の議題とは別に扱います。

判断の日付を置かない。 「超過したら判断する」とだけ書くと、超過の認定自体が先送りされます。ゲートの日付をあらかじめ入れておくと、その日に数字を出さざるを得なくなります。

中止を担当者の失敗として扱う。 基準に沿った停止を評価上の失点にすると、次からは数字が遅れて上がってきます。基準どおりに止めたことを、計画どおりの運用として記録する扱いが必要です。

計画書に撤退基準を書くことは、プロジェクトを疑うことではありません。走り出した後に冷静さを失うことを前提に、判断の材料を先に固定しておく作業です。次に計画書を承認するとき、中止の条件が書かれた欄があるかどうかを最初に見てください。