【ITニュース解説】Our lane health check was green. Four people had been waiting 43 days for an answer.

私たちのシステムは「全て問題なし」と報告しているのに、実は43日間も返事を待っている人がいたという、一見すると奇妙な出来事があった。これは、システムの健全性を測る「指標（メトリクス）」の考え方に重要な落とし穴があったことを示している。システムエンジニアを目指す上で、このような指標の設計は非常に重要であり、利用者の視点を持つことの必要性を強く教えてくれる事例だ。

システムの状態を測る指標には、大きく分けて二つの種類がある。一つ目は「私たち（システム）が何を排出したか」を測るものだ。これは、例えば「今週何件の投稿が公開されたか」「どれくらいの作業がスケジュールされたか」といった、自分たちの活動量や成果物を数える指標である。記事で言及されている「レーンヘルスチェックがグリーンだった」というのは、まさにこのタイプの指標が問題ないと報告していた状態を指す。例えば、SNSの投稿を準備したり、いくつか新しいコンテンツをスケジュールしたりといった作業が行われたとき、この指標は「よし、作業は進んでいる」と判断し、健全性を示すグリーンマークを点灯させる。しかし、この指標は自分たちの活動だけを見ているため、たとえ活発に作業が行われていたとしても、それが「誰かの困りごとを解決したか」や「誰かの期待に応えたか」という側面は一切考慮しない。自分たちが動いていればグリーンになるため、実際には誰も助けられていないのに「順調だ」と誤解してしまう危険性があるのだ。

二つ目の指標は、「誰が私たちからの返答を待っているか」、つまり「私たちが誰かに負っているもの」を測るものだ。この指標は、利用者からのコメントや質問、DM（ダイレクトメッセージ）など、相手が私たちからの反応を待っている数を数える。今回の問題の核心は、この「負債の指標」が全く存在していなかったことにある。私たちのシステムには、利用者からのコメントが何件未返信であるか、誰がどれくらいの期間返事を待っているかといった情報を把握する仕組みが一切なかった。だからこそ、システムは「問題なし」と報告し続けていたにもかかわらず、実際には4人の利用者が合計11件の会話で、最も古いものでは43日間も返事を待つという事態が起こってしまったのである。これらのコメントには、システムに対する鋭い指摘や重要な質問が含まれており、それらが長期間放置されていたことは、利用者にとって大きな不利益であったことは想像に難くない。特に、「256MBの画像ファイル処理でどれくらいのメモリを使うか」という具体的な質問に対しては、既に測定結果を記事として公開していたにもかかわらず、質問者にはその情報が届いていなかったという。これは、私たちからの一方的な情報発信だけで満足し、利用者との双方向のコミュニケーションが途絶えていたことを示している。

なぜこのような重要な情報が見過ごされてしまったのだろうか。記事では、いくつかの技術的な課題が挙げられている。まず、利用しているプラットフォーム（dev.to）には、コメントが投稿されたときに自動で通知してくれるAPI（アプリケーション・プログラミング・インターフェース）がなかった。APIとは、異なるソフトウェア同士が情報をやり取りするための窓口のようなもので、これがなければ、コメントが来たかどうかを知るためには、手動で記事を一つ一つ確認しに行くしかなかったのだ。また、コメントに自動で返信するAPIも提供されていなかったため、返答するには人間がブラウザを開き、手作業で入力するしかなかった。さらに、以前作成したコメント確認ツールも、「見たいときに自分でコマンドを実行する」という「オプトイン」形式であったため、常時稼働しているわけではなかった。これでは、わざわざ確認しようと決意しない限り、未返信のコメントを見つけることは不可能である。このような状況では、たとえツールが存在していたとしても、「意思決定を行う前に、誰もが目にするところに情報が表示される」という環境がなければ、そのツールは実質的にないのと同じ効果しか発揮しない。

この問題に対処するため、私たちは「誰が私たちからの返答を待っているか、そしてどれくらいの期間待っているか」を測定する新しいツールを開発した。このツールは、返信のないコメントスレッド、DM、さらには「一度は私たちをブロックしていたが、後でフォローしてくれたためにメッセージを送れるようになった」といった様々な種類の「負債」を自動的に検出し、集計する。このツールの設計で工夫したのは、単純に「未返信の投稿数」だけでなく、「未返信の会話数」も同時に計測することだ。一つの会話スレッドの中で複数の未返信投稿があった場合、それを全て個別の「負債」として数えてしまうと、数値は大きくなるが、問題の深刻さ（何人の人が待っているか）が分かりにくくなる。そこで、「11の会話で、合計22の投稿が未返信」というように、両方の数字を示すことで、より正確な状況を把握できるようにした。そして、この測定結果は、システムを使う全ての人が一日の作業を開始する際、必ず最初に目にする画面に表示されるようにした。これにより、システムを使う誰もが「今、どれくらいの負債を抱えているか」を常に意識し、それに対処しようという行動につながることを狙っている。

この新しい指標を導入する過程で、私たちは別の隠れた問題も発見した。それは、複数のアカウントを一度にフォローしようとしたときに、システムが一部のフォローリクエストを処理しきれずに失敗していたにもかかわらず、「全て成功した」と報告していたというものだ。これは、APIへのアクセスが一時的に制限された際のエラー処理が不十分だったために起こった。システムが「成功」と報告しても、実際には意図した結果が得られていないことがある、ということを示しており、これもまた「自分たちがやったこと」だけを測る指標の盲点であると言える。自分たちのシステムが何を報告しているかを鵜呑みにせず、常に利用者にとっての「真の実態」はどうなっているのかを検証する姿勢が重要である。

この一連の経験から得られる最も重要な教訓は、システムエンジニアとして指標を設計する際、「私たちはXを行っているか？」という自分たちの活動を測る指標だけでなく、「誰がまだXを待っているか？」という利用者の視点に立った負債の指標も必ず用意し、それを意思決定が行われる場所に表示することである。自分たちの活動量を示す指標は、いくらでも数値を上げることができ、それ自体が誰の役にも立たない「見せかけの成功」になりがちだ。しかし、利用者の体験やニーズを測る負債の指標は、実際に彼らの期待に応える行動を起こさなければ、その数値を減らすことはできない。真に価値あるシステムを開発し、運用していくためには、常に利用者の視点を持ち、彼らが何を求めているのか、何に困っているのかを正確に把握し、それに応えることが不可欠である。このプロジェクトでは、以前にも「読者がアクセスできないファイルを、開発環境では『存在する』と判断して問題なしとしていた」という教訓を得ており、これもまた「開発者の視点」と「利用者の視点」のギャップを示唆している。最終的に、利用者の視点に立ち、彼らの体験を第一に考えることが、システムの真の健全性を保つための唯一の方法なのである。私たちは今、「11の会話が待っている」という現実を常に目にしながら、その解決に取り組んでいる。