【ITニュース解説】78% of my reports had nothing to say, and I spent a month tuning the wrong thing

あるIT企業が提供する監視製品について、興味深い発見があった。この製品は、ウェブサイトの状態を監視し、その変化を毎週レポートとしてユーザーに送っていた。しかし、筆者がそのレポートの内容を詳しく調べたところ、驚くべき事実が判明した。送られたレポートの実に78%が「前回から何も変化がない」という内容、つまり、ほとんどが空っぽのレポートだったというのである。

筆者は当初、この状況を見て、変化を検出するための「閾値（しきいち）」が粗すぎると考えた。閾値とは、ある基準値のことで、この値を超えたら「変化があった」と判断し、レポートに記載するというものだ。筆者は、実際の小さな変化がこの閾値よりも小さいために検出されておらず、もっと閾値を細かく設定すれば、より多くの変化を捉えられるだろうと推測した。そして、この閾値の調整に多くの時間を費やした。これは、システムを改善しようとするエンジニアにとって自然な発想である。何か問題があれば、設定値を調整して改善しようと試みるのはよくあることだ。

しかし、時間をかけて閾値を調整しても、問題は解決しなかった。筆者は最終的に、問題は閾値の設定ではなく、レポートという「成果物」そのものにあると気づいた。「変化がない」と報告するレポートは、感度が低いのではなく、そもそも伝えるべき内容がないレポートなのだ。この認識の転換が非常に重要だった。

では、なぜ「変化なし」がこれほど多く発生したのか。筆者はその理由について、深く考えた結果、ある単純な事実にたどり着いた。多くのウェブサイトにおいて、監視対象となっている特定の要素（例えば、検索エンジン向けのrobots.txtファイルや、サイトの構造を示すスキーママークアップなど）は、一度設定されると頻繁には変更されない性質を持つ。ユーザーがウェブサイトの初期設定を完了し、発見された問題を修正すれば、その後のサイトの状態は「静的」、つまり変化がほとんどない状態になるのがむしろ正常なのだ。このような状況では、「何も起こらなかった、そしてそれで問題ない」というメッセージが正直な答えとなる。

にもかかわらず、監視製品が「毎週レポートを送る」という形式をとっていたのは、単に「監視製品は週次レポートを出すものだ」という業界の慣習に従っていたからに過ぎなかった。しかし、「変化の少ない信号」を扱う製品にとって、毎週のレポートは、データの特性に合っていない。何も変化がないことを毎週メールで知らせたり、ダッシュボードで確認させたりすることに、ほとんど価値はないのである。これは、システム設計において、システムの振る舞いとデータの性質を一致させることの重要性を示す事例だ。

そこで筆者は、本当に測定すべき指標は何かを考え直した。その結果、重要だと考えたのは、「生成されたレポートのうち、受信者がまだ知らない情報を少なくとも1つ含んでいる割合」、つまり「コンテンツ率」という指標だった。筆者の製品におけるこのコンテンツ率はわずか22%だった。この数字を知ることで、製品の方向性に関するあらゆる決定が根本的に変わってくる。閾値の調整ではなく、もっと抜本的な改善策が必要だと分かったのだ。

このコンテンツ率に基づいて、筆者はいくつかの具体的な改善策を提案している。一つは「報告頻度を信号に合わせて変更する」ことだ。毎週火曜日だからという理由でレポートを送るのではなく、実際に何らかの変化があったときにだけ送るべきだという。あるいは、「何も動きがなかった」というメッセージは、月次の要約レポートに含めるのは良いが、毎週のメールで送るのは不適切だという指摘である。

次に、「実際に変化する信号を追加する」ことも重要だ。筆者が監視していた多くの要素は、サイト所有者が能動的に変更しない限り動かないものだった。しかし、競合他社の検索順位、サイトが引用されたかどうかの情報、ログに現れる新しいクローラーの種類といった要素は、ユーザーが何も操作しなくても変化しうる。こうした動的な情報こそ、ユーザーに伝える価値があるのだ。

さらに、「安定性を製品の明確な主張にするか、その情報を捨てるか」という選択も提案された。「何も変化がない」という事実は、もし製品が「サイトの安定性を確認する」ことを目的としていれば非常に価値のある情報となる。しかし、もし製品が「問題を発見する」ことを目的としているのであれば、この「変化なし」という情報は単なる邪魔な情報に過ぎない。筆者の製品は後者の目的を持ちながら、前者の出力をしてしまっていたため、このズレを解消する必要があったのだ。

この「コンテンツ率」を測定する方法として、筆者はSQLクエリの例を提示している。これは、データベースに格納されたレポートデータの中から、過去のスコアと比較して変化があったかどうかを判定するためのものだ。特に重要なのは、IS NOT DISTINCT FROMという表現を使うことである。これは、通常の=（イコール）記号とは異なり、データが欠損していることを示すNULL値同士も等しいものとして扱う。これにより、スコアが欠損しているような異常な状況下でのデータも正確に比較でき、「変化なし」のレポートを正しくカウントできる。このクエリを実行して得られる数値は、閾値の感度の問題ではなく、製品そのものの根本的な性質を示すものとして捉えるべきだ。もし、ほとんどのレポートが空っぽであるなら、どんなに閾値を調整しても中身が満たされることはない。

筆者はこの経験から、最も重要な教訓を得た。それは、システムエンジニアとしての仕事は「閾値の調整」のように、数値で測れ、コードで記述でき、変更点が明確で、日々進捗が見えるような作業に集中しがちだということだ。そういった作業は「正しい努力」のように感じられ、達成感も得やすい。しかし、今回のケースでは、本当に問うべきだったのは「このレポートはそもそも存在する必要があるのか？」という、より根本的な問いだった。この問いに答えることは、コードの変更や設定の調整のように目に見える成果を生むわけではない。しかし、この根本的な問いこそが、製品の成否を分ける最も重要な部分だったのだ。筆者は、検出されるべき「変化」がどれくらいの頻度で発生するのかを測定することなく、検出器の感度ばかりを調整していた。この順序は逆であり、本来であれば、調整を始める前に簡単なクエリ一つで、この「コンテンツ率」を確認すべきだったと反省している。

この話は、システム開発や運用において、目の前の具体的な問題解決に没頭するあまり、根本的な目的やデータの性質を見失いがちであるという重要な教訓を示している。常に「なぜこれを行うのか」「本当に価値があるのか」という問いを忘れずに、本質的な部分に目を向けることの大切さを教えてくれる事例である。