ヒューマンエラーはなぜ起こるのか？"血で書かれた"航空業界のCRMから学ぶチーム改善術
takashiこんにちは、こんばんは！Belong で EngineeringManager をしております、takashi です！
リリース直前の設定ミス。
データベースの削除コマンド実行ミス。
コミュニケーション不足で仕様が食い違っていた。
……どれも、IT エンジニアなら一度はヒヤリとした経験があるのではないでしょうか？
はじめに：チームでの「うっかりミス」、どう防いでますか？
皆さんのチームでは、日々の開発や運用で「ヒヤリ」としたこと、ありませんか？「まさか！」と思うようなミスが、時として大きな障害に繋がってしまう…。私たち IT エンジニアも、日々そんなリスクと隣り合わせですよね。
今日は、そんなチームでのミスを防ぎ、より安全で効率的な開発を進めるためのヒントとして、航空業界の叡智：CRM（クルーリソースマネジメント）という考え方をご紹介したいと思います。
実はこの CRM、アジャイル開発の考え方と相性が良いと感じているんです。この記事を通して、皆さんのチーム運営や日々の業務に役立つ気づきがあれば嬉しいです！
CRM って、そもそも何？
「CRM」と聞くと、IT 業界では顧客管理システム (Customer Relationship Management) を思い浮かべる方が多いかもしれません。でも、今日お話しするのは、航空業界で生まれたもう一つの CRM、
Crew Resource Management の方です。
CRM の本質とは？
これは、ざっくり言うと、 「コックピットやチームで利用できる『あらゆる資源』――人、モノ（機器）、情報――を最大限に活用して、安全と効率を追求しよう！」 という考え方、そしてそのための具体的な訓練や仕組みのことなんです。
飛行機のパイロットって、ものすごい技術（テクニカルスキル）を持っているイメージですよね？もちろんそれも大事なんですが、CRM が特に注目するのは、それ以外の非技術スキル（ノンテクニカルスキル）なんです。
具体的には、
- コミュニケーション: メンバー間で正確に情報を伝え、聞き、理解し合う力
- 状況認識 (Situational Awareness): 今何が起こっていて、これから何が起こりそうか、全体像を把握する力
- 意思決定: 限られた情報や時間の中で、最善の判断を下す力
- チームワーク: 互いに協力し、補い合い、共通の目標に向かう力
- リーダーシップ: 状況に応じてリーダーシップを発揮し、チームを導く力
- エラーマネジメント: ミスが起こることを前提に、それを防ぎ、起きたとしても素早く検知し、影響を最小限に抑える力
こういったスキルをチーム全体で高めていこう、というのが CRM の目指すところです。なんだか、私たちがアジャイル開発で大切にしていることと、通じるものがあると思いませんか？
なぜ航空業界で CRM が生まれたのか？：「安全規則は血で書かれている」
では、なぜこの CRM という考え方が、特に航空業界で発展してきたのでしょうか？
それは、航空機が持つ特殊性と、そこで起こる事故の悲惨さに関係しています。
- 一瞬のミスが命取り: 高速で空を飛び、多くの乗客を乗せる航空機では、ほんの一瞬の判断ミスや連携不足が、文字通り数百名の命を奪う大惨事に直結する可能性があります。
- 「血で書かれた規則」: 航空業界には、「安全規則は血で書かれている (Aviation regulations are written in blood)」という重い言葉があります。これは、過去の多くの悲惨な事故の犠牲の上に、一つ一つの安全対策やルールが築き上げられてきたことを示しています。CRM もまた、そうした痛ましい教訓から生まれた、いわば人類の叡智の結晶なんです。
- ヒューマンエラーとの闘い: 1970 年代の研究では、航空機事故の実に 7 割以上が、機械の故障ではなく、人間のミス、つまりヒューマンエラーに起因することが明らかになりました。CRM は、この「人間であるがゆえの弱さ」に正面から向き合い、それをチームの力で克服しようとする試みとして始まったのです。
さらに、航空業界の事故調査は、私たちの IT 業界のポストモーテムとは比較にならないほど徹底しています。フライトデータレコーダーやコックピットボイスレコーダーといった「ブラックボックス」に残された膨大なデータ、あらゆるセンサー情報、関係者への聞き取りなど、莫大な時間と費用をかけて、事故原因、特にヒューマンファクターが徹底的に分析されます。CRM は、こうした分析から得られた知見を基に、常に改善され続けているのです。
そして、CRM は世界中の航空会社で採用されているグローバルスタンダードです。国籍も文化も異なるクルーが同じコックピットで協力し、安全な運航を実現するためには、文化の違いを超えた共通言語としての原則が必要でした。CRM は、いわば「人間が共通して陥りやすいエラーのパターン」に対する普遍的な対策集とも言えるでしょう。
特に注意したい「権威勾配」
CRM が特に問題視し、克服しようとしてきたヒューマンファクターの一つに「権威勾配 (Authority Gradient)」があります。
これは、チーム内に明確な上下関係や権威の差がある場合に、立場の低いメンバーが立場の高いメンバー（例えば、副操縦士が機長）に対して、疑問や懸念、異なる意見を表明しにくくなる状況を指します。
いくつか、この権威勾配が一因となったとされる有名な事故があります。
- テネリフェ空港ジャンボ機衝突事故 (1977 年): 濃霧の中、KLM 機の機長が離陸許可が出ていないにも関わらず離陸滑走を開始。副操縦士や航空機関士は疑問を感じていましたが、機長の権威（と焦り）の前で強く制止できず、滑走路上にいたパンナム機と衝突。583 名が犠牲となる航空史上最悪の事故となりました。
- ユナイテッド航空 173 便墜落事故 (1978 年): 着陸進入中に脚の問題を示す警告灯が点灯。機長は問題解決に固執するあまり、旋回待機を続けました。副操縦士や航空機関士は燃料残量を繰り返し懸念していましたが、機長にその深刻さが十分に伝わらず、結果的に燃料切れで墜落。10 名が犠牲になりました。この事故が CRM 開発の直接的な契機の一つとなりました。
これらの事故では、判断ミスだけでなく、「リーダーに異議を唱えられなかった」というチーム内のコミュニケーション不全が、悲劇を招く要因となったのです。
一方で、CRM の原則が見事に機能した成功例も存在します。
ハドソン川の奇跡に見る、CRM の体現
2009 年、US Airways 1549 便はニューヨークを離陸直後に鳥の群れと衝突し、両エンジンを失うという危機に直面しました。
機長のチェズレイ・サレンバーガーさんは、着水するまでのわずかな滑空時間の中でも、副操縦士にこう尋ねました。
「ほかに良いアイデアは？」
この問いかけは、単なる形式的な確認ではありません。
CRM が重視する「チーム全体の資源を活用する姿勢」や「権威勾配の緩和」、そして「心理的安全性の確保」が凝縮された一言です。
副操縦士はこう返答しました。
「正直言って、ありません」
お互いが必要な情報を率直に共有し、そのうえで迅速かつ的確に下された判断 ── それが、ハドソン川への緊急着水という決断でした。
結果として、乗員乗客 154 名全員が生還を果たします。
この事例は、「CRM がチームの総合力を引き出し、最悪の事態において最良の決断を導いた」成功例として、航空安全教育の文脈でもしばしば紹介されています。
特に、私たち日本人を含む東アジア文化圏では、歴史的・文化的な背景（儒教の影響などが指摘されることもありますが、断定は避けます）から、上下関係を重んじ、権威に異議を唱えることに抵抗を感じやすい傾向があるかもしれません。これは、組織の秩序を保つ面もありますが、こと安全やリスク管理においては、重大な脆弱性となり得ます。
CRM は、この権威勾配のリスクを低減するために生まれました。役職や経験に関わらず、誰もが安全のために「おかしい」と思ったことを自由に発言できる心理的安全性 (Psychological Safety) を確保し、アサーティブネス（相手に敬意を払いつつ、自分の意見や懸念を明確に主張するスキル）を奨励します。また、互いの行動をチェックし合う相互監視（クロスモニタリング）や、指示・伝達内容を確認し合うチェックバックといった具体的なコミュニケーション手法を通じて、思い込みや勘違いによるエラーを防ごうとします。
CRM の知見を、私たちの現場に活かすには？
さて、この航空業界で培われた CRM の考え方を、私たち IT エンジニアの日常業務やアジャイル開発チームにどう活かせるでしょうか？
多くの共通点があることに気づくはずです。
- 複雑なシステム: 私たちが開発・運用するシステムも、航空機に劣らず複雑です。
- チームでの協業: 一人で完結する仕事は少なく、チームでの連携が不可欠です。
- 潜在的なエラー: バグ、設定ミス、セキュリティインシデントなど、ヒューマンエラーが大きな障害に繋がるリスクは常に存在します。
- 迅速な意思決定: 変化の速い市場や、障害発生時には、迅速かつ的確な判断が求められます。
これらの共通点を踏まえ、CRM の原則を私たちの現場に適用するアイデアをいくつか考えてみましょう。
- 「権威勾配」を意識したチーム運営:
- 心理的安全性の確保: チームリーダー（EM、テックリード、マネージャーなど）は、メンバーが役職や経験に関わらず、自由に質問したり、懸念を表明したり、アイデアを出したりできる雰囲気作りが大切です。「こんなこと聞いたら馬鹿にされるかも」「反対意見を言ったら評価が下がるかも」といった不安を取り除くことが第一歩です。
- 「発言しやすい」仕組み: レトロスペクティブや設計レビューなどで、ラウンドロビン方式など全員が発言しやすい工夫を取り入れることも有効です。
- コミュニケーションの明確化:
- チェックバックの習慣化: Slack での依頼や指示、口頭での伝達など、重要な情報については「〜ということで合っていますか？」と確認し合う文化を作ることも有効です。これにより、「言ったつもり」「聞いたつもり」の齟齬を防ぎます。
- 会議での復唱確認: 議論が複雑になったり、決定事項が出たりした際には、「ここまでの決定事項は〜ということでよろしいでしょうか？」のように、認識合わせのための復唱確認を意識的に行う習慣は助けになるかもしれません。
- 状況認識の共有 (見える化):
- デイリースクラム: CRM の「ブリーフィング」のように、単なる進捗報告だけでなく、「今日のゴール」「潜在的なリスク」「困っていること」などを共有し、チーム全体の状況認識を高めましょう。問題があれば「ハドル」のように短時間で集まって認識を合わせるのも有効です。
- カンバンボード/タスクボード: ボードを常に最新の状態に保ち、誰が何をしていて、どこにボトルネックがあるのかを「見える化」することで、チーム全体で状況を把握し、助け合いを促します。
- エラーマネジメントと学習:
- 非難しない文化: バグや障害が発生した際、個人を責めるのではなく、なぜそれが起きたのか、プロセスや仕組みに問題はなかったか、という視点で原因を究明しましょう。
- 効果的なレトロスペクティブ: CRM の「デブリーフィング」のように、うまくいったことだけでなく、失敗や課題についてもオープンに話し合い、具体的な改善アクションに繋げましょう。KPT（Keep, Problem, Try）などのフレームワークも有効です。
- 相互支援とフィードバック:
_ コードレビュー/設計レビュー: 「間違い探し」だけでなく、より良い方法を提案したり、困っている点をサポートしたりする（タスク支援）文化が大切です。
_ CUS/2 チャレンジルールの精神: 安全性や品質に関わる重大な懸念を感じた際には、遠慮せずに「Concerned (懸念があります)」「Uncomfortable (不安です)」「Safety issue (安全上の問題です)」と表明できるルールや雰囲気作りを検討してみるのも良いかもしれません。
まとめ
今回は、航空業界の安全を支える CRM（クルーリソースマネジメント）という考え方と、その IT 業界、特にアジャイル開発チームへの応用可能性についてお話ししました。
CRM は、単なる手順や規則ではなく、「人間はエラーを起こすものである」という前提に立ち、チームの力でそれを乗り越えようとする、人間に対する深い洞察に基づいたアプローチです。
その核心には、心理的安全性を土台とした、オープンなコミュニケーション、効果的なチームワーク、そして継続的な学習と改善のサイクルがあります。これは、まさに私たちアジャイル開発者が目指しているチームの姿と重なるのではないでしょうか。
すべてを一度に導入するのは難しいかもしれませんが、まずは、
- 私たちのチームに「権威勾配」はないだろうか？
- メンバーは安心して意見や懸念を表明できているだろうか？
といった視点で、チームを見つめ直すことが大切かもしれません。 まずは朝会で「困っていること」を共有してみるだけでも、チームの空気が変わってくるかもしれません。
今日お話ししたような心理的安全性を重視し、オープンなコミュニケーションや失敗からの学習を奨励する文化は、 ここBelongのエンジニアリングチームにも強く根付いていると感じています。
互いにリスペクトを持ちながら率直に意見を交わし、挑戦を恐れず、もし失敗してもそこから学びを得て次に活かす。
そんな環境で、一緒に世の中を変えるようなプロダクト開発に取り組んでみたい！と思っていただけたら、
ぜひ私たちのエンジニアリングチーム紹介ページを覗いてみてください！ きっと、あなたの活躍できる場所が見つかるはずです！
最後までお読みいただき、ありがとうございました！ それではまた！