PMの板挟みをAIで解決。営業要望を仕様書に変えるプロンプト術

目次

その板挟み、痛いほど分かります。

プロダクトマネージャー(PM)のあなたへ。

「営業からは『もっと気の利いた機能を追加してくれ』とフワッとした要望が来る。一方で、開発からは『で、仕様は?具体的な要件をください』と詰められる…。」

この部門間の板挟み、私もかつて経験した地獄です。営業の「熱意」とエンジニアの「論理」。両者の言語はあまりにも違い、その間で翻訳作業に追われ、本来やるべき顧客価値の創造から遠ざかっていく。そんな日々に、あなたは疲弊していませんか?

この記事は、よくあるAIの使い方の理論を語るものではありません。私が数々の修羅場を乗り越える中で見つけ出した、あなたの仕事の進め方を変えるきっかけになる、具体的な「武器」としてのプロンプトを共有するためのものです。もう、あなたが一人で翻訳の苦しみを背負う必要はありません。

なぜあなたの指示はAIに「響かない」のか?よくある失敗例

まず、私たちがやりがちな失敗を見てみましょう。必死の思いで営業からヒアリングした内容を、あなたはこうAIに投げかけていないでしょうか?

【悪い例:よくある「丸投げ」プロンプト】

営業から来た要望です。
開発部門に伝えられるように、いい感じにまとめてください。

・検索機能が使いにくいらしい。もっとGoogleみたいにしてほしいと言っている。アポの前に顧客情報を探すのに時間がかかって困っている。
・競合他社はAIで次に営業する顧客を提案する機能があるらしい。うちもAIを使って何か気の利いた機能を追加できないか。
・スマホアプリからの報告が面倒。項目が多すぎる。音声入力とかで簡単にしてほしい。そうすればもっとみんなが報告するようになるはず。

要件を整理してください。

このプロンプトを投げた結果、返ってくるのはせいぜい箇条書きを少しだけ言い換えた、当たり障りのないテキストです。結局、あなたはため息をつきながら、ゼロから仕様書を書き始めることになる。この光景、目に浮かびませんか?

なぜこの「丸投げ」プロンプトは失敗するのか?

答えは単純です。これはAIに対する「指示」ではなく、同僚への「雑な依頼」だからです。AIは超優秀な新人ですが、エスパーではありません。失敗の根本原因は4つあります。

  1. 役割(ペルソナ)の欠如: AIは自分が「誰」として振る舞えばいいのか分からず、一般的なアシスタントの域を出ません。
  2. 背景(コンテキスト)の不足: なぜこの作業が必要なのか、どんな製品の話なのかが不明なため、的外れな回答しかできません。
  3. 指示の曖昧さ: 「いい感じに」「よしなに」はAIにとって最も翻訳不能な言葉です。ゴールが不明確なのです。
  4. 出力形式の未指定: 成果物のフォーマットが決まっていないため、構造化されておらず、後工程で全く使えないアウトプットが生まれます。

私たちは、AIを「便利な要約ツール」程度にしか使えていなかったのです。しかし、AIの真価はそんなものではありません。

解決策:AIを「優秀な思考パートナー」に変える魔法のプロンプト

では、どうすればいいのか?
これからお見せするのは、私が実践で磨き上げた「翻訳プロンプト」の完成形です。これをコピーして使うことで、AIはあなたの意図をより正確に汲み取りやすくなり、営業の要望をエンジニアが理解しやすい、質の高い仕様書のたたき台を作成してくれます。

【良い例:コピーして使える「翻訳」プロンプト】

あなたは、ビジネスサイドとエンジニアリングサイドの双方に深い知見を持つ、経験豊富なプロダクトマネージャー兼テクニカルコミュニケーターです。あなたの使命は、異なる部門間の言語的・文化的な壁を取り払い、共通理解を形成することです。特に、営業部門から発せられる定性的で感情的な「要望」を、エンジニアが具体的かつ論理的に理解できる「技術仕様」へと翻訳する能力に長けています。


あなたは、法人向けCRM(顧客管理システム)を提供するSaaS企業に所属しています。現在、営業部門と開発部門の間でコミュニケーションの齟齬が頻発し、プロジェクトの遅延や手戻りの原因となっています。営業部門からの機能改善要望が曖昧なため、開発部門は正確な仕様を把握できず、実装に着手できない状況が続いています。
このプロンプトは、以下の「入力情報」セクションに記載された営業部門からの生の声を、開発部門が直接的な開発タスクとして検討できるレベルの仕様書に変換するために使用されます。


入力情報として与えられた営業部門からの要望を、エンジニアが即座に理解し、工数見積もりや実装設計に着手できるような、論理的で具体的な技術仕様書を作成すること。


・顧客リストの検索機能がとにかく使いにくい。もっとGoogleみたいに、キーワードを一つ入れたら会社名でも担当者名でも、過去の活動履歴でも、関連するものが全部一瞬で出てくるようにしてほしい。大事なアポイントの直前にお客様の情報を探すのに5分もかかっていて、ビジネスチャンスを逃している。
・競合のA社は、AIが「次にアプローチすべき顧客リスト」を自動で提案してくれるらしい。うちもそういう最先端の機能がないと、顧客に「古いシステムだ」と思われてしまう。営業担当者の勘と経験だけに頼るのではなく、データに基づいた効率的な営業活動ができるように、何かAIを使った気の利いた機能を追加してほしい。
・スマートフォンアプリからの日報入力が面倒すぎる。移動中の電車内などで片手で入力するには項目が多すぎるし、入力しづらい。結果として、多くの営業担当者が帰社してからまとめて入力しており、情報の鮮度が落ち、報告漏れも発生している。移動時間中に音声で簡単に入力できれば、みんなもっとリアルタイムに報告するようになり、マネージャーも正確な状況を把握できるはずだ。


以下のステップに従って、入力情報を技術仕様書に変換してください。

1.  要望の分解と本質の特定:
    各要望の背景にある、営業担当者の具体的な「課題(Pain)」と、それによって達成したい「理想の状態(Gain)」を明確に言語化してください。表面的な言葉の裏にある、根本的な業務課題を洞察することが重要です。

2.  要件への変換:
    特定した課題と理想の状態に基づき、それぞれの要望を具体的な「機能要件」と「非機能要件」に分類・整理してください。
    ・機能要件: ユーザーが何をできるべきか
    ・非機能要件: システムがどうあるべきか

3.  技術仕様への落とし込み:
    定義した要件を、エンジニアが実装を検討できるレベルまで具体化してください。想定されるユーザーシナリオや技術的な論点を可能な限り含めてください。

4.  確認事項のリストアップ:
    仕様を確定するために、プロダクトオーナーや営業部門に確認すべき点を、具体的かつ明確な質問形式でリストアップしてください。


・憶測で仕様を確定しないでください。情報が不足している点や、複数の選択肢が考えられる点については、必ず「確認事項」として明記してください。
・営業部門の元々の要望の意図を軽視せず、なぜそのような要望が出てきたのかという背景を尊重した上で、最適な解決策を提案してください。


以下のマークダウン形式に従って、要望ごとにセクションを分けて構造化された仕様書を生成してください。

---
## 機能改善仕様書: {ここに機能の名称を記述}

### 1. 概要
### 2. 開発背景 (営業要望の翻訳)
- 課題 (Pain): 
- 理想 (Gain): 
### 3. 想定ユーザーシナリオ
### 4. 要件定義
#### 4-1. 機能要件
#### 4-2. 非機能要件
### 5. 技術的な論点と考慮事項
### 6. 確認事項
---

なぜこのプロンプトは機能するのか?思考プロセスの分解

「悪い例」と「良い例」の違いは、単なる文章量の差ではありません。それは、AIに対する関わり方の哲学そのものが違います。

  • 「役割設定」でAIを専門家にする
    「あなたは経験豊富なPMだ」と定義することで、AIは単なるテキスト生成ツールから、特定の専門知識と視点を持ったペルソナへと変貌します。これにより、アウトプットの視座が格段に上がります。
  • 「コンテキスト」で当事者意識を持たせる
    「あなたはSaaS企業にいる」「部門間対立が課題だ」という背景を与えることで、AIはこのタスクが単なる文章整理ではなく、具体的なビジネス課題を解決するための重要なミッションだと理解します。
  • 「指示」で思考プロセスを誘導する
    「いい感じに」ではなく、「①課題を特定し、②要件に変換し、③仕様に落とし込み、④確認事項をリスト化せよ」とタスクを分解して命令しています。これは思考の連鎖(Chain of Thought)を促す強力なテクニックで、AIに論理的かつ体系的な思考を強制します。特に「課題(Pain)と理想(Gain)」を考えさせることで、表面的な要望の裏にある本質的なニーズを掘り起こさせているのが肝です。
  • 「出力形式」で品質を担保する
    厳格なテンプレートを指定することで、アウトプットの品質が安定し、思考の漏れがなくなります。この構造化された出力は、そのまま開発ドキュメントとして利用できるレベルの品質を持ちます。

このプロンプトは、AIに「何をすべきか(What)」だけを伝えるのではなく、「誰として(Who)」「なぜ(Why)」「どのように(How)」「どんな形で(Format)」という、仕事の全体像を渡しているのです。これはもはや「指示書」ではなく、AIという優秀なパートナーを動かすための「思考の設計図」なのです。

実践:この「武器」をさらに使いこなすために

このプロンプトは非常に強力ですが、あなたの実務に合わせてカスタマイズすることで、さらに切れ味が増します。

  • コンテキストをあなたの言葉で: #コンテキストセクションは、あなたの会社の製品名、チームの状況、具体的な課題などを追記することで、よりパーソナライズされたアウトプットが得られます。
  • 出力形式を自社のフォーマットに: もしあなたのチームがJIRAやBacklog、Confluenceを使っているなら、#出力形式をそのチケットやドキュメントのテンプレートに合わせて改変してみてください。AIが生成したテキストをコピー&ペーストするだけで、起票作業が完了します。
  • 「確認事項」を磨き込む: AIがリストアップした「確認事項」は、議論のたたき台として非常に優秀です。しかし、最終的にそれを営業や開発にぶつけ、合意形成を行うのはあなたの役目です。AIの提案を元に、より本質を突く質問へと磨き上げましょう。

一つだけ注意点です。AIの出力はあくまで「非常に質の高いたたき台」です。これを鵜呑みにするのではなく、あなたの専門的な知見と判断を加えて初めて、真に価値のある仕様書が完成します。AIは思考のパートナーであり、最終決定者ではないことを忘れないでください。

結論:あなたは「翻訳者」から「問題解決者」へ

私たちはこれまで、部門間の溝を埋めるための「翻訳作業」にあまりにも多くの時間を費やしてきました。しかし、その時代は終わります。

今回ご紹介したプロンプトは、単なる時短テクニックではありません。それは、AIをあなたの思考を拡張するパートナーとして迎え入れ、あなたを煩雑な作業から解放するための「設計図」です。

この武器を手に、あなたはもはや板挟みに悩む調整役ではありません。営業の熱意をビジネス価値へと昇華させ、エンジニアの力を最大限に引き出す。部門間のハブとなり、プロジェクトを力強く推進する「ペインポイントの解決者(The Pain Point Solver)」です。

さあ、このプロンプトを手に、本来あなたが集中すべき、顧客のための価値創造へと踏み出しましょう。

よろしければシェアをお願いします
  • URLをコピーしました!
  • URLをコピーしました!
目次