プロダクト要件：インタビューからPRDを作る方法

ボタンを求められても、課題はまだ分からない

顧客が「エクスポートボタンを追加して」と言いました。それだけでは誰がファイルを使い、何を含め、次に何をするかは分かりません。プロダクト要件文書（PRD）は、チームが課題と成果の範囲を同じように理解するために使います。

ここでは一つの機能の短い作業文書を扱います。設計、契約、組織の技術要件はそれぞれ別に必要です。実装を選ぶ前に、利用者の課題を検証できる形にします。

利用者の依頼から要件へ

1. 直近の実際のケースに戻る

   いつ出力が必要になり、代わりに何をし、どのデータを移し、どこで困ったかを聞きます。文字起こしで例と影響を示します。「不便だった」だけでは改善を検証できないので、具体的に聞きます。

2. 画面を決める前にシナリオを書く

   誰がどのデータで行動を始め、どんな結果を期待するか記します。ボタン、メール、自動レポートは解決策の候補です。ニーズと制約を調べてから採用を決めます。

3. リリースの範囲を決める

   今回に含めることと、意図的に外すことを書きます。アクセス権、データ項目、結果が空の場合は別に挙げます。速度や件数を要件にする前に測定条件を合意します。

4. 検証方法を決める

   要件ごとに観察できる成果と入力例を示し、元の課題と結び付けます。依頼者が確認していない点は未解決の質問として残し、回答者と判断の期限を書きます。

対応済み問い合わせの一覧を出力する

架空の学習例です。名前、条件、結果は方法の説明用です。

必要なのは指定期間の特定の情報を渡すことです。すべてのデータ、添付ファイル、やり取りの全文が必要だとはインタビューにありません。

検証基準の例：期間を選ぶと、その期間に対応を終えた問い合わせと、合意した項目だけが出力される。境界の日付の扱いは別途確認します。

一つの機能向けのPRDテンプレート

要件を一つずつ観察事実に結び付けます。一つの出典が複数の項目を支えても、合意は別に確認します。

機能名とバージョン：
利用者の課題：
インタビューの具体例：
利用者と状況：
主なシナリオ：
期待する成果：
データと制約：
対象範囲／対象外：
検証基準：
仮定と未解決の質問：
出典とタイムコード：
承認者と日付：

文書の作成者がいなくても要件を検証できるか？

• 各要件がどの課題を解決するか分かる。
• 検証できる成果と実装方法が分かれている。
• 今回のリリース範囲が明記されている。
• 未解決の質問が明示されている。