【ITニュース解説】We messed up our query builder for years. Here's the story of how we fixed it and the lessons we earned along the way.
2025年09月10日に「Reddit /r/programming」が公開したITニュース「We messed up our query builder for years. Here's the story of how we fixed it and the lessons we earned along the way.」について初心者にもわかりやすく解説しています。
ITニュース概要
とあるチームは、データ検索機能「クエリビルダー」において、UIの断片化や複雑な条件処理の課題に長年直面した。蓄積した問題とユーザーからのフィードバックを受け、抜本的な再設計を実施。使いやすさとユーザー視点の重要性を学び、直感的で高度な検索が可能な新クエリビルダーを開発した。
ITニュース解説
SigNozチームは、自社製品に組み込まれたクエリビルダーが長年にわたり抱えていた問題を解決した経験を共有している。この話は、ソフトウェア開発における失敗から学び、最終的に成功へと導く過程を示している。
クエリビルダーとは、データベースから必要な情報を効率的に検索・抽出するためのツールだ。通常、複雑なデータベース言語(SQLなど)を直接書く代わりに、ユーザーが直感的な操作で検索条件を指定できるように作られている。SigNozチームの初期のクエリビルダーは、ログ、トレース、メトリクスといった異なる種類のシステム監視データを扱う際に、それぞれが独立したインターフェースを持っていた。ログはシステムの動作記録、トレースは処理の流れ、メトリクスは性能指標といったように、それぞれ異なる目的で使われるデータである。そのため、ユーザーはそれぞれのデータを参照するたびに操作方法が異なり、全体として一貫性のない、断片的なユーザー体験を提供していた。
この断片的な体験を解消するため、チームは次にSQLベースのユーザーインターフェース(UI)を導入し、すべてのデータタイプを統一して扱えるように試みた。SQLはデータベースを操作するための標準的な言語であり、これを使えば統一できると考えたのだ。しかし、このアプローチは特にログデータの検索において根本的な欠陥を抱えていた。ログデータは、発生した事象の詳細な記録であり、特定のエラーメッセージやユーザー行動、システムイベントなど、非常に多様な情報を含む。そのため、検索する際には「エラーが発生し、かつ特定のユーザーがログインしていた場合」のように、複数の条件を「かつ(AND)」や「または(OR)」で組み合わせるブーリアンロジックや、検索条件の優先順位を明確にするための括弧を使った複雑な検索が頻繁に必要となる。しかし、彼らが導入したSQLベースのUIは、このような複雑なブーリアンロジックや括弧の扱いが苦手だった。結果として、ユーザーは自分の意図する複雑な検索条件を直感的に表現できず、期待通りの情報を見つけられないという大きなフラストレーションを感じることになった。
この技術的な問題と、それに伴うユーザーの不満は、2年間にわたって解決されずに積み重なっていった。多くのユーザーから不満の声が寄せられ、チームはついに、これまでのアプローチを根本から見直す時期が来たと判断した。この経験から、彼らはいくつかの重要な教訓を得た。
一つ目の教訓は、「どんなに技術的に『明白』だと思える機能でも、それがユーザーに『発見可能』でなければ全く役に立たない」という点だ。開発者から見れば、ある機能が便利で当然のように使えるはず、あるいは製品内の特定の場所を探せば見つかるはず、と思っていても、実際のユーザーがその機能の存在に気づかなかったり、どう使えば良いか分からなかったりすれば、その機能は存在しないも同然である。優れた機能を作り上げるだけでなく、それをユーザーが容易に発見し、直感的に利用できるデザインが不可欠であることを痛感した。これは、製品の使いやすさ(ユーザビリティ)の根幹に関わる学びである。
二つ目の教訓は、「ユーザーに代わって仮定を置くべきではない」という点だ。開発者が「ユーザーはきっとこう使いたいだろう」「この機能があれば十分だろう」と自分たちの視点だけで決めつけてしまうと、実際のユーザーのニーズや使用方法と大きな乖離が生じる。この乖離は、ユーザーにとって予期せぬ、そしてフラストレーションの多い体験を生み出す原因となる。開発者は常にユーザーの声に耳を傾け、彼らの実際の行動や困り事を客観的に理解しようと努める必要がある。自分たちの思い込みではなく、客観的なデータや具体的なフィードバックに基づいて判断を下すことの重要性を学んだ。
これらの深い学びを経て、SigNozチームは「Query Builder V5」という新しいバージョンを開発した。これは、単なる機能追加や部分的な修正ではなく、クエリビルダーのアーキテクチャ、つまりその根本的な設計と構造を完全に書き直すという大掛かりなプロジェクトだった。この全面的な再構築によって、これまで解決できなかった複雑なブーリアンロジックや括弧の処理に関するコアな技術的問題が解消された。システムの根幹から見直すことで、以前の設計では不可能だった柔軟性と堅牢性を手に入れたのだ。
さらに、このアーキテクチャの書き直しは、これまで積み重なっていた「UX負債」を解消する機会にもなった。UX負債とは、ユーザー体験に関する未解決の問題や不満が時間の経過とともに蓄積され、製品の使いにくさやユーザー満足度の低下を引き起こす状態を指す。根本的な設計を見直すことで、単に機能的な問題を解決するだけでなく、ユーザーインターフェース全体の直感性や使いやすさを大幅に向上させることができたのだ。これにより、ユーザーはよりスムーズに、より快適にクエリビルダーを利用できるようになった。
その結果、Query Builder V5は、複雑な条件を使った高度な検索を可能にするだけでなく、非常に直感的に操作できるツールへと生まれ変わった。その使いやすさは顕著で、一部のユーザーは、これまで手書きで複雑なClickHouse SQLクエリ(ClickHouseというデータベース向けのSQL)を直接書いていたにもかかわらず、自発的に新しいQuery Builder V5を使うようになったという。これは、新しいクエリビルダーが単に問題を解決しただけでなく、ユーザーの作業効率と満足度を劇的に向上させたことの明確な証拠である。SigNozチームにとって、この開発は謙虚な学びの旅であり、過去の失敗から得られた教訓が最終的な成功に繋がった貴重な経験となった。