今回は普段書いているドキュメントについて、エッセンスをギュギュッと絞ってご紹介します。 読者のターゲットは、プロダクトマネジメントを最近はじめた方、プロダクトマネジメントに興味のある方を想定してます。
はじめまして、ATOM事業本部 プロダクトマーケテイングマネージャ（以下、PMM）のShikataです。
普段の業務では、チームの市場理解を助けるための情報を用意したり、プロダクトの市場投入戦略とローンチ計画などを行なっています。プロダクトマネージャ（以下、PM）の帽子を被ることもあり「エンジニア 1名、カスタマーサクセス 1名、私」の小さなチームで動くこともあります。 プロダクトの成長に向けて、短期・中長期の両方のアプローチを行なってます。
軽く自己紹介
どんな人か
大学卒業まで関西で過ごしていた関西人です。 お酒と音楽が大好きで、キャンプ、野外フェスによく行きます。
バックグラウンド
2016年新卒でソウルドアウト（のちにサーチライフへ出向）に入社してから、4年ほどデジタル広告の仕事をしていました。 営業、運用、BPRを経験しましたが運用者のキャリアが1番長いです。 （入社した時はデジタル広告ではなくWEB広告という言葉が主流でした。時代の流れを感じます。）
その後、ATOMのPMとしてJoinしました。 当時はPM、PMMのように分かれておらず、PMとして参画しました。
ドキュメントについて
PMの役割は大きく２つ、プロダクトの成長とステークホルダーとの調整です。ドキュメントはこの２つを推進するためのツールです。 過去様々な形式のドキュメントを試して、現在は市場要求定義書（Market requirements document 以下、MRD）と製品要件定義書（Product requirements document 以下、PRD）を書いてます。
仕様書や受け入れ条件との違いとは？
「仕様書とどこが違うの？」と思われた方もいるのではないでしょうか？ まずはその辺り解像度を上げて話していこうと思います。
MRD、PRDにベクトルを持たせてみました。 仕様書や受け入れ条件よりも前に位置するドキュメントです。
仕様書や受け入れ条件を見ている時は、「どうやってこれを開発するか？」といった「How」に意識が向いている状態と言えます。 ユーザーは何ができるのか？何ができないのか？このプルダウンに何を表示するのか？のような具体的なことは書かれていても、 どのようなユーザーが、どのような場面で、なぜその機能を使いたいのか？は書かれていないことが多いのではないでしょうか。
MRD、PRDとは？
一方、MRD、PRDは？というと、
MRD、PRDはユーザーヒアリング、市場調査、競合調査、追加機能の場合はプロダクト分析などの後に位置するドキュメントです。
MRD、PRDは「誰が何に困っていて、なぜ解決すべきなのか？」といった「Who・What・Why」、それに対するソリューションについて書かれています。 私たちのチームでは、開発前に課題やソリューションを整理・検証するために使っています。
MRDとPRDの違いとは？
MRD（Market requirements document）の役割
MRDの役割は以下のようなものです。
- 顧客を深く理解する
- 解決すべき課題が何か決める
- 顧客が達成した状態（アウトカム）を定義する
- 代行手段
- 対話
PRD（Product requirements document）の役割
PRDの役割は以下のようなものです。
- 製品の特徴や機能を深く理解する
- 開発前にソリューションを検証する
- 代行手段
- モックアップ
エッセンス
冒頭述べた通り、PM向けのエッセンスをギュギュッとまとめてお伝えします。
①MRDでは顧客の課題に熱中する
- 顧客が普段どのように仕事をしていて、何にどのくらい困っているかを学習する
- 課題を抱えている顧客の数をある程度把握する
- 最後は冷徹にジャッジする
②課題とソリューションを分けて考える
- 課題に対するソリューションは無数に存在する
- 最初に思いついたソリューション、無数の未検討のソリューション、後者の中に優れたソリューションが眠っていることも考慮する
- ソリューション先行（アイデア先行）になっていないか立ち止まる
③ドキュメントの形式にこだわる必要はない
- 会社、チーム、プロダクトの状況によって、ドキュメントの役割は異なるため、万能な形式は存在しない
- 注意さえすれば、ドキュメントは混ぜても良いと割り切る
- 私の場合は、MRDとPRDを混ぜて１つのドキュメントにしている場合もあります
番外編 PRDでは開発の前にソリューションを検証する
- 残念ながら、どれだけ品質の高いプロダクトであっても、顧客の課題を解決できなければ意味がない
- 顧客の課題を解決できても、それが持続可能でない場合、使われないプロダクトになってしまう
- これらのリスクを最小限にできる
番外編 仕様書について
- @Fritz.M.Kさんの記事がとても勉強になります！
- 要チェックです！
まとめ
今回は私が普段書いているドキュメントについて簡単に紹介しました！ 実は、今回ゲスト枠としてテックブログを書く機会をいただきまして、まずはライトな記事から書かせていただきました。 また機会がいただけたなら、もっと具体的な話、マーケティング寄りの話などもできたらなと思います。
最後まで読んでいただき、ありがとうございました！
