はじめに
個人開発や小さなSaaSを作っていると、最初はユーザーから feedback をもらえるだけでかなり嬉しいです。
「ここが分かりにくいです」
「この機能がほしいです」
「この画面でバグりました」
みたいな声が来ると、ちゃんと使ってくれている人がいるんだな、という実感があります。
ただ、少しずつユーザーが増えてくると、feedback はだんだん管理しづらくなります。
最初は Notion やスプレッドシートで十分だったのに、気づいたら Discord、メール、問い合わせフォーム、GitHub Issue、X のリプライなど、いろいろな場所にユーザーの声が散らばっている。
そして、どれが重要なのか分からなくなってきます。
この記事では、個人開発SaaSや小さなチームで「ユーザーフィードバックが散らばる問題」をどう設計すればよいか、自分なりに整理してみます。
最初は手作業でもなんとかなる
ユーザーが少ないうちは、feedback 管理はかなり雑でも回ります。
たとえば、こんな感じです。
- Discord の投稿を見て対応する
- メールで来た要望を Notion に貼る
- バグ報告を GitHub Issue にする
- 気になったものだけスプレッドシートに残す
- 重要そうな要望は Slack にメモする
この段階では、まだ大きな問題にはなりません。
開発者本人が全部覚えていられるし、ユーザーとの距離も近いので、「あの人が言っていた要望だな」と思い出せます。
ただ、これはユーザー数が少ない間だけです。
ユーザーが増えると何が起きるか
ユーザーが少し増えると、feedback は単純に「数が増える」だけではなく、質もバラバラになります。
たとえば、以下のような状態になります。
1. 同じ要望が別の言い方で何度も来る
あるユーザーは「CSV エクスポートがほしい」と言い、別のユーザーは「データを外部で分析したい」と言います。
表現は違いますが、実際にはかなり近い要望かもしれません。
ただ、手作業で見ていると、これらが同じニーズなのか、別のニーズなのか判断しづらくなります。
2. Bug、要望、質問が混ざる
ユーザーから来る声は、きれいに分類されているわけではありません。
- バグ報告
- 機能要望
- 使い方の質問
- UI への不満
- 料金への不満
- 競合サービスとの比較
- ただの感想
これらが同じ場所に流れてくると、何から見るべきか分からなくなります。
3. 優先度が「声の大きい人順」になる
これは小さなチームほど起きやすいと思っています。
強く言ってくるユーザーの要望を先に対応してしまう。
何度も催促されるものを重要だと思ってしまう。
最近見た feedback を優先してしまう。
もちろん、声の大きいユーザーの意見が重要なこともあります。
ただ、それだけで優先度を決めると、本当に多くのユーザーが困っている問題を見落とすことがあります。
4. ユーザーに進捗が伝わらない
開発側はちゃんと改善しているつもりでも、ユーザーにはそれが伝わっていないことがあります。
たとえば、裏側でバグを直したり、細かいUX改善をしたりしていても、ユーザーから見ると「最近何も変わっていない」ように見えます。
これはかなりもったいないです。
プロダクトは動いているのに、ユーザーには「止まっている」ように見えてしまうからです。
Feedback / Roadmap / Changelog は分けて考えない方がよさそう
feedback 管理というと、最初は「ユーザーの声を集める場所」を作ることだけ考えがちです。
ただ、実際には feedback だけでは閉じません。
個人的には、以下の3つをセットで考えた方がよいと思っています。
| 要素 | 役割 |
|---|---|
| Feedback | ユーザーの声を集める入口 |
| Roadmap | これから何に取り組むかを見せる場所 |
| Changelog | 実際に何を改善したかを伝える場所 |
Feedback は入口です。
でも、ユーザーから見ると「送った feedback がどうなったのか」が見えないと、だんだん送る意味を感じなくなります。
そこで Roadmap が必要になります。
Roadmap があると、ユーザーは「この要望は検討されているんだ」「この機能は開発中なんだ」と分かります。
さらに Changelog があると、「ちゃんと改善されている」「プロダクトが生きている」と伝わります。
つまり、feedback 管理は単なる問い合わせ管理ではなく、ユーザーとのコミュニケーション設計に近いと思っています。
AI でできること、できないこと
最近は AI を使って feedback を整理することも現実的になってきました。
AI が向いているのは、たとえば以下のような処理です。
- feedback の分類
- 重複している要望の検出
- 長い投稿の要約
- Bug / Feature Request / Question の切り分け
- 類似 feedback のグルーピング
- 多言語 feedback の整理
特に、Discord やメールなどから雑多な feedback が入ってくる場合、AI による一次整理はかなり相性がよいと思います。
一方で、AI に全部任せるのは少し危険です。
たとえば、優先度の最終判断は人間が見るべきだと思っています。
なぜなら、優先度には以下のような要素が入るからです。
- 何人のユーザーに影響するか
- どのユーザー層から来ているか
- 事業上どれくらい重要か
- 開発コストはどれくらいか
- 今のプロダクト方針と合っているか
- 一時的な不満なのか、構造的な問題なのか
AI は整理には向いていますが、プロダクト判断そのものを完全に任せるには、まだ人間側の設計が必要だと思います。
自分ならこういう構成にしたい
小さなSaaSで feedback loop を作るなら、個人的には以下のような構成が扱いやすそうです。
User Feedback
↓
Feedback Board
↓
AI Categorization / Deduplication
↓
Triage
↓
Roadmap
↓
Development
↓
Changelog
↓
User Trust
ポイントは、feedback を集めて終わりにしないことです。
集めた feedback を整理して、優先度を判断し、Roadmap に反映し、実際にリリースしたら Changelog として伝える。
この流れがあると、ユーザーも「自分の声がちゃんと届いている」と感じやすくなります。
実装するなら必要そうな機能
実際に作る場合、最低限ほしい機能はこのあたりです。
Feedback Board
ユーザーが要望やバグ報告を書き込める場所です。
できれば、他のユーザーが同じ要望にリアクションできるとよさそうです。
Status 管理
feedback には状態が必要です。
たとえば、以下のような status です。
- New
- Under Review
- Planned
- In Progress
- Shipped
- Closed
状態が見えるだけで、ユーザー側の不安はかなり減ります。
AI による分類・重複整理
feedback が増えると、手動でタグを付けるのは大変です。
AI である程度自動分類できると、開発者やPMの負担がかなり減ります。
ただし、最終的な判断は人間ができるようにしておくのがよさそうです。
Public Roadmap
Roadmap は、ユーザーに対する約束というより、方向性の共有だと思っています。
すべてを細かく公開する必要はありませんが、「今どの方向に進んでいるのか」が見えるだけで、プロダクトへの信頼感は変わります。
Changelog
Changelog は軽視されがちですが、かなり重要だと思っています。
小さな改善でも、ちゃんと伝えることで「このプロダクトはちゃんと更新されている」と感じてもらえます。
特に個人開発や小さなチームでは、開発スピードそのものよりも、ユーザーに進捗が伝わることが大事な場面があります。
実際に近い OSS を触ってみた
この考え方に近い OSS として、最近 FeedLog を触ってみました。
FeedLog は、Feedback、Roadmap、Changelog をまとめて扱える open-source のユーザーフィードバック管理ツールです。
特徴としては、以下のような点があります。
- feedback を一箇所に集められる
- AI による分類・重複整理ができる
- public roadmap を作れる
- changelog を公開できる
- OSS なので self-host も選べる
- SaaS 版もあるので、すぐ試すこともできる
個人的に面白いと思ったのは、単なる feedback board ではなく、「集める → 整理する → Roadmap にする → Changelog で伝える」という流れまで意識されているところです。
ユーザーの声を集めるだけなら、Notion や Google Form でもできます。
ただ、その後に「どう整理して、どうユーザーに返すか」まで考えると、Feedback / Roadmap / Changelog が一体になっている意味は大きいと思いました。
GitHub はこちらです。
Canny のような SaaS と OSS の違い
Canny のような feedback management SaaS はかなり便利です。
一方で、小さなチームや個人開発では、以下のようなことを考える場面があります。
- まだ売上が小さいので固定費を増やしたくない
- feedback データを自分たちで持ちたい
- 必要な機能だけシンプルに使いたい
- 将来的に自分たちのワークフローに合わせて調整したい
- まずは self-hosted で試したい
もちろん、すべてのチームに OSS が向いているわけではありません。
運用コストを持ちたくない場合は、普通に SaaS を使った方が楽です。
ただ、開発者がいる小さなチームなら、OSS の feedback tool から始めるのはかなり現実的な選択肢だと思います。
小さなチームほど feedback loop は早めに作った方がいい
個人的には、ユーザーが増えてから feedback 管理を整えるより、早めに軽い仕組みを作っておいた方がよいと思っています。
理由はシンプルで、feedback はあとから整理しようとするとかなり大変だからです。
最初から完璧な運用にする必要はありません。
まずは以下だけでも十分だと思います。
- feedback を一箇所に集める
- 同じ要望をまとめる
- 状態を付ける
- Roadmap に反映する
- リリースしたら Changelog に書く
これだけでも、ユーザーとのコミュニケーションはかなり変わります。
まとめ
ユーザーフィードバック管理は、単に「要望を保存する場所」を作るだけでは不十分だと感じています。
大事なのは、ユーザーの声をちゃんと受け取り、それを整理し、プロダクトの方向性に反映し、最後にユーザーへ返すことです。
つまり、feedback 管理というより feedback loop の設計です。
特に個人開発SaaSや小さなチームでは、ユーザーとの距離が近いからこそ、この loop がプロダクトの信頼につながると思います。
まだ自分も試行錯誤中ですが、同じように「feedback がいろいろな場所に散らばって困っている」という方の参考になれば幸いです。