撤退を決めた後の会議が「誰の判断が甘かったのか」から始まる組織では、次の案件の撤退申告はさらに遅れます。振り返りの場が評価の場を兼ねている限り、担当者にとって最も安全な行動は、悪い数値を出さないことだからです。

本記事では、撤退した案件の振り返り（ポストモーテム）を、責任追及ではなく次の判断材料を作る手続きとして設計する方法を示します。撤退の判断そのものを評価にどう接続するかは赤字プロジェクトの継続理由と評価制度で扱っているため、ここでは撤退が決まった後の運営に絞ります。

責任追及型の振り返りが、次の撤退を遅らせる

撤退の振り返りには、目的の異なる2つの型があります。両者は同じ「反省会」という名前で呼ばれますが、組織に残るものが違います。

評価項目責任追及型の事後評価学習型のポストモーテム
主な目的判断を誤った人物の特定前提が外れた経路の特定
記述の対象担当者の能力・判断意思決定の手続きと情報の流れ
失敗の扱い人事評価の減点材料次の起案で参照する記録
次の撤退申告が遅れる基準に沿って申告される
報告の精度悪い数値が上がらなくなる悪い数値が早く上がる

最下段が要点です。振り返りが追及の場になると、担当者は撤退時点だけでなく、進行中の報告から数値を丸め始めます。振り返りの設計は、過去の1件をどう総括するかの問題ではなく、進行中の全案件の報告精度に影響する問題です。

追及が起きている組織の兆候

  • 中止の理由が「市場環境の変化」など外部要因だけで記述されている
  • 中止された案件の資料が共有フォルダから消えている、または閲覧制限がかかっている
  • 撤退条件の数値が、判定の直前に書き換えられている
  • 縮小や方針転換の提案が、意欲の不足と受け取られる
  • 「様子見」という結論の会議が繰り返されている

1つでも当てはまる場合、撤退基準を数値化しても機能しません。基準は満たされた時点で報告されて初めて働くためです。

Googleのポストモーテム文化から借りられる4つの原則

システム障害の分野では、非難のない事後検証の実務が公開されています。Google の『Site Reliability Engineering』の Postmortem Culture の章には、事業撤退の振り返りにそのまま転用できる原則が示されています。

1. 全員が、その時点の情報のもとで善意で正しいことをしたと仮定して書く。 同書は「A blamelessly written postmortem assumes that everyone involved in an incident had good intentions and did the right thing with the information they had」と述べ、焦点を「誰が失敗したか」から「なぜ情報が不足していたのか」という仕組みの側へ移すこと、そして「you can’t ‘fix’ people, but you can fix systems」という考え方を示しています。

2. 実施基準は、事が起きる前に決めておく。 同章は「It is important to define postmortem criteria before an incident occurs so that everyone knows when a postmortem is necessary」としています。実施の可否をその都度判断すると、最も記録が必要な案件ほど「今回は特殊だから」と見送られます。

3. レビューされていない記録は、存在しないのと同じ。 同章は「An unreviewed postmortem might as well never have existed」と述べ、草稿を上級の担当者が、影響範囲の評価が網羅されているか、原因の分析が行動計画を立てられる深さに達しているかという観点で確認する運用を挙げています。

4. 書いた記録を、組織の外側まで共有する。 続編の『The Site Reliability Workbook』の同名の章では、ポストモーテムのチェックリストとして、影響評価の完了、行動計画を立てられる深さの原因分析、技術リードによる是正項目の承認、そして組織全体への共有が挙げられています。あわせて、是正項目の完了そのものを評価する、非難的な言葉づかいや是正項目の遅延を形骸化の兆候として監視する、といった運用も示されています。

障害対応の枠組みを、事業撤退へ読み替える

そのまま持ち込むと合わない部分があります。対応表として整理します。

障害対応事業・案件の撤退読み替えの要点
発生から復旧までの時系列起案から撤退決定までの判断の時系列記録するのは作業ではなく、判断とその根拠
影響範囲（停止時間・利用者数）投じた資金・人員と、拘束された期間金額だけでなく人員の拘束期間を必ず書く
根本原因崩れた前提と、それが判明した時点「見通しが甘かった」で止めず、どの数値でいつ分かったかまで下ろす
再発防止策次の起案から変える手続き・様式心構えではなく、書式・決裁経路の変更として書く
実施基準撤退・中止・大幅な縮小の決定金額や期間の下限を決め、該当したら自動的に実施

読み替えで最も重要なのは3行目です。「市場の読みが甘かった」という記述は、次の起案で使えません。どの前提が、どの数値で、いつ崩れたのかまで書いて初めて、次に同じ前提を置いたときの検知が早くなります。

実施の手順

開始前に決めること。 振り返りを実施する条件（例：一定額以上の投資を伴う案件の中止、または計画の半分以下での縮小）、書式、記録の保管場所、参加者の範囲。これらを案件の承認時に決め、承認文書に含めます。

撤退の決定から2週間以内に着手する。 担当者が異動したり、資料が整理されたりする前に記録します。着手が遅れるほど、記録は「結論の後付け」になります。

草稿は案件の担当チームが書く。 第三者が書くと、判断の前提が抜け落ちます。書く範囲は次の3点に限定します。

  1. 判断の前提：起案時に何を正しいと仮定していたか（市場規模、獲得単価、必要工数など、数値で書けるもの）
  2. 実際に起きたこと：どの前提が、いつ、どの数値で崩れたか。その時点で誰が何を知っていたか
  3. 次に変える手続き：起案書の様式、判定の時期、報告の頻度など、変更する対象と担当者と期限

レビューは、内容の是非ではなく記述の質を見る。 判断が正しかったかを再審議する場にすると、追及の場に戻ります。確認するのは、影響が網羅されているか、原因が手続きの水準まで下りているか、是正項目に担当者と期限が付いているかの3点です。

共有は、関与していない部署まで届ける。 記録は、次に似た前提を置く人が読んで初めて価値が出ます。案件名で検索できる場所に置き、四半期ごとに新しい記録を一覧で回覧する程度の運用で十分です。

形骸化の兆候

導入した後に確認すべき点は限られます。

  • 非難的な言葉が残っている。 「認識が甘かった」「連携不足」といった評価語は、手続きの記述に置き換えます。
  • 是正項目が閉じていない。 期限を過ぎた是正項目が積み上がっている状態は、記録が読まれていない証拠です。件数を四半期ごとに確認します。
  • 同じ前提の崩れが繰り返されている。 過去の記録に同じ原因があるのに再発している場合、共有の経路が機能していません。
  • 実施率が下がっている。 条件に該当したのに実施されなかった案件を数えます。ゼロでなければ、条件か運用のどちらかを直します。

まとめ

撤退の振り返りは、過去を総括する儀式ではなく、次の案件の報告精度を決める設計です。

  1. 実施条件・書式・共有先を、案件の開始前に決める
  2. 記述の対象を、個人の判断から手続きと情報の流れへ移す
  3. 「どの前提が、いつ、どの数値で崩れたか」まで下ろす
  4. 是正項目に担当者と期限を付け、完了まで追う
  5. 関与していない部署まで共有する

撤退の判断そのものからサンクコストを外す手続きはサンクコスト効果で撤退できない組織の構造と対策に、事業ポートフォリオ全体での位置づけは事業ポートフォリオ最適化と戦略的撤退の意思決定にまとめています。