MVPのフィードバックをどう集めるか

MVPをリリースしても、フィードバックは自然には集まりません。誰に・いつ・どんな方法で聞くかを設計することが、MVPの検証精度を左右します。

誰に聞くか

最も重要なのは、実際にそのシステムを使う現場担当者です。決裁者・管理職・IT担当者ではなく、日常業務でそのシステムを操作する人が、最もリアルなフィードバックを持っています。

ただし、現場担当者全員に聞く必要はありません。数名に絞って丁寧に聞く方が、大人数に簡単なアンケートを取るより有益な情報が得られることが多いです。

使い始めてすぐ（1〜2週間以内）：操作の迷いや直感的なわかりにくさは、使い慣れる前に聞かないと忘れられます。「最初に触ったときの印象」は時間が経つと薄れます。

ある程度使い込んだ後（1ヶ月前後）：初期の違和感が落ち着いた後、「実際の業務で使いにくい部分」「足りないと感じる機能」が具体的になってきます。この時期のフィードバックは、改善の方向性を決める上で重要です。

操作を観察する

「使ってみてください」と依頼し、隣で観察します。どこで手が止まるか・何度も繰り返す操作・聞いてくる箇所が、UIの問題箇所を教えてくれます。

口頭で「使いにくいですか？」と聞いても「まあ大丈夫です」と返ってくることが多いですが、操作を見れば実態がわかります。

具体的な質問でヒアリングする

「使いやすいですか？」という漠然とした質問は避けます。「入力するとき迷った箇所はありましたか？」「この画面で何をすればいいかわかりましたか？」「業務で使っていて、ここがあれば助かると思った機能はありますか？」など、具体的に聞くことで有用な回答が得られます。

簡単なログを確認する

どの機能が使われているか・どのページで離脱が多いかは、アクセスログや操作ログから把握できます。「機能はある、でも使われていない」という状況は、ヒアリングだけでは見えにくいです。

現場担当者が「問題ない」「特にないです」と言い続ける場合、いくつかのパターンが考えられます。

本当に問題がない：フィードバックが少ないこと自体が良いサインの場合もあります。ただし、実際に使われているかどうかをログで確認することが重要です。

遠慮している：「文句を言いにくい雰囲気」になっていると、フィードバックが出てきません。「改善のために聞いている」という姿勢を明示し、具体的な操作場面を一緒に確認する機会を作ると出やすくなります。

そもそも使っていない：使われていないからフィードバックがない、という状況です。使用頻度を確認することが先決です。

集まったフィードバックは、そのまま開発要件にしない方がよいです。「こう言っていた」という事実と、「なぜそう感じたか」という背景を合わせて記録します。

背景がわかると、「機能を追加する」以外の解決策（説明文の変更・操作フローの見直し・画面レイアウトの調整）が見えてくることがあります。要望通りに作ることが、必ずしも最善とは限りません。