サポートメールの最後の一文、Discordの雑談、GitHub Issues、オンラインミーティングのメモ。私たちのような少人数チームでは、開発と問い合わせ対応を同じ人が担当することも多く、忙しい週ほど大事な声が埋もれてしまいます。

以前はスプレッドシートにコピーしていました。でも、しばらくすると更新されない「もう一つの受信箱」になりました。

そこで最近は、金曜日に30分だけ、次の順番で整理しています。

最初の10分：判断せずに集める

まず、メール、Discord、GitHub Issues、打ち合わせメモを見返します。

この段階では優先順位を決めません。「夜に画面を見ると目が疲れるので、暗い表示がほしい」という声を、すぐに「テーマ機能」と言い換えないようにしています。ユーザー自身の言葉には、使う場面や困り方が残っているからです。

誰が、どこで書いたかも一緒に記録します。半年後に機能をリリースしても、依頼した人を探せなければ返事ができません。

次の10分：似ている要望を確認する

同じ要望でも、書き方はかなり違います。

• レポートをエクスポートしたい
• CSVでダウンロードしたい
• Excelでデータを開きたい

これらは同じ目的かもしれません。別々のままだと票が分かれ、本当の需要が小さく見えます。

ただし、何でもまとめるのは危険です。「毎週自動でCSVを送りたい」と「今すぐ手動でダウンロードしたい」は、必要な機能が違います。

私は「一つのリリース案内で、全部の要望に正直に答えられるか」を基準にしています。答えが違うなら、別の要望として残します。

その次の5分：次の行動を一つ決める

バックログ全体を毎週並べ替えることはしていません。少人数では、細かい点数を付けてもすぐ状況が変わります。

代わりに、数件だけ次の行動を決めます。

• 追加で質問する
• 重複としてまとめる
• 今は対応しない理由を伝える
• 調査対象にする
• 予定している作業と関連付ける

目標は、要望を全部処理することではありません。「読んだかどうか分からない状態」を減らすことです。

最後の5分：一人に返事をする

最後に、今週リリースしたもの、方針を決めたもの、見送ったものを一つ選び、要望をくれた人に返事をします。

更新履歴を公開するだけでは、本人に届くとは限りません。要望を出した人が毎週チェンジログを確認してくれる、という前提は置かないほうがよいと思います。

ツールを選ぶときに見ている点

現在、専用ツールも比較しています。

CannyやFeaturebaseは、フィードバックボードからロードマップまで一通り揃っています。一方で、ユーザー数や管理者数に応じた料金が、小規模チームに合うかは先に計算したほうがよさそうです。

Fiderはオープンソースで分かりやすい選択肢ですが、中心はフィードバックボードです。

FeedLogがまとめているカスタマーフィードバックループでは、「収集・分析・改善・通知」の4段階で整理されています。最後の「通知」を独立した工程として扱う点が、私の失敗とよく一致しました。FeedLog本体は、ボード、ロードマップ、チェンジログをつないだMITライセンスのセルフホスト型ツールです。ただし、PostgreSQL 17とpgvectorが必要なので、誰にとっても手軽とは限りません。

まだ比較中ですが、判断基準はシンプルになりました。

「誰が要望したか」「何を決めたか」「本人に伝えたか」の三つを、迷わず確認できること。

高機能であることよりも、この三つが毎週続くことのほうが大切だと感じています。