要件定義で失敗しないためのProduct Requirements Document (PRD)の型
これは何か
- 要件定義フェーズでの考慮漏れによる開発の遅延、手戻りを防ぐためのProduct Requirements Document (以下、PRD)の型を作りたい
- 活用シーンとしては、新たにアウトカムを生み出すためのEpic / Featureの意思決定をプロダクトチームで行うような場面を想定している
- 細かい改善Issueレベルでこんな大袈裟な定義はしなくて良いと思う
- AI時代にも力を発揮するPRDを作成できるようにしていきたい、そのための型を定義したい
PRDの型: Why-What-Howで要求を整理する
PRDは
で言及したような整理に基づいて、各要求をクリア (解釈の余地や曖昧さがない状態)に定義できるようWhy-What-Howの項目で言語化していきたい。
Why (施策の目的)
- 背景や前提
- 現状の問題や解決したい課題は何か
- 目標・ゴールラインをどこに設定するか
- やること
- やらないこと
What (ビジネス要求、ユーザ要求)
- 具体的にどのような機能を作ろうとしているか
- ビジネス要求、ビジネス制約
- ex) xxのデータを追加開発依頼ナシでBizメンバーが登録できる状態を作ること
- ユーザ要求、プロダクト制約 (非機能要件)
- ex) xxの画面でxxのデータを検索できること
- ex) ページロードはP95xx秒以内を実現できること
- ビジネス要求、ビジネス制約
- 想定実行 (開発)コスト
- 粗見積もりなど、投資判断をするため
- 施策の勝利条件
- 定量目標
- 定性目標
How (システム要求)
- ワイヤー / デザイン
- システムの詳細仕様
- 正常ケース・エッジケースの仕様
- 表示
- ex) 登録されたデータ一覧が、登録日時の降順で表示される
- ex) 送信ボタンはデフォルトで非活性状態で表示される
- 動き
- バリデーション、エラー、など含めて、ユーザのアクションに対する制約条件
- ex) A, B, Cの項目をすべて入力すると送信ボタンが活性になる
- 表示
- 正常ケース・エッジケースの仕様
- 本施策の完了条件
- 設計・実装方針
- ADR、デザインドキュメント
- Epicに紐づく開発Issue群のリンク
PRD意思決定ガイドライン
プロダクト開発はステークホルダーも多いので、PRDの各項目を決めるプロセスも複雑になりやすい。依存関係もあるので、決め方を間違えると手戻りが発生し、全体のブロッカー、遅延につながってしまう。
そういった事態を避けるため、「こうやって決めるのが良いのではないか」という私なりのガイドラインを言語化してみる。
登場人物想定
- PdM:
- プロダクトマネージャー、施策責任者
- 事業責任者など別の役割の方が担う場合もあるかもしれないが、簡素化のためにいったん本稿ではPdMに統一する
- Des
- デザイナー
- UI/UX、デザインに責任を持つ
- Eng
- ソフトウェアエンジニア
- 目的達成のためにどのようにその機能を実現するか、その先のソフトウェアのメンテナンス性や拡張性も含めて責任を持つ
Why (PdMメイン)
何はともあれ、Whyの部分をまず明確にする必要がある。ちなみにこれは事業全体のビジョンや戦略、プロダクトコンセプトがある前提、ない場合はまずそこをPdMが明確にする必要がある。
上段の思想に整合する形で「どんなユーザのどんな課題を解決するための機能なのか」、「誰をどんな状態にしたいのか」をその根拠、目指すインパクトの水準とともに考えていく。セールスやマーケの活動結果やデータにもとづく根拠があると良い。
What (PdM、Des、Engなど全員参加)
以下を決めていきたい:
- 具体的にどういった機能を提供したいのか
- ビジネス制約条件
- 例えばマッチングのロジックなど、具体的な仕様を詰める上で必要となる制約条件はPdM + ステークホルダーで意思決定済みである必要がある
- ビジネス制約条件
- デザイン制約条件 (UI/UXのイメージ)
- Figmaなど、EngやDesなどステークホルダーとイメージをすり合わせられるレベルのもの
- 開発制約条件
- Engの主要メンバーと開発コストの見積もりをするのが良い
Whatを意思決定するまでのやり取りとしては、以下のような流れになると想定される。
- Eng or Desがコストを見積もるための事業上の材料が不足している
- -> Why、Whatの定義へ戻る
- ビジネス制約の不足、デザイン制約 (UI/UXのイメージ、ワイヤー)の不足、施策の目的やビジネス的な合理性・根拠が不明瞭、等
- -> Why、Whatの定義へ戻る
- Eng、Des、PdMで建設的な議論ができる材料が揃っている
- -> やりたいことは明確だが、Howの不確実性が高い
- -> 検証する内容を明確にして、技術的スパイク（調査、検証開発)を小コストで実施し、不確実性をを減らした上で意思決定へ
- チームに実績のない技術を使う必要がある等
- -> 検証する内容を明確にして、技術的スパイク（調査、検証開発)を小コストで実施し、不確実性をを減らした上で意思決定へ
- -> やりたいことも明確で、Howの不確実性も一定減らせている
- -> 正式デザインの作成をDesに依頼する
- デザイン作成期間が開発ブロッカーになるので、UI/UXイメージの敲きができたタイミングでDesにどれぐらいの工数、スケジュール感になるか、PdMがヒアリングしておけると理想的
- ワイヤーだけで開発を進めつつ、正式デザインを待つなど、ここはチームのケイパビリティなどに寄って最適な進め方も変わるだろう
- -> 正式デザインの作成をDesに依頼する
- -> やりたいことは明確だが、Howの不確実性が高い
How (Des、Engメイン)
ワイヤーをベースに正式なシステム要求 (ユーザ要求も考慮して)を細かく詰めていく。
ここまでいけば、あとは「ケースを洗い出してひたすら詰める」をやっていくと良い。チーム特性にもよると思うが、エッジケースの洗い出しや想定は実際に開発をするEngが一番得意だろう。
もちろん想定外のケースが出て、追加のデザイン依頼が発生したり、開発見積もりがブレたりはすることも多いが、大どんでん返しみたいなケースは減らせるのではないだろうか。
まとめ
本稿で提案したPRDの型および意思決定ガイドラインは、複雑になりやすいプロダクト開発の要件定義段階において考慮漏れを未然に防ぎ、開発遅延や手戻りを削減することを目的としています。
主要なポイントは以下:
-
Why-What-Howフレームワークの活用: 施策の「目的 (Why)」「要求事項 (What)」「実現方法 (How)」を明確に言語化することで、プロダクト開発における共通認識を形成し、議論の質を高める
-
段階的かつ協力的な意思決定: まず「Why」で施策の根幹を固め、次に「What」で関係者（PdM、デザイナー、エンジニア等）が協力して要求を具体化し、最後に「How」で技術的な詳細を詰めるという段階的なプロセスが重要。これにより、手戻りのリスクを低減する
-
不確実性への対処: 開発プロセスにおける不確実性を認識し、情報不足の場合は定義段階へ戻ることや、技術的課題に対しては技術的スパイクを推奨するなどの対応策を組み込んでいく
曖昧さのない、目的が明確で本質的なプロダクト開発をやっていきたいですね。
Discussion