(原文) How to Write a Painless Product Requirements Document
ドキュメントの大部分は初期段階で作成されますが、実装段階はUXデザインプロセスの中で最も重要な段階の一つです。
リサーチ、分析、デザインの各段階で多くのコンセプトを練ってきましたが、いよいよ重い腰を上げる時が来ました。ドキュメントが必ずしも製品と一致するわけではないことを理解しているので、ここでは必要なものだけを紹介します。
この記事では、Product Huntのプロダクト要求仕様書をベストプラクティスとして取り上げ、あなたのものにする方法を説明します。ぜひ無料のPRDテンプレートを使ってみてください。
プロダクト要求仕様書の作成方法
「試作」段階に入ると、それまでのリサーチやプロトタイピングによって、チームは製品についてのハイレベルな理解を得られるはずです。企業によって異なるため、製品開発のいくつかの段階は（順番にではなく）同時に行われることがあります。
いずれにしても、5人のチームメンバーに、製品の全体的な目的、機能、リリース基準、スケジュールなどを尋ねれば、ほぼ同じ答えが返ってくるはずです。今日のリーンおよびアジャイルの世界では、PRDは切り詰められているかもしれません（あるいは単にプロトタイプで表現されているかもしれません）ので、ここではコアな要素だけに焦点を当てます。
PRDは製品の心臓部であり、デザイナー、開発者、ステークホルダーが製品の状況と目的を理解するための生きたドキュメントとしての役割を果たします。
上述したように、要件を文書化しないと、前提条件が大きく異なることになります。PRDは、過度なデザイン思考の危険性や、プロダクトリーダーシップにおける重要な役割について議論されてきたため、デザインチームが重視するユーザビリティや美学と、エンジニアリングが重視する機能性のバランスをとるのに役立ちます。
製品キュレーション会社のProduct Huntによると、PRDは100ページもの長さは必要ありません。製品が解決する問題を定義し、機能の一般的な説明（そして前段階のモックアップもたくさん）を記載すればよいのです。技術的な詳細は、FSDのために取っておくべきです。
出典 Product Hunt プロダクト要求仕様書
著名なベンチャーキャピタリストであるBen Horowitz氏とDavid Weiden氏によると、PRDはプロダクトマネージャーが管理する最も重要なドキュメントであり、マーケティング、デザイン、エンジニアリングのためのプロダクトバイブルとなるべきものです。優れたプロダクトマネージャーは、PRDを毎日または毎週のように更新するだけでなく、PRDのプロセス全体を継続的なものとして捉えています。つまり、PRDは決して完全なものではなく、チームのイテレーションに応じて進化するものなのです。
Silicon Valley Product GroupのパートナーであるMarty Cagan氏は、PRDの4つの主要セクション（目的の定義、機能の説明、リリース基準の設定、大まかな時期のスケッチ）について説明していますが、以下ではそれを参考にしています。Caganによると、PRDの目的は「どのように」ではなく「何を」を説明することだという。各セクションでは、解決すべき問題とその解決策を明確にしておかないと、チームが誤った推測をしてしまう可能性があります。製品のソリューションを設計しているのは、エンジニア、デザイナー、UX担当者です。PRDをガイドラインではなくレシピのようにして、彼らを怒らせないようにしましょう。
I. 製品の目的を明確にする
解決しなければならないユーザーの問題（ソリューションではない）、ターゲット層（企業、顧客、ユーザー）、各層の様々なユースケースについて必ず議論してください。
これまでにも散々議論されてきたことではありますが、製品を作っている間にそれらを再確認しておかないと、開発中に迷子になってしまう可能性があります。トップ1％のプロダクトマネージャーとトップ10％のプロダクトマネージャーを分けるのは、機能のトレードオフが必然的に求められるときに、チームが目的と文脈を求めていることを理解することです。
出典: Product Hunt 製品要求文書
II. 製品の特徴を記述する
機能セクションはPRDの本体です。
機能は、エンジニアリングに最大限の柔軟性を与えるために、インタラクションデザインとユーザーエクスペリエンスに関して記述する必要があります。さらに重要なことは、機能と製品の目的を対応させることです（要件トレーサビリティと呼ばれます）。これにより、開発中に特定の機能をカットした場合のビジネスへの影響を明確に把握することができます。また、これらの機能をランク付けすることで、スケジュールが変更になった場合や、開発を進めていく中で交換すべき機能が見つかった場合に、優先順位をつけることができます。今日最も成功している企業がどのように機能の優先順位を決めているかについては、「UXデザインプロセスとドキュメントのガイド」をご覧ください。
出典: Product Hunt 製品要求文書
III. リリース基準の概要
製品をベータテスト用にリリースする準備ができたことを、どのようにして知ることができるでしょうか？このセクションはPRDの中でも最も技術的なセクションですが、私たちは目標を記述しているだけであり、目標を達成するための手段を記述しているわけではありません。以下の5つの分野で基準を示すことになります。
機能性 - オリジナルの機能のうち、維持しなければならない基本的な割合はありますか？絶対に必要な機能は何か？
使いやすさ - プログラムの見た目は美しく、ユーザーは直感的に操作できるか？ユースケースごとのタスク完了までの許容時間はどのくらいか？
信頼性 - 最大許容故障率は？これらの故障は予測可能か？システムはこれらの故障から回復できるか？
パフォーマンス - どのくらい速くなければならないか？応答時間、スループット、メモリ消費量の最大値は？
サポート性 - テスト可能か、サービス可能か、インストール可能か、設定可能か。
リリース基準については、できるだけ早い段階で議論を始め、繰り返し検討し、構築段階に近づくにつれて正式なものにしていくことが重要です。これらは、開発の初期段階で関係者が検討し、合意する必要があります。そうしないと、製品の現状に合わせて基準を設定してしまうことになります。
IV. 制約条件とスケジュールの設定
厳密なタイミングにこだわることは、市場によって変わる可能性のある機能に責任を負わせることになるので危険です。その代わりに、大まかなスケジュールを立てることで柔軟性を持たせ、ステークホルダーの期待に応えることで、機能クリープを回避することができます。さらに、ワークフロー上の制約条件（予算やリソースなど）を書き出すことで、タイミングに影響を与える要因をより正確に把握することができます。制約条件と大まかな期日が書かれていれば、終了期日から逆算して、各機能に現実的なスプリント期間を割り当てるための情報が得られます。
うまくいったものは使い、そうでないものはすてる
製品の開発は進行中のプロセスであり、スプリントにさらに事務的な作業を課すことは、おそらく最も避けたいことです。
出典: Feature Flow
しかし、混沌とした状況の中で秩序を保つためには、ある程度の文書化が必要です。徹底的に詳細である必要はありませんが、誰が何を作っているのかがある程度わかるようにしておく必要があります。
製品管理者から送られてくるユーザーの要求を翻訳する必要があります。異なる技術的なエンティティ間の依存関係を理解しなければなりません。また、変更を正当化するために、内部および外部のテストのフィードバックを収集する必要があります。これらの作業の合間に、「どうやって皆が同じページに留まるのか」、「設定された期限内にどうやって目標を実現するのか」といったステークホルダーの質問に答える必要があります。
プロダクト要求仕様書は、究極の製品テストである発売日に向けて、参考となる資料のひとつです。
10年以上の経験を持つプロダクトマネージャーが作成したLean PRDテンプレートを無料でダウンロードできます。
本記事は2014/12/15投稿、2021/4/6更新を翻訳したものです。