OVERVIEW ／ 本レポートの位置づけ
本レポートの概要｜悪意なき失敗モデル
この回のレポートは全２本に分割しています。本ファイルはその１本目、テーマは「悪意なき失敗モデル」です。
事故の3分類
3分類
正直な過失/リスクを伴う判断/悪意ある重大違反
チャレンジャー号事故
1986年
打ち上げ直後に空中分解、乗員7名死亡
失敗の3段階
3段階
インシデント/アクシデント/クライシス
悪の陳腐さ
1963年
アーレント著『イェルサレムのアイヒマン』刊行
組織で起きたトラブルを「個人の不注意」だけで片づけず、その場の行動であるアクティブフェイラーと、組織の設計に潜むレイテントコンディションの両面から捉える「悪意なき失敗モデル」を扱う。人間は間違える生き物であり罰は情報を隠すという前提に立ち、個人の関与を正直な過失・リスクを伴う判断・悪意ある重大違反の3分類に整理し、処罰の対象を最後の1つのみに限定する設計思想を追う。
危機意識の欠如そのものがリスクになるという視点から、1986年に打ち上げ直後の空中分解で乗員7名が死亡したスペースシャトルチャレンジャー号事故や、アイヒマン裁判を傍聴したハンナ・アーレントが論じた「悪の陳腐さ」を手がかりに、心理的安全性と適度な摩擦の両立、マニュアル化とリスクを伴う判断のジレンマ、外部の目が必要な理由としての「近接性理論」までを議論する。
参加者との質疑応答では、成果が給与に反映されない評価制度のもとで重大違反に見える行動が生まれた事例、心理的安全性と摩擦の両立、業務マニュアル化が進む中でリスクを伴う判断の領域に入ってきたことの是非、しっかり準備した遭難者と準備しなかった遭難者を同列に扱ってよいかというエベレスト登山の例え、外部委員会や専門家に判断を委ねる是非といった論点が、参加者と講師とのやり取りを通じて具体的に掘り下げられている。
PART 1｜組織理論
悪意なき失敗モデル ― 誰の責任かではなく、何が失敗を誘発したかを見る
1-1. 「組織事故」という考え方
組織で何らかのトラブルが起きたとき、一般的にはその場で対処していた「個人の問題」として処理されがちである。しかし個人の行動や判断には、組織の中に存在する文化・仕組み・流れが影響している。したがって問題を分析する際には、「個人に明らかな問題があったのか」と「組織的な文化的背景に問題があったのか」という2つの視点の境界線を、意識的に設計してから考える必要がある。この境界線を設計しないまま「ヒューマンエラー」だけに言及してしまうと、組織側の構造的な問題が見えなくなってしまう。
アクティブフェイラー（個人の不注意）
比較的わかりやすい、その場で起きた失敗そのもの。時間軸としては短期的な視点で捉えられる。
レイテントコンディション（組織的な弱点）
組織の設計・仕組みに潜在する脆弱性。マクロな視点かつ、比較的長い時間軸で蓄積される。
重要なのは、この2つを「どちらか」ではなく「両方がどの程度関わっているか」という割合の問題として同時に検討することである。個人の問題だけでも、構造の問題だけでもない。通常の対応フローでは、トラブル発生後に個人の不注意と結論づけ、処罰（叱責・懲戒など）で終わらせがちだが、これでは個人の問題にしか言及されず、次も同じパターンの問題が繰り返される。悪意なき失敗モデルでは、トラブル発生後に「仕組みの問題ではないか」という前提で構造を調査・分析するプロセスを取る。
悪意なき失敗（No-Fault / Just Culture の考え方に近い）：組織として必要なことをやっていても、トラブルや問題は起こり得る。個人が悪意を持って何かをしたわけではなくても失敗は発生する、という前提に立ち、責任者を「祭り上げて」終わらせるのではなく、組織のシステムに問題がなかったかを検証する考え方。
1-2. 人間は間違えるものであり、罰は情報を隠す
このモデルの土台には3つの前提がある。第一に、人間はそもそも間違える生き物であり、それを前提にしない組織構造は脆弱になりやすいということ。第二に、罰を与えられた人間は情報を隠蔽する傾向に走るため、罰を先に立てると必要な情報が組織に集まらなくなるということ。第三に、失敗やトラブルは「悪いこと」ではなく次につながる新しい情報源であり、積極的に拾いに行くべきものだということである。ただし、失敗にはインシデント・アクシデント・クライシスという段階があり、ダメージの少ない「インシデント」の段階で情報を拾うことが重要になる（クライシスまで進んでしまうと、もはや情報源どころではなくなる）。
1-3. 事故の3分類と処罰の設計
個人の関与を評価する際、事の重大さだけでなく「その人がどれだけ誠実にオペレーションへ向き合っていたか」という観点で3つに分類する。
| 分類 | 内容 | 組織としての対応 |
|---|
| 正直な過失 | マニュアル・オペレーションに従って実行していたが、結果としてミスが発生した | 処罰の対象にしない。慰め・励ましを行う |
| リスクを伴う判断 | オペレーションより良いと考え、自己判断で変更した結果トラブルが発生した | 呼び出して注意する（処罰ではなく指導） |
| 悪意ある重大違反 | やってはいけないと分かっていることを意図的に行った | 明確に処罰する |
ポイント：処罰の対象になるのは「悪意ある重大違反」のみ。正直な過失とリスクを伴う判断を同列に処罰してしまうと、「準備しない・挑戦しない方が得」というインセンティブが組織内に生まれ、行動する人が損をする文化になってしまう（セッション内で「エベレスト登山」の例え話として議論された）。
1-4. 危機意識の欠如そのものがリスクになる
安心・順調・成功が続くことは一見ポジティブだが、これらは警戒心・多様な解釈・監視能力という、事故を抑制するために必要な意識を奪ってしまう。したがって「危機意識の欠如そのものがリスクである」という捉え方が重要になる。セッションでは前回扱ったスペースシャトル・チャレンジャー号の事故にも触れ、事前に積み重なっていた予兆・リスクが「許容範囲内」として無視され続けた結果、組織構造の見直しが行われないまま事故に至った例が引用された。
📌 Claude補足：スペースシャトル・チャレンジャー号事故
1986年1月28日、アメリカのスペースシャトル「チャレンジャー号」が打ち上げ直後に空中分解し、乗員7名全員が死亡した事故。原因は低温下でOリング（部品の接合部を密閉するゴム部品）が正常に機能しなかったことだが、事故以前から技術者によるOリングの異常への懸念が繰り返し報告されていたにもかかわらず、組織的な意思決定プロセスの中でリスクが「許容範囲内」として扱われ続けたことが、組織事故・レジリエンス研究における代表的な事例として広く引用されている。
1-5. 議論：ハンナ・アーレントと「悪の陳腐さ」
参加者から「個人か組織かの判断をせず、最初から構造の問題として考えてきた」というコメントがあり、悪意ある重大違反に見える行動（営業担当が取引先に取引を控えるよう促した事例）についても、その背景に評価制度（成果が給与に反映されない仕組み）という組織構造の問題がある可能性が指摘された。これに対し講師は、ハンナ・アーレントの議論を引用して補足した。
📌 Claude補足：ハンナ・アーレントと「悪の陳腐さ」
ハンナ・アーレント（Hannah Arendt、1906–1975）はドイツ出身の政治哲学者。ナチス・ドイツでユダヤ人移送の実務を統括したアドルフ・アイヒマンの裁判（1961年、エルサレム）を傍聴し、その記録を著書『イェルサレムのアイヒマン』（1963年）にまとめた。アイヒマンは裁判で「自分は上からの命令・規則に従っただけ」と繰り返し主張し、極めて凶悪な犯罪の実行者でありながら、その姿は特別な悪人というより、思考停止したまま組織のルールに従う平凡な官僚のようであった。アーレントはこれを「悪の陳腐さ（Banality of Evil）」と表現した。セッションでは、組織のルールや基準に無批判に従うこと自体が「逸脱に気づかない構造」を生みかねないという文脈で紹介されている。
続いて、心理的安全性と組織文化における「摩擦」の必要性についても議論された。過失や失敗を責めない文化は重要である一方、安全性だけを重視すると警戒心が失われ、挑戦や多様性が生まれにくくなるリスクもある。そのため心理的安全性と適度な摩擦は両立させるべきバランスであるという見解で一致した。
1-6. リスクを伴う判断とマニュアル化のジレンマ
業務マニュアルを整備し単純作業の効率化を進める中で「リスクを伴う判断」の領域に入ってきたという相談に対し、講師は「リスクを伴う判断とは、自分たちが持つ基準からどの程度逸脱しているかという考え方であり、必ずしも悪いことではない」とした上で、組織が大きくなるためには不確定要素を取り込んでいく必要があると説明した。実務上は、金銭的・時間的にどこまでの損失やロスなら許容できるかという「リスク許容度」を数値化した上で、権限の範囲を設計する必要がある。数値化できないもの（状態などの定性的な要素）を基準にした権限委譲は推奨されず、その場合は判断できる人自身がジャッジするか、判断できる人材を育成する必要があるとされた。
1-7. 外部の目が必要な理由 ― 近接性理論
社会的影響の大きい事故が起きた際に、外部委員会や専門家の判断を仰ぐべきかという問いに対し、講師は「内部の人間が客観的に判断するのはほぼ不可能」と回答した。この根拠として「近接性理論」が紹介された。
近接性理論（適切な距離感の必要性）：物事を見るとき、近すぎても遠すぎても全体像は正しく捉えられない。近い人間は全体像が見えず一部分しか見えない（バイアスがかかる）一方、遠すぎる人間は点としてしか見えない。内部の人間は対象と完全に密着しているため、それより距離のある第三者でなければ組織の問題を適切に捉えることは難しい。ただし専門家であっても、その業界の慣習・ルールに染まりすぎている場合は同じ理由で機能しなくなるリスクがある点にも注意が必要である。
💬 Q&A
質疑応答
参加者トラブルや失敗が起きたとき、個人か組織かを判断する前に、最初から「構造の問題」として考えるようにしてきた。悪意ある重大違反に見えるケース（成果が給与に反映されないという評価制度の中で、営業担当が取引先に取引縮小を促した事例）も、実は組織の評価基準の問題ではないか。この考え方についてどう思うか。
講師まず構造から目を向けるべきという考え方は妥当。ハンナ・アーレントが指摘した「悪の陳腐さ」（アイヒマンが「上に従っただけ」と繰り返した事例）のように、組織の基準に無批判に従うこと自体が逸脱に気づかない構造を生むことがある。悪意なき失敗モデルはこうした議論とも通じるところがある。
参加者心理的安全性も関係するのではないか。失敗やヒヤリハットの情報こそ、より良い組織のために必要な情報になるはずだが、安全性を高めすぎると警戒心が失われ、多様性が生まれにくくなる懸念もある。
講師その通りで、安全性と摩擦は両方セットでないと成り立たない。行動しないことこそが最大のリスクであるという企業文化を作ることが最も難しい課題であり、そのための教育システムを作る側の人間自身が、まずその考え方を持っていなければならない。
参加者（前田さん）業務マニュアル・効率化を進める中で、単純作業では成果が出ているが、今まさに「リスクを伴う判断」の領域に入ってきている。これは良い傾向か、良くない傾向か。
講師リスクを伴う判断とは「これぐらいなら大丈夫だろう」という警戒感が抜けた考え方であり、それ自体が必要になる局面もある。重要なのは、自分たちがどこまで監視・統制するか、どこまでのリスクなら受け入れられるかという「リスク許容度」を定義した上で、権限の範囲を設計すること。数値化できない基準は推奨できず、その場合は判断できる人材自身が担うか、そうした人材を育成する必要がある。
参加者（前田さん）エベレスト登山にたとえると、しっかり準備をして遭難した人と、何も準備せず遭難した人を、結果が同じ「遭難」だからといって同列に扱ってよいのか。
講師良い例え。準備をしていれば「正直な過失」に分類され、評価は変わるべき。ただしこれを組織のルールとして明文化しようとすると「差別」と受け取られかねないため、評価基準・ポイントを明確化した上でレジリエンスを設計しないと、「頑張った人が損をする」「行動しない方が得」という状態に陥ってしまう。行動する人にインセンティブが働く仕組みにすることが、悪意なき失敗モデルが目指す方向性だと考えている。
参加者組織で大きな事故・社会的影響のある問題が起きた際、外部委員会や外部の専門家に判断を委ねるべきかどうかは、自分たちで客観的に判断できるものなのか。
講師内部の人間が客観的に判断するのはほぼ不可能。「近接性理論」の通り、対象に近すぎても遠すぎても全体像は見えない。内部の人間は対象と密着しているため、少なくともそれよりは距離のある第三者（適切な距離感を持つ専門家など）でなければ問題を正しく捉えられない。ただし専門家であっても、その業界の慣習に染まりすぎていると同じ理由で機能しなくなるリスクがある点には注意が必要。
参加者SOC・SASE・CNAPPのうち、将来的に最も儲かりそうなのはどこか、という質問に対する議論の中で、クラウドストライクがSOC領域で強い理由は何か。
講師端末（デバイス）に最も多くの情報が集まるため。クラウドストライクは端末に直接営業をかけ、自社プラットフォーム「Falcon」に他社のセキュリティ機能を集約させる仕組みを作った。ネットワーク領域は自社で開発せず外部（Zscaler、Cloudflareなど）に任せることで開発コストを抑え、顧客の予算に合わせた柔軟な提案ができる点が強み。
参加者Microsoftのセキュリティ事業は、EUの独占禁止法（ドッキー法）の問題を抱えているのではないか。それによって動きが制約されるのでは。
講師アメリカの独占禁止法は、想定されているほど強制力が強くない。仮に独禁法上の疑いをかけられても、即座の是正命令（中国のような強制力）には至らず、裁判を長期化させている間に別の抜け道を見つけて対応する、というのがアメリカ企業に見られがちなパターンだと捉えている。
参加者FortinetやCheck Pointは、Palo Alto Networksと同じジャンルで見たときにどう位置づけられるか。
講師両社はもともとファイアウォール企業であり、Palo Alto Networksよりも、SASE領域のZscalerやCloudflareと並べて比較する方が分かりやすい。なおZscalerについては、直近の状況から見て厳しいという見立てを持っている。