撤退＝失敗 をやめる：KPIが品質を壊すとき
この記事に出てくる「テラ」は 大人になってから（25歳前後） の想定です。
KPIのせいで“変な意思決定”が増えて困っているケースを、テラの会話でほどきます。
サマリー（テラから先に結論）
テラ「先に要点だけ置きますね」
- 「止められない」の根は、欠陥ではなく 評価軸（KPI）が作る行動設計 であることが多い
- 撤退＝失敗 は、リスク情報（品質シグナル）を隠す方向に働く
- 完了率を捨てずに意味を変える：撤退＝品質検知（改善の入口） として扱う
- いきなり全社変更は難しいので、2週間のパイロットで“数字として勝つ”形に落とす
1. 完了率は上がっているのに、現場がしんどい
テラ「“完了率は良い。納期も守っている。なのに現場が疲弊している。”
この状態、テストの問題に見えるんですけど……だいたい テストの外 で起きてます」
テラ「僕がよく見るのは、こういう構造です」
- 完了率を守るほど評価が上がる
- 途中撤退（中断・延期）が増えるほど評価が下がる
- だから、リスクが見えても止めない（止められない）
現場「止めたいんですけど、止めた瞬間に“失敗”って扱いになって…」
テラ「うん。止めるのが“正しい/正しくない”の前に、損する設計になってる」
テラ「“止められない”の原因が、技術じゃなく 評価軸 にあるやつです」
2. KPIは「テストコントロールの入力」になる
テラ「KPIって、ただの数字に見えるんですけど……実際は 意思決定の入力なんですよ」
- テストモニタリング（monitoring）：状況を測る
- テストコントロール（control）：測った情報で意思決定を調整する
- リスク（risk）：欠陥の発生確率 × 影響（損失）
テラ「ここでKPIが悪いと、“良くない行動”が自然に強化されます」
KPIは“現場の行動設計”そのもの。
テストコントロールを壊すKPIは、品質を壊します。
現場「でも、完了率って大事ですよね？」
テラ「大事です。だから 捨てない。捨てずに意味を変えます」
3. 「撤退＝失敗」が生む、典型的な悪循環
テラ「撤退が“失敗”扱いになると、現場は自然にこう動きます」
- 撤退しないために“軽い問題”として扱う（隠す）
- 問題を抱えたまま出す（リスク受容）
- 結果、障害や割り込みが増える
- さらに次の完了率が苦しくなる
現場「言いづらいけど…止めたら怒られるから、出しちゃう」
テラ「うん。“怒られる”が原因じゃなくて、怒られる構造が原因です」
図の案（因果ループ）
- 撤退＝失敗 → 隠蔽 → 高リスク出荷 → 障害/割り込み増 → テスト省略 → 炎上 → さらに撤退を隠す
テラ「根性論では止まりません。
評価軸が、正しい行動を罰しているからです」
4. 完了率を捨てずに、意味を変える（撤退＝品質検知）
テラ「ここがポイントです。完了率を否定すると、反発されやすい。
だから 完了率は保持します」
テラ「代わりに、撤退を罰するのをやめて、**品質検知（改善の入口）**として扱う」
4.1 まず、撤退を“品質シグナル”に定義する
テラ「撤退（中断・延期・止める判断）は、現場の肌感では“負け”に見える。
でも、リスクベースで見ると 検知 です」
- 撤退＝「不確実性が高い」ことを検知した
- 撤退＝「影響が大きい」兆候を検知した
- 撤退＝「コントロールが必要」な局面を検知した
テラ「つまり撤退は、品質を守るための情報です」
4.2 KPIの“書き換え”例
テラ「いきなり複雑にしません。置き換えやすいところから」
- 完了率（Completion Rate）は保持する
- 追加で、次の“検知系KPI”を置く（例）
検知系KPI（例）
- 品質検知率：撤退判断が「停止条件に合致」していた割合
- 撤退の再発率（再訪率）：同じ理由で止まっている割合（恒久対策できていないシグナル）
- 欠陥流出（Defect leakage）：出荷後に見つかった重大インシデント比率（最終指標）
テラ「言い換えると、こうです」
「撤退が増えた＝失敗」ではなく、
「撤退が“正しく検知できている”＝品質コントロールが効いている」へ。
5. 「正しさ」ではなく「損失を減らす」話として通す
テラ「上層に通すとき、理想論で殴らない。損失で話します」
- 障害対応の割り込み（工数）
- 顧客影響（解約・CSコスト・信頼低下）
- リリース速度の低下（見かけの速度ではなく将来速度）
上層「撤退が増えると、契約更新に響くんだよ」
テラ「はい。だから“撤退を隠す”ほうが、もっと響きます」
例の言い回し
- 「完了率で炎上したら、更新（契約）はもっと飛びます」
- 「撤退は失敗じゃなくて、品質検知です。隠すほど損します」
- 「これは正しさの話ではなく、損失を減らす話です」
6. 2週間パイロット：上層がYesと言える“最小設計”
テラ「いきなり全社KPI変更は無理です。
だから 2週間 で “数字として勝つ” パイロットに落とします」
6.1 パイロットのスコープ（最小）
- 対象：1チーム or 1導線 or 1イベント（範囲は小さく）
- 期間：2週間（短く）
- 目的：撤退の扱いを変えることで、損失が減ることを示す
上層「2週間で何が分かる？」
テラ「“全部”は分かりません。でも、止められない構造が数字に出るのは2週間で十分です」
6.2 成功条件（Exit criteriaとして書く）
- S1相当の流出が減る／または増えない
- 割り込み（緊急対応）が減る／または増えない
- “撤退の理由”がテンプレで説明できる（属人化しない）
テラ「“成功”を先に定義しておけば、議論が感情戦になりません」
6.3 収集するデータ（Monitoring）
- 撤退件数（だけではダメ。理由を必ず取る）
- 撤退理由（停止条件に合致しているか）
- 影響（ユーザー・売上・CS・再現性）
- 出荷後の重大インシデント（Defect leakage）
6.4 2週間で出す成果物（上層向け）
- 1枚のサマリ（Before/After）
- 「撤退＝品質検知」になった具体例を1つ
- 次の改善（恒久対策）1つ
上層「結局、何が欲しいの？」
テラ「“撤退＝失敗”が損失を増やしてる証拠と、置き換え案の勝ち筋です。1枚で出します」
まとめ（テラの締め）
テラ「止められない現場は、欠陥のせいじゃなく 評価軸のせい のことがある」
- 撤退＝失敗 をやめて、撤退＝品質検知 に書き換える
- 全社変更ではなく、2週間のパイロットで「損失が減る」を数字で示す
テラ「次回は、パイロットが成功した後に来る “止めすぎ（黄だらけ）” をどう収束させるか。
“文化”じゃなく、運用設計として扱います」