【ITニュース解説】My checks failed nine times in one day. The checks on my checks caught all nine.

システム開発において、私たちが作成するプログラムやシステムが正しく動作しているかを確認する「チェック」は非常に重要だ。しかし、このチェック自体が完璧であるとは限らない。時には、チェックが「成功」と報告しているにもかかわらず、実際には正しく機能していない、あるいは間違った情報を測定しているという事態が発生することがある。ある開発者は、たった一日で自分の使っている測定器（チェック）に9つもの欠陥を発見した経験を語っている。これらの欠陥は、誤ったトークンを使っていたり、定数が間違っていたり、意図しない単語にパターンが一致してしまったりといったもので、本来ならシステムに深刻な影響を与える可能性があった。しかし、これらの欠陥はどれ一つとして他の開発者に影響を与えることなく、その場で発見・修正された。それは、それぞれのチェックに「二次的な、より単純なチェック」を付属させていたからである。この経験から生まれた、あらゆる測定に適用できる5つの制御について解説する。

まず一つ目は「ポジティブコントロール」だ。これは、チェックが「成功」と報告する能力があることを確認するためのものだ。何かを検索して「0件ヒット」という結果が出た時、本当に何も見つからなかったのか、それとも検索ツール自体が壊れているのかを判断することは難しい。そこで、必ずヒットするはずだと分かっている対象に対して一度チェックを実行する。もしその「確実な成功例」に対してもチェックが失敗するようなら、そのチェックツール自体が壊れていると判断し、本来の測定結果を信じる前に修正に取り掛かることができる。例えば、あるツールの名前がファイル群に含まれているか確認したい場合、そのツールのソースコードには当然そのツールの名前が含まれているはずだ。もしソースコードを検索してもツールの名前が見つからないなら、検索に使っているルール（正規表現やキーワード）が間違っているとすぐに気づくことができる。つまり、「0件」という結果が意味を持つのは、その同じツールが直前に「1件以上」を検出できることを示した場合のみである、というルールを適用する。

二つ目は「ネガティブコントロール」で、これはポジティブコントロールの逆の考え方だ。チェックが「失敗」すべきときに正しく失敗することを確認する。つまり、絶対に存在しないはずの対象をチェックし、「0件ヒット」が返ってくることを確認する。ここで重要なのは、この「絶対に存在しないはずの対象」を常に新しく生成して使うことだ。例えば、「zzz-nope」のような文字列を検索したが、これが39件もヒットしてしまったとする。これは、他の文書でたまたま同じ「明らかに存在しないはずのプレースホルダー」が使われていたために起こる。このような事態を避けるため、チェックを実行するたびに乱数などを用いて「neg-xxxxxxxx」のような一意の文字列を生成し、それを検索対象に含める。このようにすれば、直前に生成した文字列が既存のファイルにすでに含まれているということは考えられないため、もしヒットすればチェックルールが間違っているとすぐにわかる。

三つ目は「セカンドインスツルメント（第二の測定器）」だ。これは、同じことを二つの全く異なる独立した方法で測定し、その結果が一致するかどうかを確認する手法だ。もし二つの測定器が同じ「もの」を測っているはずなのに異なる結果を出した場合、その不一致こそが最も価値のある情報となる。例えば、特定のフレーズの出現回数を数えるとき、grep -c（一致する行数を数える）と grep -o | wc -l（一致する文字列の出現回数を数える）では、同じような結果に見えても意味が異なる場合がある。grep -cで数えすぎた結果、uncomfortableやaccountableの中にtableという単語がマッチしてしまっていたケースや、5/5という文字列を探していたが、文書中の***5/5***というフォーマット付きの値が認識されなかったケースなどがある。また、特定のプロセスが実行中かを確認する際に、その確認コマンド自体がパターンに一致してしまい、自分自身のプロセスをカウントしてしまうこともあった。このように、異なるツールや異なるアプローチで同じ概念を測定し、結果の不一致を発見することで、それぞれの測定器に潜む欠陥を見つけ出すことができる。

四つ目は「インポッシブルナンバー（不可能な数値）」の検出だ。これは、測定結果が論理的にありえない数値になっていないかをチェックするシンプルな方法である。ほとんどの測定結果には、満たすべき明確な関係性がある。例えば、「部分が全体より大きくない」「失敗の数が試行回数より多くない」「終了時間が開始時間より前ではない」といった関係だ。もしあるテーブルに7行しかないのに、ユニークなキーが10個あると報告されたら、それは明らかに不可能だ。筆者はこのケースで、テーブル外の太字の数字までパターンが拾ってしまっていた欠陥を発見した。このようなチェックは一行のコードで簡単に記述でき、測定器がいつの間にか何を測定しているのかを変えてしまっていた場合に、すぐに異常を検知できる。テストスイートを構築するまでもなく、自明な論理的矛盾を検出する。

五つ目は、何かを「書き込む」操作を伴う場合、「意図的に二度実行する」という手法だ。以前、あるツールがファイルをコピーして他の場所に配置する際、同名のファイルがすでに存在すると、警告なしに上書きしてしまうという問題があった。これは18回も気づかれずに発生した。この問題を解決した新しいツールでは、上書きを拒否し、上書きが発生しようとすると明確に失敗するように改善された。しかし、そのツールが本番運用された際、まず一度ファイルを配信し、その直後にもう一度全く同じファイルを意図的に配信したところ、驚くべきことに、そのツール自身の「配信記録（レシート）」が上書きされて消えていた。受信者側のファイルは問題なく維持されたものの、ツールが「何をしたか」を記録する部分に、以前のツールと同じ上書きバグが残っていたのである。この欠陥はわずか12秒で発見できたが、それは二度目の実行を意図的に行ったからだ。この教訓から、何かを書き込む処理を行う場合、最初の実行の直後に全く同じ二度目の実行を行い、その結果として、ターゲットのシステムと、自分自身の記録の両方が期待通りの状態になっていることを確認するというルールが生まれた。

これらの制御は非常に強力だが、すべての問題を解決するわけではない。例えば、ファイルのハッシュ値（SHA-256など）は「バイト列が変更されていない」ことを証明するが、「そのバイト列の内容がそもそも正しいか」については何も語らない。また、二つの異なるパスが実際にはシンボリックリンクによって同じファイルを指しているという状況もある。見た目上は別のファイルのように見えても、実体は一つだったというケースで、ファイル比較を行う前に、それがシンボリックリンクではないことをtest -Lなどで確認する必要がある。

結局のところ、一日で発見された9つの欠陥は、特別な悪い日に起こった稀なミスではない。それらは、測定という行為を詳細に見てみると、常に存在する可能性のある問題を示している。これらの欠陥が他の開発者に影響を与えるか否かの違いは、開発者のスキルによるものではなく、それぞれの測定器に付属していた、より単純な二次的な測定器の存在によるものだった。それは、必ず見つけるべき既知の成功例、絶対に合致してはならない新しい失敗例、第一の測定器と共有しない第二の測定器、絶対に発生しない不可能な数値、そして書き込み操作に対する意図的な二度目の実行だ。一度も失敗するのを見たことがないチェックは、まだ本当のチェックとは言えない。一度意図的に失敗させてみることが、そのチェックの信頼性を確認するための最も重要なステップなのである。これらの制御はチェックを完璧にするものではないが、壊れたチェックを可視化し、早期に問題を特定する上で極めて有効な手段となる。