システム開発における障害の再発防止策を考える 〜なぜなぜ思考と「混入・流出・止血」の視点〜

はじめに

システム開発において「障害対応」は避けられないテーマです。
しかし、単なる 「原因を修正して終わり」 では、同じような障害が再発してしまいます。

この記事では、障害の再発防止を考える上で役立つ

• なぜなぜ思考（根本原因の深掘り）
• 混入・流出・止血（再発防止の3つの視点）

を整理したうえで、さらに一般的な再発防止の枠組みでよく言及される要素（教育・文化・ポストモーテムなど）も補足します。

---

1. なぜなぜ思考（原因の深掘り）

トヨタ生産方式で有名な「5 Whys（5回のなぜ）」の考え方です。

🎯 目的

表面的な修正にとどまらず、根本原因にたどり着く

📝 進め方

1. 発生した障害の事象を言語化する
2. 「なぜ？」を繰り返す（目安は5回程度）
3. 真因にたどり着いたら、それを防ぐ仕組みを考える

💡 ポイント

• 個人を責めず、プロセスに着目する
• 原因は1つとは限らない。分岐して複数の要因を追うのもOK

例

「本番でAPIが落ちた」
→ なぜ？ ログイン処理でメモリリークが発生
→ なぜ？ コードレビューで検知できなかった
→ なぜ？ レビュー観点にメモリ管理がなかった
→

---

2. 再発防止策の3つの考え方

障害を防ぐためには、「混入」「流出」「止血」 の3つの視点が有効です。

(1) 混入防止（不具合を作り込まない）

• コーディング規約・レビュー観点の強化
• 静的解析ツールの導入
• 設計チェックリストの運用
• 要件定義の精緻化

(2) 流出防止（早期に検知する）

• 単体・結合テストの自動化
• QAチームによるテスト設計強化
• ステージング環境での本番同等テスト
• 探索的テストによる想定外ケースの発見

(3) 止血（影響を最小化する）

• フィーチャーフラグでの切り戻し
• ロールバック手順の整備と訓練
• 監視・アラート体制の強化
• 障害対応マニュアル・オンコール体制の整備

---

3. 補足

(1) 教育・ナレッジ共有

• 障害から得た学びをチームだけで閉じず、全社やプロジェクト横断で共有する
• 勉強会・ドキュメント化・ナレッジベースへの蓄積が有効

(2) 文化・組織的側面

• 「誰かを責めない」 文化を徹底する
• 再発防止は個人ではなくチームとプロセスの責任
• 心理的安全性を担保しないと、原因が正直に出てこない

(3) ポストモーテム（事後分析）

• 障害の事実を正しく記録し、公開する
• 発生から検知・対応・復旧までの流れを時系列で残す
• 「責任追及」ではなく「学びの共有」 の文化を根付かせる

(4) 改善の実効性チェック

• 再発防止策を立てたあと、「本当に機能しているか」を定期的に見直す
• チェックリストやレビューに組み込むことで形骸化を防ぐ

---

4. チームで取り組む際のポイント

• 再発防止は「個人の注意力」ではなく 仕組みで担保する
• 混入・流出・止血をバランス良く検討することが重要
• 実際の障害事例を題材にして、チームで
  • なぜなぜ分析 → 3視点で再発防止策を洗い出す → 教育・共有・定着まで回す
    という流れを回すと効果的

---

まとめ

障害は起きて欲しいものではないですが、発生したら強くなれるチャンスです！
しっかり振り返りをしてより強固なシステムや組織構築を行っていきましょう！