この記事の要約
- 【課題】 機能要件（Function）は決まったが、それが「いつ、どんな状況で、どんな感情で」使われるかの解像度が低く、リリース後に「使いにくい」と言われてしまう。
- 【解決】 PRDをLLMに入力し、「特定のペルソナがその機能を使う1週間のストーリー」を生成させることで、机上の空論ではないリアルな利用シーン（文脈）をあぶり出す。
- 【実践】 架空の「1on1支援ツール」を題材に、AIによるシミュレーションを通じて「会議直前の焦り」や「気まずい沈黙」といった文脈を発見し、仕様をブラッシュアップする過程を紹介。
プロダクトマネージャー（PdM）の皆さん、PRD（要求仕様書）を書くとき、どこまで「ユーザーの生活」を想像できているでしょうか？
「ユーザーはxxxボタンを押して、レポートを閲覧できる」
これは仕様書としては正解です。でも、現実のユーザーは仕様の中に生きているわけではありません。そのボタンを押すとき、彼は満員電車にいるかもしれません。あるいは、上司への報告直前で冷や汗をかきながら、震える指で操作しているかもしれません。
この「利用シーンの解像度」の低さが、リリース後の「なんか使いにくい」「現場では使えない」という悲しいフィードバックを生みます。
そこで提案したいのが、生成AI（LLM）を使って、作成した機能を「ユーザーの生活/仕事シーン」の中でシミュレーションさせる手法です。
開発者のためにチケットを書くのではありません。PdMであるあなたが、仕様を確定させる前に「本当にこの仕様で、あの忙しいユーザーを救えるのか？」を検証し、要求をブラッシュアップするためにAIを使うのです。
機能（Function）と体験（Experience）の間にある「文脈」の壁
「ユーザーストーリー」を形式だけで終わらせない
アジャイル開発でおなじみのユーザーストーリー。
「＜ユーザー＞として、＜目的＞のために、＜機能＞がほしい」という構文は有名ですが、多くのPdMはこれを単なる開発チケットのフォーマットとして処理してしまっています。
しかし、本来のユーザーストーリーとは、その名の通り「物語」であるはずです。
- 朝9時、メールチェックのついでに見るのか？
- 金曜日の夕方、疲れ切った状態で行うのか？
- その時、ユーザーはポジティブな気分か、ネガティブな気分か？
この「文脈（コンテキスト）」が抜け落ちたまま仕様を固めると、機能としては満たしていても、体験としては破綻しているプロダクトができあがります。
以前、ユーザーインタビューでたった1つ意識するなら「コンテクストの徹底的な深堀」という記事でも書きましたが、コンテキストなき機能は、ただの「動くゴミ」になりかねません。
AIは「文脈」を補完する最高のシミュレーター
とはいえ、自分一人で多様なユーザーの多様な状況を想像するのは限界があります。
ここでAI（LLM）の出番です。
AIは「網羅性の鬼」です。
あなたが考えた機能を、AIという仮想ユーザーに渡して、「この機能を使って1週間生活してみて」と指示する。
するとAIは、あなたが想定していなかった「忙しい火曜日の朝」や「トラブルが起きた木曜日の午後」のシーンを生成し、仕様の穴を教えてくれます。
【実践】HRテック機能「1on1トピックサジェスト」をシミュレーションする
では、具体的にどうやるのか。架空のHRテックプロダクト「OneSync」の新機能を題材に実演します。
Step 1：ベースとなる機能要件（PRDの概要）
まず、PdMが考えた「機能の原案」を用意します。
機能名：スマート・トピックサジェスト
概要： 1on1の会話ネタに困らないよう、部下の最近の活動（日報、Slack、勤怠）から、AIが自動で「話すべきトピック」を3つ提案する。
UIイメージ： 1on1画面を開くと、サイドバーに「おすすめトピック」が表示される。
一見、良さそうな機能です。
しかし、このままエンジニアに渡したり、ユーザーリサーチに入る前に、AIで「解像度」を上げてみましょう（もちろん、この機能を考える前提として切実な顧客の課題と捉えている必要があります）。
Step 2：AIに「生活シーン」をシミュレーションさせるプロンプト
以下のプロンプトをChatGPTやGeminiに入力します。
ポイントは、「機能のテスト」ではなく「生活のドラマ」を描かせることです。
# 命令 あなたは「多忙を極めるプレイングマネージャー（30代後半、部下8名）」です。 今回、利用中のツールに新機能「スマート・トピックサジェスト」が実装されました。 以下の機能要件をもとに、あなたのリアルな1週間の業務シーンの中で、この機能がどう使われるか（あるいは使われないか）を、具体的なショートストーリー形式で3パターン生成してください。 # 機能要件 （ここに先ほどのPRD概要を貼る） # 制約条件 ・「便利でした」という感想だけでなく、使用する直前の状況（時間、場所、焦り具合）や、使用した時の感情（安堵、イラつき、困惑）を超具体的に描写すること。 ・ハッピーパス（理想的な成功）だけでなく、バッドパターン（期待外れ、状況に合わない）も含めること。
Step 3：AIが出力した「3つのリアルなシーン」
すると、AIは以下のようなストーリーを返してきました（要約）。
シーンA：【火曜 10:58】 会議直前の駆け込み利用
次の1on1まであと2分。前の会議が伸びて準備時間ゼロ。焦りながらスマホでアプリを開く。
「サジェスト」が出た！……が、文章が長すぎて読む時間がない。
「部下の田中さんは最近、Reactの学習に意欲的で……」と3行も書いてある。
「要するに何を話せばいいんだ！」とイラつきながら、結局いつもの雑談でお茶を濁した。
👉 PdMの気づき（仕様の修正点）：
要約文はいらない。「Reactの学習について褒める」という「アクション（見出し）」だけを大きく表示するモードが必要だ。
シーンB：【木曜 15:00】 関係性の薄い部下との1on1
最近配属されたばかりの新人との1on1。まだ信頼関係が浅い。
サジェスト機能は「昨日の残業時間が4時間でした。体調を気遣いましょう」と提案してきた。
しかし、関係が浅い状態でいきなり勤怠の話をするのは「監視されている」と思われそうで怖い。
結局、このサジェストは「重すぎて」使えなかった。
👉 PdMの気づき（仕様の修正点）：
トピックには「業務（Heavy）」と「雑談（Light）」のタグ付けが必要だ。関係性に合わせて「ライトな話題」だけでフィルタリングする機能がないと、マネージャーは怖くて使えない。
シーンC：【金曜 18:00】 ネガティブフィードバック後
先週、厳しい指導をした部下との回。気まずい空気が流れている。
AIは空気を読まず「先週のゴルフコンペの話で盛り上がりましょう！」と提案してきた。
「今そんな空気じゃないんだよ……」と画面をそっと閉じた。
👉 PdMの気づき（仕様の修正点）：
「直近の1on1メモ」の感情分析が必要かもしれない。あるいは、ユーザーが手動で「今は真面目モード」とトーンを設定できるスイッチが必要だ。
「網羅性の鬼」であるAIを使って考慮漏れを防ぐ
いかがでしょうか？
当初の「おすすめトピックを表示する」という単純な仕様が、AIによるシミュレーションを経ることで、より現場に即した形にブラッシュアップされました。
人間（PdM）は、どうしても自分の都合の良い「ハッピーパス（正常に機能が使われて喜ばれるルート）」ばかりを想像してしまいます。
しかし、AIは感情を持たないからこそ、冷徹に、そして網羅的に「文脈にそぐわないケース（アンハッピーパス）」をシミュレーションしてくれます。
これは、ユーザーインタビューで起こるバイアスを開発プロセスの中で擬似的に発見する作業とも言えます。
「現場で使えない」と言われる前に、AIという「一番口うるさいユーザー」にボコボコにされる。これこそが手戻りを防ぐ最短ルートです。
PdMの仕事は「機能」を作ることではなく、「シーン」を作ること
「機能を考えたら終わり」ではありません。
その機能が、ユーザーの泥臭い日常の中でどう着地するか。
その着地シーン（ユーザーストーリー）の解像度こそが、プロダクトの勝敗を分けます。
AIに開発コードを書かせるのも便利ですが、企画段階で「生活」を演じてもらう。
これこそが、手戻りを防ぎ、本当に使われるプロダクトを作るための、PdMならではのAI活用法ではないでしょうか。
今日から実践できるアクションリスト
- 作成中のPRDや機能案を、上記プロンプトを使ってAIに投げ、「バッドエンドのストーリー」を生成させてみる。
- 生成されたストーリーを見て、「UIで解決できるか？（表示の簡素化など）」「ロジックで解決できるか？（フィルタリングなど）」を検討し、仕様書に追記する。
- エンジニアへの仕様説明時に、AIが作ったストーリー（特に失敗シーン）を共有し、「こういう状況を防ぐために、この仕様にしています」と伝える。
よくあるQ&A
- Q. AIの想像したストーリーは、ただの妄想ではありませんか？
- A. その通り、妄想（シミュレーション）です。しかし、“顧客は未来を語れない”から、徹底的にファクトを集めてPdMが未来を妄想する必要があるのです。AIの妄想をトリガーにして、PdMが「確かにありえる！」と気づきを得ることが重要であり、それが正しいかどうかは最終的にご自身の経験やユーザーリサーチで判断してください。
- Q. どのフェーズでやるのが最適ですか？
- A. PRDの初稿が書き上がったタイミングがベストです。エンジニアやデザイナーに見せる前に、AIと壁打ちして「論理的な穴」や「体験の穴」を塞いでおくと、レビューの手戻りが劇的に減ります。
コメント