【ITニュース解説】"Unknown" was the right third value. It is not enough on its own.

システムやプログラムの状態をチェックする際、多くの場合は「成功」か「失敗」の二択で判断する。しかし、実際には「不明」という第三の状態が存在し、これを見過ごすと予期せぬ問題を引き起こす可能性があることが、この記事では強調されている。単に「不明」という選択肢を追加するだけでなく、それが明らかにする新たな課題と、それらに対処するための考え方が提示されている。

記事の筆者は、システム内の制約が解除可能か否かを判断する小さなプログラムを運用していた。このプログラムは、設定ファイルから特定の値を読み取り、その有無で判断を下していた。しかし、ファイルに該当する値が全く存在せず空の場合、プログラムはこれを「値がない＝解除不可」と解釈してしまっていた。この結果、実際には解除されていない制約が、プログラム上では「解除可能」と誤って判定されてしまう「偽の正常判定」が発生した。この問題に対処するため、筆者はプログラムの判定結果に「解除可能」「まだ解除不可」に加えて、「条件を読み取れなかった」という第三の選択肢を追加した。これにより、不明な状態を明確に区別できるようになり、意図しない誤った正常判定を防ぐことが可能になった。この修正は当初の目的通りに機能したが、「不明」という第三の値が導入されたことで、さらに四つの新たな「間違い方」が明らかになったという。

一つ目は、「ゼロ」という結果が実際には「不明」であったケースである。ある危険なコードがシステムから削除されたかを確認するため、筆者はgrepコマンドを使ってコードの存在を検索した。コマンドは「0」という結果を返し、これは通常「該当するコードは存在しない」ことを意味する。筆者はコードが削除されたと判断したが、実際には検索パターンにわずかな誤りがあり（スペースの有無）、コードは存在していたにもかかわらず見つけられなかっただけであった。コマンド自体は正常に終了し、出力も「0」というクリーンな結果であったため、エラーとして認識しづらかった。これは「実行はされたが、主張（コードの有無）を確立できなかった」という状態に他ならない。この経験から、あるパターンが一度も「存在する」と確認できていない場合、その検索結果が「0」であっても、それは「存在しない」のではなく「不明」であると考えるべきだ、という教訓が生まれた。

二つ目は、「該当なし（Not applicable）」という結果が実際には「見ることができなかった」であったケースである。システムの状態をチェックするツールが「該当なし」と報告する場合がある。これはチェックすべき対象が存在しない場合など、正当な結果であることもある。しかし、あるチェックツールが筆者の記事に対して「該当なし」と報告した際、実際には記事内に特定の形式で書かれた割り当て（アサインメント）が存在していたにもかかわらず、ツールがそれを認識できずに「該当なし」と判断していたことが判明した。つまり、チェック対象は存在していたのに、ツールがそれを「見ることができなかった」のである。このような「該当なし」は、実際には問題を見落としている可能性を隠している。この問題への対策として、ツールが「該当なし」と報告した場合、実際にチェック対象の既知の例を与えて、ツールが正しく認識できるかを確認するべきだというルールが作られた。確認できない場合は、「該当なし」ではなく「不明」と記録すべきである。

三つ目は、一つの「正常」が実際には三つの異なる状態を隠していたケースである。筆者は、自身の三つのヘルパープロセスが「生きている（alive）」かどうかを日常的にチェックしていた。この「生きている」という一つの状態は、長らく単一の正常な状態として扱われていた。しかし、詳細に分析すると、この「生きている」という状態は実際には、「監視プロセスが稼働している」「実際にワーカーが最近活動している」「未処理の依頼が残っていない」という三つの独立した事実の組み合わせであることが明らかになった。例えば、監視プロセスが正常に稼働していても、実際に仕事を担うワーカーが数日間何もしていなかったり、活動の兆候とされる信号が、ワーカー自身の活動ではなく、データベースファイルの更新や監視プロセス自身の記録であったりするケースがあった。この経験から、一つのチェック項目が実際には複数の異なる要素を測っている場合は、それぞれを個別のチェックとして扱い、それぞれに「不明」という可能性を持たせるべきだという教訓が得られた。

四つ目は、測定結果は正しかったものの、その原因に関する説明が誤っていたケースである。筆者は、新しくリリースされた検索インデックスで、最新のドキュメントが実際には一週間前の古いものであることに気づいた。この測定結果自体は正確であり、確認した74件中71件のドキュメントが指定された期間内のものであった。筆者は、その原因を「ドキュメントを収集するプロセスが一時停止していたため」と推測し、記録した。しかし、実際にはその収集プロセスはすでに再開されており、本当の原因は、インデックスがレビューのために意図的に古い情報源のリストから構築されていたためであった。測定結果は正しかったが、その原因に関する説明は古く、不正確だったのだ。このことから、観察結果、その原因に関する説明、そしてその説明が現在の状態と一致するかどうかの確認、という三段階が必要であることが示された。原因を特定する際は、その原因の担当者から現在の状態を直接確認することが重要である。

これらの経験から、システムエンジニアが学ぶべき重要な教訓は、「不明」という第三の値は、システムの状態チェックにおいて非常に強力な概念であり、従来の二値判断では見過ごされていた問題を明らかにするという点である。しかし、単にこの値を追加するだけで全てが解決するわけではない。第三の値を導入することで、これまで気づかなかった「クリーンなゼロが実は不明だった」「該当なしが見落としだった」「一つの正常が複数の状態を隠していた」「正しい測定結果でも説明が古い」といった、新たな「間違った状態」が露呈する。したがって、ツールが「不明」と報告しない場合でも、システムエンジニアは、見かけ上の成功やきれいなゼロを安易に鵜呑みにせず、常に「これは本当に正しいのか、それとも見えていない部分があるのか」という疑問を持ち、自ら「不明」の可能性を問い続ける批判的な姿勢が求められる。第三の値は、システムが抱える問題をより明確にし、その失敗を早期に発見するための強力な手段となるのだ。