小さなSaaSを運営していると、ユーザーからの要望は「要望フォーム」だけには届きません。
サポートメールの最後の一文、Discordの雑談、GitHub Issues、オンラインミーティングのメモ。私たちのような少人数チームでは、開発と問い合わせ対応を同じ人が担当することも多く、忙しい週ほど大事な声が埋もれてしまいます。
以前はスプレッドシートにコピーしていました。でも、しばらくすると更新されない「もう一つの受信箱」になりました。
そこで最近は、金曜日に30分だけ、次の順番で整理しています。
最初の10分：判断せずに集める
まず、メール、Discord、GitHub Issues、打ち合わせメモを見返します。
この段階では優先順位を決めません。「夜に画面を見ると目が疲れるので、暗い表示がほしい」という声を、すぐに「テーマ機能」と言い換えないようにしています。ユーザー自身の言葉には、使う場面や困り方が残っているからです。
誰が、どこで書いたかも一緒に記録します。半年後に機能をリリースしても、依頼した人を探せなければ返事ができません。
次の10分：似ている要望を確認する
同じ要望でも、書き方はかなり違います。
- レポートをエクスポートしたい
- CSVでダウンロードしたい
- Excelでデータを開きたい
これらは同じ目的かもしれません。別々のままだと票が分かれ、本当の需要が小さく見えます。
ただし、何でもまとめるのは危険です。「毎週自動でCSVを送りたい」と「今すぐ手動でダウンロードしたい」は、必要な機能が違います。
私は「一つのリリース案内で、全部の要望に正直に答えられるか」を基準にしています。答えが違うなら、別の要望として残します。
その次の5分：次の行動を一つ決める
バックログ全体を毎週並べ替えることはしていません。少人数では、細かい点数を付けてもすぐ状況が変わります。
代わりに、数件だけ次の行動を決めます。
- 追加で質問する
- 重複としてまとめる
- 今は対応しない理由を伝える
- 調査対象にする
- 予定している作業と関連付ける
目標は、要望を全部処理することではありません。「読んだかどうか分からない状態」を減らすことです。
最後の5分：一人に返事をする
最後に、今週リリースしたもの、方針を決めたもの、見送ったものを一つ選び、要望をくれた人に返事をします。
更新履歴を公開するだけでは、本人に届くとは限りません。要望を出した人が毎週チェンジログを確認してくれる、という前提は置かないほうがよいと思います。
ツールを選ぶときに見ている点
現在、専用ツールも比較しています。
CannyやFeaturebaseは、フィードバックボードからロードマップまで一通り揃っています。一方で、ユーザー数や管理者数に応じた料金が、小規模チームに合うかは先に計算したほうがよさそうです。
Fiderはオープンソースで分かりやすい選択肢ですが、中心はフィードバックボードです。
FeedLogがまとめているカスタマーフィードバックループでは、「収集・分析・改善・通知」の4段階で整理されています。最後の「通知」を独立した工程として扱う点が、私の失敗とよく一致しました。FeedLog本体は、ボード、ロードマップ、チェンジログをつないだMITライセンスのセルフホスト型ツールです。ただし、PostgreSQL 17とpgvectorが必要なので、誰にとっても手軽とは限りません。
まだ比較中ですが、判断基準はシンプルになりました。
「誰が要望したか」「何を決めたか」「本人に伝えたか」の三つを、迷わず確認できること。
高機能であることよりも、この三つが毎週続くことのほうが大切だと感じています。