Web Storeのレビューで「エイリアス機能つけて」って言われたので、ちゃんと対応した話

前回、前々回と「同じタブで開く」の仕様を巡るドタバタと、権限まわりの整理を書いてきました。今回はちょっと毛色が違って、Web Storeのレビュー欄に届いた1件のコメントに、実際にどう対応したかという話です。

個人的な話をすると、レビューの中でも「ここが良かった」だけの感想より、「ここをこうしてほしい」という提案・要望が混ざったコメントの方が、正直だいぶテンションが上がります。使ってくれてるだけでもありがたいのに、さらに一歩踏み込んで「こうだったらもっといい」まで言語化して送ってくれるのは、地味な個人開発を続けてる身としては素直に嬉しいものです。今回はまさにそういう1件だったので、実際にどう考えて、どう対応したかを書いておきます。

目次 ① レビュー欄に来た、シンプルだけど的確な要望 ② 「エイリアス」って、具体的に何をどう表示すればいいんだっけ ③ URLを消すんじゃなくて、切り替えられるようにした ④ とりあえず返信して、実装して、審査に出す まとめ

① レビュー欄に来た、シンプルだけど的確な要望

The SwitcherをChromeウェブストアで公開してしばらく経ったある日、こんなレビューが届きました。

Works great, can you support aliases for domains? As an example https://test.xxx.com -> testing env, https://prod.xxx.com -> prod env

日本語にすると「いい感じに動いてます、ドメインのエイリアスに対応してもらえませんか？例えば https://test.xxx.com を「testing env」、https://prod.xxx.com を「prod env」みたいに」という内容です。

読んだ瞬間、素直に「いいこと言うな」と思いました。まず思ったのは、これがめちゃくちゃ的確な要望だということでした。The Switcherは本番・ステージング・ローカルみたいな複数環境を切り替えるツールなんですが、プロジェクトの環境が増えてくると、ポップアップに並ぶURLがどれも似たような見た目になって、「あれ、どれが本番だっけ」となる瞬間が普通にあります。すでに前回の記事で書いたカラーラベル機能（URLごとに色を設定できるやつ）はその対策の一つだったんですが、色だけだと「この赤色のURLって結局どの環境だっけ」という、もう一段階の変換作業が頭の中で発生するんですよね。名前で直接わかった方が速い、というのはその通りだなと。具体例まで添えてくれていたのも地味にありがたくて、おかげで実装イメージがすぐ湧きました。

② 「エイリアス」って、具体的に何をどう表示すればいいんだっけ

要望自体はシンプルですが、実装方針を考え始めると地味に悩むポイントがありました。「URLをエイリアス名に置き換える」と一言で言っても、やり方はいくつかあります。

最初は素朴にB案（併記）で考えていたんですが、実際に手を動かしてみると、環境の数が増えたときに1行の情報量が多すぎて、むしろ「見分けやすくするため」の機能なのに見づらくなるという本末転倒が起きそうでした。最終的にC案、ポップアップの下にトグルボタンを置いて、URL表示とラベル表示をいつでも切り替えられる形に落ち着きました。ラベル表示中でもURLの情報を消したくなかったので、リンクにマウスを乗せたときに実際のURLがツールチップで見えるようにしています。

③ URLを消すんじゃなくて、切り替えられるようにした

実装の細かい話を少しだけ書いておきます。データの持ち方としては、既存のカラー設定（colorsという配列でURLごとの色を持っている）と同じパターンで、labelsという配列をプロジェクトのデータに追加しました。オプション画面の各URL入力欄の横に、色のピッカーと並べて「表示名」のテキスト欄を置いて、そこに「prod env」のような名前を入れられるようにしています。

表示モードの切り替え自体は、地味に判断が必要な設計ポイントでした。これを「アカウントに紐づく設定」として同期対象にするか、「この端末だけの見た目の好み」としてローカルにとどめるか、という選択です。結論としては後者、常にその端末だけの設定として保存することにしました。理由は単純で、URL表示かラベル表示かというのは「プロジェクトのデータ」ではなく「今この画面をどう見たいか」という、その場その場の好みだからです。会社のPCではラベル表示、自宅のPCではURL表示、みたいな使い分けがあっても不自然じゃないよなと。

エイリアス機能があるのに、既存のカラー表示のヒント文（「見分けにくい場合は色を設定できます」）はそのまま残しているんですが、これも変に統合しようとせず、それぞれ独立した機能として置いておくことにしました。色もラベルも、どちらも「見分けやすくする」という同じ目的のための別々の道具なので、片方があるからもう片方が要らない、という話にはならないんですよね。

④ とりあえず返信して、実装して、審査に出す

機能ができたところで、レビューをくれた人に一度返信を書きました。「対応予定です」と先に一言添えておいて、実装が終わった後に「審査に出しました、数日で反映されるはずです」と追記する、という2段階のコミュニケーションです。

正直、この手のレビュー対応は後回しにしがちで、実装が終わってから一括で返信すればいいや、と思いがちなんですが、要望をもらった時点で一度「見てます」と反応しておくのは地味に大事だなと思っています。開発者側は「今対応中です」というのがわかっていても、レビューを書いた側からすると音沙汰がないと「読まれてすらいないのでは」という不安になりますし、他の人がそのレビューを見たときの印象にも関わってきます。個人開発の拡張機能なんて基本的に開発者は自分ひとりなので、「ちゃんと中の人がいて、ちゃんと読んでますよ」というのが伝わるだけで、レビュー欄自体の空気が変わる気がしています。

審査に出した後の返信では、「Googleの審査に提出したので、承認され次第、数日以内に反映される見込みです」という趣旨を一言添えました。ここで大事なのは「もう対応は完了していて、あとは待ちだけです」というステータスをはっきり伝えることです。ユーザー視点だと「いつ使えるようになるのか」が一番気になるところなので、そこを曖昧にしないようにしています。

地味だけど地雷になりがちなところ

機能を追加するとき、いつも気にしているのが「今まで使ってくれている人のデータを壊さないこと」です。今回で言うと、既存ユーザーの設定データには当然labelsなんてキーは存在しません。なので、コードのあちこちで「labelsがあれば使う、なければ空扱いにする」という存在チェックを必ず挟んでいます。これを怠ると、アップデート直後に「設定が消えた」「エラーが出た」みたいな問い合わせが飛んでくることになるので、新しいフィールドを1つ増やすたびに、それが無い状態（＝これまでのユーザー全員の状態）でも壊れないかを確認する、というのを毎回のルーティンにしています。地味ですが、ここをサボると信頼を一瞬で失うので、一番手を抜けないところだと思っています。

まとめ

• Web Storeのレビューは、ただの感想じゃなくて具体的な改善のヒントが飛んでくることがある。今回のエイリアス要望はその典型でした
• 「見分けやすくする」機能は、1つの正解に決め打ちせず、目的が近い機能同士（今回なら色とラベル）を共存させる方が、結果的にユーザーの選択肢が増える
• 表示に関する設定は「データなのか、好みなのか」を一度立ち止まって考えると、同期する/しないの判断がすっきりする
• 新しいフィールドを追加するときは、それが「無い」状態（＝既存ユーザー全員の状態）でも壊れないことを毎回確認する。ここをサボらないのが信頼を保つ一番の近道
• レビューへの返信は「見てます」の一言を早めに、機能が実装できたら「対応しました、あとは審査待ちです」の二段構えにすると、相手にも他の閲覧者にも状況が伝わりやすい

The Switcherはこうやって、実際に使ってくれている人からの声を拾いながら、ちょっとずつ形を変えています。感想だけのレビューももちろん嬉しいんですが、今回みたいに具体的な提案や要望が乗っかっているコメントは、次に何を作ればいいかの道しるべそのものなので、個人的には一番好物です。もし普段Chrome拡張を使っていて「ここがこうだったらいいのに」と思うことがあれば、レビュー欄でも何でも、気軽に教えてもらえると嬉しいです。