レビューをOKにしたのであればその結果を残す

僕のチームでは二次障害（仕様変更等を行ったことにより新たに埋め込まれた障害）が発生する毎に根本原因究明・再発防止検討のためふりかえりを行うという非常に健全なルールがあるのだが、その中で思ったことを。

レビューOK、なんで？

その障害は「ある項目がブランクのまま別の項目を編集しようとすると、予期しないバリデーションが働き画面が動かなくなる」という事象だった。

直接的な原因は「今回改修方法として実装済であった別項目編集後に動くバリデーションロジックを別の項目にコピペしたら八方塞りになってしまうケースがありえた」というところなのだが、システム開発に従事する方であれば口を揃えてこう言うだろう。「ブランクの値をテストしないなんてあり得ない！」と。

我々もそう考えた。僕のチームではテスト仕様書レビュー時にはレビューシートでテストケースに考慮漏れがないか、これまた健全なルールを以って確認しており、当然値が正常値・異常値・閾値のケースとともにブランクのケースも網羅しているかをチェックしている。

では今回はレビュー結果はどうだったのか？確認するとレビューOKになっている証跡がしっかりと残っていた。

ブランクの考慮は対象外

しかしそれをよくよく見てみると、レビュー者はブランクの考慮は「対象外」としていたのだ。つまり、そのポイントのレビュー結果はOKでもNGでもなくN/Aの扱いであった訳だ。（それも含めてテスト仕様書全体のレビュー結果はOK、という状況。）

なぜレビュー対象外としたかというと、「今回の項目ではブランクになることがあり得ないから」。

確かに、今回バリデーションを追加した項目自体にはブランクの値は発生し得なかった。しかし、バリデーションで参照している項目にはブランクが発生するケースがあり、その場合八方塞りのロジックに入ってしまう、ということで、「他の項目がブランク」というところまでレビュワーが（もちろんテスト仕様書作成者も）気付けなかった、という訳。

「気付き」が生まれる仕組み

どうすればこの障害を防げただろうか。

その方法は無限にあるのだけれど、個人的に一番もったいなかったのは、せっかくレビューをする仕組みがあるのにそこで「気付き」が生まれなかったこと。

レビューシートにOK、NG（とN/A）しか記載する必要がなく、「なぜそう判断したのか」を書く必要がほとんどなかったのだ。そこで「なぜそう判断したのか？」をしっかりと書かせるフォーマット、ないしルールになっていれば、まずは最悪でも「XXXの項目ではブランクはあり得ないためN/A」となっただろう。そう書きかけたレビュワーが「でもAAAの項目も関係あるよな？そっちは考慮しなくていいんだっけ？」と気付いてくれる可能性は、理由を明文化しない時に比べて飛躍的に上昇する。（さらに、僕のチームでは、レビュワーのレビュー結果を受け入れチェックする体制になっているので、最低でも受け入れチェック時に気付く可能性は非常に大きい。）

もちろん理由を文章化する分工数はちょっとだけ増えるので最終的には効果対工数の問題なのだが、「文字に落とすことで得られる気付き」の価値の大きさは、測定し辛い内容なだけに過小評価されている気がする。