【ITニュース解説】The number in your marketing copy is a bug waiting to happen

あるWebサイトで、提供しているテンプレートの数が複数の場所でバラバラに表示されているという問題が発生した。具体的には、サイトの様々なページやファイルで「86個」「82個」「100+個」「96個」といった異なる数字が同時に主張されており、実際にはどの数字も正しいものではなかった。このような食い違いは初めてではなく、以前にも「80個」程度のテンプレートに対し「200+個」と広告していたことがあり、これは単なる入力ミスというよりも、正直さに欠ける問題として修正された経緯があった。手作業で多くの場所に同じ数字を繰り返し入力していると、時間の経過とともに必ずどこかで食い違いが生じ、顧客に誤った情報を提供するリスクがある。

この問題を根本的に解決するため、開発チームは実際のテンプレート数を正確に計算し、さらにWebサイトのコードベース全体を検索して、実際の数と異なる表記がないかを検出するスクリプトを作成した。これが自動化による解決への第一歩だった。

しかし、このスクリプトの最初のバージョンは、期待に反して「すべてのテンプレート数が一致しています」と報告した。この報告を信じてしまうと、Webサイトは依然として間違った情報を表示しているにもかかわらず、問題が解決されたと誤解してしまうことになる。実際には、サイトのタイトルには「96個のATS対応デザイン」とあり、料金説明には「92個のプレミアムテンプレート」と記載されており、どちらも間違っていた。そして、これら両方の間違いが、スクリプトのチェックからは見過ごされてしまっていたのである。その理由は二つあった。

一つ目の理由は、スクリプトが間違ったディレクトリをスキャンしていたためだ。Webサイトのタイトルなど、実際に検索エンジンに表示される重要な文字列は、Webサイトのソースコード（srcディレクトリ）には直接書かれていなかった。それらは、静的なメタタグを挿入するビルドスクリプト（scripts/prerender-head.mjs）の中にハードコードされていたのだ。スクリプトがスキャンする対象のルートディレクトリのリストに「scripts」ディレクトリが含まれていなかったため、これらの重要なファイルが見過ごされてしまった。さらに悪いことに、たとえ「scripts」ディレクトリを追加したとしても、スクリプトのファイル拡張子フィルターが問題を引き起こした。そのフィルターは「.ts」「.tsx」「.html」「.txt」「.md」「.json」といった拡張子のファイルのみを対象としており、ビルドスクリプトが使用していた「.mjs」という拡張子が含まれていなかったのだ。結果として、スクリプトは「scripts」ディレクトリに入ったとしても、その中のすべての「.mjs」ファイルを無視してしまい、何も検出できなかった。

二つ目の理由は、スクリプトが使用していたパターンマッチングの仮定が間違っていたことにある。スクリプトは、数字の後に「premium templates」という特定の単語が続くパターンを検索するよう設定されていた。「96 ATS-Ready Designs」という記述は、Webサイト上で最も目立つ情報の一つであるにもかかわらず、「templates」という単語を含んでいなかったため、このパターンには一致しなかった。マーケティングコピーは多様な表現を用いるため、厳密な単語の組み合わせに依存するパターンでは不十分だったのだ。この問題を解決するため、スクリプトのパターンは「premium templates」または「ATS-Ready」のどちらかを含むように修正された。

これらの修正を加えてスクリプトを再実行すると、今度は「86、82、100、96」といった不一致を報告した。これらの数字は、実はスクリプト自身のドキュメント文字列（コメント部分）に書かれていたものだった。スクリプトの作成者が、このスクリプトが存在する理由である「手動更新による数値の食い違い」を説明するために、過去の誤った数値を例としてリストアップしていたのだ。これは面白い出来事だが、自身のソースファイルをスキャンするチェッカーが陥りがちな問題であり、スクリプト自身をスキャン対象から除外する一行のコードで解決された。

これらの三つの失敗から、一つの共通のテーマが浮かび上がってくる。それは、いずれの失敗も「パターンマッチングのロジックそのもの」ではなく、「スキャン範囲の誤り」「除外されたファイルタイプ」「表現の多様性を考慮しないパターン」といった、検査の「設定」や「前提」に関するものであったということだ。そして何よりも重要な点は、これらの誤りがあったにもかかわらず、スクリプトは自信を持って「問題なし」と報告したことである。派手にエラーを出すチェッカーは多少の手間だが、チェック対象が壊れているにもかかわらず「すべて正常」と報告するチェッカーは、チェッカーがないよりもたちが悪い。なぜなら、それは「未解決の問題」を「解決済み」と誤認させてしまうからだ。

しかし、これらの経験があったからといって、スクリプトの有用性が否定されるわけではない。最終的にスクリプトは、最初の本格的な実行で四つの矛盾する数字を発見し、今では数秒で実行できるようになった。この経験から得られる教訓は、「検証ツールを作成する際には、その検証ツール自体を検証するべきだ」ということである。既知の悪い値をツールに入力し、それが正しくエラーを報告することを確認する必要がある。これを怠ると、私たちが信じたい間は「すべて問題ない」と誤った情報を伝え続けることになる。

もしあなたが開発する製品のマーケティング資料に、テンプレート数、連携サービス数、ユーザー数、対応国数などの数字が含まれている場合、それはあなたが思っているよりも多くの場所に存在し、そしてそのうちの少なくとも一つはすでに間違っている可能性が高い。Webサイトの事例のように、その間違いを発見するには、結局のところスクリプトの力が必要だったのだ。