日々プロダクト開発に携わる中で、ユーザーやビジネスサイドから次々と寄せられる要望。そのすべてに応えようとすると、プロダクトは本来の価値を見失い、複雑で使いにくいものになってしまうかもしれません。では、プロダクトマネージャー（PdM）は、無数の要望の中から何をつくり、何をつくらないのかを、どのように判断すればよいのでしょうか。

2025年4月30日に開催されたFLEXY Meetupでは、「つくらない勇気」をテーマに、株式会社スナネコのすぅ氏が登壇。アクセンチュア、リクルートで数々のプロジェクトを率い、現在はPdM支援事業を手がける同氏が、要望の裏にある本質的な課題を見抜く思考法、プロダクトの核を守るための判断軸、そしてチームの納得感を得るためのコミュニケーション術について、豊富な経験を基に語りました。

本レポートでは、そのセッションの模様を詳しくお届けします。

登壇者紹介

すぅ氏｜株式会社スナネコ 代表取締役

株式会社スナネコ 代表取締役。PM（プロジェクトマネジメントやプロダクトマネジメント）の支援事業を展開。2012年アクセンチュア株式会社入社。製造業界向けのITプロジェクト推進。2013年株式会社リクルート（旧リクルートキャリア）に入社。リクルート社内向けDX推進部署にて、派遣事業の業務効率化プロジェクトや日本最大級のカスタマーIDの利活用プロジェクトなどを推進。その後、新規事業のプロダクトマネジメントおよびオペレーション戦略を担当。2024年株式会社スナネコ創業。BPRなどのプロジェクトマネジメント、新規プロダクトプロダクトマネジメントにおける豊富な経験を活かしたサービス提供が強み。200名以上が参加するPMコミュニティ「PM研究所」を運営。

セッション1：要望の裏にある「本当の課題」を見抜く思考法

最初のセッションでは、日々寄せられる要望にどう向き合い、その裏にある本質的な要求や課題をいかにして見抜くか、その思考法が語られました。

判断の拠り所は「誰の、何の課題を解決するプロダクトか」

すぅ氏： プロダクトに向き合う上で最も大切にしているのは、「そのプロダクトが、誰の・何の課題を解決するものなのか」という原点に常に立ち返ることです。PdMには大量の要望が寄せられるため、この軸がないとすべてに対応しようとしてしまい、立ち行かなくなります。

すぅ氏： ビジネスサイドから強い要望が来たとしても、前提としてプロダクトのコンセプトやビジョン、そして現在のフェーズにおける優先順位（例えば、コスト重視なのか、スピード重視なのか）に照らし合わせて判断します。「その要望は本当にユーザーが求めていることなのか？」と問い直し、ユーザーにとってどんなプロダクトにしたいのかをステークホルダーと話し合うことが重要です。

要望を受け取ったら、まず「一次情報」を取りに行く

すぅ氏： 社内から要望を受け取った際にまず確認すべきは、一次情報を取りに行くことです。要望の多くは「このボタンをこうしてほしい」といった具体的なソリューションの形で寄せられます。しかし、それを鵜呑みにするのではなく、「なぜそれが必要なのか」「どんな背景や課題があるのか」「現状、どのような影響が出ているのか」をヒアリングし、それが本当に最適な解決策なのかを見極めることが大切です。

すぅ氏： 納得感のないまま開発を進めてしまうと、結果的に負の遺産を生み出すことになりかねません。なぜそれをするのか、他に方法はないのかを突き詰めて議論することが重要です。例えば「こういうレポートを出してほしい」という要望も、実はユーザーが本当に求めているのは「CSVでデータをダウンロードしたい」だけかもしれません。

「要件」ではなく「要求」を聞き出すための信頼関係構築術

すぅ氏： 要望の背景にある本質的な要求を聞き出すためには、結局のところ、日々の信頼関係の構築に尽きます。いきなり「なぜそれが必要なんですか？」と聞くと、相手は突き返されたと感じ、ハレーションが起きかねません。

すぅ氏： 信頼関係を築くために、特にリモートワーク環境では、テキストコミュニケーションだけでなく、オンラインで直接会話する機会を意識的に増やしています。テキストでは伝わりきらないトーンやニュアンスを掴み、相手の真意を深く理解するためです。もちろん、ログを残すという点ではテキストも重要なので、うまく使い分けています。

すぅ氏： また、要望を聞く際には、ただ受け身で聞くのではなく、こちらである程度たたき台を用意し、「こういうことですかね？」と提示しながら進めることも有効です。これにより、相手は「自分たちの要望を真剣に考えてくれている」と感じ、より深い対話につながります。

セッション2：「つくらない勇気」でプロダクトの核を守る

次のセッションでは、イベントの核心である「つくらない勇気」をテーマに、プロダクトのコンセプトを守るための意思決定の軸や、チームでそれを共有するための仕組みについて議論が展開されました。

「やらない」と判断する軸はプロダクトのコンセプトとビジョン

すぅ氏： ユーザーの声をすべて反映するのではなく、あえて「やらない」と判断する場面での軸は、やはりプロダクトのコンセプトとビジョンです。その機能を追加することで、プロダクトが提供したいユーザー体験が損なわれないかを考えます。

すぅ氏： 例えば、クリエイターのコンテンツ配信プラットフォームである「note」は、多くのブログサービスにあるような文字のフォントサイズ変更機能などを実装していません。これは、noteが持つブランドイメージや「誰もが創作を始め、続けられるようにする」というコンセプトを守るための、意図的な判断だと考えられます。

すぅ氏： しかし、組織が大きくなるにつれて、創業当初の純度の高いビジョンは薄れがちです。機能ごとに組織が分かれ、それぞれの判断で開発を進めると、プロダクト全体としての一貫性がなくなり、カオスな状態に陥ってしまいます。

コンセプトの形骸化を防ぐ、オープンな意思決定の仕組み

すぅ氏： コンセプトの形骸化を防ぎ、上手くいっている組織には2つのパターンがあります。1つ目は、PO（プロダクトオーナー）が全ての機能をレビューすることです。特にスタートアップでは、思想を最も理解しているPOが判断することで、一貫性を保つことができます。

すぅ氏： 2つ目は、組織が大きくなった場合の対策として、意思決定のプロセスをオープンかつフラットにすることです。要望がいつの間にか採用されたり、却下されたりするのではなく、「なぜこの機能はやるのか」「なぜ今回はやらないのか」という判断の理由と軸をオープンにしていくことが重要です。

すぅ氏： 月次の定例会議などで、これらの判断を事例と共に共有し続けることが重要です。これを繰り返すことで、チーム全体に判断軸が「刷り込み」のように浸透し、要望を出す側もプロダクトのコンセプトに沿った提案をするように変わっていきます。

セッション3：チームの納得感を得るコミュニケーション術

最後のセッションでは、PdMがチームと向き合い、納得感を持って開発を進めてもらうためのコミュニケーションのスタンスや工夫が語られました。

PdMのスタンスは常に「フラット」であること

すぅ氏： チーム、特にエンジニアと向き合う上で意識しているスタンスは、常にフラットであることです。そして、開発を依頼する際には、単なる指示ではなく、その機能が必要な背景や目的を必ず伝えるようにしています。

すぅ氏： なぜそれをつくるのかという情報が共有されていないと、エンジニアは言われた通りにつくるしかありません。しかし、背景を理解していれば、「もっとこういうやり方の方が良いのでは？」といった、より良い提案が出てくる可能性があります。チームとして上下関係はなく、あくまで役割として向き合うスタンスが大切です。

すぅ氏： また、後から「この機能はなぜつくったんだっけ？」とならないように、背景や目的、やる/やらないと決めたことなどを「Notion」のようなツールにドキュメントとして残しておくことが、将来の負債を防ぐ上で非常に重要です。

意見の衝突は「ユーザー視点」で乗り越える

すぅ氏： チーム内で意見がぶつかった時、PdMは「自分の判断軸」を極力消し、「ユーザー視点でどうなのか」という一点に集中すべきです。お互いがユーザーのために良いものをつくろうという前提での衝突は、プロダクトをより良くするための健全な議論です。

すぅ氏： よくある「あった方がいいよね」という意見は、裏を返せば「なくても誰も困らない」ということです。個人的には、こうした要望の優先度は下げます。それよりも、「これがないと、ユーザーがこういう不利益を被る」という、明確な課題を解決する機能の優先度を高く設定します。

すぅ氏： 意見がぶつかった際に、PdMが無理に着地させようとするのではなく、お互いが納得するまでとことん議論し、一緒に着地点を見つけるというスタンスが重要です。どうしても決まらない場合は、最終判断者であるPOに委ねることも必要です。

Q&Aセッション

セッションの合間や最後に設けられたQ&Aセッションでは、視聴者から寄せられた具体的な悩みについて、すぅ氏が回答しました。

Q. リモートワークでのコミュニケーションのコツは？

すぅ氏： 顔色を伺うよりも、お互いが言いたいことを言える心理的安全性の高い環境をつくることが重要です。そのためには、まずコミュニケーションの絶対量を増やすことが効果的です。SlackのDMでちょっとした雑談をしたり、会議で良い発言があった際に「ありがとうございました」と伝えたり、日々の小さなジャブの積み重ねが、いざという時の円滑なコミュニケーションにつながります。

Q. 要望の質を上げるための工夫は？

すぅ氏： 最も効果的なのは、PdM自身がそのプロダクトのヘビーユーザーになることです。自分が一人のユーザーとしてプロダクトを使い込んでいれば、寄せられた要望に対して「分かる、確かに不便だ」とか「いや、本当に困っているのはそこじゃないはずだ」といった肌感覚が養われます。テクニック以前に、まず自分のプロダクトを愛し、使い倒すことが基本です。

Q. 判断に迷った際のフレームワークはありますか？

すぅ氏： 万能なフレームワークはありませんが、QCD（品質・コスト・納期）や、プロダクトの現在のフェーズ（立ち上げ期・成長期など）における優先順位を明確にしておくことは、判断の助けになります。それでも自分で判断できない時は、一人で抱え込まず、関係者を巻き込んで議論したり、最終的にはPOに相談して決めるのが良いでしょう。

Q. ビジネス側と開発側がお互いの視点を持つにはどうすればよいですか？

すぅ氏： 一番のおすすめは、自分でゼロからプロダクトをつくってみることです。今ならノーコードツールを使えば、比較的簡単にLPや簡単なアプリケーションがつくれます。企画から設計・実装・リリースまでの一連の流れを経験することで、ビジネス側は開発の構造を、開発側はビジネスの視点を、身をもって理解することができます。

Q. 理想の組織とはどのようなものですか？

すぅ氏： 全員が「ユーザーにとってどうするべきか」を常に考えている組織が理想です。職種や役割に関わらず、すべての議論がユーザー視点で行われる組織は、素晴らしいプロダクトを生み出します。PdMからエンジニア、ビジネスサイドまで、全員がユーザーへの価値提供を軸にコミュニケーションを取っている企業は目指すべき組織の在り方だと感じています。

全体のまとめ

今回のイベントでは、プロダクトマネジメントにおける「つくらない勇気」というテーマが、単なる機能の取捨選択の技術ではなく、プロダクトの本質的な価値を守り育てるための哲学であることが浮き彫りになりました。すぅ氏が繰り返し強調していたのは、すべての判断軸の根底にある「ユーザー視点」の重要性です。

ビジネスサイドの要求、開発リソースの制約、そしてチーム内の意見。様々な要素が絡み合う中で、PdMは常に「これは本当にユーザーのためになるのか？」と自問し、プロダクトのコンセプトやビジョンから逸脱しないよう舵を取る、いわば「プロダクトの核の守護者」です。その役割を果たすためには、要望の裏にある本質を見抜く洞察力、チームの納得感を引き出すオープンなコミュニケーション、そして何よりも、ユーザーとプロダクトへの深い愛情が不可欠なのだと感じました。

「ユーザーとしてプロダクトを使い込む」「開発の背景をチームに伝える」「意見の衝突を恐れず議論する」。本セッションで語られた数々の実践的な知見は、明日からのプロダクト開発をより良い方向へと導く、確かなヒントとなるでしょう。