【ITニュース解説】My coverage check did arithmetic instead of looking. All 23 pointers were wrong.

システム開発では、作成したものが意図通りに機能しているかを確認する「チェック」が非常に重要である。しかし、そのチェックの仕方を誤ると、あたかも問題がないかのように見えても、実は深刻な不具合が潜んでいる場合がある。今回のニュース記事は、まさにそのような状況で起きた出来事を詳細に語っている。ある文書内の表には、別の文書のどこに記述されているかを示す「ポインタ」と呼ばれる情報が24行分含まれていた。このポインタは、読者が元情報と照合できるようにするための、ある情報がどこにあるかを示す「住所」のようなものだ。このポインタがきちんと機能しているかを検証する「カバレッジチェック」、つまりある機能やデータがどれだけきちんと網羅されているかを確認する作業では、常に「すべて網羅されている（Complete）」と報告されていた。しかし、後になって判明した事実は、そのチェックが全く意味をなしていなかったということである。

このカバレッジチェックは、「表にある行数」と「ポインタを持つ行数」、そして「特定の形式（ここでは『vessel』と呼ばれる形式）の行数」を単に引き算するだけで「未確認の行数」を算出していた。具体的には、24行 - 23行（ポインタあり） - 1行（vessel） = 0行（未確認）という計算であり、この結果がゼロになることで「すべて網羅されている」と判断していたのだ。この計算方法は、表の「内部的な構造」しか見ていなかったため、ポインタが指し示す先が実際に存在するかどうか、正しい内容を指しているかどうかといった「外部の現実」を一切確認していなかった。例えば、ポインタが指す行がそもそも存在しない、間違った行を指している、あるいは指しているファイル自体が削除されている、といった状況でも、この引き算の結果は常にゼロになり、「問題なし」と報告され続けてしまうのである。

最終的にポインタの指し示す先が実際に解決されたとき、23個あったポインタの全てが間違っていたことが判明した。しかも、その間違い方は非常に特徴的だった。23個のポインタ全てが、たった1行か2行だけずれているという、均一なずれ方だったのだ。この「1行または2行のずれ」という情報が非常に重要である。ポインタが指し示す先のファイルに何らかの変更（例えば途中の行が追加されるなど）があった場合、ポインタは時間の経過とともに大きく、ばらばらの行数でずれていくのが一般的だ。これは「ドリフト」と呼ばれる現象で、ポインタが古くなり、参照先と現在の状態が合わなくなることで発生する。しかし、今回の場合は「全てが1行か2行のずれ」という均一な状態だったため、これはドリフトではないと判断された。全てのポインタが作成された時点から、何らかの原因で一律にずれていた、いわゆる「オフバイワンエラー」と呼ばれる種類のバグであったことが示唆されたのだ。

ドリフトとオフバイワンエラーは、報告上はどちらも「ポインタが古くなっている」ように見えるかもしれないが、その根本原因と修正方法は全く異なる。ドリフトは時間の経過とともに発生し、個々のポインタを再設定し、以降は定期的に新鮮さを確認する仕組みが必要となる。一方、オフバイワンエラーは、ポインタを生成するプログラムやロジック自体に間違いがあった場合に発生する。この場合、個々のポインタを修正しても、原因を直さなければまた同じように間違ったポインタが生成されてしまう。したがって、ポインタを生成する部分のバグを修正し、その上で既存のポインタを全て修正する必要がある。エラーの「分布」、つまり「ずれの量」と「その均一性」を分析することで、問題の根源がどこにあるのかを特定し、適切な修正策を講じることができるという良い例だ。

筆者はこのポインタの問題を修正している最中に、さらに別の類似した問題を四つの異なるツールで見つけた。それは、データベースなどで使用される二つのテーブルのデータを組み合わせる（「結合」する）際の方法に関するものだった。多くのツールで、行の「順番」に基づいてテーブルを結合していたのだ。例えば、「こちらのテーブルの7行目は、あちらのテーブルの7行目に対応する」というように、単に上から数えて同じ位置にある行同士を関連付けていた。しかし、この「位置による結合」は非常に危険である。もしどちらか一方のテーブルに行が追加されたり削除されたりすると、それ以降の全ての行の対応関係が「サイレントに」、つまりエラーを発生させることなく間違ってしまう。データ自体は存在するため、システムは何のエラーも報告せず、あたかも正しいかのように処理を続けてしまうのだ。これは今回のポインタの問題と本質的に同じ、表面的な整合性だけで判断し、実態を見ないことの危険性を示している。

この問題を解決するため、筆者は「キーによる結合」に修正した。これは、行の位置ではなく、行ごとに割り振られたユニークな「識別子（ID）」のような「キー」を使って結合する方法である。例えば、「こちらのテーブルの『商品ID: A123』の行は、あちらのテーブルの『商品ID: A123』の行に対応する」というように、個々のデータ自体が持つ識別情報に基づいて関連付ける。この方法であれば、どちらかのテーブルに行が追加されても、キーが一致しない行は「存在しない（MISSING）」として明確に検出され、エラーとして報告される。つまり、位置による結合は「間違っていても気づけない」のに対し、キーによる結合は「間違いを検出し、報告できる」という決定的な違いがある。これはシステムが「間違った時にそれを認識し、報告する能力」がいかに重要かを示している。

今回の根本的な問題であったカバレッジチェックは、最終的にどのように改善されたのだろうか。新しい方法では、各ポインタの行が、そのポインタが指し示す先の「内容そのもの」を verbatim（一字一句そのまま）で引用して保持するように変更された。そして、カバレッジチェックでは、ポインタが保持している引用された内容と、実際にポインタが指し示す場所にある現在の内容とを比較し、一致するかどうかを確認するようになった。これは、テーブル「内部」の情報だけを見るのではなく、ポインタが指し示す「外部の世界（実際のファイルやデータ）」に問い合わせて、整合性を確認する方法だ。この改善によって、たとえ計算上の数字が正しく見えても、実際に内容が一致しなければ「不整合」として報告されるようになった。

この一連の出来事から、システム開発の初心者が学ぶべき重要な教訓が二つある。一つ目は、**「計算上の数字だけで物事を判断してはならない」ということだ。あるデータが「完全に網羅されている」という数値が正しくても、その数値が何を根拠に算出されたのか、本当に実態を反映しているのかを常に疑う必要がある。今回の例のように、外部の現実を確認しないチェックは、たとえ正しい数値を報告しても、それは単なる偶然であり、何の保証にもならない。二つ目は、「エラーが発生した際、その『数』だけでなく『分布』に着目する」**ことの重要性だ。「23個全てが古い」という報告と、「23個全てが1行ずれている」という報告は、どちらも「23個が問題」という同じ数値を提示するが、その意味合いは全く異なる。前者は経年劣化による問題を示唆し、後者は初期からの設計ミスやプログラムのバグを示唆する。エラーのパターンや分布を詳細に分析することで、問題の根本原因を正確に特定し、適切な対策を講じることができるようになる。これらの教訓は、将来システムエンジニアとして働く上で、見せかけの成功に騙されず、本当に信頼できるシステムを構築するために非常に役立つ視点となるだろう。