「うちはPRDを書いていない」——プロダクトマネジメントを兼務している経営者の方から、そう伺うことがあります。
そして多くの場合、それで問題は起きていません。書かなくてもプロダクトは進むし、開発チームも困っていない。むしろ書類を作る時間があるなら顧客に会いたい、というのは正しい判断だと思います。
問題が起きるのは、1人目のプロダクトマネージャー(PdM)を採用した直後です。
「採用したのに立ち上がらない」という相談の多くは、採用した人の能力の話ではありません。社長の頭の中にあった判断の根拠が、どこにも書かれていなかったという構造の話です。
本記事では、PRDを「開発チーム向けの仕様書」ではなく、社長が持っている判断基準を外に出すための道具として捉え直します。何を書けばよいのか、いつ書くべきなのか、そして最初の1本をどう書き始めるかまで、実務にそのまま使える形で解説します。
兼務している間、PRDがなくても回るのはなぜか
まず、なぜ書かなくても成立していたのかを整理します。ここを飛ばすと、「とりあえずPRDを書きましょう」という中身のない話になります。
社長がプロダクトを見ている状態では、判断の根拠がすべて社長の頭の中にあり、しかも常時アクセス可能です。
- なぜこの機能を先にやるのか → 直近の商談で3社から同じ要望が出たから
- なぜこの実装方針でよいのか → 半年後にこの方向に振る予定があるから
- どこまで作れば十分か → この顧客が満期を迎える前に動けばよいから
これらは書かれていませんが、判断が必要になるたびに社長が答えるので、詰まりません。ドキュメントの代わりに、社長本人がリアルタイムの参照先になっている状態です。
この状態は効率的です。書く時間もメンテナンスの手間もかからず、しかも常に最新です。事業のスピードを考えれば、初期のスタートアップがPRDを書かないのは合理的な選択だと言えます。
1人目を入れた瞬間に、何が起きるか
問題は、参照先が社長本人であることに依存している点です。人が増えると、この構造がそのままボトルネックに変わります。
パターン1：質問が止まらなくなる
採用したPdMは、判断のたびに根拠を必要とします。書かれていないので、社長に聞くしかありません。
最初のうちは「聞いてくれればいい」で回ります。しかし質問は減りません。判断の数だけ質問が発生するからです。そして社長は、自分の時間を空けるために採用したはずが、質問対応で以前より時間を取られる状態になります。
「自分でやったほうが早い」という感覚は、この段階で生まれます。
パターン2：質問が来なくなる
もう一つのパターンは、より静かに進行します。
聞きづらい空気を察したPdMは、質問を減らし、自分の解釈で判断を埋めはじめます。前職の経験や一般論に照らして、もっともらしい判断を積み上げていく。表面上は順調に見えます。
ずれが表面化するのは、動くものが出てきたときです。「思っていたものと違う」という指摘が出て、しかしなぜ違うのかを説明する材料が双方にないため、議論が個人の感覚のぶつかり合いになります。
どちらも「採用の失敗」ではない
重要なのは、どちらのパターンも、採用した人の問題ではないということです。
判断の根拠にアクセスできない状態で、正しい判断を続けられる人はいません。優秀な人ほどパターン1になり、遠慮のできる人ほどパターン2になる、という違いがあるだけです。
構造の問題なので、人を替えても再発します。
だからPRDは、採用の「前」に書く
ここから結論です。
PRDは、採用したPdMに書かせるものだと思われがちです。実際、業務としてはPdMが書きます。しかし最初の1本だけは、社長自身が採用前に書く必要があります。
理由は単純で、書く材料を持っているのが社長しかいないからです。
採用してから「PRDを整備してください」と依頼すると、新しい人は社長にヒアリングしながら書くことになります。これは可能ですが、時間がかかります。そして立ち上がりの数ヶ月は、まさにこのヒアリングに費やされます。
採用前に1本書いておけば、その数ヶ月が短縮できます。 さらに副次的な効果として、書く過程で「自分が何を任せたいのか」がはっきりします。求人票が書けない、何を任せるか決められない、という悩みは、この工程で解消することが少なくありません。
PRDに書く5項目：社長にしか書けないものはどれか
PRDの構成自体は一般的なもので構いません。ただし5項目のうち3つは、社長以外には書けません。 そこに時間を集中させてください。
① 背景・目的(Why) —— 社長にしか書けない
なぜこの機能に取り組むのか。どのビジネス課題・顧客課題を解決するために必要なのか。
ここが最も重要で、最も外部化されていない情報です。 商談で聞いた声、解約の理由、競合の動き、資金調達の計画。判断の材料は社長の中に散らばっていて、書き出されていません。
データや顧客の声とセットで言語化してください。「なんとなく必要だと思った」ものは、書けないなら優先度を下げるべき候補でもあります。
② 対象ユーザーと利用シーン —— 社長にしか書けない
誰の、どのような場面のための機能なのか。
解像度が粗いと、実装やデザインの細部で判断に迷うたび、各自が異なるユーザー像を想像して進めます。社長は具体的な顧客の顔を思い浮かべながら判断していますが、それは共有されていません。
実在する顧客名を挙げて書くのが最も速い方法です（社外に出す文書ではないので、抽象化する必要はありません）。
③ 要件(What)とスコープ外(Not in scope) —— スコープ外は社長にしか書けない
「何を作るか」は、エンジニアやデザイナーと共同で詰められます。一方**「何を作らないか」は、社長の判断です。**
やらないことを決めるのは、事業の優先順位そのものだからです。ここが書かれていないPRDは、開発の途中で対象範囲がなし崩しに広がります。
「今回は対応しない」と明言することを面倒がらないでください。PRDの中で、最も後工程の手戻りを減らす一行です。
④ 成功指標(KPI) —— 共同で書ける
リリース後、何をもって成功と判断するか。「利用率を〇%向上させる」「問い合わせを月〇件削減する」など、検証可能な数値で置きます。
事業目標から逆算すると、ぶれにくくなります。
⑤ 前提条件・リスク・スケジュール —— 共同で書ける
依存する外部連携、想定されるリスクと対応方針、大まかなマイルストーン。
前提が崩れたとき、どこまで遡って見直すべきかの判断材料になります。
🔗 PRDテンプレート(Notion)：ここまでの5項目をそのまま反映したテンプレートを用意しました。PRDテンプレート(プロダクト要求仕様書)を開き、右上のメニューから「複製(Duplicate)」すると、ご自身のNotionワークスペースにコピーしてご利用いただけます。
記入例：BtoB SaaSの新機能
イメージをつかみやすくするため、BtoB SaaSに「請求書一括ダウンロード機能」を追加するケースを示します。
背景・目的：サポート問い合わせのうち月間約120件が「請求書を1件ずつしかダウンロードできない」という内容。7月の商談でも大手2社から同じ指摘を受けており、エンタープライズ展開の障害になりつつある。対応工数の削減と、上位プランの受注確度向上が目的。
対象ユーザー：月間10件以上の請求書を発行する法人プラン利用企業の経理担当者。想定するのは〇〇社の経理部のような、月末に数十件をまとめて処理する運用。
要件(What)：管理画面から期間を指定し、対象期間の請求書をまとめてZIP形式でダウンロードできる。
スコープ外：会計ソフトとのAPI連携、請求書フォーマットのカスタマイズは対象外。API連携は次の資金調達後にエンタープライズ向けの本命施策として着手する予定があるため、今回は前倒ししない。
成功指標：リリース後3ヶ月で、請求書ダウンロード関連の問い合わせを月間30件以下に削減する。
前提条件・リスク：既存の請求書生成バッチの負荷増加が懸念されるため、事前に想定同時アクセス数で検証する。
注目していただきたいのは、スコープ外に書かれた「なぜ今やらないのか」の一文です。ここが書かれていれば、採用したPdMは「API連携もやったほうがいいのでは」という提案を、事業の時間軸を理解した上で行えます。書かれていなければ、毎回説明することになります。
最初の1本をどう書き始めるか
すべてを整備しようとすると始まりません。現実的な進め方を3つ挙げます。
1. 全機能を網羅しない。直近で着手する1つだけ書く。 過去の機能を遡って文書化する必要はありません。次に作るもの1つで十分です。1本書けば型ができ、2本目以降は速くなります。
2. A4で2〜4ページに収める。 詳細に書きすぎたPRDは更新されなくなり、結局形骸化します。読むのに5〜10分で全体像がつかめる分量が目安です。
3. AIとの対話で書く。 これは実務で有効性を確認している方法です。ゼロから書き出すのではなく、「なぜこの機能をやるのか」をAIに質問させながら答えていく形にすると、頭の中にあるものが構造化されて出てきます。
筆者自身、自社サイトの再構築で同じ進め方をしました。ミッション・ビジョン・バリューの言語化から要求定義までをAIとの対話で行い、上流の整理に最も効果があることを確認しています。AIは、頭の中にあるものの精度を上げます。持っていないものを作り出すことはできません。 材料を持っている社長だからこそ、この方法が効きます。
よくある質問(FAQ)
Q1. PRDと仕様書は何が違いますか?
仕様書は「何を作るか」という実装レベルの詳細に焦点を当てます。PRDは「なぜ作るのか」から「何を作るか」までを含む上位の文書です。PRDをもとに、エンジニアが詳細な技術仕様書を別途作成する進め方が一般的です。
Q2. 開発チームがPRDを求めていないのですが、それでも必要ですか?
現時点で必要とされていないなら、それは社長が実質的に参照先として機能しているからです。PRDが必要になるのは、社長以外が判断する場面が出てきたときです。 採用を検討している段階なら、その手前と考えてください。
Q3. 1人目のPdMに、PRDの整備そのものを任せてもよいですか?
業務としては任せて構いません。ただし最初の1本は社長が書いてください。 材料を持っているのが社長だけである以上、任せるとヒアリングから始まり、立ち上がりに数ヶ月かかります。1本の型があれば、そこから先は引き取ってもらえます。
Q4. 書いたPRDは、どう運用すればよいですか?
3点あります。ドラフト段階でエンジニア・デザイナーにレビューしてもらい実装可否を確認すること。開発中に要件が変わったら、変更内容と理由を追記すること。リリース後に成功指標を実際に計測して振り返ること。書きっぱなしにせず、リリース後にもう一度開く習慣が、形骸化を防ぐ最大のポイントです。
まとめ
PRDは、開発チームに渡す仕様書である前に、社長の頭の中にある判断基準を外に出すための道具です。
- 社長が兼務している間、PRDがなくても回るのは、社長本人が参照先になっているから
- 1人目を採用すると、この構造がそのままボトルネックになる。質問が止まらないか、質問が来なくなるかのどちらか
- どちらも採用した人の問題ではなく、構造の問題なので、人を替えても再発する
- したがって、最初の1本は採用の前に、社長自身が書く
- 5項目のうち、背景・目的、対象ユーザー、スコープ外の3つは社長にしか書けない
全部を整備する必要はありません。次に作る機能1つについて、A4で2〜4ページ。それだけで、1人目の立ち上がりは大きく変わります。
そして書き終えたとき、「何を任せたいのか」も同時に見えているはずです。求人票は、そのあとのほうが書きやすくなります。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。 「社長が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。 おおむね2営業日以内にご返信します。
