システム開発は手作業が多いです。設計書を書くのも人。プログラムを書くのもテストをするのも人がやっていることがほとんどです。定型作業を探して自動化をすることもやりますが、手作業の範囲が広いのがシステム開発の特長だと思います。今後、AIがシステム開発をしてくれる世の中がやってくるかも知れませんが、あと数年はかかるのではないでしょうか？
人がやることですから、ヒューマンエラーは起こり得ます。ミスをしない人なんていないと思います。しかし、このミスが原因で大規模なシステム障害につながることもあるのです。ですから、人が作った成果物は、しっかりチェックする必要があります。作業者がセルフチェックし、精査者が再鑑する。なんなら、有識者にもチェックしてもらう。3人の目が入っているから安心だ！と思いたいところですが、そうはならないのがシステム開発あるあるなのです。
2人、3人でチェックすると、責任が分散してしまいます。セルフチェックを適当に終わらせても、精査者がミスを拾ってくれるだろう、という発想になりがちです。実際、セルフチェックをした形跡のない成果物をよく見かけます。完全に精査者任せの、作りっぱなし状態です。
責任の薄れるダブルチェックなら、やめてしまえ！責任を持ってひとりでチェックせよ！というのは乱暴です。どれだけ注意してもヒューマンエラーは起こりうるのです。この前提は忘れてはいけません。ダブルチェックでヒューマンエラーを救う必要があります。
私の答えはこうです。ダブルチェックは必要。責任が薄れるデメリットを回避することが出来れば良いのです。どうすれば、責任を持ってもらえるのでしょうか？
まずは、チェックした証を残すのをルール化することです。昔は設計書やプログラムソースなどの成果物を紙に印刷して、ポイントをマーカーで塗りながらチェックしたものです。今はペーパーレスの流れがあり、PCの画面で確認することが多いと思いますが、基本は同じ。ポイントに色をつけたり、チェックした観点を吹き出しで書き残しておくことが必要です。そうすることで、精査者が見たときに、チェックポイントがズレていることに気づけるようにもなります。
次にチェックした証として、チェックしましたの名前を書くルールとすること。昔の紙ベースの時代では、チェックした証として自分のハンコを押す運用もありました。名前を書くことで、責任が生じます。セルフチェックせずに精査者に回すことがし辛くなります。
この２つをすればうまく行く！と思いたいところですが、これで満足するのは性善説。この運用が適切に回っていることをチェックする必要があります。全てをチェックするのは、工数増が激しくなってしまうので、抜き打ちチェックをするなどの工夫があっても良いでしょう。
ひとりひとりに責任を持ってもらい、ヒューマンエラーを防ぐ事が重要だ、というお話しでした。
