GMOアドパートナーズのtakedaです。
長年システムエンジニアやってると事故の一つや二つは起こすことあると思います。規模の大小はともかくとして。
で、事故対応に必ずついてくるのが再発防止策。ここで「確認不足のためダブルチェックします」みたいな防止策を述べたり見たりした人はまあまあ多いんじゃないでしょうか。これを撲滅したいっていう話をします。
あ、きちんと設計されたダブルチェックは有意義なものなので、そこは誤解されないよう始めに断っておきます。
なぜ撲滅したいのか
ダブルチェックを再発防止策に採用することにはいくつか問題があると思います。
・単純に工数が増大する
当然ながらチェッカーの工数がかかります。さらにいうとチェッカーたり得るのはより生産性の高いエンジニアであることが多く、チームとしての生産性に悪影響があります。
・問題を未然に発見するための施策であり、そもそも問題を作りこまないという思想がない
文字通り。作り込み原因に対策しなければ繰り返し同じ問題をチェック段階で摘出することになります。不毛ですね。
そもそも再発防止策をどう立てるか
再発防止策を立てるにあたり、なぜなぜ分析（5 why）で根本原因を特定して対策を立てるのが一般的だと思います。本当か気になって少し調べてみましたが、IPAの「情報処理システム高信頼性化教訓作成ガイドブック(ITサービス編)」（https://www.ipa.go.jp/archive/files/000051042.pdf）を見ても代表的な原因分析の手法の筆頭に挙げられていました。
なぜなぜ分析をよく知らん、という方は同資料を参照して頂きたいのですが、ざっくりいうと問題に対して直接の原因を1段階目のなぜとして、その原因事象が発生したのは「なぜ」を繰り返し根本原因に至るというような考え方です。
しかしこのなぜなぜ分析、うまく機能しないことも多く、否定的な見解もあります。
どうしてダブルチェックになってしまうのか
実際に自分が駆け出しだった頃に陥った例を挙げます。まあちょっとレベルの低い話ではあるのですが、複数プロセスが同時にアクセスするファイルの排他制御をしておらずデータ不整合の問題を起こしました。この問題に対して、なぜなぜ分析（当時は5Whyでしたが）をせよ、と言われて考えました。
なぜ１：あるプロセスの処理中に別プロセスでファイルが更新されたから
なぜ２：排他制御をしていなかったから
なぜ３：していなかった理由・・？しなきゃいけないと思ってなかったから？
なぜ４：思ってなかった理由・・？
と行き詰まりました。
そもそも正解を知らずに問題を起こした人はなぜ？とオープンに聞かれてもわからないわけです。ついでになぜなぜを他人からやられるともう詰問されているとしか感じられず、すみません、僕にはわからないんでコードレビューしてもらいます、みたいになってしまいます。
ではどうするか
あくまで私見ですが、結局のところ、再発防止策として必要になるのは「どのプロセスでどうしていればその問題を作り込まなかったのか」と「その問題がどのプロセスで検出されるべきだったのか」の2点だと思っています。つまり再発防止策＝プロセス設計の改善と捉えます。
上記の問題でいうと、ファイルの排他制御をしていなかった設計不良（と同時にテストケース不足）なわけで、それに対する「なぜ」の回答は設計時の観点不足（当然対応するテストケースもない）となります。であれば再発防止策は「ファイルI/Oを伴う処理について排他制御を検討する」という設計観点（テスト観点）を加えることで一応解決します。
ちょっと話が前後しますが、つまり前提として要件定義、基本設計、詳細設計、コーディング、コードレビュー、単体テスト、結合テストなど各プロセスで考慮すべき観点リスト（=そのプロセスで何を担保するのか）が整理されている必要があります。近年はアジャイルやらスクラムやらで明示的にそんな工程確保してない、という場合も多いのですが、開発者としては小さな開発サイクルでもどこで何を担保するのかは常に意識すべきでしょう。
もう一歩考えてみる
あれ、じゃあなぜなぜ分析とかいう必要なくない？と思いますよね。
先ほど一応解決と書きましたが、ファイルの排他を知らない人がDBレコードの排他を考慮するでしょうか。また別の観点で、複数プロセスの同時実行を考慮できない人が正確なシステムリソース必要量を見積もっているでしょうか。これらはYesかも知れないしNoかも知れない、作り込んだ本人にしかわからない領域です。正しい辿り方が定義できないため、「なぜ」を繰り返すという手法が取られているのだと思います。
正直なところこうすれば良い、みたいな話はちょっと思い当たりませんが、問題の抽象化、一般化は一つのカギになると思います。排他制御が必要なケースって他に何があるんだろう？とか複数プロセス同時実行時の懸念点て他に何があるだろう？みたいなことを考えると朧げに自分に欠けている視点が見えて似て非なる問題も未然に防げることもあるでしょう。
まとめ
・効果的な再発防止策設定のためにはまずプロセスごとにどんな観点で何を担保するのか整理することが大切
・当然定めたプロセスを愚直に守ることが大切
・「なぜ」というオープンクエスチョンを改善すべきプロセスの特定と問題の一般化に落とし込む
これが正解とか思ってはいませんが、思考の型みたいなものがあると叱責されているような負の感情も意外と小さくなるのでご参考になれば幸いです。
