第６章チェックは「節目で味見」を

第６章チェックは「節目で味見」を

ダブルチェックは有害行為の自己申告より、結果の味見やり直しの可能性がミスを減らすマニュアルを発行する前には試用テストを

第６章チェックは「節目で味見」を

作業手順には、何かを検査する段取りが含まれるものだ。

検査が万全であれば、ミスや事故は起こらないはずであるが、現実ではそうではない。

ミスを見逃すのは、「検査方法が正しいのに、検査者がたるんでいるからだ」と片付けられがちである。

私は逆の考えで、かなり悲惨な検査方法が世の中にはびこっているからだと思っている。

どこがどう悲惨であるのか見ていこう。

ダブルチェックは有害念入りに検査したい場合は、ダブルチェック、つまり２回検査するとか、２人が検査をするという方式が選ばれがちである。

ダブルチェックは非常に人気が高い。

何か事故が起これば、「再発防止策としてダブルチェックをすることにしました」と釈明するのがパターンである。

しかし、ダブルチェックには効果が無い。

より踏み込んで言えば、有害にすらなりうる。

各種の実験結果や、産業事故の分析によれば、２人でチェックしても異常の発見率はあまり向上しないことが分かっている。

検査の人数が多くなると、かえって異常の見逃しが増えることすらある。

考えてみれば当たり前のことある。

まず、責任感と緊張感が緩む。

１人目がすでにチェックして異常なしと答えていることを、２人目がチェックしても、たぶん異常がないのだろうという先入観を持ってしまう。

１人目が異常をたびたび見逃すなら、２人目はハラハラドキドキして真剣にチェックする。

しかし、普通は滅多に異常は残っていないのであるから、異常なしの品ばかり続けざまに見せられる２人目は緊張感が続かない。

さらに、同調バイアスが起こる。

片方が「これで大丈夫だよね？」と言えば、相手は「そうだね」と付和雷同してしまう。

これならば１人で作業する方が責任感を感じている分マシである。

２人は１人より危険になりうる。

数を増やせばいいわけではない。

検査者を多重化しても効果が無い。

人間は、みな同じように思考するから、間違えるところが同じである。

「大阪冬の陣、夏の陣」という文字は、日常感覚的には誤字は含まれていないように見える。

よって、２回点検しても、２人がかりで検査しても、見逃してしまう。

（大阪の阪の字が、正しくは「坂」である。

）検査の回数や人数を増やせば、指数関数的にミス見逃し確率は激減するはずだというのは、甘い願望に過ぎない。

ダブルチェックは廃止するに越したことはない。

代替策はいっぱいある。

先に述べたように、節目で作業を停止させて検査する方が、信頼は置ける。

どうしても２人で作業したいのであれば、「同調バイアス」を徹底的に崩す。

「これで大丈夫だよね？」に対しては「いや、ダメだよね」と、「札幌だよね？」に対しては「いや秋田だよ」などと、あえて逆らって答えるのである。

人間は、意表を突かれる反論を受けて初めて、自分が正しいのか深く考えるようになる。

そこで、検査者の横に、意表を突く発言をする人を立たせて、問答を仕掛けるのである。

航空の世界では、機長が威張りすぎて、副操縦士は唯々諾々となり、機長の勘違いを誰も指摘できずに大惨事に至ったという事例がいくつもある。

そこで訓練では、機長役の教官がわざと間違ったことを強硬に主張したり、逆に何でも「よきに計らえ」という優柔不断な機長を演じたりして、訓練生がそれに対処できるかをテストしている。

ダブルチェック有害論は安全工学の学界では別に珍しくないが、世間からは強硬な反発を受ける。

年に１通ぐらいは、「これは嘘でしょ」という批判の電子メールが来る。

「ダブルチェックをやめたいなと思いましたが、上司を説得できなくて、結局、残しました」という声も聞く。

腹をくくって旧弊を捨て、より効果的な検査方法に切り替えられる組織は、案外少ない。

◆ダブルチェックは廃止する。

行為の自己申告より、結果の味見検査は、行為の結果に対して目を向けるべきであり、行為の有無を問うてはならない。

「砂糖を入れましたか？塩を入れましたか？」と問うのではなく、「味見しなさい」と指示するべきである。

結果を検査する方が確実である。

結果は動かぬ証拠である。

行為の有無は、物体ではないのですぐに消え失せてしまうため、確認しにくい。

また、行為をやり終えた直後の作業者に、「やりましたか？」と尋ねることは、かったるい。

この尋問を立て続けにされると、作業者は検査を馬鹿馬鹿しく感じて軽視してしまう。

また、「やりましたか？／やっていませんか？」という質問は、非常に問題があり、検査の信頼性を下げる。

やったつもりになっている人は、本当はやっていなくても、「やりました」と答えるものだ。

誤答を物理的に阻止できないのである。

尋問の頻度が多すぎると、ますます誤答のリスクは高まる。

通常の仕事では、「やりました」で答えるべき回数は「やっていません」よりはるかに多い。

普通の職場なら、ほとんどの場合、「やりました」と答え続けることになる。

「やりました」ばかりを答えることに慣れた人が、やり忘れのミスをした時だけ都合よく「やっていません」を選べるわけはない。

尋問のしすぎは、こうした正常性バイアスを育ててしまう。

時折、交通機関や金融機関、通信施設などで使われている大規模なコンピューターシステムがダウンして大騒動になる事件が起こる。

私はそのたびに、あの独特のチェックリストが原因なのではないかと思わずにはいられない。

大規模コンピューターシステムの業界では、作業手順を誘導し検査するために、資料24のような形式のチェックリストをよく使う。

行為の直後に行為の有無を尋ね、結果の味見はしないという、信頼の置けない方式である。

私の経験では、多くのシステム開発・運用会社でこの形式を使っていたので、この業界の伝統なのではないかと思われる。

改良策として、資料25のように、行為の結果、システムが正しく作動している証拠を調べさせ、それを書き込ませるようにする。

行為の有無を徹底的に無視し、証拠集めに徹することがポイントである。

結果を味見させる方式なら、作業者本人の自覚は脇に置き、結果がどうなっているかを問うから、ぬか喜びのミスは起きない。

◆論より証拠。

行為の有無より、結果の味見。

やり直しの可能性がミスを減らす作業において、直前の操作を打ち消し、元の状態に戻すことを、「取り消し」「引き戻し」「アンドゥ」などと呼ぶ。

こうしたやり直しが無制限に利くのであれば、一切のミスや事故は無くなる。

ミスが生じても、何回でもやり直しができるのであれば、ミスではなくなる。

可逆性が豊富なら、その仕事はかなり安全である。

とはいえ、世の中にはやり直しが利かない仕事が多い。

自然法則上、不可逆な仕事がある。

生卵を目玉焼きにする作業は、失敗しても元の生卵には戻せない。

あきらめて、損失をかぶるしかない。

一方で、仕事をわざと不可逆にしているケースもある。

格式を高めることが目的で、ノーミスを見せつけるという作業がある。

長いお経を誤字なしで書いて、寺に奉納するという習慣がある。

難しい作業をノーミスで仕上げているわけだから、その貴重さに感動する。

しかし、就職活動で使う履歴書に、手書き、かつ無謬を求めるのは、さすがに厳しすぎる。

コンピューターシステムで、アンドゥが設置されていないものを見かける。

これは使用者にとって大問題であり、大欠陥である。

だが、アンドゥ用のプログラムを作るにも金がかかる。

システムの発注者は、コンピューターの玄人とは限らないから、「アンドゥができること」という仕様を要求することを忘れがちなのである。

すると、システム制作者は当然として作らない。

こうしてポンコツなシステムが誕生する。

コンピューターシステムの発注者には、適切な仕様を自分で設計する能力、すなわち「発注力」が求められる。

ロサンゼルス・タイムズは１９９６年の記事で、米連邦政府の発注力の無さを「昨日の技術を明日購入しようというのがモットーのようだ」と評した（しかし米国は、「文書業務削減法」や「政府書類業務排除法」といった露骨な名前の法律を作って、業務効率化改革を長年にわたり推し進めてきたから、マシな方である）。

コンピューターシステムの発注者が、最低限要求するべき仕様を挙げてみよう。

○ボタンを押し間違えても、取り消せること。

直前の画面にすぐに戻れること。

○ここから先に進むと、入力の取り消しが不能になるという場面（ラスト・チャンス）では、その旨を大きく表示すること。

○ラスト・チャンスでは、入力の結果の全てを見やすく表示し、作業者が見直せるようにすること。

○ラスト・チャンスは、全入力手順の終わりに設置すること。

つまり、入力が一通り済んだ段階で、全ての項目が修正可能であるようにすること。

○ラスト・チャンス以降であっても、作業者は仕事の状態を観察することができるよう

にすること（済んだ仕事であっても、事後確認する必要がたびたび起こるものである。

だが、作業者の手の届かないところへデータを隠してしまうシステムが多い）。

◆アンドゥのないシステムは敵だ。

マニュアルを発行する前には試用テストをもう一つ、発注の際に要求すべきは試運転の実施である。

試運転のテストは必ずする。

老若男女を被験者としてシステムを使わせる。

実験前に、作業の所要時間と入力ミス率を見積もっておき、見積もりと実験結果がどれだけずれたかを報告する。

使い方を間違えた部分と、使いにくいという意見が出た部分をリストにし、要因を分析する。

試運転テストは、よいシステムを作る上で絶対にやるべき事項でありながら、ほとんどの場合、発注者から要求されることがない。

試運転テストがないので、粗だらけで使いにくいシステムが世にあふれている。

この問題を扱った本に、ギルブとワインバーグによる『HumanizedInput』（人間に合った入力方式）がある。

その献辞はこうだ。

「『女の子』呼ばわりされつつも、コンピューターの悪辣な欠陥を、その指先で救ってきた幾千のデータ入力係たちに、本書を捧げる。

」例外的に、イギリス国防省は、装備品製造に関する規格で、念入りな試運転テストを求めている。

コンピューターシステムばかりではなく、マニュアルも試運転が必要である。

第三者に読ませてみて、作業をさせてみる。

すんなり仕事ができればよいが、思わぬ欠陥を見つけることも多々ある。

試運転をしてもらう被験者は多様であるほどよい。

さまざまな背景を持った、いろいろな年齢層の人を集めて、マニュアルの意図が伝わるか、そしてマニュアル通りに作業を実行できるのか、その作業は正しい結果にたどり着けるのか調べる。

イギリスの規格は、被験者の多様性を発注時の検討項目に挙げている。

子どもは意外な欠陥を見つけてくれるので、被験者に選ぶと非常に有益である。

漢字が読めない、計算ができない、社会知識がない、集中力が続かない、ということが普通である子どもをぶつけることで、マニュアルの「過負荷耐久テスト」をするのだ。

職場に子どもがいないからといって、これを使わない手は無い。

家族に子どもがいる人から斡旋してもらおう。

子どもや、高齢者、外国人といったマイノリティーのテストを乗り越えたマニュアルは、粗が取れている。

それは職場の効率を上げ、事故を減らす。

試運転よりも効果があるマニュアル改善法は無い。

◆リハーサルは念入りに。

マニュアルは子どもに下読みさせよ。