撤退＝失敗をやめる：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週間のパイロットで「損失が減る」を数字で示す

テラ「次回は、パイロットが成功した後に来る “止めすぎ（黄だらけ）” をどう収束させるか。
“文化”じゃなく、運用設計として扱います」