プロダクトマネージャーの機能提案ドキュメント｜戦略（Why）と要件（What）の書き方

機能を提案するドキュメントが通らない原因は、文章力ではなく書く項目の抜けにあります。なぜ今この機能なのか（Why）と、何を作るのか（What）が同じ文書の中で結びついていないと、レビューは「で、結局いくらかかるのか」で止まります。この記事では、IPA「共通フレーム2013」が示す要件の4区分、要件を1文に落とすEARS記法、要求の強さを表すRFC 2119の助動詞、そしてAmazonが公開している6ページのメモの運用を手がかりに、提案ドキュメントに何をどう書くかを具体化します。

まとめ

機能提案ドキュメントは、戦略（Why）と要件（What）を1本につなぐ文書です。Whyには課題・対象・成功指標を数値で書き、Whatは業務要件から機能要件・非機能要件へ降ろします。IPAの原理原則は「数値化されない要件は人によって基準が異なる」「表現されない要件はシステムとして実現されない」と明言しており、抽象語のまま残した項目は実装されないと考えて構いません。

要件の1文はEARS記法の型に当てはめると曖昧さが消え、優先度はRFC 2119のMUST／SHOULD／MAYで表せます。スコープの膨張は「やらないこと」を明記して止めます。レビューはAmazonの読み合わせ方式（会議の冒頭で全員が黙読する）が有効で、質の高い文書は数時間では書けず1週間以上かかることもある、と同社自身が書いています。文書の型そのもの（見出し構成やテンプレート）はデザインドック（Design Doc）とは？書き方・項目テンプレート・AI活用まで解説で扱っています。

機能提案ドキュメントの守備範囲

提案ドキュメントは、実装方式を決める設計文書ではありません。「この機能に投資すべきか」という意思決定を1回で通すための文書です。だからWhyが主役で、Whatは投資判断に必要な粒度まで書けば足ります。データベースのスキーマやAPIの引数まで書き始めた時点で、それは提案ではなく設計文書に変わっています。

デザインドック・PRD・要件定義書との使い分け

実務では4つの文書が並走します。提案ドキュメントは投資判断、デザインドックは実装方式の合意、要件定義書は契約と受け入れの基準、PRDはその中間で製品仕様を固定する役割です。役割が重なると同じ内容を2箇所で保守することになり、片方が必ず古くなります。1つの決定は1つの文書だけに書いてください。

このうち要件定義書だけは性格が違います。IPA「超上流から攻めるIT化の原理原則17ヶ条」の原理原則[10]が「要件定義書はバイブルであり，事あらばここへ立ち返るもの」と位置づけているとおり、開発中に議論が割れたときの参照先になるからです。発注者とベンダーの間で線を引くときは、要求定義と要件定義の違いとは？責任範囲・成果物・契約の分界点を解説が分界点の整理に使えます。

「要件定義は発注者の責任である」という前提

17ヶ条は原理原則[9]で「要件定義は発注者の責任である」と定めています。ベンダーに要件定義を委託していても、何を作るかを決める責任は発注側から移りません。プロダクトマネージャーが提案ドキュメントを書くのは、この責任を果たす作業そのものです。

提案ドキュメントも要件定義書と同じ扱いにしてください。開発中に判断が揺れたら、チャットの過去ログではなく文書に戻る運用にすると、決定の履歴が1箇所に残ります。

プロダクトマネージャーが戦略（Why）に書く3項目

Whyの章に必要なのは、課題・対象ユーザー・成功指標の3つだけです。市場環境の説明や競合の一覧は、判断が変わらないなら付録に回してください。読み手が知りたいのは「この機能を作らなかったら何が起きるか」です。

成功指標の数値化

17ヶ条の原理原則[13]は「数値化されない要件は人によって基準が異なる」と述べています。「使いやすくする」「離脱を減らす」は指標ではありません。「申込フォームの離脱率を現在の62%から45%まで下げる」「問い合わせ対応の平均処理時間を8分から5分に短縮する」のように、現在値と目標値を対で書きます。現在値が測れていないなら、それを測ることが最初の提案になります。

目標値には期限も添えます。期限のない目標は達成判定ができず、機能をリリースしたことが成果として扱われてしまいます。あわせて、リリース後に測る成功指標と、リリースしてよいかを判定する完了条件は別々に書いてください。前者は数か月後にしか分かりませんが、後者は開発チームが今週判断する基準です。

ここで書き落とした項目は戻ってきません。原理原則[12]が「表現されない要件はシステムとして実現されない」と言い切っているとおり、口頭で合意しただけの指標は実装にも受け入れテストにも現れません。

方針の周知を前提にした書き方

原理原則[8]は「システム化の方針・狙いの周知徹底が成功の鍵となる」としています。提案ドキュメントは意思決定者だけでなく、実装者・運用者・サポート担当が読む前提で書いてください。専門用語を使うなら、その文書内で定義します。共通フレーム2013も「特に組織特有の意味をもつ用語は残らず定義するとよい」と記しています。

要件（What）を漏らさない4区分

IPA「共通フレーム2013 第3部 共通フレームとガイダンス」の2.2.3.1は、要件として定義する内容を4つに分けています。(1)業務要件の定義、(2)組織及び環境要件の具体化、(3)機能要件の定義、(4)非機能要件の定義です。この順序には意味があり、業務要件で決めた「新しい業務のあり方」を実現するために必要なシステム機能が機能要件、という導出関係になっています。

提案ドキュメントで抜けやすいのは(2)です。新機能に合わせて運用体制や担当者の役割が変わるなら、それも提案の一部です。人員配置の変更が必要な提案を「機能追加」として出すと、承認後に運用部門で止まります。

業務要件から機能要件を導く順序

共通フレーム2013は業務要件に記述する内容として、業務内容（手順、入出力情報、組織、責任、権限など）、業務特性（ルール、制約など）、業務用語、外部環境と業務の関係と授受する情報を挙げています。機能の一覧から書き始めると、この4つが埋まらないまま画面の話になります。

画面については、同文書に「画面の設計では，画面の原案を利用部門が作成して，それを開発者が実装可能なレベルに変換することが望ましい」という記述があります。プロダクトマネージャーがラフを描いて渡すやり方は、この記述に沿った分担です。業務側の詳細な整理手順は業務要件定義とは？8つの記載項目と業務要件定義書の作り方・機能要件との階層を解説にまとめています。

非機能要件の6分類とセキュリティの置き場所

共通フレーム2013が非機能要件の例として挙げているのは次の6つです。提案段階では全項目を埋める必要はありませんが、「今回は定義しない」と書くことで、後から要求が湧いてくるのを防げます。

ここで注意が要ります。品質要件として援用されているのはJIS X 0129-1（ISO/IEC 9126-1）の6特性で、セキュリティは独立した特性として並んでいません。同じ2.2.3.1の項番4は「運用プロセス（3.1 参照）で設定された，応答時間，回復時間，セキュリティなどの業務運用評価基準がある場合には，運用，操作要件としてこれらを定義した上で，他の非機能要件への反映も検討する」と書いています。運用側にサービス水準の基準がすでにあるなら、セキュリティ要件は品質要件の欄を探すのではなく、まず運用・操作要件として書き出し、そのうえで他の非機能要件への影響を見てください。

EARS記法による1要件1文への落とし込み

要件の文が曖昧になるのは、条件と動作が1文に混ざるからです。EARS（Easy Approach to Requirements Syntax）は、ロールス・ロイスのAlistair Mavinらがジェットエンジン制御システムの耐空性規定を分析する中で考案し、2009年に公開した記法です。要件を5つの基本パターンと、それらを組み合わせた複合形に振り分け、それぞれ決まった語順で書きます。

日本語でもそのまま使えます。「請求書が未確定の状態で、承認ボタンが押されたとき、システムは確定処理を実行せず警告を表示する」は複合形です。型に当てはまらない要件が出てきたら、それは要件ではなく背景説明か、複数の要件が1文に詰まっています。型ごとの実例はEARS記法とは？6つの型と書き方・実例をKiro連携まで解説で確認できます。

MUST・SHOULD・MAYによる強度の書き分け

優先度を「高・中・低」で付けると、実装時に「中って作るんですか」という質問が必ず来ます。RFC 2119（BCP 14、1997年3月）は要求の強さを表す語を定義しており、MUSTは「絶対的な要求」、SHOULDは「無視してよい正当な理由が特定の状況では存在しうるが、異なる選択をする前にその影響を完全に理解し慎重に検討しなければならない」、MAYは「本当に任意」を意味します。

この3語で書くと、SHOULDを落とすときに理由の説明が要る、という運用が自然に生まれます。ただしRFC 2119自身が、これらの語は「注意深く、控えめに」使うべきで、相互運用や有害な挙動の制限に本当に必要な箇所にのみ使うよう求めています。全要件がMUSTになっている提案書は、優先度を付けていないのと同じです。

禁止側の語も定義されています。MUST NOTは「仕様の絶対的な禁止」、SHOULD NOTは「その挙動が許容される、あるいは有用でさえある正当な理由が特定の状況では存在しうるが、実装前に影響を完全に理解し慎重に検討すべきもの」です。次の「やらないこと」欄は、この禁止側をそのまま文書化する場所と考えてください。

スコープ膨張を止める「やらないこと」欄

17ヶ条の原理原則[16]は「機能要求は膨張する。コスト，納期が抑制する」と言い切っています。膨張は例外ではなく既定の挙動です。だから提案ドキュメントには、やることと同じ分量で「今回やらないこと」を書きます。

書き方は「対象外の項目」と「対象外にした理由」を対にします。理由が「優先度が低いため」だけだと、次の会議で復活します。「対象外：多言語対応（現在の海外からのアクセスは月間セッションの1%未満のため、この機能の投資判断には影響しない）」のように、判断の根拠になった数字を残してください。

もう1つ、原理原則[3]は「プロジェクトの成否を左右する要件確定の先送りは厳禁である」としています。「詳細は開発中に詰める」と書いた項目は、先送りの別名です。決められないなら、決めるための調査を1つの提案として切り出すほうが早く進みます。

レビューを通す運び方

Amazonは2017年の株主への手紙で、社内の文書運用を明かしています。「We don’t do PowerPoint (or any other slide-oriented) presentations at Amazon. Instead, we write narratively structured six-page memos. We silently read one at the beginning of each meeting in a kind of “study hall.”」——スライドを使わず、物語形式の6ページのメモを書き、会議の冒頭で全員が自習室のように黙読する、という運用です。

同じ手紙は、質の低いメモが生まれる原因を、高い基準を認識できないからではなく、かかる手間の見積もり違いに求めています。「高い基準の6ページのメモが1〜2日、あるいは数時間で書けると誤解しているが、実際には1週間以上かかることもある」。そして良いメモは「書かれ、書き直され、同僚に共有して改善を求め、二日ほど寝かせてから新しい頭で再び編集される」ものだ、としています。

この運用から実務に持ち込める点は2つです。1つは、提案ドキュメントのレビューを「事前に読んできてください」ではなく「会議の最初の10分で全員が読む」に変えること。読んでこない人がいる前提のほうが会議は成立します。もう1つは、執筆に週単位の時間を確保すること。前日の夜に書いた提案が通らないのは、内容が悪いからというより寝かせる時間がなかったからだ、と考えるほうが実態に合います。

文書の先頭には、承認者の氏名と現在のステータス（作成中・レビュー中・承認済み）を書いておいてください。誰が最終判断を下すのかが書かれていない提案は、会議で意見だけが集まって決まりません。

提案が承認された後は、原理原則[17]「要件定義は説明責任を伴う」が効いてきます。要件を変更したときは、変更点と理由をドキュメントに追記して、読み合わせた全員に届く経路で共有してください。文書を書く文化そのものが根づかない場合の対処はドキュメント化とは？エンジニアが書かない理由と開発現場で回る仕組みで扱っています。

提案ドキュメントを書くべきでない場面

すべての機能に提案ドキュメントが要るわけではありません。書かないほうが速い場面が3つあります。

1つ目は、意思決定者が1人で、影響範囲が既存画面の文言修正やソート順の変更にとどまる場合です。15分の口頭確認で決まる内容に6ページを書くのは、承認プロセスの儀式化でしかありません。

2つ目は、仮説が検証されていない段階です。ユーザーがその機能を使うかどうか自体が不明なら、提案ドキュメントで議論しても答えは出ません。最小構成を出して実データを取るほうが速く、その考え方はMVP（Minimum Viable Product）の定義と開発目的の基本を理解するにまとめています。

3つ目は、要件が固まっていないのに体裁だけ整えるケースです。空欄を「検討中」で埋めた文書は、原理原則[3]が禁じる先送りを、通ったように見せるだけの装置になります。この場合は提案を出さず、決められない理由を1ページで共有するほうが誠実です。

よくある質問

機能提案ドキュメントとデザインドックは何が違いますか？

提案ドキュメントは「作るべきか」を決める文書、デザインドックは「どう作るか」を合意する文書です。提案が承認された後にデザインドックへ進みます。項目テンプレートや書き方はデザインドック（Design Doc）とは？書き方・項目テンプレート・AI活用まで解説を参照してください。

提案ドキュメントは何ページ書けばよいですか？

Amazonが株主への手紙で公開している運用は6ページです。ページ数そのものより、意思決定者が読み切れる分量に収まっているかが基準になります。Whyと成功指標が1ページ目で分かる構成であれば、後半が長くても読まれます。

要件定義は発注者とベンダーのどちらが書くのですか？

IPAの17ヶ条は原理原則[9]で「要件定義は発注者の責任である」と定めています。作成作業をベンダーに支援してもらうことはあっても、内容に対する責任は発注側に残ります。責任範囲と契約上の分界点は要求定義と要件定義の違いとは？責任範囲・成果物・契約の分界点を解説で整理しています。

非機能要件はどこまで書けばよいですか？

提案段階では、投資判断に影響する項目だけで足ります。応答時間や障害復旧時間のように、満たすためにインフラ費用が変わる項目は必須です。共通フレーム2013が例示する6分類のうち今回定義しないものは「対象外」と明記し、後工程で埋める前提を書き残してください。

アジャイル開発でも提案ドキュメントは必要ですか？

必要です。共通フレーム2013は、開発形態や開発モデルによっては要件定義プロセスがプロジェクト開始前の作業として位置づけられ、契約の内容に応じて取捨選択されることがある、としています。つまり文書の作り方は開発形態で変わりますが、原理原則[3]の「要件確定の先送りは厳禁」は残ります。反復開発では要件を一度に固めない代わりに、Whyとやらないことをスプリントごとに見直す運用になります。進め方の違いはアジャイル開発の要件定義とは？進め方の5ステップとウォーターフォールとの違いで解説しています。

関連記事

• デザインドック（Design Doc）とは？書き方・項目テンプレート・AI活用まで解説
• 業務要件定義とは？8つの記載項目と業務要件定義書の作り方・機能要件との階層を解説
• 要求定義と要件定義の違いとは？責任範囲・成果物・契約の分界点を解説
• EARS記法とは？6つの型と書き方・実例をKiro連携まで解説
• アジャイル開発の要件定義とは？進め方の5ステップとウォーターフォールとの違い