【ITニュース解説】"A Raw JSON Textarea Was Quietly Costing Me Users"

システム開発において、プログラムが正しく動作することだけが重要だと考えられがちだが、実際にシステムを利用するユーザーの「使いやすさ」も非常に重要である。今回の事例は、まさにそのユーザーインターフェース（UI）の重要性を示している。

この話は、データ収集やAPI連携を行う「アクター」と呼ばれるプログラム群を運用している開発者の経験に基づいている。アクターとは、特定のタスクを実行する小さなプログラムのことで、ここではサーバー上で動作するスクレイパー（Webサイトから情報を自動で収集するツール）やAPI連携ツールを指す。開発者は、自身が管理するいくつかのアクターの利用状況を分析していた。その中で、「企業購買シグナルレポート」という特定のアクターの利用状況に、非常に異常なパターンがあることに気づいた。このアクターの入力ページを開いたユーザーは5人いたのに、実際にアクターを実行したユーザーはたった1人だったのだ。他のアクターでは、入力から実行までの間にユーザーが徐々に減少する（これは一般的なことだ）のに対し、このアクターでは突然、利用率が大きく落ち込んでいる、まるで崖から落ちるような状態だったのである。

この異常な利用率の低下の原因を探ったところ、問題はアクターのコードそのものにはなかった。コードは設計通りに動作していた。問題は、ユーザーがアクターにデータを与えるための「入力フォーム」にあったのだ。このアクターには、companies（企業群）という名前の一つの主要な入力フィールドがあった。このフィールドは、技術的には「オブジェクトの配列」を受け取るように設計されていた。オブジェクトの配列とは、例えば[{ "domain": "example.com", "greenhouseSlug": "value1", "leverSlug": "value2" }]のように、複数のデータ項目（この場合はdomain、greenhouseSlug、leverSlug）をまとめたものを一つの塊（オブジェクト）とし、その塊を複数（配列）で渡す形式を指す。しかし、アクターが動作するApifyというプラットフォームのコンソール（管理画面）では、この入力フィールドが「生のJSONエディタ」として表示されていた。JSONとは、データを人間が読み書きしやすい形式で記述するための標準的なテキスト形式である。生のJSONエディタとは、ユーザーが直接JSON形式のテキストを入力しなければならないフォームのことだ。

ほとんどのユーザーは、このアクターを一回実行する際に、たった一つの企業についてのみ情報を入力したいと考えていた。しかし、彼らが目にする入力フォームは、真っ白なJSONテキストエリアだった。そこに「オブジェクトの配列」という複雑な形式でデータを入力するよう求められるのは、初心者にとって非常にハードルが高く、直感的ではない。例えば、単一の企業情報だけを入力したい場合でも、ユーザーは角括弧や波括弧、引用符などを使って正確なJSON形式を記述する必要があった。これは、単に「会社のドメイン名を入力してください」といった分かりやすいテキストボックスに慣れているユーザーにとって、非常に不親切な体験であり、多くのユーザーが入力段階で利用を諦めてしまっていたのだ。入力形式が技術的に正しくても、それがユーザーにとって使いにくいものであれば、システムは利用されなくなってしまうという典型的な例だった。

この問題に対する解決策は、非常にシンプルで小さなものだった。開発者は、既存のcompaniesという配列フィールドはそのまま残しつつ、その横に「単一の項目を入力するためのフラットなフィールド」をいくつか追加したのだ。具体的には、domain、greenhouseSlug、leverSlugという、それぞれが単独でテキストを入力できるフィールドを追加した。これにより、ユーザーは複数の企業情報を複雑なJSON形式で入力する必要がなくなり、最も一般的なケースである「一つの企業の情報だけを入力したい」場合に、より直感的で簡単な入力方法を選べるようになった。

そして、アクターのコードも少し変更された。新しい単一入力フィールド（例えばsingleDomain、greenhouseSlug、leverSlugなど）に値が入力されていれば、コードはまずその値を優先して処理する。もしこれらの単一入力フィールドが空の場合や、複数の企業情報を一度に扱いたいユーザーがいる場合は、既存のcompaniesInputという配列フィールドにフォールバック（切り替え）して、そちらの値を処理するように修正された。具体的なコードの一部を見ると、const companies = singleDomain ? [{ domain: singleDomain, greenhouseSlug, leverSlug }] : (companiesInput?.length ? companiesInput : defaultCompanies); となっている。これは、「もしsingleDomain（単一のドメイン名入力フィールド）に値があれば、その値を使って一つのオブジェクト（{ domain, greenhouseSlug, leverSlug }）の配列を作成する。そうでなければ、companiesInput（元々あった配列入力フィールド）に値があればそれを使用し、何もなければdefaultCompanies（デフォルトの企業情報）を使用する」という意味である。このように、入力の優先順位を設けることで、多様なユーザーのニーズに対応しつつ、最も一般的な使い方を簡単にしたのだ。

この変更を適用した結果、「企業購買シグナルレポート」アクターの利用率は劇的に改善された。この成功を受けて、開発者は自身の管理する他のアクターにも同様の問題がないかを確認した。"editor": "json"という設定で「オブジェクトの配列」を受け取るフィールドがあり、かつ単一項目を入力するショートカットがないパターンを探したところ、「採用トラッカー」「天気トラッカー」「リスクブリーフィングツール」「市議会モニター」という、他にも4つのアクターで全く同じ入力の摩擦（使いにくさ）が見つかった。これら全てのアクターに対して同様の修正を適用した結果、それぞれのアクターでも利用率が改善し、効果が実証された。

この事例が特に示しているのは、コードのレビューだけではこのような問題は発見しにくいということである。コードレビューでは、プログラムの論理的な正しさや効率性、セキュリティなどが主にチェックされる。しかし、ユーザーがシステムを実際に利用する際の感覚や、どこで戸惑い、どこで操作を諦めてしまうかといった「ユーザー体験」に関わる問題は、実際にユーザーが操作する様子を観察したり、利用データを詳細に分析したりしないと見えてこないことが多い。バックエンドのロジックが完璧に機能していても、ユーザーが入力フォームで躓いてしまえば、そのシステムの価値は十分に発揮されない。システム開発者は、単にプログラムを正しく動かすだけでなく、システムを使う「生身の人間」の視点に立って、どうすればより使いやすく、よりスムーズに目的を達成できるかを常に考える必要があるという大切な教訓を示している。ユーザーの使い勝手を考慮した設計は、システムの成功に不可欠な要素なのだ。