POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

FeedlyRSSTwitterFacebook

本記事は、原著者の許諾のもとに翻訳・掲載しております。

先週、Owen Thomas が Business Insider に、Etsyでのエラーとミスの取り扱いについて素晴らしい記事を投稿しました。それについて、私たちが実際にどうやっているのか、またその理由について詳しく説明したいと思います。

規模の大小に関わらず、テクノロジー関連の仕事をしていれば、誰でも失敗はよく経験します。失敗は、あなたが取り組むアーキテクチャ設計や、書いたりレビューしたりするコード、入念に調べる警告やメトリクスが何であれ、お構いなしです。

そして、失敗が起こります。これは、複雑なシステムでの作業では必然の結果なのです。でも、個人の作為(または、場合によっては無作為)が引き起こす失敗についてはどうでしょうか。皆を困らせる、こんな不注意な人をどうしましょう?

クビにすべきでしょうか。それとも、そういう危ないプログラムには二度と触らせないようにすべき? もっとトレーニングを積ませるべきでしょうか。

これは、失敗に関わった個人の特性に注目する、従来の「ヒューマンエラー」の考え方です。 Sidney Dekker はこれを、「腐ったリンゴの理論」と呼びます。腐ったリンゴを取り除けばヒューマンエラーがなくなるという考え方です。簡単そうに見えますね。

Etsyでは、この従来の考え方を採用しません。それよりも、ミスやエラー、手違いや落ち度を学習の観点から見ようとします。その取り組みの一部として、機能停止や事故について、非難を伴わない事後分析を行います。

非難なき事後分析

「非難なき」事後分析とは、どういう意味でしょうか。
ミスした人の誰もが放免されるということでしょうか? そうではありません。いや、そうかも知れません。

「放免される」の意味によります。説明しましょう。

公正な企業文化 をもつことは、安全 責務のバランスをとるべく努力することを意味します。つまり、失敗のメカニズムの状況的側面と、失敗の直近にいた個人の意志決定過程とに注目する方法でミスを調査することにより、失敗に関与した行為者を矯正として単に罰した場合の通常の結果よりも、組織は安全になります。

「非難なき」事後分析の過程では、ある技術者の行為が事故に関与したとき、その技術者は次のことについて詳細な説明をすることができます。
* いつ、どのような行為をしたか。
* どのような効果が見られたか。
* 何を期待したか。
* 何を仮定したか。
* 事象が発生したとき、事象の時系列をどう考えていたか。

そして、技術者はこの詳細を、 懲罰の恐れなく 説明することができます。

罰したり叱責したりすべきではないのは、なぜでしょうか。技術者は、叱責されるだろうと思えば、失敗のメカニズムや病理、動作を理解するために必要な詳細を積極的に説明する気にはならないからです。事故がどのようにして起こったのかが分からなければ、それが 必ず 繰り返されることが保証されるだけです。その技術者本人でなくても、将来、別の人が繰り返すことでしょう。

Etsyでは、この詳細こそが安全を強化するための最優先事項だと考えています。

「非難」を主要な手法とするならば、組織安全化の方法として 抑止 を暗に容認することになります。抑止は、エラーを起こすのは条件ではなく個人だという信念に基づきます。また、仕事を正しく行わ ない と罰につながるかも知れない、という恐怖が必要だという考えにも沿います。罰への恐れは、人々を将来正しく行動するように動機付けするから。そうでしょうか?

この説明~非難~恥辱のサイクルは、次のように回ります。

  1. 技術者が行為をし、失敗または事故に関与する。
  2. 技術者は罰せられたり、恥をかかされたり、再教育されたりする。
  3. 現場の技術者(鋭い側)と、誰かに責任をなすりつけようとする管理者(鈍い側)の間の信頼が弱まる。
  4. 技術者は行為/状況/観察について詳細を話さなくなり、その結果「叩かれないように尻を隠す」エンジニアリングになる(罰を恐れるから)。
  5. 4の沈黙のせいで、管理者には日々の作業がどのように行われているか知らされず、ますます分からなくなり、技術者は失敗の潜在的な条件について教育されることがなくなっていく。
  6. 5のせいで、ますますエラーが起こりやすくなり、潜在的条件を特定できなくなる。
  7. ステップ1から繰り返し。

このサイクルを回避しなければなりません。エラーを起こした技術者に、なぜ(明示的または暗示的に)それを行ったのか、なぜその時はその行為が理にかなっていると思ったのか、詳細を説明してもらいたいのです。これは、失敗の病理を理解するための最優先事項です。その行為は、行った時点では、それを行った人にとって理にかなったことだったのです。なぜなら、その時点で理にかなっていると思わなければ、 そもそもその行為をしなかったはず だからです。

この根本的な基礎は、 Erik Hollnagel の言説にあります。
>事故は人々が賭けに負けるから起こるのではないことを理解するように務めなければならない。
事故の原因は、人々が次のように思い込んでいることだ:
これから起こることを「あり得ない」と思っているか、
これから起こることが自分のしていることと関係ないと思っているか、
どんなリスクがあろうとも、意図する結果が得られる可能性には価値があると思っている。

第2のストーリー

技術者が置かれた事情と環境を深く掘り下げて調べるという考えを「第2のストーリー」と呼びます。事後分析の会議では、失敗を理解するのに役立てるために第2のストーリーを探します。

『Behind Human Error』 から、ヒューマンエラーの第1と第2のストーリーの違いを次に引用します。

第1のストーリー 第2のストーリー
ヒューマンエラーを失敗の原因と見なす ヒューマンエラーを組織内部の深部にあるシステム的な脆弱性の影響と見なす
人が何をすべきだったかを問えば、十分に失敗を説明できる 何をすべきだったかの話をしても、行った行為がその人にとって理にかなっていたことの理由の説明にはならない
人にもっと注意するように促せば問題は解消する 組織は、その脆弱性を絶えず模索することによってのみ安全を強化することができる

技術者に自分のストーリーを語らせる

技術者がミスを起こしたとき、その詳細を説明しても安全だと感じれば、面白いことが起こります。積極的に説明責任を負うだけではなく、会社の他の人たちが将来同じ誤りを避けられるように喜んで力を貸します。要するに、人は自分のミスのエキスパートなのです。改善策の考案には、彼らが深く関わるべきです。

技術的には、技術者は非難なき事後分析の過程から「放免される」わけでは全くありません。結局、彼らには、Etsyがより安全になり、早く立ち直れるようになるために手助けする義務があります。そして、驚くべきことに、私の知っている技術者のほとんどは、ものごとを他人のために改善するというこの考えを、実践に値すると考えています。

さて、Etsyでは、「公正な企業文化」を可能にするために何をしているでしょうか。
* 機能停止や事故について、この非難なき事後分析による学習を奨励する。
* 目標は、ある事故が将来に発生するのに備えるために、その事故が どのようにして 発生するに至ったかを理解すること。
* 第2のストーリーを見つけ、故障について複数の観点から詳細を収集し、ミスを起こした人を処罰しない。
* 技術者を罰するのではなく、その代わりに、失敗への関与について彼らが詳細に説明できるようにすることにより、安全を強化するために必要な権限を与える。
* 実際に ミスを起こした人が、将来そのミスを起こさないようにする方法を組織の他の人たちに教えるエキスパートになれるようにし、またそうなるように奨励する。
* 人がある行為をするか否か判断できる裁量の余地を常に認め、その判断の良否の評価は単なる後知恵だと認める。
* 後知恵バイアス は過去の事象の査定を曇らせると認め、これを無くすように尽力する。
* 基本的帰属錯誤 もまた避け難いと認め、事故を調査する際は人が働く環境と事情に注目する。
* 仕事が「鋭い側」で実際に(工程管理表や手順から想像するものと違って)どのように行われているか、組織の「鈍い側」に理解させるように尽力する。
* 「鋭い側」は、適切な行為と不適切な行為の間の境界線がどこにあるか組織に知らせる役割を期待される。これは、「鈍い側」が自力で考え出すことのできない種類のものだ。

失敗は必ず起こります。失敗がどのようにして起こるのかを理解するには、まず、失敗に対する人の反応を理解しなければなりません。

原因となった人だけが無能なのだと決めつけて、「気をつけろ!」とか「もっと慎重に!」などと技術者を怒鳴りつけるのも1つの選択肢でしょう。
事故が実際にどのようにして発生したか詳細に調べ、関わった技術者を尊重し、事象から 学ぶ こともまた、別の選択肢です。

このような理由から、Etsyでは非難なき事後分析を行い、公正な企業文化を育成しようとしているのです。

監修者
監修者_古川陽介
古川陽介
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
複合機メーカー、ゲーム会社を経て、2016年に株式会社リクルートテクノロジーズ(現リクルート)入社。 現在はAPソリューショングループのマネジャーとしてアプリ基盤の改善や運用、各種開発支援ツールの開発、またテックリードとしてエンジニアチームの支援や育成までを担う。 2019年より株式会社ニジボックスを兼務し、室長としてエンジニア育成基盤の設計、技術指南も遂行。 Node.js 日本ユーザーグループの代表を務め、Node学園祭などを主宰。