You better watch out // 刮目せよ！
You better not cry // 泣いている場合ではない
Better not pout // 拗ねている場合でもない
I’m telling you why // 理由を教えたろか
Santa Claus is coming to town // もう年末だからだよ
いいですね～ クリスマスです🎄
He’s making a list, // 一覧を作成したら、
And checking it twice; // ダブルチェックします
あ、サンタさんもダブルチェックしてますね。確認大事です。
でもダブルチェックって、何かインシデントが発生したときの対策として
<これをやっておけば防げた> かのように書かれる割には、
案外2人目の目をすり抜けてしまったりして、万全かというとそうではないんですよね。
\😸👉 ﾖｼ!/
そこで私のチームで実践している、比較的に確認効果の高いと感じられるダブルチェック・テクニックを書いておこうと思います。
チームに取り入れてよかったダブルチェック・テクニック
① 確認方法を確認する
【時間がない方もここだけは読んでほしい！！！】
今年のなかで かなり上位に入るいい発明でした。
■もともとはどうだったか：
開発者の開発物に対して、コードレビューを2回行っていました。
-
1回目のコードレビュー
MRや簡単な要件説明だけを見てソースコードの観点からレビューをする。 -
2回目のコードレビュー
時間をあけて、本人の説明付きで再度レビューする。
もともとはチーム内で同時に同じファイルを触ったことでコンフリクト・不具合が発生してしまった経緯から、次のアップ日に上がる案件を全部並べて見るという目的のもと行われていました。
その目的自体はよかったのですが、2回目のタイミングで（まあ前にもう見たしな）という気分になってしまって、シンプルに開発の中で発生する考慮漏れなどはこの体制ではなかなか防げていませんでした。
■取り入れた方法：
2回目のコードレビューは行わず、代わりに 「どのようなデバッグ方法で確認したのか」 というデバッグ方法のレビューを行うようにしました。
■どうよくなったか：
後続のエビデンスの確認の話にもつながりますが、私の所属するチームではMRとエビデンスは必ずセットで1つのチケットにまとめて記載をするルールになっています。まず1回目で見たMRの中身を確認しつつ、チケットに記載のエビデンスを見ながらどういった手順でデバッグをしたのか見ていきます。
この確認をしているのならば大丈夫だろうと、レビュー者がOKを出す確度も上がりますし、「念のためにこれも見ておいた方がいいのではないか」というようなワードも多く出てきました。MRをレビューしただけですべての不具合がわかるプロダクトというのはなかなか存在しないと思うので、挙動確認の手順をレビューするというのは大変おすすめです。チームとしてデバッグの質を担保できるいい策だったと思います。
また副産物的に、「（同じ確認内容でも）この方法の方が早くデバッグできるよ」とか「あのページにデバッグ用の便利ツールがあるから使うといい」とか「前に使った対象抽出のSQLあるからあげるよ」などの有用な情報もそこで出てきます。
総じて、先輩社員のデバッグ時の手順・観点などが引き継げるという点で教育効果も高かったです。
（一番書きたかったこと、ここまで！時間がない方は、またお時間のある時に）
②エビデンスを確認する
言わずもがなですね～
エビデンスのないテストはテストじゃない！
③ プロセスを確認する
コードレビューならまだしも、データ修正のためのSQL UPDATE文とかDELETE文なんてダブルチェックしてくださいと言われてもどないしたらええねん！！て感じですよね。
えーもうよくわかんないし いいんじゃないの？ ちゃんと確認したんでしょ？
ハイ！ちゃんと確認しました！
・・・。
■取り入れた方法：
例えばデータの書き換えを行う場合、書き換え対象を出すためのSQL文と、手順をダブルチェックする。既にある顧客リストなどから作成する場合、その作成に使ったExcelやExcel関数をダブルチェックする。
ものによっては実際に抽出した対象をいくつかピックアップしてアプリケーション側から検索し、結果が一致するかダブルチェックする。
番外編
ダブルチェックのテクニックではありませんが、日々のこういう活動が不具合・インシデントを防いでいるなと思うものを挙げてみました。当たり前のことが多いですが、凡事徹底がやはりむずかしいのです。
確認観点を書き溜める
①のデバッグ方法レビュー会などで出てきた（言語化された）観点
②のエビデンスで書き溜められた確認方法
③のような資料
そういったものををコツコツ書き溜めていきます。必ずしも全部書き溜められているわけじゃないけれど、一つ一つの案件チケットが貴重な過去資料となっていくわけなので、いつかこのチケットを見る未来人あるいは自分のために書き残していきます。
チームミーティングを活用する
週2で30分～1時間ほどチームミーティングを設けています。設計やデバッグ方法、リリース段取りなどについてチームに共有・相談・意見をもらう場となっていて、開発上なにかしらの懸念が大きい案件は基本ミーティングで共有することになっています。
他のメンバーと重要案件やリスクの共有が出来たり、フィードバックがもらえるのはもちろんのこと、人に説明するための準備段階で言語化や案件自体の理解度が進み、自分で懸念点に気づくこともできます。
ダブルチェックしやすい依頼文を書けるようになる
ダブルチェックしてくださいとだけ言われても、それを言われた人はなにをどうチェックしたらいいのかわかりません。どこをどんな観点で確認してほしいのか、依頼者が正確に依頼できる必要があります。
「AとBの件数が一致していることを確認してください」
「XXを変更したので、YYになっているかを確認してください」
（指示された点以外の不備・違和感に気づけるかどうかは、やはりやや経験値に依ってしまうなと思います）
（だからこそ言語化・明文化しておくことがより一層大事だなと思います！）
ダブルチェックしやすい<最高の手順書>を創り上げる
チーム全員が関わるような大きなリリースは、非常に細かいタイムラインを立てて手順書を作成し、当日はそれに従って動くようにしていきます。つまりリリースの当日までに最高の手順書をつくっておく必要があります。
「日付の列はいらない」とか「主担当者名とサブ担当者名のそれぞれ右列に確認済みのチェックボックスを入れろ」とか 手順書を作るだけでも侃々諤々ですが、、それをやっておくことでチームが脳内リハーサルをすることができますし、当日に手順の漏れが発生することもなく、万が一イレギュラーの発生があっても焦った頭で判断をする必要が無くなります。
まとめ
私達のチームは運用歴が長い商品ということもあり、1つ目の開発をするときから、その案件のリリース、保守運用、その次の新規開発まで添い遂げられるのか？と自分たちに問うて、より良いものを目指す文化がある素晴らしいチームです。
エンジニアたるもの、ソースコードを書いて終わりというわけにはいきません。
クライアントをはじめとする自分の開発物の利用者にポジティブをもたらそうとして開発しているにもかかわらず、ポジティブどころかBADをもらたしてはかなしいですから、よりよい方策を探求していきましょう！
サンタさんへ
もしサンタさんもダブルチェックの漏れに悩んでいたら、この記事が参考になるとうれしいよ～！🎅🎁