###### tags:　`テンプレ`

# PRD
## タイトルの付け方
会議資料のタイトル『社内の省エネ対策における費用対効果』より『空調温度プラス2度で年間10万円コスト削減』どっちが伝えたいことがわかりやすいか

## 全体に関わる注意事項(必ずチェックしてから公開)
- [ ] 先の見えない状況、正解のない問題に対して様々な事実と情報から自分ならどうするかを見つけることが大切
- [ ] この世でおこったすべてのことは、感情やモチベーションではなく運と構造(その確率)によって引き起こされている。という概念で物事を見ているか。
- [ ] So What(結局なんなの), Why So(なんでそうなの)を問い続け、思考を深め広げる
- [ ] 抽象的な表現やビッグワードは具体的な数字や行動に直す
- [ ] ググって出てこないような本質の一次情報を集めているかどうか
- [ ] 話のモレズレ、重複、飛躍がないか
- [ ] PREPの語順が守れているか
- [ ] 常に仮説ファーストになっているか。その仮説に客観的な根拠はあるか。
- [ ] 思考を整理するために作ったminispecは公開しないで、自分用に保存。簡潔で伝えたいことが適切な根拠とともに伝わるくらいまで内容を削ってから公開する

## 解決すべき課題（Issue to be Solved）

### 現状(事象)
#### いいところ
いいところをまず、あげる。
そうでないと、「このシステムにしているあなたたちは私よりも劣っている」というメッセージになってしまうから。

#### 課題とその根拠
できる限り解決すべき課題が実感できるように書く。
課題は相手の批判です。
だから、かならずその課題の根拠をつける。言いがかりに見えてくる。

### 本当に得たい成果(目標)
<span style="color: #ef0606">具体的に数字を使って設定する</span>。
営業資料を新しくしてくれと言われたら、
ゴールは「営業資料を新しくすること」ではありません。(ジョブ理論、卓越論)

本当に得たい成果は
「お客さんから信頼を得て、成約率を上げること」

また、あいまいさを避けるため、信頼される資料と成約率を定義しする。
信頼される資料
- 情報が最新
- デザインがかっこいい
- パット見て、伝えたいことが伝わる

そして、
- 成約率 = 成約数/資料を見た人数

のような感じ。

### 現状と目標の差(課題)

### なぜその問題が起こったのか(要因)
なぜ？には必ず根拠がつきもの。
仮説ファーストで書き出してから、ファクトベースで検証する。
その根拠があったらつけておく。

### どうしたらその問題が無くなるのか(仮説)
現在顕在化している課題とその解決のニーズを記載します。

ニーズというのは、つまりジョブ理論的なウォントのこと。
どのペルソナにとって、なんでこの機能が必要なのか。

提案であれば、提案する相手にしてほしいリアクションを考えながら作りましょう。

## ユーザーストーリー（User Stories）
どうやってやるのか。
ユーザー視点でどうあるべきかのストーリーを、ユーザーが機能に気がつくところから箇条書きで順序を追って記載します。

ここで大事なのは、アクターに漏れがないかです。エンドユーザーだけでなく、コンテンツを運用する人や、分析する人、外部のパートナー等あらゆるアクターのユースケースを書きます。そうしないと、管理ツールってどうするの？みたいなあるあるが後で起きて露頭に迷うので最初から決めます。管理ツールがないなら、エンジニアが redis にデータを投入する等書きます。

そして、ここはストーリーなので特にエンドユーザー向けのユースケースは、ワクワクするような、ユーザー感情も一緒に記載するようにします。

## 検証方法(Minimum Viable Product)
### MVP

### ベンチマーク
- 市場のフィードバック
- 定量的な測定
- ユーザーインタビューを用いた検証

とかそもそもの手段から具体的な方法までしっかりと記述する。

## KPI（Purpose）ベンチマーク
現状の KPI と目標の KPI、もしくは定性的な目標を記載します。 追うKPIを定義することで、どの数字を計測可能な状態にしておくかを明確にするのが目的です。 また、ネガティブなインパクトが考えられる数字もKPIとして定義し、可能であれば許容する範囲を事前に定めます。

## 影響範囲（Repository/Platform）
改修範囲がWeb か、アプリか、両方か、管理画面か等を記載します。アプリの場合は必要であればバージョンの指定もします。

詳細にわかればリポジトリ単位で変更点を列挙していきます。もし初期段階でわからない部分があれば複数の可能性について書いても良いです。（ここをこう変えてもいいかもしれないし、他の部分を変えてもいいかもしれない、のように書く）

### 設計

## 非機能要件
機能以外の要件を書きましょう。 画面やAPIのレスポンススピード、バッチの処理時間、データ量などシステム的に気にしておくべきことを箇条書きで列挙します。

## リリース希望日（Target Due）
希望なのか、デッドラインなのか、理由も含めて記載します。 最終的なスケジュールは全体のプライオリティの中で決めるので、デッドラインがない場合はだいたいで大丈夫です。

## 体制 / 規模感（Team）
ざっくり何人でどれくらいの期間かを記載します。

## リスク（Risks）
プロジェクトを進行する上で認識しているリスクがあれば記載、かつリスクへの対処法も併記します。実装で詰まる可能性が見えている箇所などがあれば挙げておいてください。また、施策の結果起こりうるリスクも記載してください。 いちばん大事なのは許容するリスクを書いておくことです。このリスクは承知で挑むのだ、ということを伝えて腹落ち感が出るように。

## ステークホルダ（Stakeholders）
この要件に対してレビューが必要な人を by name で記載します。 誰にどのタイミングでどんな観点で見てもらうのかを意識して書きましょう。

## TODO
仕様書を書くために必要なやることを書きましょう

## 参照（Reference）
参考資料があれば記載します。 過去の仕様書だったり、既存仕様、ベンチマークにしている他社サービスなど index として並べます。