営業 兼 PMが語る、顧客課題の引き出し方 ── 営業の視点がPMをもっと強くする

こんにちは、マッハチームの日吉です。

先日、「AI時代のプロジェクトマネジメントスペシャル by クラスメソッド」という勉強会で登壇する機会をいただきました。
今日はその内容をブログとして書いてみます。

PMをやっていると、こういう経験はないでしょうか。

• 要件定義をしっかり進めたつもりなのに、開発が終わってから「なんか違う」と言われる。
• 顧客が言っていた機能を作ったのに、なぜか使われない。
• 途中から要件がどんどん膨らんでいく。

こういった問題の根本には、「顧客課題の解像度」が低いまま動き出してしまっていることが多いです。
今日はそれを「営業の視点」で解決するアプローチについて書きます。営業っぽい話に聞こえるかもしれませんが、PMにこそ役立つ考え方だと思っています。

私のポジションについて

少しだけ自己紹介。

私はエンジニアとしてキャリアをスタートし、その後PMになり、今は営業・PM・事業企画・マネージャーと複数の役割を同時に担っています。
「営業もPMも両方やる」という少し珍しいポジションにいるからこそ、気づいたことがあります。

PMが苦労していることの多くは、営業の視点を持ち込むことで解決できる。

これが今日の話の出発点です。

PMが直面する「課題の解像度」問題

PMの皆さんが要件定義で苦労するシーンを少し思い浮かべてみてください。

顧客から来る依頼は、だいたいこういう形です。

• 「○○の機能がほしい」
• 「こういうシステムを作りたい」

一見すると具体的に聞こえます。でも、この段階で「何を作れば本当に解決するか」を明確に整理できているお客様は、実はかなり少ない。

よくあるパターンを3つ挙げます。

パターン①：作りたい機能はあるが、目的が整理できていない

「○○の機能がほしい」と言ってくれる。でも「なぜその機能なのか」「それで何を解決したいのか」を深掘りすると、機能が目的化していて、その先にあるビジネス課題との接続が切れている。

パターン②：いきなりHow（どう作るか）の話になる

最初から技術的な仕様や画面の話が始まる。「どう作るか」の議論が先行して、「なぜ作るのか」「誰のためなのか」が後回しになる。エンドユーザーの課題やビジネス課題が、最初から置き去りになっているケース。

パターン③：作ること自体が目的になってしまっている

実際に何かを作ることになってから相談が来る。でも「なぜそれを作るのか」を深掘りしていくと、作るべき機能が大きく変わる、なんてこともあります。本来「ビジネス課題を解決すること」が目的のはずなのに、いつの間にか「システムを作ること」が目的にすり替わっている。

PMとして、こういう状態で要件定義を進めることへの違和感を感じたことはないでしょうか。

なぜ解像度が上がらないのか

大きな原因は、顧客がそもそもシステム開発に慣れていないことだと思っています。

システム開発を依頼すること自体が、多くの顧客にとって初めてに近い経験です。だからこそ、こういう状況が生まれやすい。

• 何を開発会社に伝えれば良いのか分からない。
  要件定義に必要な情報を揃えて伝える、ということ自体が分からない。
• WhyやWhatを言語化して伝えることが少ない。
  「なぜ作るのか」「何を解決したいのか」という問いに答える習慣がない。伝えられるのは「こういう機能がほしい」というHowの話だけになってしまう。
• 「開発会社が何とかしてくれる」という期待がある。
  要件の整理は自分たちの仕事だという認識が薄く、曖昧なまま渡してしまう。

これは顧客が悪いわけではありません。開発プロジェクトの進め方に慣れていないのだから、当然のことです。
それをプロとしてサポートしてあげるのがわれわれであり、顧客に寄り添ってあげることが必要だと考えています。

一方でPM側にも落とし穴があります。顧客がHowの話をしてくると、ついその前提で乗ってしまいがち。「どう作るか」の議論は得意でも、「なぜ作るか」を引き戻す問いかけに慣れていない。エンジニア出身のPMは特にこれが起きやすいと感じています。（僕もエンジニア出身ということもあり、この思考から抜け出すのはかなり苦労しました）

顧客は「うまく伝えられない」、PMは「聞き方がHow寄りになりやすい」。この両方が重なって、Whyが掘れないまま話が進んでしまうのです。

さらに忘れがちな視点：「困りごとは何なのか」

もう一つ、PMとして意識したいことがあります。

顧客（発注者）の課題と、エンドユーザーの困りごとは、別の話です。

顧客は「業務効率を上げたい」「売上を伸ばしたい」というビジネス上の課題を持っています。一方でエンドユーザーは「この作業が面倒」「ここで毎回詰まる」という日々の痛みを持っている。

PMとして解像度を上げるべき対象は、この2つです。

• 顧客（発注者）のビジネス課題 — なぜ作るのか、何を達成したいのか
• エンドユーザーの困りごと — 誰が、どんな場面で、何に困っているのか

この両方が揃って初めて、「本当に必要なものを作る」ための土台ができます。どちらか一方だけでは、ビジネス的には正しくても使われないものになったり、現場は便利でも経営課題の解決にならないものになったりしてしまいます。

AI時代に、この問題がより深刻になる

ここが大事な話です。

AIで「それっぽいもの」がすぐ作れるようになったことで、余計にHowに飛びやすくなりました。

「こういう機能がほしい」と言われたら、以前なら「まず要件を整理して…」という時間があった。でも今は「じゃあClaudeで作ってみますね」とその場でプロトタイプが動いてしまう。Whyを掘る前にHowが走り出すリスクが、格段に高まっています。

もう一つ、開発スピードが上がることで、事業会社のPO・ビジネス側が置いていかれるという問題も起きています。

エンジニアやAIが高速で開発を進める中、要件を定義すべきPOや事業担当者がついていけない。「なんかすごい速さで進んでいるけど、これで本当によかったっけ？」という状態になる。ビジネス課題の定義者が置き去りになったまま、開発だけが先走ってしまう。

AIがどれだけ進化しても、「顧客の課題を正しく引き出して整理する」という部分は、人がやらなければなりません。AIが高速化するほど、課題の定義が間違ったまま爆速で進んでしまうリスクが高まる。

「課題を引き出す力」が、AI時代のPMに求められる最重要スキルになっています。

営業の視点を持ち込む

顧客は営業との商談でも、「こういう機能がほしい」「こういうシステムが必要だ」というHowの話から入ってくる。WhyやWhatが整理されていないまま、具体的な提案を求めてくる。「何を解決したいのか」より先に「何を作ってほしいのか」の話になってしまう。
これはPMだけの問題ではなく、顧客と向き合うすべての場面で共通して起きることです。
だからこそ、営業の現場で積み上げてきたアプローチが、PMの要件定義でもそのまま機能します。それが「Why・What・Howの仮説を全部持って、顧客のところに行く」というやり方です。

• Why（なぜ作るのか）の仮説： 「おそらく御社はこういうビジネス課題を抱えているのではないですか？」
• What（何を作るべきか）の仮説： 「だとすれば、必要なのはこういう仕組みではないですか？」
• How（どう作るか）の仮説： 「それを実現するなら、こういう画面・構成が考えられます」

この3つをセットで持っていくことで、顧客を「How脳」から引き戻すことができます。

仮説は「答えを当てにいく」ためではない

ここで一つ、重要なことを伝えたいです。

仮説提案は「正解を当てにいく」ためではありません。
もちろん正解であれば良いですが、大事なのは顧客が自分の課題に気づくための「鏡」として機能させることです。

「こういうビジネス課題ではないですか？」という仮説を見せると、「そうそう、まさにそれです！」となることがある。あるいは「いや、それよりもっと根本的には…」と、顧客自身も言語化できていなかった課題が出てくることがある。

顧客は空白を埋めるのが苦手です。でも「これは違う」は言える。仮説への反応から、本当の課題が見えてくるんです。

これは営業の現場でずっと実感してきたことですが、PMの要件定義でも全く同じように機能します。

ClaudeのSkillsで高速に実践する

「Why・What・Howの仮説を毎回準備するのは大変では？」と思うかもしれません。

そこでClaudeのSkillsを使っています。
Skillsとは、 Claude Codeに「特定の作業のやり方」を覚えさせる仕組みです。私たちのチームでは、仮説提案資料を作るためのSkillsと、画面モックを生成するためのSkillsを独自に開発し、チームのPlugin Marketplaceとして共有しています。

仮説提案資料のSkills：
業界・会社情報・問い合わせ内容を渡すだけで、WhyとWhatの課題仮説・解決策の素案を一貫したフォーマットで出力してくれます。ヒアリング前の叩き台を数分で用意できます。

画面モックのSkills：
ヒアリング内容をもとに、打ち合わせ当日に持参できるレベルの画面モックを高速で生成できます。「言葉でイメージを共有する」より「画面を見ながら違いを話す」方が、顧客の本音がはるかに出やすいです。

一人が良いSkillsを作れば、チーム全員がすぐに使えるようになる。ノウハウが個人の中で止まらず、チーム全体の力になります。

やってみて変わったこと

これをやり始めてから、顧客との最初の打ち合わせの質が明らかに変わりました。

以前は「どんなシステムが作りたいですか？」から始まって、なんとなくHowの話が続くことがありました。今は「おそらくこういうビジネス課題があるのではないですか？」という仮説と、「こういう画面をイメージしていますか？」というモックを持っていきます。
すると最初の打ち合わせから「違う、本当はこうなんです」という具体的な会話が生まれる。顧客が言語化できていなかった課題が、最初の1時間で見えてくる。
要件定義の精度が上がり、手戻りが減る。そして何より、顧客自身が「自分たちが本当にやりたいこと」を整理できた状態でプロジェクトが始まる。それがいちばん大きな変化だと感じています。

まとめ

PMの皆さんに向けて、今日一番伝えたかったことを書きます。

繰り返しになりますが、顧客課題の解像度が上がらない根本的な原因は、多くの場合、顧客がそもそもシステム開発に慣れていないことにあります。

• 何を開発会社に伝えれば良いのか分からない
• WhyやWhatを言語化して伝えることに慣れていない

だから顧客は、伝えられるHowの話から入ってくる。これはPMのスキル不足でも、顧客の問題意識が低いわけでもない。慣れていないだけです。

さらに、PMが解像度を上げるべき対象は顧客（発注者）の課題だけではありません。実際にシステムを使うエンドユーザーの困りごとも同様です。この両方の解像度が揃って初めて、本当に必要なものを作る土台ができます。

そのために、営業が当たり前にやっている「Why・What・Howの仮説を持って顧客のところに行く」というアプローチが、PMの現場でも強力に機能します。顧客が言語化できないなら、こちらから仮説を出して「これですか？」と確認する。その反応から本当の課題が見えてくる。

Why・What・Howの仮説を先に作る。Claudeのskillsでそのサイクルを高速に回す。

これを日々のヒアリングや打ち合わせのサイクルに取り入れていくことで、顧客課題の解像度が格段に変わってきます。一回やって終わりではなく、仮説を持っていく→反応を見る→課題を深める、このサイクルを回し続けることが大事です。

最後まで読んでいただきありがとうございました。
ではまた！