MVP公開後のフィードバックは、利用ログで「何が起きたか」をつかみ、インタビューや問い合わせで「なぜそうなったか」を確かめる、という組み合わせで集めるのが基本です。ログだけでは理由が分からず、声だけでは一部の利用者の意見に引っ張られます。両方を同じ利用者について突き合わせることで、初めて改善に使える情報になります。アンケートは、その中間で傾向を確かめる道具として位置づけると扱いやすくなります。
この記事は、MVPを公開した、または公開を控えている新規事業の担当者、プロダクトマネージャー、利用者の声をどう集めて改善につなげればよいか悩んでいる方に向けたものです。「アンケートを取ったが改善に使えなかった」「要望は集まるが、どれを優先すればよいか分からない」といった状況の整理にも役立ちます。
読み終えると、利用ログ・インタビュー・アンケート・問い合わせのそれぞれで何が分かり、何が分からないか、それらをどう組み合わせて集めるか、集めた情報をどう整理して改善の判断につなげるかが分かります。
MVPのフィードバック収集で目指すこと
MVPでフィードバックを集める目的は、利用者の満足度を測ることではありません。検証したい仮説が正しかったか、正しくなかったならどこが違ったかを知り、次に何を作るか、あるいは方向を変えるかを判断することです。
この目的を意識しないと、フィードバック集めは「たくさんの意見を集めること」になりがちです。意見が多いほど判断が難しくなり、結局は声の大きい利用者の要望や、担当者の印象で優先順位が決まってしまいます。
フィードバックを集める前に、次の二つを決めておきます。
- 確かめたい問い：たとえば「登録した人はなぜ二回目を使わないのか」「どの業種の利用者が最も継続しているか」「料金に対する抵抗はどこにあるか」
- 判断の期限：いつまでに、何を決めるか（続ける・変える・止める、次に作る機能を決める、など）
問いと期限が決まっていれば、どの方法で、誰から、どのくらい集めるかも自然に決まります。
4つの収集方法で分かること・分からないこと
MVPのフィードバックを集める方法は、大きく分けて利用ログ、インタビュー、アンケート、問い合わせの4つです。それぞれ得意なことと苦手なことがあります。
| 方法 | 分かること | 分からないこと | 向いている問い |
|---|---|---|---|
| 利用ログ | 実際に何をしたか、どこで止まったか、何回使ったか | なぜそうしたか、何を感じたか | どの画面で離脱しているか、継続している人の特徴は何か |
| インタビュー | 行動の理由、背景の業務や状況、言葉にされない不満 | 全体の傾向、少数意見かどうか | なぜ使わなくなったのか、何を期待して登録したのか |
| アンケート | 多くの利用者の傾向、選択肢の中での評価 | 選択肢にない理由、深い背景 | どの機能が役立っているか、料金をどう感じるか |
| 問い合わせ | 利用者がつまずいた具体的な箇所、緊急の不具合 | 問い合わせない人の困りごと | どこで迷っているか、どんな不具合があるか |
この表から分かるとおり、どれか一つの方法で十分ということはありません。特に重要なのは、利用ログとインタビューの組み合わせです。ログで「登録した人の多くが、最初の設定画面で止まっている」と分かれば、インタビューでは「設定画面で何に迷ったか」を具体的に聞けます。逆に、インタビューで「この機能が一番便利」と言われても、ログで実際の利用回数を見ると、ほとんど使われていないこともあります。
利用ログから「何が起きたか」をつかむ
利用ログは、利用者の実際の行動を記録したデータです。言葉と違って、利用者の記憶違いや遠慮の影響を受けません。MVPのフィードバックの土台になるのは、このログです。
最低限見るべき数字
MVPの段階で毎週確認したい数字は、次のようなものです。
- 新しく登録した人の数と、その流入元
- 登録した人のうち、主要機能を一度でも使った人の割合
- 主要機能を使った人のうち、翌週・翌月にも使った人の割合
- 主要な流れの中で、どの画面で止まっている人が多いか
- 利用者ごとの利用回数や利用頻度の分布
これらの数字を見るには、公開前に計測の設定が必要です。計測すべき項目と設定の方法はMVPに最低限入れる計測で詳しく説明しています。
利用者を個別に追う
MVPは利用者の数が少ないことが多いため、全体の割合だけでなく、利用者一人ひとりの行動を追うことにも意味があります。たとえば、継続して使っている利用者を数人選び、どの機能をどの順番で使っているかを見ると、価値を感じている使い方が見えてきます。反対に、登録してすぐに離れた利用者の行動を追えば、どこでつまずいたかが分かります。
このためには、ログインした利用者の識別子をイベントログに記録しておく必要があります。個人情報の扱いについては、プライバシーポリシーでの説明と、社内での閲覧範囲の管理を忘れずに行ってください。
インタビューで「なぜそうなったか」を確かめる
ログで気になる行動が見つかったら、インタビューでその理由を確かめます。MVPの段階では、インタビューが最も多くの学びをもたらすことがよくあります。
誰に話を聞くか
インタビューの対象は、ログの結果をもとに選びます。目的に応じて、次のような組み合わせを考えます。
- 継続して使っている利用者：何に価値を感じているか、どんな場面で使っているか
- 登録したが使わなくなった利用者：何を期待して登録し、何が合わなかったか
- 途中の画面で止まった利用者：どこで、なぜ迷ったか
- 検討したが登録しなかった人：何が決め手にならなかったか
使わなくなった人や登録しなかった人は話を聞きにくいものですが、改善のヒントが最も多く含まれています。短時間の依頼にする、謝礼を用意するなどの工夫をして、話を聞く機会を作ります。対象者の集め方と謝礼の考え方はインタビュー対象者の集め方で詳しく扱っています。
何を聞くか
インタビューでは、意見や要望より、実際の行動と状況を聞くことを重視します。
- 背景：普段その業務や作業をどのように行っているか、どこに手間を感じているか
- きっかけ：サービスを知った経緯、登録したときに何を期待したか
- 実際の利用：最後に使ったのはいつか、そのとき何をしたか（画面を一緒に見ながら聞けるとよい）
- つまずき：迷ったところ、使うのをやめた（または続けている）理由
- 代わりの手段：このサービスを使わないとき、何で代用しているか
「どんな機能があったらいいですか」という質問は、つい聞きたくなりますが、答えが利用者の想像に頼るため、実際の行動と食い違うことが多くあります。要望が出てきたら、「それがあると、どんな場面で何が変わりますか」と、背景にある困りごとを聞き返すようにします。
記録と共有の仕方
インタビューの内容は、話を聞いた人の頭の中だけに残しておくと、関係者に伝わる段階で要約され、印象の強い発言だけが独り歩きします。避けるために、インタビューごとに「対象者の属性」「利用の状況」「印象に残った発言（そのままの言葉）」「観察した行動」「聞き手の解釈」を同じ形式で残します。発言と解釈を分けて書くことで、ほかの人が読んだときにも、どこまでが事実かを判断できます。
可能であれば、開発者もインタビューに同席するか、記録を読む時間を取るようにします。利用者の言葉を直接知っている開発者は、改善の方法を考えるときに、仕様書に書かれていない利用者の事情まで踏まえた提案ができるようになります。
アンケートと問い合わせをどう活かすか
アンケートは傾向の確認に使う
アンケートは、多くの利用者から同じ形式で回答を集められる点が強みです。ただし、MVPの段階では回答数が少なく、選択肢の作り方次第で結果が大きく変わるため、アンケートだけで判断するのは危険です。
アンケートは、インタビューで見つかった仮説が多くの利用者に当てはまるかを確かめる道具として使うと効果的です。たとえば、インタビューで「設定が面倒」という声が複数あったなら、アンケートで「初期設定の手間をどう感じたか」を全体に聞き、傾向を確認します。
設問数は少なく絞り、回答者の負担を減らします。自由記述欄は一つ設け、選択肢にない理由を拾えるようにします。
問い合わせは改善の宝庫として記録する
問い合わせは、利用者が自分から連絡してくる、熱量の高いフィードバックです。不具合の報告、操作方法の質問、要望など、内容はさまざまですが、どれもMVPの改善に役立ちます。
問い合わせを活かすには、内容を記録し、分類することが大切です。日付、利用者、内容、分類（不具合・操作の質問・要望・その他）、対応結果を一覧にしておくと、同じ質問が繰り返し来ている箇所、つまり分かりにくい画面や説明が見えてきます。
分類の例としては、次のような区分が使いやすいでしょう。
| 分類 | 内容の例 | 主な対応 |
|---|---|---|
| 不具合 | エラーが出る、データが保存されない | 影響を確認し、すぐに修正する |
| 操作の質問 | どこから設定するのか分からない | 回答し、画面の説明や導線を見直す候補にする |
| 要望 | この形式で出力したい | 背景の困りごとを聞き、改善候補の一覧に加える |
| 契約・料金 | 請求書の宛名を変えたい、解約したい | 手順を整え、繰り返し来るなら仕組み化を検討する |
フィードバックを集める手順と頻度
ここまでの方法を組み合わせた、MVP公開後のフィードバック収集の手順を示します。
- 公開前に問いと期限を決める：何を確かめ、いつまでに何を判断するかを関係者で共有する。
- 計測と問い合わせの記録を準備する：利用ログの計測設定と、問い合わせを記録する場所を用意する。
- 公開後、毎週ログを確認する：登録、主要機能の利用、継続、離脱の数字を週ごとに見る。気になる動きがあれば書き留める。
- 2〜3週間ごとにインタビューを行う：ログで見つかった気になる行動をもとに対象者を選び、数人ずつ話を聞く。
- 必要に応じてアンケートで傾向を確かめる：インタビューで見つかった仮説が、多くの利用者に当てはまるかを確認する。
- フィードバックを一か所にまとめる：ログの気づき、インタビューの要点、アンケートの結果、問い合わせの分類を同じ表に整理する。
- 判断の場を設ける：期限に合わせて関係者が集まり、集めた情報をもとに次の行動を決める。
対象者を限定して公開する場合は、利用者と直接やり取りしやすいため、インタビューの頻度を上げることもできます。進め方はクローズドβテストの進め方も参考にしてください。
集めたフィードバックを整理して改善につなげる
集めた情報は、そのままでは改善に使えません。次の観点で整理します。
- 事実と解釈を分ける：「設定画面で多くの人が止まっている」（事実）と「設定項目が多すぎるのだろう」（解釈）を分けて書く。
- 困りごとと要望を分ける：「〇〇機能がほしい」という要望の背後にある困りごとを書き出す。同じ困りごとから出た複数の要望をまとめる。
- 仮説との関係を確認する：その情報が、検証したい仮説を支持しているか、否定しているか、関係ないかを分類する。
- 影響の大きさを見る：何人の利用者に関わるか、主要な流れに影響するかを確認する。
整理した結果をもとに、改善の優先順位を決めます。要望の多さだけで順番を決めると、検証したいことから外れていきます。判断の基準はMVP公開後の開発の優先順位で詳しく説明しています。
フィードバック収集でよくある失敗と避け方
失敗1：アンケートの結果だけで判断する
「満足」と答えた人が多くても、実際には使われていないことがあります。避け方は、アンケートの結果を利用ログと照らし合わせ、回答と行動が一致しているかを確認することです。
失敗2：熱心な利用者の声ばかりを聞く
自分から連絡してくる利用者や、インタビューに快く応じてくれる利用者は、もともとサービスに好意的な人が多くなります。その声だけを聞くと、離れていった人の理由が見えません。避け方は、インタビュー対象者の中に、使わなくなった人や登録しなかった人を意識して含めることです。
失敗3：要望をそのまま機能にする
利用者の要望どおりに機能を作っても、問題が解決しないことがあります。要望は利用者が思いついた解決策であり、最適な解決策とは限らないからです。避け方は、要望の背景にある困りごとを聞き出し、それを解決する方法を自分たちで考えることです。
失敗4：集めるだけで判断しない
フィードバックは集まっているのに、それを使って何かを決める場がなく、改善が進まない失敗です。避け方は、公開前に判断の期限と場を決めておくことです。
失敗5：数字の変化の理由を思い込みで決める
ある週に利用が増えたとき、直前に追加した機能のおかげだと考えがちですが、実際には別の要因（季節、外部の出来事、案内の送付など）かもしれません。避け方は、変化の理由を一つに決めつけず、インタビューなどで確かめることです。相関と因果を区別する考え方は相関と因果で説明しています。
フィードバック収集のチェックリスト
- 確かめたい問いと、判断の期限が決まっている
- 主要な行動の利用ログが記録され、利用者単位で追える
- 毎週ログを確認する担当者と時間が決まっている
- インタビューの対象者に、継続利用者と離脱者の両方が含まれている
- インタビューで、要望より行動と状況を聞く質問を用意している
- アンケートは設問を絞り、インタビューの仮説の確認に使っている
- 問い合わせの内容と分類を記録している
- 事実と解釈、困りごとと要望を分けて整理している
- 集めた情報をもとに判断する場が設けられている
具体的な場面で考える：架空の経費精算サービスの例
架空の例として、小規模事業者向けの経費精算サービスのMVPを公開し、1か月が経った場面を考えます。登録した事業者は数十社ありましたが、継続して使っているのは一部にとどまっていました。
まず利用ログを見ると、登録した事業者の多くが、最初の領収書を一枚登録したところで止まっていました。継続している事業者は、登録の翌日から複数の従業員を招待していたことも分かりました。
そこで、止まってしまった事業者と、継続している事業者の両方に話を聞きました。止まった事業者からは「従業員を招待する方法が分からなかった」「自分だけで使っても意味がないと感じた」という声がありました。継続している事業者は、「従業員がスマートフォンで撮って送るだけになり、月末の回収が楽になった」と話していました。
この結果から、価値の中心は「経営者の入力の手間」ではなく「従業員からの回収の手間」にあると分かりました。次の改善では、新しい機能を増やすのではなく、登録直後に従業員の招待を案内する流れを整えることを優先しました。アンケートで全体に聞いたところ、同様の傾向が確認できました。
このように、ログで行動の違いを見つけ、インタビューで理由を確かめることで、改善の方向がはっきりします。
よくある質問
Q. MVPの利用者が少なく、ログの数字に意味があるのか不安です。
利用者が少ない段階では、割合よりも、一人ひとりの行動を追うほうが役立ちます。数字は傾向をつかむ参考程度にとどめ、インタビューと組み合わせて判断してください。
Q. インタビューは何人くらいに聞けばよいですか？
決まった人数はありませんが、同じような話が繰り返し出てくるようになれば、その問いについては一通り聞けたと考えてよいでしょう。対象の種類（継続者、離脱者など）ごとに数人ずつ聞くのが一つの目安です。
Q. 利用者に話を聞くのを断られることが多いです。どうすればよいですか？
依頼の時間を短くする、利用者の都合のよい時間に合わせる、謝礼を用意するなどの工夫が役立ちます。また、登録時や利用開始時に「話を聞かせてもらえるか」をあらかじめ尋ねておくと、後の依頼がしやすくなります。
Q. フィードバックで方向転換が必要だと分かったら、どうすればよいですか？
まず、どの仮説が否定されたのかを明確にします。課題そのものがなかったのか、解決策が合わなかったのか、対象者が違ったのかによって、次の行動が変わります。方向を変える場合も、MVPで分かったことは次の検証の出発点になります。
Otsumuに相談できること
計測の設定ができていて、利用者に直接話を聞ける関係があり、集めた情報をもとに判断する場を持てるなら、この記事の方法で自社でもフィードバックの収集と活用を進められます。まずは、毎週ログを見る時間と、2〜3週間に一度のインタビューを習慣にするところから始めてみてください。
一方で、計測の設計に自信がない、インタビューで何を聞けばよいか分からない、集めた情報が多すぎて判断できない、といった場合は、外部の視点が役立つことがあります。事業の判断とデータの見方の両方に慣れた相手と一緒に進めると、判断までの時間が短くなります。
Otsumuの新規事業の爆速MVPシステム開発では、MVPの開発だけでなく、計測の設計、公開後のフィードバックの整理と改善の判断まで一気通貫で支援しています。公開後の数字の改善に焦点を当てる場合は、KPI改善コンサルティングもご相談いただけます。顧客の声をもとに仮説を検証する段階であれば、4週間の顧客検証 Sprint（98万円〜、税別・参考価格）という形もあります。
「フィードバックは集まっているが、どう判断すればよいか分からない」という段階でも構いません。30分の無料相談で、今集まっている情報をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01