商談のあとに顧客から言われたことをSlackに書き込んだ。カスタマーサポートの担当者は、問い合わせの中にあった改善の声をスプレッドシートにまとめている。営業担当は「あのお客様もこの機能が欲しいと言っていました」と口頭で伝えてくる。そして一番多くの要望を聞いているのは、商談にもサポートにも顔を出している経営者自身の頭の中——そうした状態のまま、プロダクトの開発計画を立てていないでしょうか。
顧客の要望は、プロダクトを良くするための貴重な材料です。しかし、あちこちに散らばったままでは、「どの要望が何社から来ているのか」「前にも同じことを言われていなかったか」が分からず、結局は直近に聞いた声や、声の大きい顧客の要望が優先されてしまいます。
本記事では、顧客や営業から届く要望を1か所に集め、記録し、課題ごとにまとめ、開発の判断に渡すまでの流れを4つのステップに整理して解説します。専用のツールや担当者がいない少人数のチームでも始められ、続けられる形を前提にしています。
顧客要望が散らばったままだと、何が起きるか
まず、要望が管理されていない状態で起きやすいことを確認しておきます。
1つ目は、優先順位が「最後に聞いた声」で決まることです。 要望の全体像が見えないと、判断の材料は記憶に頼るしかありません。記憶に残りやすいのは、直近の商談で強く言われたことや、大口の顧客から言われたことです。その結果、本当は多くの顧客が困っている課題が後回しになり、1社だけの要望が先に開発されるということが起こります。
2つ目は、同じ要望に何度も対応することです。 以前に検討して見送った要望が、別の顧客から別の言葉で届いたとき、記録がなければ一から検討し直すことになります。逆に、過去に「次の見直しで検討します」と伝えた顧客に、その後の連絡を忘れてしまうこともあります。
3つ目は、要望を聞いた人にしか背景が分からないことです。 「CSV出力が欲しい」という一言だけが伝わっても、なぜ必要なのか、どの業務で困っているのかは、商談に同席した人にしか分かりません。背景が分からないまま開発すると、要望どおりに作ったのに使われない、ということが起きます。
4つ目は、仕事を誰かに渡せないことです。 要望の全体像が経営者の頭の中にしかない状態では、1人目のPdMを迎えても、何を根拠に優先順位を決めてきたのかを渡せません。要望の管理は、プロダクトマネジメントを手放していくための準備でもあります。
始める前に決めておく3つのこと
要望の管理は、仕組みを作ること自体は難しくありません。続かなくなる原因の多くは、始める前に役割や置き場所を決めていないことにあります。最初に次の3つを決めておきます。
置き場所を1つに決める
要望を記録する場所を1つに決めます。最初はスプレッドシートやNotionのデータベースなど、チーム全員がすでに使っているもので十分です。大切なのは、ツールの機能よりも「要望はここに書く」という置き場所が1つに決まっていることです。
Slackの専用チャンネルを入口にするのはよい方法ですが、チャンネルそのものを置き場所にすると、流れていった投稿を後から集計できません。Slackは「受け付ける場所」、スプレッドシートなどは「蓄積する場所」と分けて考えます。
記録する人を決める
要望を聞いた人が、その場で記録するのが原則です。商談なら営業担当、問い合わせならサポート担当、経営者が聞いた場合は経営者自身が書きます。
ただし、全員に完璧な記録を求めると続きません。聞いた人は「顧客名と、言われたことそのまま」だけを書き、背景の整理や分類は、要望の管理を担う1人がまとめて行う、という分担が現実的です。プロダクトマネジメントを兼務している段階では、この「まとめる1人」は経営者自身になることが多いでしょう。
見る日を決める
記録した要望を、いつ見直すかを決めます。毎週15〜30分程度、決まった曜日に要望の一覧に目を通す時間を予定に入れておきます。見る日が決まっていないと、記録は増えていくのに誰も見ない状態になり、記録する側の意欲も下がっていきます。
顧客要望を管理する4ステップ
準備ができたら、実際の管理の流れに移ります。要望の管理は、次の4つのステップで回します。
ステップ1：集める——入口を1つにそろえる
最初のステップは、あちこちに散らばっている要望を、決めた置き場所に集めることです。
始めるときは、まず過去の要望を一度棚卸しします。Slackの過去の投稿、商談メモ、サポートの問い合わせ履歴、そして経営者自身の記憶にある要望を、思い出せる範囲で書き出します。完璧に集める必要はありません。直近3か月分程度でも、要望の傾向をつかむには十分です。
棚卸しのあとは、新しく届く要望の入口を1つにそろえます。たとえば、「顧客から要望を聞いたら、Slackの要望チャンネルに書く。要望の管理担当が週に1回それをシートに転記する」というルールにしておけば、記録する側の負担は投稿1回で済みます。
ステップ2：記録する——「言われたこと」と「困っていること」を分けて書く
集めた要望は、決まった項目で記録します。このとき最も大切なのは、顧客が言った言葉と、その背景にある課題を分けて書くことです。
顧客の要望は、多くの場合「〇〇機能が欲しい」という解決策の形で届きます。しかし、その機能が本当に最適な解決策とは限りません。「CSVで出力したい」という要望の背景には、「月次の会議資料を作るために、毎月手作業で数字を転記している」という課題があるかもしれません。課題が分かれば、CSV出力以外の解決策も検討できます。
記録しておきたい項目は、後ほど表にまとめて紹介します。聞いた時点で背景が分からない場合は、課題の欄を空けておき、次の接点で確認すれば問題ありません。
ステップ3：まとめる——要望ではなく「課題」の単位で束ねる
記録が溜まってきたら、似た要望をまとめます。ここでのポイントは、要望の言葉ではなく、背景にある課題の単位で束ねることです。
たとえば、「CSV出力が欲しい」「ダッシュボードを印刷したい」「月次レポートをメールで送ってほしい」という3つの要望は、言葉はばらばらですが、「月次の報告資料を作る手間を減らしたい」という同じ課題から来ている可能性があります。機能の名前で分類すると3件の別々の要望に見えますが、課題でまとめると、3社が同じことで困っているという事実が見えてきます。
束ねた課題ごとに、次の情報を集計しておくと、判断の材料になります。
- 何社から上がっているか
- どのような顧客から上がっているか（業種、規模、契約プランなど）
- 最初に上がったのはいつで、最近も上がり続けているか
特に「どのような顧客から」という視点は重要です。件数が多くても、プロダクトが主に狙っている顧客層とは異なる顧客からの要望ばかりであれば、優先度は下がります。逆に件数が少なくても、今後増やしたい顧客層からの要望であれば、注目する価値があります。
📌 関連記事：ユーザーインタビューの分析・まとめ方｜発言を「使える示唆」に変える5ステップ（PdMを兼務する経営者向け）
ステップ4：判断に渡す——バックログに載せるか、見送るか、保留するかを決める
最後のステップは、まとめた課題を開発の判断に渡すことです。要望の管理は、記録を集めること自体が目的ではありません。開発の優先順位を決める場に、根拠のある材料として届けるところまでが役割です。
週1回の見直しの場では、束ねた課題ごとに、次の3つのいずれかに振り分けます。
- バックログに載せる：解決する価値があり、他の開発項目と比較する段階に進めるもの
- 見送る：プロダクトの方向性に合わない、または既存機能の使い方の案内で解決できるもの
- 保留する：まだ件数が少ない、背景が分からないなど、判断材料が足りないもの
バックログに載せた課題は、他の開発項目と同じ基準で優先順位を比較します。要望の件数は判断材料の1つですが、それだけで順位を決めるわけではありません。
振り分けた結果は、要望を寄せてくれた顧客や、要望を伝えてくれた社内のメンバーに返すことも忘れないようにします。見送りや保留を伝える場面では、伝え方に工夫が必要です。
また、なぜその判断をしたのかを短く残しておくと、同じ要望が再び届いたときに、過去の判断を踏まえて検討できます。
記録シートの項目例
ステップ2で記録する項目の例です。最初からすべてを埋める必要はなく、太字の4項目だけで始めても構いません。
| 項目 | 記入する内容 | 記入する人 |
|---|---|---|
| 受け付けた日 | 要望を聞いた日付 | 聞いた人 |
| 顧客名 | 会社名・担当者名 | 聞いた人 |
| 言われたこと | 顧客の言葉をできるだけそのまま | 聞いた人 |
| 聞いた人 | 社内で要望を受けたメンバー | 聞いた人 |
| 背景にある課題 | 何に困っているか、どの業務で発生しているか | 管理担当 |
| 顧客の属性 | 業種・規模・契約プランなど | 管理担当 |
| 切実さ | 契約や解約に関わるか、「あれば便利」程度か | 聞いた人・管理担当 |
| 束ねた課題 | ステップ3でまとめた課題の名前 | 管理担当 |
| 判断 | バックログ・見送り・保留 | 管理担当 |
| 顧客への返答 | 返答した日と内容 | 管理担当 |
「言われたこと」の欄には、聞いた人の解釈を混ぜず、顧客の言葉をなるべくそのまま書くのがポイントです。解釈を加えると、後から背景を確認するときに、元の発言が分からなくなります。
「切実さ」は、契約更新や解約の判断に関わるのか、あれば便利という程度なのかを書く欄です。営業担当にとっては書きやすい項目で、後の判断の際にも役立ちます。
ツールはいつ、どう選ぶか
要望を管理するための専用ツールもいくつかありますが、少人数のスタートアップでは、最初はスプレッドシートやNotionなど、すでに使っているもので始めることをおすすめします。
専用ツールを先に導入すると、ツールの使い方を覚えること自体が負担になり、記録する人が増えないまま終わることがあります。まずは手元のツールで1〜2か月運用し、次のような状態になってから専用ツールを検討しても遅くありません。
- 月に数十件以上の要望が届き、転記や集計に時間がかかるようになった
- サポートの問い合わせツールや顧客管理のツールと、要望の記録をつなげたくなった
- 顧客自身に要望を投稿してもらう仕組みを作りたくなった
ツールを選ぶ際も、「記録する人が迷わずに書けるか」を一番の基準にします。管理する側にとって便利な機能が多くても、記録する人が書かなくなれば、要望は再び散らばっていきます。
運用を続けるための週次・月次のリズム
要望の管理は、仕組みを作るより、続けることのほうが難しい仕事です。少人数のチームでも続けやすいリズムの例を紹介します。
週次（15〜30分）：新しく届いた要望をシートに転記し、背景の課題を補います。既存の課題に束ねられるものは束ね、明らかに見送るものは判断を記入します。
月次（1時間程度）：課題ごとの件数と顧客の属性を見直し、バックログに載せるべき課題がないかを確認します。保留にしていた課題も、件数が増えていないかを確認します。顧客への返答が漏れていないかもここで確認します。
ロードマップの見直し時：まとめた課題の一覧を、ロードマップを見直す際の材料として使います。「次の見直しで検討します」と顧客に伝えていた要望は、このタイミングで必ず判断し、結果を返します。
よくある失敗
- 記録の項目を最初から増やしすぎる：項目が多いと、記録する人が書くのを面倒に感じ、記録そのものが止まります。最初は4項目程度に絞り、必要になった項目を後から足していきます。
- 要望の件数だけで優先順位を決める：件数は分かりやすい指標ですが、件数の多さと、プロダクトにとっての重要さは必ずしも一致しません。どのような顧客から上がっているか、事業の方向性に合っているかを合わせて見ます。
- 記録したまま、誰にも結果を返さない：要望を伝えても何も返ってこない状態が続くと、営業やサポートの担当者は記録しなくなり、顧客も要望を伝えてくれなくなります。見送りや保留であっても、判断の結果は返します。
- 経営者だけが要望を記録している：経営者が聞いた要望だけが記録され、営業やサポートが聞いた要望が漏れていると、全体像がかえって偏ります。記録する人を広げることが、管理の精度を上げる近道です。
具体例：散らばっていた要望を集めて、優先順位が変わったケース
従業員12名、創業3年目のBtoB SaaSスタートアップの例です。経営者がプロダクトマネジメントを兼務しており、要望は商談メモ、Slack、サポート担当のスプレッドシートにばらばらに残っていました。開発の優先順位は、経営者が直近の商談で聞いた要望をもとに決めることが多く、営業担当からは「現場の声が反映されていない」という不満が出ていました。
そこで、Slackに要望専用のチャンネルを作り、聞いた人は「顧客名と言われたこと」だけを投稿するルールにしました。経営者は毎週金曜日に30分、投稿をスプレッドシートに転記し、背景の課題を補う時間を取りました。過去3か月分の要望も、思い出せる範囲で書き出しました。
2か月後、課題の単位でまとめてみると、経営者が最優先だと考えていた機能は、大口の1社からの要望だけでした。一方で、「承認の手続きが煩雑で、担当者が休むと処理が止まる」という課題は、言葉は違えど8社から上がっていました。その8社のうち6社は、今後増やしていきたい中堅規模の顧客でした。
この結果をもとに開発の優先順位を見直し、承認の手続きを改善する開発を先に進めることにしました。大口の顧客には、理由と今後の検討時期を伝えたうえで、既存機能の組み合わせで当面対応する方法を案内しました。営業担当からは、自分が伝えた要望がどう扱われたかが見えるようになったことで、要望を記録する件数そのものが増えたという声が上がっています。
よくある質問（FAQ）
Q1. 要望の件数がまだ少ないのですが、管理を始める意味はありますか。
あります。件数が少ない段階のほうが、記録のルールを作りやすく、習慣にもしやすいためです。件数が増えてから仕組みを作ろうとすると、過去の要望の棚卸しだけで大きな手間がかかります。月に数件でも、置き場所と記録の項目を決めておくことをおすすめします。
Q2. 営業担当が要望を記録してくれません。どうすればよいですか。
記録の負担を減らすことと、記録した結果を返すことの2つが効果的です。記録はSlackへの投稿1回で済むようにし、細かい整理は管理担当が引き受けます。そのうえで、営業担当が伝えた要望がどう判断されたかを定期的に共有すると、「伝えれば反映される」という実感が生まれ、記録が続きやすくなります。
Q3. 社内のメンバーから出てくる改善の提案も、同じシートで管理すべきですか。
同じ置き場所で管理して構いませんが、「顧客から」なのか「社内から」なのかを区別できる項目を設けておくことをおすすめします。社内からの提案にも価値はありますが、顧客が実際に困っている課題とは分けて見たほうが、判断を誤りにくくなります。
Q4. 1人目のPdMを採用したら、要望の管理は誰が担うべきですか。
要望をまとめて判断に渡す役割は、PdMに任せるのが自然です。その際、経営者がこれまで頭の中で行ってきた「どの顧客の声を重く見るか」という判断の基準も、あわせて言葉にして渡しておくことが大切です。記録シートが整っていれば、引き継ぎの材料としても使えます。
まとめ
顧客要望の管理は、置き場所・記録する人・見る日の3つを決めたうえで、「集める」「記録する」「まとめる」「判断に渡す」の4ステップで回すことで、少人数のチームでも始められます。要望を機能の名前ではなく背景の課題の単位で束ねると、どの課題に何社が困っているのかが見えるようになり、直近の声や大きな声に左右されない判断ができるようになります。
まずは、Slackや商談メモに残っている直近3か月分の要望を1つのシートに書き出すところから始めてみてください。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。
「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。
おおむね2営業日以内にご返信します。
