ヒアリングシート1枚でPRとPRDを同時生成する。AI版ワーキングバックワーズ実践ガイド

Amazonが提唱したワーキングバックワーズは、未来のプレスリリースを先に書き、そこから逆算して製品を作る手法です。AIの登場でこの手法は、ヒアリングシート1枚を種にして、PR（顧客への約束）とPRD（実装指針）を同時に生成するプロセスへと進化しました。この記事では、ヒアリングシートのテンプレートから、計画書、タスク分解までの一続きのワークフローを解説します。

「PRを書く手法」から「PRとPRDを同時に咲かせる手法」へ

従来のワーキングバックワーズでは、プレスリリースを書く作業自体に時間がかかりました。書き上げたPRを直すと、要件書も手で直す必要があり、2つの文書は放っておくとすぐ乖離します。

AIを組み込むと、この関係が変わります。人間が用意するのは「誰の、どんな課題を、どう解決するか」を凝縮したヒアリングシート1枚だけです。AIがそれを読み込み、エンジニアが実装に使えるPRDと、顧客に価値を伝えるPRの両方を生成します。PRD（仕様）を修正すれば、PR（告知文）も即座に追従させられるため、「何を作るか」と「どう売るか」が常に一致した状態を保てます。

ワークフローの全体は4ステップです。

ステップ	アクション	AIの役割	成果物
① 抽出	ヒアリングシートの記入	思考の整理・深掘りの提案	ビジョンの核
② 生成	PRDの自動構成	情緒から論理への翻訳	PRD（要件定義書）
③ 検証	仮想プレスリリースの作成	顧客視点でのフィードバック	PR（プレスリリース）
④ 実行	プロトタイプ開発	コード生成・仕様の即時修正	プロダクト

入力はヒアリングシート1枚

AIが精度の高いPRDとPRを生成できるかは、入力の質で決まります。次の構成のシートを使います。大型家具のフリマアプリを例にした記入例つきです。

プロジェクトの骨子（戦略）

項目	聞くこと	記入例
対象ユーザー（Who）	誰が、どんな状況で使うか	引越しを控え、まだ使える家具を処分したい人。安く家具を揃えたい近隣住民
顧客の痛み（Why）	現状のどんな課題を、なぜ今解決するのか	大型家具は送料が高く、既存フリマアプリでは売買が成立しにくい。結局廃棄されている
解決策（What）	課題をどう解決する製品か	近隣住民同士が直接会って受け渡す仕組みで、配送コストをゼロにする
魔法の瞬間	ユーザーが喜びを確信する瞬間はいつか	出品後すぐに近所から連絡が来て、その日のうちに部屋が片づいた瞬間
目標・指標（KPI）	成功をどう定義するか	3ヶ月で1,000成約。出品から成約まで72時間以内

要件と体験（実装）: 必須機能（地図検索、カレンダー連携チャット、エスクロー決済）、ユーザーフロー（検索→チャット調整→対面受け渡し→QR決済）、非機能要件（現在地の曖昧化、3秒以内の地図描画、本人確認の必須化）。

境界線とリスク（管理）: やらないこと（配送代行なし、PC版なし、オークション形式なし）と、前提・リスク（地図APIのコスト増、対面時のドタキャンには評価制で対策）。

記入時のコツは「Why」の深掘りです。ヒアリング相手が機能の話ばかりする場合は、「それで対象ユーザーのどんな課題が解決されるのか」と問い直します。非機能要件とリスクの欄は、エンジニアと一緒に埋めると技術的な手戻りを減らせます。ヒアリングの場で埋まらなかった項目は、推測で補わずTBDとして残し、後工程で確認します。顧客が明言した事実と、文脈からの推測と、未確認事項を区別して記録しておくと、後工程のPRDで「根拠のない仕様」が混入するのを防げます。

FAQを自動生成してガードレールにする

シートが埋まったら、PRDの生成と合わせて、AIに「この製品に対して顧客が抱くであろう不満や疑問」を大量に出させます。出てきたFAQの中には、プライバシーの懸念や決済トラブルなど、仕様で先回りすべき論点が含まれています。これをPRDの制約事項に反映させることで、リリース後に発覚するはずだった問題の一部を、企画段階で潰せます。

戦略と実装をつなぐプロジェクト計画書

PRとPRDができたら、プロジェクト計画書で現実に着地させます。計画書に書くのは、ヒアリングシートから抽出した背景・目的・KPI、PRDに基づく機能定義とスコープ外、体制と会議体、リスク、そしてリリース日から逆算したマイルストーンです。gaipackのプロジェクト計画書ガイドラインでは、ここに品質方針の章を設け、QCD（品質・コスト・納期）の優先度をこの段階で関係者と合意しておきます。計画書はドラフト→質問票→再ドラフトの3段階で仕上げ、不明点を推測で埋めずに質問として顧客へ返します。

会議体でこのモデルに特有なのが、隔週のビジョン同期会です。PO・PM・リードが集まり、「今の実装は、最初に書いたプレスリリースで約束した体験を叶えているか」を検証します。実装が進むほど視線は目の前のタスクに向かうため、約束からの逸脱を定期的に検出する仕組みを最初から組み込んでおきます。開発が遅延したときの選択肢も明快で、「PRの内容を修正する」か「機能を削る」かを即断します。

タスク粒度と成果物の黄金フロー

最後に、構想から実装までの全体を、タスク粒度と成果物の対応で整理します。

フェーズ	タスク粒度	成果物	役割
1. 構想	テーマ〜エピック	PR、PRD概要（ドラフト）	理想を描き、Why/Whatの骨組みを定義する
2. 計画	エピック	プロジェクト計画書	予算・期間・体制を確定し、スコープをロックする
3. 仕様化	エピック→ストーリー	PRD詳細	例外処理まで詰め、開発可能なサイズに分割する
4. 実行	タスク	コード（機能）	ストーリーを作業手順に分解して消化する

流れを一言でいうと、「PRとPRD概要で風呂敷を広げ、計画書で現実的なサイズに畳み直し、PRD詳細で中身を整理して、ストーリーとタスクで形にしていく」となります。構想段階でPRDを「概要」にとどめるのは手抜きではなく、計画段階で理想と現実（見積もり）をすり合わせる余地を残すためです。たとえば「オフライン閲覧まで入れるとリリースに間に合わない」と分かった時点でスコープから外す、という判断がここで行われます。

この構造は、gaipackのAIDDスキームが定義する要件ドキュメントの階層とも対応しています。プロジェクト計画書とPRD概要が上位レイヤー、画面定義まで詳細化したPRDが中間、開発可能な最小単位であるEPIC（受け入れ条件をGherkin形式で記述）が最下層で、EPICはGitHub Issueとして起票し、その子issueとしてPBIを管理します。粒度を段階的に細かくしながら、上位の約束と下位のタスクをつなぎ続ける、という思想は同じです。

まとめ

原則	内容
種はヒアリングシート1枚	Who・Why・What・魔法の瞬間・KPIを人間が言語化する
PRとPRDを同時生成	顧客への約束と実装指針を、AIで常に同期させる
埋まらない欄はTBD	推測で補わず、事実・推測・未確認を区別して残す
FAQでガードレール	顧客の不満をAIに先回りさせ、仕様の制約に反映する
ビジョン同期会	実装がPRの約束を叶えているかを定期的に検証する
風呂敷は広げてから畳む	PR/PRD概要→計画書→PRD詳細→ストーリーの順に解像度を上げる

gaipackでは、ヒアリングからPRD・EPICの生成までをAIDD 要件定義として、新規開発（0→1）を3ヶ月で動くMVPに仕上げるPoCパッケージをAIDD MVPとして提供しています。新規プロダクトの立ち上げをご検討でしたら、お気軽にKDDIアイレットへお問い合わせください！