99 回の成功と 1 回の失敗は同じ仕組みから生まれる ―障害に対する視座の転換

はじめに ―障害について考える時の視点

こんにちは．品質企画の kuritaro です．freee QA Advent Calendar 2025 の 19 日目です．本日は，障害について考える時の視座について掘り下げてみたいと思います．

障害（欠陥，バグ）が発生したら，もう同じ（ような）ことが，二度と起こらないよう（起こさないよう）に，原因を調査・探求して対策を打つ．これは基本的かつ重要なことです．また，単一の障害を見るだけではなく，複数の障害を俯瞰して分析し，たとえば欠陥が集中している箇所（いわゆる「バグの巣」）を見つけたり，アーキテクチャや仕事やプロセス等のシステムのより根本的な問題に目を向けたりすることも重要です．フリーではこれらの活動を「振り返り」や「障害 DeepDive」などと呼んでいます．

さて，このように障害やシステムを見て分析・考察するときに，私たちは，「悪いこと」ばかりに目を向けてはいないでしょうか．そして，時には目を逸らしたくなるような問題に向き合い，障害の根本原因分析を重ねても，必ずしも品質が良くならないということはないでしょうか．

それはもしかすると，見ている方向が片側だけだからかもしれません．本日は，障害 DeepDive における着眼点のひとつである，「成功からも学ぶ」という視点について考えてみたいと思います．

Safety-I と Safety-II ―2 つの考え方，ものの見方

安全工学の世界には，Safety-I と Safety-II という考え方があります *1．

Safety-I は，従来の考え方です．事故や失敗の原因を特定してそれを取り除く，「悪いことが起こらないようにする」アプローチです．他方の Safety-II は，これとは異なるアプローチです．「うまくいっていることを理解して，それが起きることを増やす」という発想です（表 1）．

考えてみれば当たり前のようにも思いますが，興味深いのは，このふたつが表裏一体であるということです．「機能共鳴分析手法（FRAM（Functional Resonance Analysis Method））」*2 を提唱したエリック・ホルナゲルは，これを「失敗と成功の等価性」と呼んでいます．システムが柔軟に変動できる能力は，うまくいくときの強みであると同時に，うまくいかないときのリスクにもなる．つまり，成功と失敗は同じ仕組みから生まれているという考え方です．

この考え方に従うならば，失敗だけを見ていても，全体の半分しか見ていないことになります．あるいは，世の中で動いているシステムでは，うまくいっていることがほとんど（例えば 999,999 回）で，対してうまくいっていないことの数はごく少数（例えば 1 回）ですから，失敗だけ見ているのでは，全体のごく一部（上記の例ですと 0.0001% = 1ppm）の事象でしかシステムを見ていないと言うこともできます．

表 1: Safety-I と Safety-II の対比

	Safety-I	Safety-II
安全の定義	悪い方向に向かうものごとができるだけ少ないこと	できるだけ多くのものごとが正しい方向に向かうこと
安全管理の原則	何か起こったときに，反応し，応答する	事前対策を行う．発展や事象を予期するように努める
事故の説明	事故は失敗や機能不全が原因で起こる	結果によらず，ものごとは同じ方法で起きる
ヒューマンファクタの見方	責任．人間は危険要因である	資源．人間はシステムの柔軟性とレジリエンスに必要な要素である

開発対象のソフトウェアや開発チーム等のシステムは，複数の機能（人，モジュール，プロセス，ツール等）が相互に作用して動いています．ある事象にただひとつの原因（真因）があるとは限りません．システムの構成要素は有機的に結びついており，「A が起きたから B になった」という単純な因果関係では説明できないことも多いのです．

そして，システムにあるそれぞれの機能や資源には「変動」があり（人の判断のばらつき，処理時間のゆれ等），通常はこの変動が吸収されてうまくいく（成功）が，複数の変動が重なると予期しない結果（悪いこと，失敗，障害）になることもある．つまり「変動」は悪いものではなく，システムが柔軟に動くために必要なものであり，「変動をなくす」のではなく「変動を理解し，『共鳴』のパターンを把握する」という考え方が必要になります．

障害 DeepDive における実践 ―成功からの学び

私たちの障害 DeepDive という活動では，この考え方も取り入れようとしています．

障害 DeepDive は，一定期間に発生した複数の障害を横断的に分析する組織的な取り組みです．個別の障害分析だけでは見えてこない傾向やパターンを発見し，プロダクトとチーム活動の品質を継続的に向上させることを目指しています．ここで大切なのは，失敗の分析だけでなく，「成功要因からの学び」についても取り上げることです．

たとえば，こんなことを考えます．

過去には発生したけれど，今回は防ぐことができた障害はないか？
重大な障害を未然に防いだ仕組みや判断は何だったか？
影響を最小限に抑えられた設計や対応はどのようなものか？
チームの連携がうまくいったのはどのような場面か？

これらの問いは，誰かのミスを探すためのものではありません．どの変動の重なりによってうまくいったり，いかなかったりするのか，よりよくするためにはどこにバッファを持たせるべきか，複数の要因の組み合わせを理解するためのものです．

たとえば，あるプログラムの間違いに関して下記のような分析をします．

実装者がその機能に不慣れだった（普段はレビューでお互いの不慣れをカバーできている）
レビュアーがちょうど忙しく，レビュー時間が短かった（普段はテストでカバーできている）
テストの範囲が広がりテストの期間が予定より短くなった（普段は重点領域を絞ってカバーできている）
影響範囲のリスク分析が楽観的だった（普段は誰かが気がつくことが多い）

どれも単独では問題にならなかったかもしれません．しかし，これらが同時に重なったことで，どの工程でもカバーできず障害が流出した．このように障害を，レビュー不足，テスト不足などといった単一の原因ではなく，複数の変動が重なった結果として捉えるのです．

逆に，うまくいった例も考えてみましょう．本来なら見逃していたかもしれない欠陥を，リリース前に発見できたケースがあったとします．

たまたまその機能に詳しい人がいた
リリース前の雑談で「ここ怪しくない？」という話が出た
スケジュールに少し余裕があり，追加確認ができた

これも複数の変動が重なった結果です．大切なのは，これを「運が良かった」で終わらせないことです．なぜうまくいったのかを言葉にして，意図的に再現できるようにする．それが Safety-II の考え方です．

前述の通り，一般的には，悪いことよりも，変動が調整されてうまくいっていることの数の方が多いです．うまくいっていることを認識して，それを意図的に増やしていくことができれば，悪いことは起きにくくなる．これが Safety-II の発想であり，障害 DeepDive が目指している，より高い視座でシステムを見ようとする方法です．

レジリエンスエンジニアリング ―システムの学習と成長の仕組み

Safety-II と関連するのがレジリエンスエンジニアリングという考え方です．レジリエンスとは，回復力や復元力のことです．これは，予期しない変化や問題に対して，柔軟に対応し，学習し，成長していく力です．

レジリエンスエンジニアリングでは，4 つの能力が重要だとされています *3．

対応する: 今起きていることに適切に対処する（たとえば障害対応，ロールバック判断）
モニタリングする: 状況を継続的に観察し，変化を察知する（たとえばアラート監視，メトリクス確認）
学習する: 経験から知識を蓄積し，次に活かす（たとえば振り返り，ナレッジ共有）
予想する: 将来起こりうることを先読みして備える（たとえばリスクアセスメント，技術的負債の可視化）

障害 DeepDive でも，このレジリエンスの観点を取り入れています．「予防」「検知」「隔離」「復旧」「学習」といった視点で，チームや仕組みを振り返り，高めていくのです．単に障害を防ぐだけでなく，変化に強い開発チーム，開発対象システムをつくることを目指します．

おわりに ―問題を減らすために良いことを増やす

「障害を少なくすること（あるいは障害ゼロ）を目指す」という言葉は，一見すると正しそうに思えます．しかし，発生した，あるいは発生しそうな障害にばかり目を向けてしまうと，活動や思考の袋小路に入り込んでしまうかもしれません．

障害ゼロを追い求めるあまり，個人やチームが萎縮してしまったり，挑戦を避けるようになったりしては本末転倒です．反省や問題の究明と同時に大切なことは，「よいことを増やす」という視点ではないでしょうか．うまくいっていることに目を向け，それをチームで言語化して共有する．そうすることで，良いやり方が自然と広がり，結果として障害も減っていくことが期待できます．

また，障害 DeepDive は個人やチーム・組織が学習し，成長するための機会です．プロダクトに関わるすべての人が協力して，「なぜうまくいったのか」も一緒に考えていくことに価値があります．また，これらの視点は，特別な活動だけではなく，日常の振り返りや，個々のコードレビューの際にも活かせます．うまくいった確認のしあいや，誰もが素晴らしいと感じた設計の判断について，なぜうまくいったのかを言語化し，知識として蓄積・共有するところからはじめてみませんか．きっと，新しい発見があるはずです．

最後に，Safety-II を提唱するエリック・ホルナゲルの言葉 *4 を引用してこの記事を締めくくります．