[マーケターコラム] Half Empty? Half Full?

プロダクト開発とマーケティング ~マーケターもPRDを書いてみよう

マーケターコラム、今回は村石怜菜氏。マーケターも知っておきたいPRD(プロダクト要求仕様書)について紹介します。

こんにちは、村石怜菜です。

今回のテーマは「PRDを書いてみよう」です。PRDはProduct Requirements Documentの略で、プロダクト要求仕様書のこと。プロダクト開発マネジメントでは欠かせないドキュメントです。このPRDが、マーケティングに関わっている方々の実務にも活用できそうなので、お伝えしようと思います。

PRDとは?

なぜ「PRDを書いてみよう」をテーマに選んだかというと、電子チケットサービスなどを開発するベンチャー企業へ私が転職したときに、プロダクトチームが効率的に開発を推進している姿に感銘を受けたからです(※)。

※村石怜菜の経歴の詳細については、「マーケティングで大事なことは、新卒入社したパン屋の現場で身につけた」をご参照ください。

それまでは受託開発型のビジネスモデルの企業で、「企画→設計→開発→テスト→リリース」のように段階的に開発を進める「ウォーターフォール式」のプロジェクトマネジメントを採用していました。そのため、「仕様の漏れがなく、開発の手戻りがなくプロジェクトを進行すること」が大命題でした。

しかし、ベンチャー企業ではそれとは文化が大きく異なるアジャイル方式を採用しており、手戻りを最小限にしながら効率的に開発を行っていたのです。その手法やツールは、「ぜひビジネスサイドも知って、参考にすべきだ!」と実感するものが多く、目から鱗の連続でした。そのツールの1つがPRDです。

どういった製品を作るのかを明確にする

システム開発を外部の開発会社に委託している場合、要求書や仕様書と聞くと、「RFP(提案要求書)」や「要求定義書」、「要件定義書」、「機能仕様書」といった言葉を思い浮かべる方も多いのではないでしょうか。

PRDに記す項目は後ほど紹介しますが、一般的にPRDは上記仕様書とは求められていることが全く異なります。プロダクトを開発する前に、「どういったプロダクト/サービス(以降、製品と表現します)を作るのか」を定義するドキュメントです。

開発を推進するプロダクトマネージャー(PdM)やプロダクトオーナー(PO)が書くのが一般的ですが、「PRDはPdMやPOが書かなければならぬ」というルールはありません。製品の企画者がマーケターであれば、マーケターが書く場合もあります。

PRDには、マーケターが得意とする市場分析や競合分析、ユーザー分析といった項目も記載します。PRDを書いてみると、製品開発にどうマーケティングが関わってくるのかが見えてくるはずです。マーケティングの基礎知識として最初に学ぶであろうPEST分析や3C分析、SWOT分析、4P、4Cといったフレームワークは知っているけど、実際に実務で使う機会が少ないという方も、自分がPdMになったと仮定して、試しにPRDを書いてみることをおすすめします。

スピード感を失わず、製品の市場価値を高めるために存在するPRD

私は、PRDの存在意義は、次のように、大きく2つあると考えています。

  • 開発前のプロトタイピングの一部
  • 製品の市場価値を高める

プロトタイピングの一部としてのPRD

「手戻りなくプロジェクトを進行すること」が大命題だったと前述しましたが、手戻りを最小限にする手法の1つが、開発の早い段階でプロトタイピング(試作)を作り、設計書どおりの機能が実装されているか、ユーザーニーズに合ったものかを見極めながら進めることです。「どういった製品を作るのか」を、製品イメージが浮かぶように記すPRDは、開発前のプロトタイピングとして捉えることもできます。

技術進化の速度が加速し、市場のニーズを読み、製品を提供するためには、スピード感をもった開発が必須です。プロダクトチームで働きながら、PRDも、市場ニーズをとらえて更新し、進化させていくことが肝要だと実感しました。

製品の市場価値を高めるPRD

企業にとって、「最終的に利益を発生させること=その製品の市場価値を高めること」が至上命題です。製品を開発するプロダクトサイドだけでなくビジネスサイドも理解できる「PRD」という共通言語ドキュメントがあれば、市場・競合分析も、完成イメージも共有でき、より価値を高めることに向かうことができます。

なお、開発後に「こんな製品は売れない・需要がない」「使いにくい」と言われてしまうリスクも低減できるでしょう。

PRDに記す項目とは?

私は、PRDに以下のような項目を記していました。

1.概要・ゴール

なぜこの製品/機能が必要なのか、そしてそのゴールを記す。

2.誰のために作るのか

誰が製品/機能を利用するのかを記す。

  • B to B / B to C / B to B to Cなのか?
  • ペルソナ(ユーザー属性や利用環境等) など

3.どういうものを作るのか(UI/UX、機能、用語)

どのようなUI(User Interface:ユーザーインターフェイス)やUX(User eXperience:ユーザーエクスペリエンス)か、どのような機能をもっているのかを記す。

誰が読んでも具体的に製品のイメージが浮かぶように書くと、その後の議論が進みやすい。そのため、業界用語・専門用語の説明も記しておく。

4.モックアップ

最終的な製品ができあがる前に、完成形と同様の機能などを有したモックアップについて記す。

自分で作る場合もある(ただし時間は掛けすぎない)が、すでにモックアップが存在する場合は、URLや説明を明記する。ビジネスサイドとプロダクトサイドとで、各々想像していた完成形が違っていて、最終的に「こんなものは売れない」という結果になることを避けることができる。

5.スコープ

製品開発において生み出される全ての成果物を記す。

なお、エンタープライズ向けの製品であれば、ファーストカスタマー(企業名)を書いておくと社内での共通認識が得やすいため、ここに追記しておくとよい。

6.アイディア

今回の開発には入らないかもしれないけど、将来像や次のバージョンに入れたい機能などを記す。

7.市場分析

その製品の市場の分析内容を書く。参入障壁や市場規模、他社動向など。

8.競合分析

自社・製品の競合の動向や売上・顧客層などの分析結果を記す。

9.リリーススケジュール・マイルストーン

リリースしたい日時やテストを開始する日など、開発過程で目安となる日を記す。

10.マーケティング計画

製品のマーケティング計画について記す。

たとえば、プレスリリースの配信可否、Web広告出稿可否、Webサイト更新・ランディングページ・販促物等の制作可否、CRMチームと連携して既存ユーザーとのコミュニケーションをどうするかなど。

11.リリース後の運用

リリース直後/初期対応/中期~長期対応など、フェーズごとにビジネス/プロダクトサイドの運用方針を記す。

PRDを書いて、市場・競合分析の解像度をあげよう

基本的には全製品において上記の内容をPRDとして記すようにしてきましたが、開発規模や機能によって項目は増減してもOKです。PRDに正式なフォーマットはなく、システムデザイン会社やプロダクトマネジメントのコンサル企業などが提案しているフォーマットがいくつか存在するので、ネット検索して参考にしてみてください。

私は、PdMになってから、新たに製品を開発する場合でも小規模な機能改善でも、基本はPRDを書くようにしていました。プロダクト開発視点からマーケットを考えることで、市場・競合分析の解像度もぐっと上げられたように感じます。

PRDを書くことで、経営者目線で俯瞰して製品の将来を想像する視点も養えると思います。ぜひ皆さんも自社の製品を想定してPRDを書いてみてはいかがでしょうか。

この記事が役に立ったらシェア!
これは広告です
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

アンカーテキスト
HTMLでページからページへジャンプする「リンク」に使われるテキスト(文字列 ...→用語集へ

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]