エンジニアがすぐ動ける PRD の書き方

PRD は仕様書である前に説得の文書

PRD は Product Requirements Document、プロダクト要求文書の略です。何を作るのか、なぜ作るのかを書いて、エンジニア・デザイナー・関係者に同じ絵を見せる文書です。初めて書く人が最も多くする誤解がここにあります。PRD を機能仕様書だと思って、画面とボタンの一覧から埋め始めることです。

機能一覧だけの文書を渡されたエンジニアは、二つのうちどちらかをします。一覧をそのまま実装して変な箇所をその都度聞き返すか、自分の解釈で空白を埋めるか。どちらでも会議は増えます。よい PRD は逆に読む人を説得します。この問題は本物で、この方向が正しく、ここまでが範囲だと。納得したエンジニアは聞き返す代わりに、より良い実装を提案してくれます。

文書の半分は問題定義

誰が、どんな状況で、どのくらいの頻度で困っているのかを具体的に書きます。データがあれば数字を付け、なければユーザーインタビューや問い合わせ履歴のような根拠を添えます。問題定義があいまいな機能は、優先度会議で押され始めたら守る術がありません。

問題を書いていて根拠が薄いと感じたら、それは文書の問題ではなく企画の問題です。PRD はその薄さをリリース前にあぶり出す装置でもあります。根拠を補強するにせよ方向を変えるにせよ、一番安くできるタイミングはコードを書く前です。

やらないことを書くと会議が減る

範囲から外したことを明示する non-goals の節は、グーグルのエンジニアが書く設計文書でほぼ標準になっている慣行です。合理的に期待されそうだが今回はやらないと決めたことを、文書に打ち込んでおくのです。今回の検索改善ではタイポ補正は扱わない、という具合です。

この節がないと、同じ議論が開発の間じゅう繰り返されます。これも対応すべきでは、という質問が出るたびに一から説明することになるからです。やらないという決定と理由が文書にあれば、リンク一つで済みます。範囲がじわじわ広がるのを防ぐ最も安い装置です。

要件は検証可能な文で

要件文の基準は一つです。完成したかどうかを第三者が判定できるか。改善する、便利にするといった動詞は判定不能なので、要件ではなく願望です。

成功指標はリリース前に決める

リリース後に指標を選ぶと、必ず上がっている指標を選んでしまいます。だから成功指標は作る前に、目標数値と測定方法まで書いておきます。リリース4週間後にカート離脱率が60%から45%未満に下がれば成功、という具合です。

指標が先に決まっていれば、リリースは終わりではなく実験の始まりになります。目標に届かなかった結果も、どの前提が間違っていたかを教えてくれるデータとして残り、次の PRD の問題定義がその分厚くなります。

1枚に収まる骨組み

形式はチームごとに違っても、答えるべき質問は同じです。以下の5つの節があれば、1枚でも PRD の役目を果たします。

リリースまで書き直し続ける文書

PRD は一度書いて決裁をもらう文書ではなく、リリースまで更新し続ける作業文書です。開発中に要件が変わったら文書を先に直し、変えた日付と理由を残します。文書と実際に作っているものがずれた瞬間から、PRD は誰も開かない文書になります。

書き終えたら、いちばん忙しいエンジニア一人にまず見せて、どこで読み詰まったかを聞いてみてください。質問が出た場所が文書の穴です。その分を直してから全体に共有すれば、キックオフ会議は説明会ではなく議論の場になります。

よくある質問