炎上プロジェクトのサンクコストに抗い、現場を軟着陸させる技術『インターステラー』

致命的なバグを隠したまま、プロジェクトは発進する

老教授のブランドが死の間際に放った告白。人類を救う計画の根幹である重力方程式は、最初から解けていませんでした。彼は致命的なバグを隠したまま、国家規模のプロジェクトを立ち上げていたのです。
私はこの場面を見るたび、胃の奥が焼き付くような痛みに襲われます。この「致命的なバグ」を抱えて走り出す様子が、私が30代の頃にプロジェクトマネージャーとして携わった、泥沼の社内システム開発現場と重なるからです。

堅牢なシステムを築くための要件と、隠れていた罠

法人向けの受注から課金請求（O2C：Order-to-Cash）を担うシステム開発では、1円の狂いも許されません。品質を確実に担保するために仕様書を精緻に作り、緻密な設計図に落とし込む。このウォーターフォール型の手順は、プロジェクトを成功させるための正攻法でした。大規模システムの実績が豊富なITコンサルのRFP回答を信じることも、間違っていなかったと思います。
当時、私がシステムに求めていた要件は以下のものでした。

• 業務を止めない「可用性」と「信頼性」
  パフォーマンスの維持、メンテナンス性の担保、障害対策、災害対策

• 事業の成長や変化に対応する「適合性」
  データの一元管理、他システム連携、権限管理、証跡管理、法令対応

当時は仕様書通りに機能要件を満たすこと、「スペック至上主義」の先に、プロジェクトの成功があると信じて疑いませんでした。
そして、この手順の先に大きな落とし穴が潜んでいました。

ベンダーを評価する能力を持たない絶望

ブランド教授が数式を解けていなかったこと自体が絶望だとは思いません。本当の絶望は、その方程式をレビューする工程や、正しさを見抜く能力がなかったことです。
発注元である私もまた、ITコンサルのRFP回答の裏にある「ベンダーの実質的な開発能力」を評価する基準を持っていませんでした。
当時、私がベンダーに求めていた要件は以下のものでした。

• 自社の目的適合性と実現性
  過去の類似案件の実績や経験をもとに、自社の要件を形にできるか

• 信頼性・継続性と運用・保守力
  企業体力や開発体制から、長期的なパートナーとなり得るか

しかし、当時の私に決定的に足りなかったのは、開発中の進捗のうち「要件の充足度」をどう評価し、客観的に判断するかという視点でした。
どれほど実績のあるベンダーでも、開発途中の成果物がこちらの意図した要件を満たしているかを検証するケイパビリティが発注側に欠落していれば、プロジェクトは机上の空論のままです。

深夜2時に鳴り響くアラートとその理由

発注元の評価能力が不足したまま進んだプロジェクトは、テスト工程で致命的なエラーを連発しました。
私はベンダーと裁判沙汰になるようなミスの全てを踏み抜いたと思います、どれも言い訳の立たない過失でした。

• 要件定義が膠着した状態でバッファを消化し、見切り発車して実運用との整合を追う工程を失った

• 多重下請けの構造の中で、システムを跨ぐユーザーのユニークキー欠損の構造把握が漏れた

• 商慣習に基づく現場の要望をコントロールできずに仕様変更を繰り返し、正常系が破綻した

• 遅延の焦りから新旧システムの並行稼働テストを簡略化し、明細の行ズレを見過ごした

• データ移行の設計と計算を誤り、バッチ処理がシステム全体をスタックさせ切り戻しに24時間以上を要した

プロジェクトが破綻した理由は、現場の業務プロセスにシステムが耐えられるかを評価する能力が、仕組みも含めて発注元になかったことです。
プロジェクトが終結した後も、しばらくは寝ていてもアラート音が鳴ったように感じ夜中に起きてしまうほどトラウマになりました。

現場放棄するか軟着陸させるか

ブランド教授の嘘が見抜けず、燃料も時間も底を突きかけたあの絶望的な宇宙船の操縦席に、もし今の私が放り込まれたらどう動くでしょうか。
話しが違うと訴訟をしても、目の前の未完成なシステムは1ミリも動きません。現場のリーダーが果たすべき役割は、崩壊した計画の中で、どうやってプロジェクトを強引に着陸させるかという泥臭い生存戦略だけです。

ここから先は、私が25年の現場経験で何度も失敗を重ねながら身に付けた、実行論の話をします。契約書や仕様書の裏にあるリスクを回避し、炎上したプロジェクトを力技で着陸させるための、具体的な判断基準です。
誰かが決めた計画通りにいかず、開発現場で孤軍奮闘しているあなたにだけ、届いてほしいと思います。

PMの判断が職場の時間を溶かしてしまう

「水の惑星」で、アメリアは先遣隊のデータ回収に固執し、宇宙船の離陸タイミングを逃しました。わずか1時間が地球の7年に相当する極限状態で、彼らは23年という時間を一瞬で失います。
炎上プロジェクトの中で迷走していた私は、一旦プロジェクト立ち上げ当初に立ち返ろうと考え、元の仕様書のスコープから何を削れるかの調整を始めました。
しかし、モグラ叩きのようなBugfixが終わらない現実を前に、疲弊しきった現場でその調整を続けることは、システム障害のリスクを高め、プロジェクトの時間と費用を浪費するだけの致命傷になります。
ガントチャートの進捗率とバッファの消化率を注視し、サンクコストへの未練タラタラで、何とか計画通りに進めようと足掻いている場合ではありませんでした。

イチからではなく、ゼロから考える

当初の成功基準通りに完了したものはゼロです。品質（Q）を最優先にして業務の継続性を死守した結果、コスト（C）と納期（D）は当初の計画から大幅に超過しました。
しかし、QCDすべてを完璧に満たそうとすれば、開発は完全にスタックし、ベンダーとの泥沼の訴訟に突入していたはずです。
ベンダーは、私たちのビジネスまでは守ってくれません。私がやるべきだったのは、元の仕様書からスコープを「削る」ことではなく、明日も事業を運営し続けるためのミニマムをゼロから再設計し、開発途中の状態と照らし合わせて、最速でプロジェクトを終わらせる妥当なラインを引き直すことでした。

炎上プロジェクトを軟着陸させるためのチェックリスト

完璧なシステムリリースを諦め、炎上プロジェクトを終結させるための、具体的な判断基準を共有します。
無理なスコープ調整でプロジェクトを焼失させないために、明日あなたの職場でこの状況を確認してください。

• サンクコストへの未練を断つ
  元の仕様書から機能を「削る」妥協ではなく、運用に必要な最小要件（ミニマム）をゼロから再設計しているか

• 最速の終結ルートの策定
  再設計したミニマム要件と「現在の開発途中のデータ」を照らし合わせ、最短で検収できるスコープを引き直しているか

• システム化を諦める逃げ道の確保
  システム障害リスクを回避するため、エラー時は「手運用での相殺・伝票取消」で翌営業日までにリカバーする合意を事業側と直接握れているか

不完全なままで飛び出す覚悟を、あなたは持っているか

どれほど精緻に作り込んだ仕様書や設計図があっても、費用と時間が尽きればシステムは市場に出ることなく死にます。未完成の重力方程式を抱えたまま宇宙へ飛び出したクーパーのように、私たちは不完全なシステムを抱えて現場を走るしかありません。
現場の業務を止めないために、あなたは今、何を捨てる覚悟を持っていますか。

もし、この思考の跡があなたの「武器」や「盾」の一助となったなら、「スキ」をいただけると幸いです。
画面の向こうに、同じ景色を見ている誰かがいる。それだけで、明日もまた現場に立てる気がします。