"バグじゃない。運用が品質を壊す：止められない仕組みの見つけ方"
この記事に出てくる「テラ」は 大人になってから（25歳前後） の想定です。
サマリー
- 品質問題に見えて、実は テストコントロール（監視・制御）不在 の問題
- 「止められない」は、リスクが 受容されてしまう仕組み ができている状態
- 解決の第一歩は、終了基準（Exit criteria） と 停止条件 を“運用の言葉”で定義すること
1. ある日、テストは通っているのに炎上が始まった
テストは通っている。受入条件も満たしている。
それなのに、リリース直後から現場が荒れていく。
僕（テラ）が最初に見たのは、コードでもバグ一覧でもなく 運用 でした。
「誰が止めるの？」「いつ止めるの？」「止めたらどうなるの？」が曖昧なまま、リリースが続いていた。
「テスト範囲の外」に見えるもの（運用・評価軸・例外処理）が、最終的な品質を決めることがある。
2. 何が起きているか
- テストベース（test basis）：要求仕様、受入基準、リスク、過去の障害など
- テストモニタリングとコントロール（test monitoring & control）：進捗や品質状況を見て、計画・判断を調整すること
- リスク（risk）：不具合そのものだけでなく、影響（損失）込みで扱う
「止められない」は多くの場合、
-
終了基準（Exit criteria）が定義されていない
もしくは -
終了基準はあるが、守られない（守れない）仕組みになっている
状態です。
3. “止められない運用”は、どうやって作られるのか
よくある例：
- 撤退＝失敗（途中でやめたユーザーがいると評価が落ちる）
- 止めると評価が下がる（「止めた人」が悪者になる）
- 例外が常態化する（「今回だけ」が毎回になる）
これが テストコントロール不能 を生みます。
4. テスターが最初に置ける「最小のガードレール」
大きな改革をいきなり通すのは難しいです。
だから最初は、“最小セット”で運用にテストコントロールを戻すのが現実的です。
4.1 Entry criteria / Exit criteria を運用の言葉に落とす
- Entry criteria（開始条件）：揃っていないなら、テストに入らない／出荷判定しない
- Exit criteria（終了条件）：満たせないなら、出荷しない／一時停止する
4.2 停止条件を「重大度 × 影響範囲」で定義する
- Severity（重大度）：S1/S2…（組織定義でOK）
- 影響範囲：影響ユーザー数、課金/法務/セキュリティ、復旧可否 など
4.3 “止めた後にどうするか”までセット化する
- ロールバック手順（戻せるか）
- 代替導線（ユーザーが今できること）
- 監視指標（成功条件・中止条件）
- 再開条件（何が揃えば進めるか）
「現場あるある」
例1：Exit criteria が“あるのに使われていない”
やわらかテラ（大人）の語り（会話ログ風）
PM「テスト通ったよね？じゃあ出そう」
テラ「うん、テストは通ってる。でも “止める条件” が今ここにない」
PM「条件ならあるよ。品質基準のページ」
テラ「“ある”は分かった。今日の意思決定で 使う形になってる？
使えないなら、ないのと同じだよ」
- 問題：テストコントロールが機能していない（Exit criteriaが意思決定に接続されていない）
- 直す：Exit criteriaを「文書」から「運用のチェック（Go/No-Go）」に落とす
- 例：出荷判定の議題に 必ず「Exit criteriaの充足状況」を入れる（未充足なら例外扱い）
例2：「止めたら評価が下がる」せいで止められない
やわらかテラ（大人）の語り（会話ログ風）
現場「止めると“遅い”って言われるんで…一時対応で出しちゃいます」
テラ「止めた人が損をするなら、止められないのが普通だよ」
現場「でも間に合わないし…」
テラ「じゃあ“止める”を勇気にしないで、条件にしよう。
“重大度×影響範囲”で止める。個人判断にしない」
- 問題：リスクが見えても 受容されやすい仕組み（意思決定が属人化）
- 直す：停止条件を リスクベースで定義し、判断を標準化する
- Severity（S1/S2…）× 影響範囲（限定/広範、課金・法務・セキュリティ等）
- 交点で「継続／一時停止／即停止」を決める
例3：「止めた後が地獄」だから止められない
やわらかテラ（大人）の語り（会話ログ風）
現場「止めたら、戻し方が分からなくて炎上しそうで…」
テラ「うん。だから止められない。
“止める”は単体じゃなくて、ロールバックと代替導線がセットなんだ」
現場「代替導線…？」
テラ「ユーザーが今できること。CSが案内できること。
それがあると、“止める”は放棄じゃなくて安全措置になるよ」
- 問題：テストコントロールに必要な 再開条件／回復手段 が欠けている
- 直す：「止めた後」の運用テンプレを最小で用意する
- ロールバック手順（復旧可能性）
- 代替導線（ユーザー対応）
- 監視指標（成功条件・中止条件）
- 再開条件（何が揃えば進めるか）
5. まとめ：品質を守るのはテスト技法だけではない
テスト技法（同値分割・境界値・状態遷移など）はもちろん大事です。
でも、それだけでは守れない局面があります。
- 止める＝放棄 ではない
- 止める＝安全措置（リスク低減策） である
テスターが現場を救う最初の一手は、派手な自動化より先に、
Exit criteria と停止条件を“運用の言葉”で置くことだったりします。
停止条件マトリクス（影響範囲 × 重大度）
目的：判断を属人化させず、テストコントロール（監視・制御）として「Go / Hold / No-Go」を決めるための表
前提：用語の最小定義（例）
-
重大度（Severity）
- S1（Critical）：法務/セキュリティ/課金・金銭/安全/大規模データ不整合/復旧困難に該当
- S2（Major）：主要機能が使えない、または顧客業務が止まる（回避策が弱い）
- S3（Minor）：軽微な不具合、回避策あり、限定的なUX低下
-
影響範囲（Impact scope）
- 広範（Wide）：コア機能・主要導線、または影響ユーザーが大きい（例：10%以上 / 重要顧客を含む）
- 中（Medium）：特定セグメント・一部導線（例：1〜10% / 一部顧客）
- 限定（Limited）：限定条件でのみ発生（例：<1% / 特定環境・特定操作・内部）
判断マトリクス（Go / Hold / No-Go）
| 重大度＼影響範囲 | 広範（Wide） | 中（Medium） | 限定（Limited） |
|---|---|---|---|
| S1（Critical） | No-Go（即停止）：ロールバック/出荷中止。緊急対応は“例外手順”で実施 | No-Go（即停止）：同上 | No-Go（原則停止）：例外にするなら根拠とガードレール必須 |
| S2（Major） | No-Go or Hold：原則No-Go。回避策・縮退運用・フラグ無効化が成立するならHoldで再判定 | Hold（期限付き）：24h以内に「修正してGo」or「No-Go」へ確定 | Go（条件付き）：監視強化＋既知問題として周知、次便で修正（Fast-Track） |
| S3（Minor） | Hold or Go（条件付き）：広範なら問い合わせ増のリスク。周知＋監視でGo可、状況次第でHold | Go（条件付き）：周知＋監視、次便で修正 | Go：通常運用で次便修正 |
“Hold（保留）”の最低条件（テンプレ）
- 期限（例：24h）を置く（ずっと黄を許さない）
- Owner（判断責任ではなく整理担当）を1名置く
- 以下が揃ったらGo／揃わなければNo-Go
- 回避策（ユーザーが詰まらない導線）
- 監視指標（成功条件・中止条件）
- ロールバック可否（戻せる/戻せない）
- 顧客影響コミュニケーション（CS/告知）
コツ：判断は「最悪ケース（ワーストケース）でセルを選ぶ」。迷うなら影響範囲を1段階大きく見る。