はじめに

今更いうことではないのだけれど、自分は凡ミスの多い人間だという自覚がある。例えば、このブログを書いていたとしても、結構な割合で「てにおは」を間違えることが多いし、また予定等を勘違いして、実は期日を過ぎていたということもある。

そういうこともあってか、「こういう単純な凡ミスを無くす」ことが出来ないかなと思って、本を手に取ったのだけど、いい意味で裏切られた。いい意味、というのは、その本のタイトルに反して、要するに「ミスをエンジニアリングするということがどういうことか」ということが書かれていたからだ。この本はタイトルで純粋に損しているとは思う。

個人において「ミスをする」ということはどういうことか

大抵、人間が何かをミスする場合、そのミスというのは無能であるか、あるいはうっかりといったような「能力の欠如」として捉えることが多い。しかし、本書の場合、それよりかは、むしろ「人間の知恵が働きすぎたため、その副作用で間違えた(p.18)」という捉え方をしている。

具体的に説明すると、例えば、自分がブログで「てにおは」を間違えたとしても、人間の脳では、適切に「てにおは」の文章を補足して、なんとなく「こういう意味だろう」というように解釈できる。「象が鼻を長い」という文章に対して、違和感を覚えつつも、しかし言わんとしていることが伝わるのも、そのせいだ。本書にはそういった事例が数多く紹介されているが、そのように「脳が無駄に優秀である」が故に「ミスが起きる」ということになる。

その派生型の一つとして、過剰適応によるミスというのを取り上げている。例えば、本書では『NHKスペシャル』で紹介されていた年金番号の上四桁が「3101」であるところを、「3100」と入力していたパターンを紹介している(p.25)。このように、ルーチンワークとして慣れてくると、逆に思い込みによって作業した結果、ミスをしてしまうということになる。

これはWeb系のエンジニアリングでも起こりうることで、過去にこういうことがあったから、こうなっている筈だ、という仮説だけで作業していると、詰まってしまうことが多い。なので、「計測」が必要になってくる。

このような熟練者問題について、過去にユーザーインターフェイスを例にして問題にしたことがある。このように、熟練しているということが、逆にミスを起こしやすくするというのがある。変な話、エンジニアが常に新しい技術を取得する必要があるのは、このように自分の作業パターンを「慣れさせない」ためにあるという側面は一つあると思う。実際に、本書でも「本当に熟練を極めた人は、むしろ慣れすぎないように注意しています(p.134)」と書いてある。

そもそも現象としての「ミス」とは何か

ミスというと、そもそも「本当はしちゃいけないことをしてしまうこと」という定義が一番てっとり早いものだと思うけれど、しかし本書では、何がミスであるかというのは、結果を見てみないとわからないということを述べている。つまり、ある作業フローがいくら正しくても、その出力に誤りがあるならば、それは「ミス」であるだろうし、例えば作業フローがミスっても、結果オーライという可能性もある。したがって、本書では「ミス」のことを「不確実性」と呼ぶのが適切だろう、と結論している(p.59)。

では、不確実性を減らせばそれで十分かというと、そうではない。

最近になって免許書を落として、休日に警察署へ受け取りに行ったことがあったけれども、そのときに知ったことだが、警察署では、落とし物は会計係として別窓口となっており、その窓口は休日は閉まっている。何としても免許書が必要な用事だったので、そこで「なんとかなりませんか、緊急なので」という話をしたのだけれども、「そうはいっても無理です」という話になり、がっくりとうなだれたことがある。

確かに、「落し物を処理する係」がフローとして存在しているため、不確実性は少ない。しかし、便宜性という意味ではどうだろうか。実際に、「これは規則だから」の一点張りで不愉快になり、「少しくらい融通を利かせてくれればいいのに」という、身勝手ではあるけども、抱く感情を覚えることはないだろうか。

ミスを「不確実性」と捉えた場合、このような「便宜性」というのはトレードオフの関係になっているということを指摘している(p.70)。そこで、技術改良などによって、「不確実性」を許容範囲に収めながらも「便宜性」を確保するのがベターであるというように述べている。

いわゆるITにおけるエンジニアリングにおいても、これが当てはまると思う。Chef, Ansibleなどのコードによるインフラ構築というのが最近の話題になっているが、これは不確実性を出来るだけ排除しつつ、またDockerや、AWSのように、なんらかの形で環境を破壊したとしても、実験したり、改良したりしやすくするという便宜性も同時に考えているのかなあ、などと浅はかな知識で考えたりしたのであった。

ミスの改善は六つの観点から考える

ミスを改善する方法には、六つの方法があるという。

それ無しで済ます
やり方を変える
道具を変える
やり直しが効くようにする
致命傷にならないための備えを講じる
問題を逆手にとる

これらそれぞれは、たぶんエンジニアとして働いている人ならば思い当たる節があることではないだろうか。例えば、「やり方を変える」というのは、「手作業でやるのではなく、シェルスクリプトで任せてしまう」といったり、「道具を変えるというのは、既存のサードパーティをリプレイスする」というのもあるし、また「やり直しが効くようにする」のはヴァージョニング管理であったり……とか、いろいろ考えることができる。

ただ、ポイントとして「それ無しで済ます」「問題を逆手にとる」というものは、確かに抜本的な解決に結びつきやすいが、それだけコストが大きい。「やり直しが効くようにする」や、「致命傷にならないための備えを講じる」のは、それらに比べれば、抜本的ではないものの、コストは少なくなる。一番コストが低いのは、「やり方を変える」「道具を変える」ということであるのだけれども、同様に根本的な解決とは言い難いというように整理されている(p.89)。

ミスを防ぐ方法

とはいえ、ではミスを防ぐ方法というと、本書で挙げられているのは三つのものである。

作業内容に異常が潜伏していることを検知できる能力
どこからが異常であるかを逆探知できる能力
少ない失敗率で作業を実行できる能力

ミスを防ぐということを考えた場合に、どうしても少ない失敗率で作業を実行できる方向に目を向けがちではある。つまり、作業の確実性を挙げるということを重要視しがちなのだけれど、実際のところは、「どうしてその失敗が起きたのか」というトレーサビリティと、そして異常が起きたときにアラートをちゃんと受け取れるかといったことのほうが重要になるように感じる。

また、このようなトレースできることこそが、品質保障の鍵であることも本書では述べている。

まとめ - 単なる事務の本ではなく、ミスのエンジニアリングの本として

先にも述べた通り、本書は良い意味で裏切られた本だ。要するに「事務ミスはこうしたら無くせる」というような、即効性のあることを期待していると損するけれども、そもそも「ミスを捉えて、それを制御するということはどういうことか」ということを考えるうえにおいては、非常に参考にできるところがあるし、またそのような事例も豊富で、「なるほど、こういう考え方もあるのか」といったように、感心しながら本を読んでいた。

またこういったミスってへこんでしまうようなエンジニアにとっても、事務では全く関係ないところで役にたつと思う。もちろん、事務の人にもオススメだけど、どちらかというと、事務の中でも、事務職ではなくて、その業務フロー自体を考えたい人向けかもしれない。

ちなみに、最後に通達の仕方には以下のような工夫が必要だということが書いてある: