【連載1】「前提が全く違います」完璧な計画が死んだ日。東京湾アクアラインに学ぶ、想定外のリスクをねじ伏せるPM術
予期せぬトラブルで、完璧な計画が「死に体」になる瞬間
プロジェクトが中盤に差し掛かったある日、
現場から信じられない報告が飛び込んでくる。
「事前の調査データと前提が全く違います」
「このまま進めばシステム全体が崩壊します」
入念にWBS（作業分解構成図）を引き、
ステークホルダーの根回しを終え、予算も確保した。
まさにこれから走り出すという時に発覚する「想定外の致命的トラブル」。
経営陣からは
「なんとか期日通りに進めろ」
とプレッシャーをかけられ、
現場のチームは
「物理的に不可能です」
と疲弊していく。
板挟みになったリーダーのあなたは、
プロジェクトが音を立てて頓挫していくのをただ見つめるしかない——。
新規事業やシステム開発において、
誰もが一度は直面する絶望的な瞬間です。
東京湾アクアライン：「マヨネーズ」と「異常水圧」という自然の猛威
この「想定外の絶望」を、
国家規模のメガプロジェクトで味わったチームがあります。
東京湾アクアラインの開発チームです。
川崎と木更津を結ぶ全長約15kmの海底トンネル計画。
彼らが海底の掘削を進める中で直面したのは、
事前の地質調査の想定を遥かに超える「マヨネーズ層」と呼ばれる
超軟弱地盤でした。
巨大なシールドマシン（掘削機）が少しでもバランスを崩せば、
自重でズブズブと海底深くへ沈み込んでしまうほどの泥沼です。
さらに、水深60mの海底には異常な高水圧が押し寄せ、
一歩間違えればトンネル内に海水が激しく噴出し、
作業員の命すら奪いかねない極限状態でした。
莫大な国家予算と絶対的な工期。
後戻りは許されない中で、足元はマヨネーズのように崩れ、
頭上からは圧倒的な水圧が迫る。
まさにプロジェクトマネジメントの観点から言えば
「完全な詰み」の状況でした。
絶望的な状況を打破する「攻め」と「守り」の設計
この絶望的な状況を、
当時のリーダーや技術者たちはどう乗り越えたのでしょうか？
精神論で突撃したわけではありません。
彼らは極めて高度な「リスクマネジメントの型」を持っていました。
この史実から導き出された
「未知のリスクを克服する技術的アプローチ」と、
「致命傷を避ける撤退基準の設計」について解説します。
明日のあなたの仕事、特に炎上しかけているプロジェクトを立て直すための
具体的なPMフレームワークとしてお持ち帰りください。
しかし、「撤退基準」を頭で理解していても、いざという時に経営陣からの
「ここまで予算を使ったんだから」
というプレッシャー（サンクコストの呪縛）に押し切られ、
チームが壊滅するケースは後を絶ちません。
今回は、上層部を確実に納得させ、現場の命を守り抜くための
「絶対的な撤退基準（フェイルセーフ）の設計書」と、
未知のリスクを飼い慣らす具体的なステップを公開します。
史実の突破口：地盤改良と絶対的な安全基準
アクアラインのチームは、この未知の脅威に対し
「技術の組み合わせ」と「厳格なルール」で立ち向かいました。
マヨネーズ状の軟弱地盤に対しては、
海底の泥に特殊な硬化材を注入し、
地盤そのものをカチカチに固める「深層混合処理工法」などの
地盤改良技術を駆使しました。
足元が緩いなら、巨大なマシンが進めるように
「自分たちで人工的に強固な地盤を作り出す」
というアプローチをとったのです。
同時に、異常水圧に対しては
「もし出水量が規定値を超えたら、
直ちに隔壁を閉鎖して無条件で撤退する」
という厳格な基準（フェイルセーフ）を設けました。
撤退のボーダーラインを明確に引いたからこそ、
現場はパニックに呑まれず、ギリギリまで掘削作業に集中できたのです。
現代ビジネスへの応用：未知のリスクを飼い慣らすフレームワーク
この史実を、現代のIT開発や新規事業のプロジェクトに抽象化してみましょう。
1. 未知のリスクへの技術的アプローチ（地盤改良フェーズ）
システム開発において「連携予定だった既存システムの仕様が
完全にブラックボックス（＝マヨネーズ地盤）」だと発覚した際、
そのまま強行突破してはいけません。
まずは本番開発の手を止め、
「技術的PoC（概念実証）」を実施してください。
影響範囲を小さく切り出し、
プロトタイプで仮説を検証し、
見えないリスクを「見える課題」へと固める（＝地盤改良する）
プロセスを最優先で組み込むのです。
足元が固まっていない状態での前進は、
確実にプロジェクトを沈没させます。
2. 致命傷を避ける撤退基準の設計（フェイルセーフ）
プロジェクトが迷走する最大の原因は、
「サンクコスト（埋没費用）の呪縛」です。
「ここまで予算と時間を使ったから」
とズルズル続けると致命傷を負います。
アクアラインの出水基準と同様に、
「エラー率が〇%を超えたら一度ロールバックする」
「〇月末までにテストユーザーのCVRが〇%を下回ったら、
追加機能の実装をストップする」
という『撤退・停止の定量基準』を、リスクの高いフェーズへ
突入する前にステークホルダーと合意しておくこと。
【すぐ使える：統合変更管理対応型の撤退基準・合意テンプレート】
未知のフェーズに入る前、
ステークホルダーと以下の3点を文書化して
合意（ベースライン化）してください。
・トリガー（監視指標）：
例）API連携先の未定義仕様の発覚
・閾値（限界点）：
例）追加の調査・開発工数が、確保した予備費（バッファ）の
20%を消化した時点
・即時アクション（エスカレーションルール）：
例）現場の判断で開発を即時停止。正式な変更要求を発行し、
ステークホルダー会議にて「予算追加」「スコープ削減」
「プロジェクト中止」のいずれかを再決議する。
これが、リーダーとチームの命を守る最大の盾となります。
まとめ：プロジェクトを前進させるのは「勇気」ではなく「設計」です
想定外のトラブルに直面したとき、
必要なのは気合や根性ではありません。
未知を既知に変える技術的アプローチと、
最悪の事態をコントロールする撤退の設計です。
あなたの目の前にある「マヨネーズ地盤」も、
正しい手順を踏めば必ず強固な道に変わります。
焦らず、まずは「足元を固めること」、
そして「撤退ラインを引くこと」から始めてみませんか。
今回の記事が、
あなたの困難なプロジェクトを前進させるヒントになれば幸いです。
この事例が役立つと感じたら、ぜひ「スキ」とフォローをお願いします。
次回も、歴史と実務が交差するリアルなPMの知見をお届けします！
