---
name: prd-from-notes
description: 散らかったメモ、Slack のスレッド、商談メモ、創業者の頭の中を書き出したものから、プロダクト要求仕様書（PRD）を作る。課題とその根拠、ユーザー、目標と目標外、成功指標、Must・Should・Could の要件、未解決の問い、リスクをそろえ、足りない情報はつくらずに挙げる。散らばったメモから PRD、仕様書、1枚の企画書を作りたいとき、「開発が作れるようにまとめて」と頼まれたときに使う。
---

# メモから PRD を作る

よい PRD があれば、エンジニアとデザイナーは打ち合わせなしで作業を始められ、読み手はわかっていることと推測を見分けられる。解決策より先に課題を書き、どの要件も課題に結びつけ、足りない情報はすべてはっきり書く。足りない情報を隠した PRD からは、違うものができあがる。

## 使う場面

- ある機能についてのメモ、Slack のスレッド、商談メモ、顧客の声があり、PRD にしたいとき。
- 打ち合わせやホワイトボードでの議論のあと、創業者から「チーム向けにまとめて」と言われたとき。
- 作るかどうかを決める前に、1枚の企画書がほしいとき。
- できあがった PRD のレビューには使わない。spec-review を使う。作業をチケットに分けるためにも使わない。user-stories を使う。

## 用意するもの

- 元になる材料: メモ、スレッド、文字起こし、顧客の声、文章で説明したスクリーンショット。
- その機能がだれのためのものか（メモに書かれていなければ）。一度だけ聞き、それでもわからなければ「[仮定: 対象ユーザー]」と書く。
- わかっている期限、制約、指標の目標。なければ目標は「[未定: 目標値なし]」のままにする。

## 手順

1. **課題とその根拠を抜き出す。** Marty Cagan の機会評価の最初の問い「これはだれの、どんな課題を解決するのか」に答える。課題は、ユーザーがいまできないこと、またはそれで失っているものとして書く。その下に根拠を並べる: 顧客の声、問い合わせの件数、失注、数字。メモに根拠がなければ、理由をつくらずに「メモに根拠なし」と書く。
2. **ユーザーを特定する。** 主なユーザー一人と、多くて2人の副次的なユーザー。それぞれ、課題にぶつかるときの状況を添える。「中小企業の経営者」では広すぎる。「スマートフォンからはじめて請求書を送る経営者」くらいに絞る。
3. **目標と目標外を分ける。** 目標は機能ではなく成果で書く。目標外は少なくとも2つ書く。メモで話に出て見送られたものはここに入れ、だれも蒸し返さないようにする。
4. **成功指標を決める。** 課題が解決すれば動く主指標をひとつと、悪化させてはいけないガードレール指標を1〜2個。どれにも現状値と目標値が要る。メモになければ「[未定: 現状値]」「[未定: 目標値]」と書く。
5. **要件を Must・Should・Could（MoSCoW）で書く。** Must = これがなければ成り立たない。Should = 大事で、外すと痛いが、回避策がある。Could = あるとよく、期日が危うくなったら最初に削る。Won't（今回はやらない）は目標外に入れ、こっそり戻ってこないようにする。どの行も確かめられる形で書き（「ユーザーが CSV に書き出せる」）、あいまいにしない（「かんたんに書き出せる」）。Agile Business Consortium のガイドでは、Must はふつう作業量の60%以下に収める。Must がそれより大きく見えたら、1回のリリースには範囲が大きすぎると書く。
6. **未解決の問いとリスクを挙げる。** 2つのメモの食い違いは、両方の立場を書いた未解決の問いにする。リスクには、機能がうまくいかない原因になりうるものを書く: 使われない、技術、法務、ほかのチームへの依存。メモに担当者が出ていれば、それぞれにつける。
7. **主張ごとに出どころを示す。** メモにある事実はそのまま書く。推測したことには「[仮定]」をつける。入力にない数字、日付、顧客名は埋めない。

## 出力の形式

```markdown
# PRD: [機能名]

**作成者:** [名前] · **状態:** 下書き · **最終更新:** [日付]

## 課題
[2〜4文: ユーザーがいまできないことと、それで失っているもの。]

**根拠**
- [顧客の声、件数、データ。出どころつき]

## ユーザー
- **主なユーザー:** [だれが、どんな状況で]
- **副次的なユーザー:** [だれが、どんな状況で]

## 目標
- [成果]

## 目標外
- [今回のリリースでやらないこと。わかっていれば理由も]

## 成功指標
| 指標 | 種類 | 現状値 | 目標値 |
|---|---|---|---|
| [指標] | 主指標 | [値または未定] | [値または未定] |
| [指標] | ガードレール | [値または未定] | [… を下回らない] |

## 要件
| # | 要件 | 優先度 | メモ |
|---|---|---|---|
| R1 | [確かめられる文] | Must | [出どころまたは仮定] |

## 未解決の問い
- [問い] — [わかっていれば担当者]

## リスク
- [リスク] — [対策、または「まだなし」]

## メモに足りないこと
- [作る前にチームが決めなければならない、欠けている情報]
```

## 例

**入力（抜粋）:**

> Slack、坂本さん（CS）: 今週3社から、席の料金を払わずに顧問税理士を招待したいと言われた。
> 商談メモ、岡田さん（代表）:「閲覧だけの席？ 無料でもいいかも。権限の仕組みはまだ作りたくない」
> 藤井さん（開発）: 書き込みのエンドポイントすべてに権限チェックが要る。たぶん2週間。

**出力:**

```markdown
# PRD: 税理士向けの無料の閲覧専用席

**作成者:** [名前] · **状態:** 下書き · **最終更新:** [日付]

## 課題
顧客は、1席分の料金を払わないと顧問税理士に帳簿を見せられない。

**根拠**
- 1週間で顧客3社から要望（坂本さん、CS、Slack）。

## ユーザー
- **主なユーザー:** 毎月、顧問税理士に数字を確認してもらう必要があるアカウントのオーナー。
- **副次的なユーザー:** 見るだけで、編集はしない税理士。

## 目標
- オーナーが、席の料金を払わずに外部の確認者にアクセスを渡せる。

## 目標外
- 本格的なロールと権限の仕組み（岡田さん:「権限の仕組みはまだ作りたくない」）。
- 税理士による編集。席は閲覧専用にする（岡田さん:「閲覧だけの席？」）。

## 成功指標
| 指標 | 種類 | 現状値 | 目標値 |
|---|---|---|---|
| 閲覧専用席が1席以上あるアカウント数 | 主指標 | 0 | [未定: 目標値] |
| 有料の席数 | ガードレール | [未定: 現状値] | 減らさない |

## 要件
| # | 要件 | 優先度 | メモ |
|---|---|---|---|
| R1 | オーナーが、メールアドレスで人を閲覧専用として招待できる | Must | 坂本さんが受けた要望 |
| R2 | 閲覧専用のユーザーは、作成、編集、削除が一切できない | Must | 藤井さん: 書き込みのエンドポイントすべてでチェック |
| R3 | 閲覧専用席は請求の対象に数えない | Must | 岡田さん:「無料でもいいかも」（要確認） |
| R4 | オーナーが閲覧専用のユーザーを外せる | Should | [仮定] |

## 未解決の問い
- 席は無料か、安い料金か。岡田さんは「無料でもいいかも」と言った。 — 岡田さん
- 1アカウントに閲覧専用席はいくつまでか。 — 話に出ていない

## リスク
- 有料のユーザーが、料金を抑えるためにチームメンバーを閲覧専用に切り替える。 — アカウントごとの上限を検討する

## メモに足りないこと
- 利用の目標値がない。
- 税理士がはじめてログインしたときに何が見えるかが書かれていない。
- 顧客がいま税理士にどうやって帳簿を渡しているかが書かれていない。
```

## 送る前のチェック

- [ ] 課題の節にユーザーと失っているものが書いてあり、解決策には触れていない。
- [ ] どの数字、名前、引用も入力にある。それ以外には「[仮定]」か「[未定]」がついている。
- [ ] どの要件も確かめられる形で、優先度がある。Must は作業量の60%以下に見える。
- [ ] 目標外が少なくとも2つある。
- [ ] メモの食い違いはすべて、未解決の問いに入っている。
- [ ] 主指標に現状値と目標値がある。なければ両方に未定と書いてある。

## よくある失敗

- 課題に解決策を書く（「ユーザーには閲覧専用ロールが必要」）。課題は困っていることで、作るものではない。
- 二人の意見の違いをならしてしまう。両方を引用し、未解決のままにする。
- 「ユーザー満足度」のような、測りようのない指標。数えるイベントや数字を書く。