「ダブルチェックの有効性を再考する」をプログラマ視点で読んだ
このツイートで見かけたのがきっかけで、ダブルチェックの有効性を再考する (PDF)を読みました。プログラマ視点で。エンジニア視点って書くと主語広くなっちゃうので、今日はあえてプログラマ視点という表現にしてます。
トリプルチェックしているからヨシ!
— ところてん (@tokoroten) 2020年9月8日
トリプルチェックがシングルチェックと変わらないエラー検出率なの、面白いなぁhttps://t.co/KCbVH8FLoK pic.twitter.com/GLkrNXkxtj
まず、そもそもこの資料での「ダブルチェック」は医療現場での話で、現場猫が出てくるような工事現場やシステム開発の現場じゃないです。
また、ソフトウェア工学の論文などに首を突っ込めば、ここで出てくる話の検証などがあるのかもですが、そこまでは調べていません。
小さいリスクは整理して捨てる話
これはスライド中の「小さいリスクは整理して捨てる」(p.39) といった表現や、それを具体的に言った「有害事象につながらないエラーは発生しても許容しましょう」(p.55) という話のことです。ただ楽をしましょうということではなくて、大きな事故を減らすために何ができるかという話です。大きな事故が減った様子は p.59 にあります。
話題がダブルチェックなので、コードレビューと対比してしまうのですが、そちらに置き換えると、CSS を1行1行チェックする行為がしっくりきます。念入りにチェックしている方の気分を害したらすみません。
自分が CSS をレビューするとき、見た目に問題がなくて、コードもざっと見て大丈夫そうなら割と LGTM 出しています。例えば .foo, .bar { color: red; }
と書いてあって、この .bar
のセレクタが実は使われていないということもあるかもですが、そういったところまで 100% 確認しているかというと、できていないと思います。
他にも確認すべき大事なところがあるならば、細かいところよりもそっちに時間をかけたほうがいいでしょう。
確認エラーの分類
p.12 からの「ダブルチェックしたのになぜ?」で、確認エラーの分類というものが出てきます。「うっかり」「失念」「思い込み」「ルール違反」の4つに分かれていて、プログラミングではどう分類されるか考えてみました。
- うっかり
- typo
- 不等号の向きを間違える
- 失念
- リソース解放忘れ
- 仮データをそのままコミット
- 思い込み
- typo ではなく本人が正しいと思っている英語間違い(registUser, denyed など)
- 「ドキュメント修正」と書かれたコミットをよく見ずにマージしたけど、よく見たらドキュメント以外に意図しない変更が入っていた
- ルール違反
- 時間がない、面倒、など
- 例外握りつぶし
- グローバル変数
なんでルール違反を?と思うところですが、時間がなかったり、面倒でさぼってしまったりで発生するのでしょう。後で戻すつもりの一時的なルール違反をそのままコミットしてしまうのは、失念の方に分類されそうです。
ダブルチェックとペアプロと不具合
ダブルチェックの現場の様子が何度か出てきますが、2人で一緒に作業をしているという点ではペアプロに近いように感じられました。
個人的には、ペアプロは開発効率を上げるためのもので、不具合を減らしたりするものではないと考えています。結果的に減るかもしれないけど、それを目的としているわけではない、ということです。
有効なダブルチェックをするなら、同席同時ではなく独立がいいとありますが (p.28)、これはプログラミングでも同じだと思います。
その他雑多な話
- 「誤薬防止のための6R」なるものがあるそうで、プログラマ的にも「正しい計算量」「正しい権限」みたいに書けると教育に良さそう
- ダブルチェックは、エラーそのものを減らすのではなく、発見するため
- James Reason のエラーの定義では「偶然の作用に起因しない」。Wikipedia のヒューマンエラーにもそう書いてあった
- 話題のトリプルチェックの図は「人間による防護の多重化の有効性」がソース。日本品質管理学会の、島倉、田中による論文
- 最初読んだときは SLO との類似性を求めていたけど、読んでいったらちょっと違う感じだった
以上、プログラマが読んでも色々と考えさせられる資料でした。
ウェブサービスなら多少のエラーは許容する戦略がありうるけど、医療現場でそれはできないだろうな……と思ったら「有害事象につながらないエラーは発生しても許容しましょう」という結論だったのにはびっくりしました。でも実際に効果が出ているようで安心しました。