プロダクト要求仕様書：[プロダクト名]
[角括弧]内をすべて書き換え、各セクションを書き終えたらガイド文を削除してください。チーム外の人がこの文書だけで最初のリリースを作れ、別の人がそれを検証できる状態になれば完成です。
01概要
2〜3行で。何を、誰のために作るのかをこの短さで言えないなら、残りの文書でも解決しません。
- プロダクト: [名称]
- オーナー: [スコープの判断をする人]
- ステータス: [下書き / レビュー中 / 合意済み]
- 最終更新: [日付]
- 一言で: [何か、誰のためか、何を置き換えるか]
02課題
足りない機能としてではなく、ユーザーが実際に困っている形で書きます。今は代わりに何をしているか、なぜそう言えるのかも添えてください。
現在、[誰]は[何かをする]必要があるとき、[どんな回避策]を使っている。その結果、[実際に観察した時間・費用・リスク]が生じている。
根拠: [インタビュー、サポート問い合わせ、商談、自分自身の利用。どれを何件か明記。]
03ターゲットユーザー
主要ユーザーは一人に絞ります。解決策を探し始めるきっかけと、対象外の人も明記します。
- 主要ユーザー: [役割、会社規模、状況]
- きっかけ: [新しい手段を探し始める出来事]
- 現在の代替手段: [スプレッドシート、他のツール、人、何もしない]
- 対象外: [あえて対象にしない人とその理由]
04ジョブ（Jobs to be done）
ユーザーが成し遂げたいことを、ユーザーの言葉で。3〜5個、重要な順に。
- ジョブ1: [状況]のとき、[行動]したい。そうすれば[成果]が得られる。
- ジョブ2: [状況]のとき、[行動]したい。そうすれば[成果]が得られる。
- ジョブ3: [状況]のとき、[行動]したい。そうすれば[成果]が得られる。
05MVPのスコープ
最初のリリースでできること。各行は、動いている様子を人が確認できるものにします。
- [これがないとリリースできない最初の機能]
- [2つ目の機能]
- [3つ目の機能]
06要件
1行に検証可能な記述を1つ。受け入れ基準は、稼働中のプロダクトでどう確認するかを書きます。これがない要件は監査できません。優先度はMoSCoW（Must / Should / Could / Won't）。種別は機能要件（振る舞い）、非機能要件（速度・可用性・アクセシビリティ）、制約（規制・プラットフォーム・予算）のいずれかです。
キーは永久に固定です。番号の振り直しや再利用はしないでください。タスク、コミット、監査がこのキーを参照します。
| キー | 要件 | 受け入れ基準 | 優先度 | 種別 |
|---|---|---|---|---|
| REQ-001 | ユーザーは[目に見える操作]ができる | [稼働中のシステムで動作を示す手順] | Must | 機能 |
| REQ-002 | [ページや操作]が[負荷]のもとで[時間]以内に応答する | [どこで、どう計測するか] | Should | 非機能 |
| REQ-003 | [規制・プラットフォーム・予算の制限] | [守られていることの証拠] | Must | 制約 |
| REQ-004 | [言及はあるが後回しにするもの] | [後日どう確認するか] | Won't | 機能 |
07成功指標
リリースがうまくいったかをどう判断するか。指標、計測場所、目標値を書きます。目標値は、作るくらいなら空欄のままに。
- 主要指標: [何を]を[ツール]で計測、目標[値、またはベースライン計測後に設定]
- 副次指標: [何を]を[ツール]で計測、目標[値]
- ガードレール: [悪化させてはいけない数値。エラー率や返金など]
08非ゴール
このリリースであえてやらないこと。最も多くの議論を未然に防ぐセクションです。
- [含まれていると思われがちなもの、と含めない理由]
- [2つ目の非ゴール]
09未決事項
まだ決まっていないことすべてに、担当者と期日を。担当者のいない問いは永遠に開いたままです。
- [問い]（担当：[名前]、期日：[日付]）
- [問い]（担当：[名前]、期日：[日付]）
10承認
このバージョンに合意した人。これ以降のスコープ変更は、提案して記録するもの。こっそり紛れ込ませるものではありません。
- 承認者: [氏名]
- 承認日: [日付]
- スコープ変更の方法: [変更の提案方法と記録場所]