MVP公開後の開発の優先順位：要望に振り回されない判断基準

MVPを公開すると、利用者から機能の要望が次々に届きます。そのすべてに応えようとすると、開発の方向がぶれ、検証したかった仮説の答えが出ないまま、機能だけが増えていきます。要望に振り回されないための基本は、要望を「やることの候補」ではなく「顧客の困りごとを知る手がかり」として受け取り、検証中の仮説と事業の指標に照らして、取り組む順番を決めることです。声の大きい顧客や、最後に話した顧客の要望が優先される状態を、判断の基準で置き換えます。

この記事は、MVPを公開した後の開発計画に悩んでいる新規事業の責任者、プロダクトマネージャー、少人数の開発チームのリーダーに向けて書いています。要望の受け取り方と整理の仕方、優先順位を決める判断基準、評価の方法、決めた順番の伝え方、よくある失敗とチェックリストまでを整理しました。

読み終えるころには、手元に集まった要望を整理し、次に何を作り、何を作らないかを、関係者に説明できる形で決められるはずです。

MVP公開後に要望へ振り回される理由

公開後に開発の優先順位が乱れる原因は、主に次の4つです。

• 要望がそのまま開発の候補になる：「この機能がほしい」という言葉を、そのまま作る機能の一覧に加えてしまう
• 判断の基準がない：何を基準に順番を決めるかが決まっていないため、その場の勢いや声の大きさで決まる
• 要望の出どころが偏る：熱心な一部の利用者や、売上の大きい顧客の声が、全体の声のように扱われる
• 断ることへの抵抗：せっかくの要望を断ると、利用者が離れてしまうのではないかと不安になる

特にMVPの段階では、利用者の数が少なく、一人ひとりの声が大きく聞こえます。初期の熱心な利用者は、サービスにとって大切な存在ですが、その人たちの要望が、これから獲得したい多くの利用者の要望と一致するとは限りません。

また、要望に応え続けることは、一見すると顧客志向に見えます。しかし、検証したかった仮説に答えが出ないまま機能が増えると、何が効いて何が効いていないのかが分からなくなります。機能が増えるほど、保守の負担も増え、次の検証の速度が落ちていきます。

要望は「解決策」ではなく「困りごと」として受け取る

利用者が「この機能がほしい」と言うとき、その裏には必ず困りごとがあります。要望をそのまま実装するのではなく、困りごとまで掘り下げてから判断します。

要望を掘り下げる3つの質問

要望を受けたら、次の3つを確認します。

1. その機能があったら、何ができるようになりますか（目的）
2. 今はその作業をどうやって行っていますか（現状の回避策）
3. それができないと、どれくらい困りますか（困りごとの深さ）

たとえば「データをCSVで書き出したい」という要望を掘り下げると、「月末に上司へ報告する資料を作るため」「今は画面を見ながら手で表計算ソフトに転記している」「毎月半日かかっている」といった背景が見えてきます。この場合、本当に必要なのはCSVの書き出しではなく、報告用の集計画面かもしれません。逆に、別の利用者は「会計ソフトに取り込むため」にCSVを求めているかもしれません。同じ要望でも、困りごとが違えば、作るべきものは変わります。

要望の記録の仕方

要望は、次の項目で記録します。表計算ソフトや課題管理ツールの一覧で構いません。

• 要望の内容（利用者の言葉のまま）
• 掘り下げて分かった困りごと
• 現状の回避策
• 要望を出した利用者の属性（業種、規模、利用頻度など）
• 同じ困りごとを持つ利用者の数
• 受け取った日と経路（問い合わせ、面談、アンケートなど）

記録の際は、要望ではなく困りごとを単位にまとめます。「CSV書き出し」「集計画面」「報告書の自動作成」という3つの要望が、すべて「月次報告に時間がかかる」という同じ困りごとから来ているなら、それは1つの課題として扱います。要望の受け付け口が、営業担当のメモ、問い合わせのメール、開発者へのチャットなどに散らばっていると、同じ困りごとが何度も別々に記録されたり、誰も記録しないまま消えたりします。どこで受け取った要望も、最終的には一つの一覧に集まるように、記録する人と方法を決めておきます。顧客の声の集め方はMVPでの顧客の声の集め方でも詳しく解説しています。

優先順位を決める判断基準

困りごとに整理した課題に、次の判断基準を当てて順番を決めます。

基準1：検証中の仮説に関わるか

MVPの公開後に最も優先すべきは、検証中の仮説に答えを出すための開発です。たとえば「中小企業の経理担当者が、請求書の処理を自動化するために月額料金を払うか」を検証しているなら、その仮説の答えに影響する課題を優先します。仮説と関係のない課題は、どれほど要望が多くても後回しにします。

基準2：事業の指標にどう効くか

事業として追っている指標、たとえば継続率、有料プランへの移行率、紹介による新規登録などに、その課題の解決がどう効くかを考えます。指標と課題のつながりを整理するには、指標を要素に分解したKPIツリーが役立ちます。指標とのつながりが説明できない課題は、優先度を下げます。

基準3：どれだけの利用者に関わるか

同じ困りごとを持つ利用者が多いほど、優先度は上がります。ただし、数だけでなく、その利用者が狙っている顧客像に当てはまるかも重要です。狙っていない顧客層からの要望が多い場合は、要望に応えるより、狙いの顧客層に届いているかを見直すべき合図かもしれません。

基準4：解決にかかる手間

開発にかかる手間、運用への影響、既存の機能への影響を見積もります。効果が同じなら、手間の小さいものを先にします。手間を見積もるときは、作る手間だけでなく、作った後の保守の手間も含めます。

基準5：やらないとどうなるか

要望に応えないことで、契約の解約、重要な顧客の離脱、法令や安全上の問題が起きるかを確認します。これらに当たる課題は、他の基準より優先して対応します。

優先順位を決める手順

実際に優先順位を決める手順は次のとおりです。2週間から1か月に一度、定期的に行います。

1. 前回の見直しから届いた要望を、困りごと単位に整理する
2. 検証中の仮説と、追っている事業の指標を改めて確認する
3. 各課題について、仮説との関係、指標への効果、利用者の範囲を評価する
4. 開発チームと一緒に、解決の手間を大まかに見積もる
5. やらないと重大な影響が出る課題を、最優先に置く
6. 残りの課題を、効果と手間で並べ、上位から次の期間に取り組むものを選ぶ
7. 選んだ課題ごとに、解決策の案を複数考え、最も手間の小さい案から検討する
8. 取り組む課題、取り組まない課題、保留にする課題を一覧にして、関係者に共有する
9. 取り組んだ課題について、効果を測る指標と確認の時期を決める

手順7は見落とされがちです。要望された機能をそのまま作るのではなく、同じ困りごとをより小さな手間で解決できる方法がないかを考えます。画面の説明を変える、使い方の案内を送る、手作業で対応する、といった方法で解決できることも少なくありません。

開発の時間の配分を先に決めておく

優先順位を決めても、日々届く不具合の報告や小さな改善の依頼に時間を取られ、肝心の課題に手が回らないことがあります。これを防ぐには、期間ごとの開発の時間を、あらかじめ大まかに配分しておくのが有効です。たとえば「仮説の検証に関わる課題」「不具合の修正」「小さな改善」「技術的な整備」の4つに分け、それぞれにどれくらいの割合を使うかをチームで決めておきます。配分は事業の段階によって変えてよく、検証の山場では仮説に関わる課題に大きく寄せ、利用者が増えてきたら不具合の修正や整備の割合を増やします。配分を決めておけば、小さな依頼が積み重なっても、重要な課題の時間が消えることはありません。

点数をつけて並べる方法

課題の数が多い場合は、点数をつけて並べると判断がしやすくなります。影響の大きさ、確信の度合い、手間の3つで評価するICEスコアや、影響する人数を加えたRICEスコアといった方法があります。ただし、点数は議論の材料であって、答えそのものではありません。点数の高い順に機械的に並べるのではなく、点数の根拠を話し合うことで、チームの認識をそろえるために使います。

MVPの開発前に機能を絞り込む考え方はMVPの機能の絞り方で解説しています。公開後の優先順位づけは、その延長線上にあります。違いは、公開後には実際の利用データと顧客の声という、より確かな材料が手に入ることです。

利用データと声を組み合わせて判断する

要望の声だけで判断すると、声を上げる利用者の意見に偏ります。実際の利用データと組み合わせることで、判断の精度が上がります。

• 声は多いが、データでは影響が小さい：一部の熱心な利用者の要望かもしれない。全体への効果を慎重に見積もる
• 声は少ないが、データでは問題が大きい：多くの利用者が、声を上げずに離れている可能性がある。優先度を上げる
• 声もデータも一致している：優先して取り組む
• 声もデータも小さい：保留にする

たとえば、登録後に最初の操作まで進まずに離れる利用者が多いのに、そのことについての要望はほとんど届いていない、という状況はよくあります。離れた利用者は、要望を出してくれないからです。声を上げない利用者の行動を知るために、MVPの段階から最低限の計測を入れておくことが重要です。計測の入れ方はMVPに最低限入れる計測を参考にしてください。

架空の例：飲食店向けのシフト管理サービス

ある架空のチームが、飲食店向けのシフト管理サービスのMVPを公開したとします。検証中の仮説は「店長がシフト作成の時間を減らすために、月額料金を払う」というものでした。

公開から1か月で、次のような要望が届きました。

• 給与計算ソフトと連携したい（複数の店舗から）
• アルバイトがスマートフォンで希望シフトを出せるようにしたい（多数の店舗から）
• シフト表の色を変えたい（1店舗から、強い要望）
• 複数店舗のシフトをまとめて見たい（チェーン店1社から）

利用データを見ると、アルバイトの希望シフトを店長が手で入力しているために、シフト作成の時間が思ったほど減っていないことが分かりました。これは仮説の検証に直接関わる課題です。チームは、アルバイトのスマートフォンからの希望提出を最優先にしました。

給与計算ソフトとの連携は、有料化の判断に効く可能性がありましたが、手間が大きかったため、まずは書き出したファイルを給与計算ソフトに取り込む手順を案内することで対応しました。シフト表の色の変更は保留とし、複数店舗の管理は、狙いの顧客層が単独店舗であることを確認したうえで、今回は取り組まないと決めました。チェーン店には、その理由と今後の予定を丁寧に伝えました。

決めた優先順位の伝え方

優先順位を決めたら、社内の関係者と利用者の両方に、適切に伝えます。

社内への伝え方

営業担当、顧客対応の担当、経営層など、要望を受け取る立場の人に、次の内容を共有します。

• 次の期間に取り組む課題と、その理由
• 取り組まない課題と、その理由
• 保留にしている課題と、再検討の時期
• 新しい要望を受けたときの記録の方法

特に営業担当には、まだ作っていない機能を顧客に約束しないよう、取り組む予定のない機能を明確に伝えます。

利用者への伝え方

要望を出してくれた利用者には、結果がどうであれ返事をします。

• 取り組む場合：いつごろ提供できる見込みか、提供したら知らせることを伝える
• 取り組まない場合：今は取り組まない理由と、代わりの方法があれば案内する
• 保留の場合：要望を記録したこと、今後の判断の材料にすることを伝える

断る場合も、要望の背景にある困りごとを理解していることを示し、代わりの方法を案内すれば、多くの利用者は納得してくれます。要望を出しても何の反応もない状態のほうが、利用者の信頼を損ないます。改善した内容を定期的にお知らせとしてまとめ、「いただいた声をもとに改善しました」と伝えることも、要望を出してくれる利用者との関係を保つうえで効果があります。

よくある失敗と避け方

• 要望の数で順番を決める：数が多くても、狙いの顧客層でなかったり、仮説と関係がなかったりすることがあります。数は判断基準の一つにすぎません。
• 大口の顧客の要望を無条件に優先する：その顧客専用の機能が増え、他の利用者にとって使いにくいサービスになります。個別の対応が必要な場合は、別の契約や料金で扱うことを検討します。
• 小さな要望を次々に片付ける：手間の小さい要望ばかりを処理していると、重要だが手間の大きい課題が後回しになり続けます。期間ごとに、重要な課題に使う時間を確保します。
• 作った後の効果を確認しない：要望に応えた機能が使われているか、指標が改善したかを確認しないと、判断の精度が上がりません。
• 優先順位を頻繁に変える：毎週のように順番が入れ替わると、開発チームが何も完成させられません。見直しの周期を決め、その間は原則として変えないようにします。
• 断ることを避ける：すべての要望を「検討します」で受け流すと、利用者の期待だけが積み上がります。取り組まないものは、取り組まないと伝えます。

優先順位を決める前のチェックリスト

• 届いた要望を、困りごと単位に整理した
• 要望ごとに、目的・現状の回避策・困りごとの深さを確認した
• 検証中の仮説と、追っている事業の指標を確認した
• 各課題について、仮説との関係と指標への効果を評価した
• 同じ困りごとを持つ利用者の数と、その属性を確認した
• 利用データと声の両方を見て判断した
• 解決の手間を、開発と保守の両面で見積もった
• 同じ困りごとをより小さな手間で解決する方法を検討した
• 取り組む・取り組まない・保留の一覧を作り、関係者に共有した
• 要望を出した利用者に、結果を返す段取りを決めた
• 取り組んだ課題の効果を測る方法と時期を決めた

このチェックリストは、優先順位を決める定例の冒頭で毎回確認すると効果的です。チェックが付かない項目が続く場合は、要望の集め方や判断の進め方そのものを見直す合図と考えます。

よくある質問

Q. 有料の顧客から強く要望されたら、断るのは難しくありませんか？

断ることが難しい場合でも、まず困りごとを掘り下げ、他の方法で解決できないかを検討します。その顧客専用の機能が必要な場合は、個別の開発として別の費用や契約で扱う、という選択肢もあります。サービス全体の方向性と、個別の顧客への対応を分けて考えることが大切です。

Q. 検証中の仮説が外れたら、優先順位はどうなりますか？

仮説が外れた場合は、まず次に検証する仮説を決め直します。そのうえで、新しい仮説に照らして課題の優先順位を付け直します。これまでに集めた要望や困りごとは、新しい仮説を立てるときの貴重な材料になります。

Q. 優先順位を決めるのは誰の役割ですか？

最終的な判断は、プロダクトの責任者が行うのが一般的です。ただし、手間の見積もりは開発チーム、顧客の困りごとは営業や顧客対応の担当者が詳しいため、判断の材料は複数の立場から集めます。誰が決めるのかを明確にしておくことで、判断が遅れたり、何度も覆ったりすることを防げます。

Q. 要望の管理にはどんなツールを使えばよいですか？

最初は表計算ソフトや、開発で使っている課題管理ツールで十分です。重要なのは、要望を一か所に集め、困りごと単位で整理し、関係者が見られる状態にすることです。

Otsumuに相談できること

検証中の仮説と追うべき指標がはっきりしていて、プロダクトの責任者が判断の役割を担える場合は、この記事の判断基準と手順を使って、自社で優先順位を決めていくことができます。まずは手元の要望を困りごと単位に整理するところから始めてみてください。

一方で、そもそも何を検証しているのかが曖昧になっている、どの指標を追えばよいか定まらない、大口の顧客の要望と全体の方向性の間で判断がつかない、といった場合は、事業と開発の両方を見られる外部の視点が役立つことがあります。

Otsumuは、自らも事業を手がける実践者として、目的から逆算して必要な機能に絞り込み、構想から開発・運用・改善までを一気通貫で支援しています。新規事業の爆速MVPシステム開発では、AIを活用した少人数・短期間の開発で、公開後の改善サイクルまでを一緒に回します。追うべき指標の設計から見直したい場合は、KPI改善コンサルティングもご用意しています。いまの事業の状況を短期間で整理したい場合は、1〜2週間で行う新規事業レビュー Sprint（48万円、税別・参考価格）もあります。

公開後の開発の進め方に迷っている段階からでも構いません。30分の無料相談でお気軽にご相談ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01