スタートアップのための製品要求仕様書(MRD & PRD)の書き方

プロダクトマネジメントの名著 Inspired: 顧客の心を捉える製品の創り方[1] によれば、プロダクトマネージャの役割は2つある。

1. 製品の市場性を評価すること
2. 開発すべき製品の定義

このふたつをまとめると、プロダクトマネージャの目的は「 市場性の高い製品（≒売れる製品）を定義すること」ということになる。

前半の市場性評価は、市場要求仕様書（MRD, Market Requirements Document）というドキュメントにまとめられ、MRDは主にソリューションではなく課題にフォーカスしたものだ。製品がどんな問題を解決するか（バリュープロポジションはなにか）、誰のためにこの問題を解決するか、その市場が大きいかといったことを書く。

後半の開発すべき製品の定義に関しては、製品要求仕様書（PRD, Product Requirements Document）がその役割を担う。PRDはMRDで明らかになった課題に対してのソリューションを形作るもので、製品の特徴や機能について書かれている。

基本的にはMRDとPRDは分けて書かれることが望ましい。それは、課題とソリューションを切り離して考えることに意味があるからだ。通常、起業や新しいプロダクトのアイディアを思いつくときは、斬新なソリューションが先に思いついて、その後に課題を後付するようなことになることが多い。しかし、実際はその課題に対するソリューションは他にも無数に存在しているのだ。その可能性をすべて考慮せずに出た最初のアイディアが最も優れているとは普通は言い難い。

ただし、その点にさえ注意すれば、いちいち大掛かりな市場調査などをやっていられないスタートアップにとってはMRDはコンパクトにまとめ、PRDに内包してしまったほうが効率は良い。そこで、本記事ではscoutyでも製品リニューアルの際に使われたMRD内包版PRD（以降PRDと呼ぶ）の書き方およびフォーマットを公開しようと思う。

なお、「スタートアップのための」とタイトルにあるが、もちろん今回扱うPRDはスタートアップ以外でも利用することはできる。

なぜPRDが必要か

PRDが必要な理由の前に、プロトタイプが必要な理由を考えてみよう。
もしプロトタイプを使わずにいきなり本製品を作った場合、製品をいきなり市場に投入することになる。製品ができるのは、開発リソースをすべて投入したあとだ。この時点で製品の仮説が間違っていることがわかったり、顧客の必要としていたものと違っていたことがわかったら、すべて作り直しをしないといけない。このコストは甚大だ。プロトタイプはそれに比べ巻き戻しコストが低いので、作り直しを繰り返して徐々に顧客の本当のニーズに近づけていくことができる。

私は、PRDが必要な理由もこれと同じだと考える。一般に、製品の方向性が決まっていない状態であるほど巻き戻しコストの低い表現方法を使わないといけない。プロトタイプとはいえ、製品が複雑だと作るのはそれなりに大変だ。大きな方向性が定まる前には探索範囲を増やして、いろいろな可能性を顧客と模索すべきだ。「うちはもう製品の方向性がだいたい決まっているからPRDは書いていない」という会社もあるだろうが、その場合、その方向性が正しいことはすでに検証済みだろうか？検証するとしたら、プロトタイプでやるよりは文書ベースでやる方が効率的だろう。もちろん、顧客は製品が目に見える形になってはじめてイメージがつくものなので、プロトタイプでの検証はそれでも必要だろう。

また、ソリューションの検証はできても、課題の検証はプロトタイプだけだとやりにくい。製品を作ったあとに、「解決しようとしていた課題が、プロダクトマネージャー本人には重要だと感じられていたが、顧客にとっては実際はそこまで重要じゃなかった」といったことが発覚するとたちまち無意味になる。市場の中で重要な課題をつかむためにも、PRD（特にMRDの部分の要素）を作って顧客にヒアリングしていかなければならない。

特にスタートアップでは、CEOかCTOが深夜のノリで書いたコードがそのまま製品版になることが多く、まともな市場調査ができているようなところは多くは無いだろう。そういう組織こそ、きちんとPRDを書いて検証することで、半年後に「売れなくなってきたが、大してエンジニアもいないのでピボットもできないまま資金ショートする」といった悲惨な事態を避けることができる。

PRDのフォーマット

ここで紹介するのは、下記の文献を参考にして作ったPRDに含まれるべき各項目である。冒頭で述べた通り、MRDの要素も含んだものとしている。これはプロダクトをゼロから作るときの仕様書で、その一機能を作るときのFunctional Spec (機能仕様書) のフォーマットとは異なる。この他にも様々な項目を加えている文献もあるが、これは早く製品をリリースしなければいけないスタートアップにとって最低限重要な部分を抜き出したものである。

1. 製品がどんな問題を解決するか

これはすなわちバリュープロポジションのカスタマープロファイルをまとめたものである。顧客の持つPainとGainのうち、特にクリティカルなものはなにかを考える。この時点ではソリューションには全く着目せず、顧客の課題に集中しなければならない。例えば、「優秀なエンジニアが採用できない」「優秀な転職潜在層と継続コンタクトができず採用につながらない」など。

2. 誰のために問題を解決するか

解決しようとしている問題を持っている人、ターゲットユーザーは誰か。これは想定するペルソナのことであり、B2Bの場合は運用者まで想定すると良い。たとえばエンジニア採用ツールであるscoutyの場合、企業の人事が運用するのか、エンジニアが運用するのかまでもある程度は想定して置かなければならない。
ペルソナを明確化することは、「あらゆる人を満足させる製品を作る」というプロダクト開発における典型的な間違いを防止してくれる上、自分たちを顧客と混同することも防いでくれる。

3. プロダクト要件

課題を解決するためには、どのようなことが必要かを記述する。ここでも、まだソリューションそのものには触れない。たとえば、「優秀なエンジニアの母集団形成が可能で、サービス上での連絡が可能であること」や「採用しようとしている候補者のステータス管理ができること」「人事が1人で運用できること」など。

また、私はこの項目にはビジネス上の要件を書くことをオススメする。たとえば、「カスタマーサポートがなくても運用が可能であるためスケーラビリティが高い」「採用ニーズがなくなってからもツールとして機能し、継続率が高い」など。こういったものからソリューションの形が見えてくる。

4. エレベーターピッチ（プロダクト概要）

以上を踏まえて、

＜解決したい課題＞ したい
＜ターゲットユーザー＞ 向けの
◯◯というプロダクトは、＜プロダクトのカテゴリ＞ です。
これは、＜アピールポイント＞ することができ、
＜従来の方法＞ とは違って、＜差別化要因となる決定的な特徴＞ が備わっています。

という形にまとめる。

5. プロダクトの機能および特長

このプロダクトが他の製品と違う理由、差別化要因となる決定的な機能や特長をシンプルに記述する。機能の記述のやり方として、コアユーザーストーリー（ユーザーが実行できる重要な機能）を書いていくというやり方もある。例えば、「使用プログラミング言語で候補者をフィルタリングできる」「候補者の経歴やブログが閲覧できる」など。英語だと、”As a user I can ◯◯ …” という形で始まる。

6. 想定する運用方法

ユーザーがこのプロダクトを実際にどのように使うのかを記述する。このように運用をすればプロダクトの要件が達成できる、という理想の運用方法でよい。たとえば、「デイリールーチンとして企業の人事がレコメンドを見て候補者の選定を行い、通知が来たタイミングでスカウトを送信する。」といったものだ。理想の運用方法がわかっていればUIも製品サポートもその方向性に寄せていくことができる。B2Cであれば、それがどういうシーンで利用されるのかを明文化する。

7. 想定する料金

想定している料金体系や金額を記述する。

PRDを検証する

PRDは書くだけでは意味が無い。実際のプロトタイプ開発に先立って、市場のニーズと合致していることを検証しなければ書く意味は無いだろう。具体的には、PRDを書く前、あるいは書き終わったタイミングで、顧客にヒアリングに行くと良い。特に、1と2の課題の調査に関しては、復数の顧客から証言を得ると良い。これは当たり前のことのようであるが、実際にできているスタートアップは多くはないだろう。

スタートアップの製品が失敗する理由として、

• 解決しようとしていた課題が深刻ではなかった。課題を持っているユーザーがごく一部だった。
• 課題は存在していたが、自社のソリューションがそれを解決できなかった。
• 顧客の課題を解決する製品仕様はできたが、それを開発できなかった。
• 製品は顧客の課題を解決するが、プロダクトマーケティングに失敗した。（価格が不適当、認知が取れなかった 等）

といったものが挙げられるが、特に多いであろう1つ目と2つ目の要因による失敗の可能性は、このPRDの段階で最小化することができる。これをプロダクトマーケットフィットの前段階として、プロブレムソリューションフィット（Problem Solution Fit）と呼ばれることがある。顧客へのヒアリングによってPRDを更新していき、大きな変更が見られなくなった時点でプロトタイピングに入れば、大きなミスはなくなるだろう。

1つ目と2つ目に責任を持っているのはプロダクトマネージャー（ちなみに3つ目はプロダクトオーナー、4つ目はプロダクトマーケティングマネージャーの責任）なので、あなたがプロダクトマネージャーであれば、面倒臭がらずにPRDを書くことをオススメする。

参考文献

[1] Inspired: 顧客の心を捉える製品の創り方, Marty Cagan, マーレアッズーロ出版, 2015

[2] How to write a good PRD, Marty Cagan, Silicon Valley Product Group, 2005

[3] How to Write Painless Product Requirements Document, Jerry Cao

[4] The Agile Inception Deck, The Agile Warrior, Jonathan Rasmusson
https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/