プロダクトマネージャーがプロダクト企画についてエンジニアと話すときに、あらかじめ書いておくとよいリスト（ラフな PRD テンプレのようなもの）

プロダクトマネジメント プロダクト開発プロセス

以前「プロダクト企画にエンジニアを早めに巻き込む（嫌がられずに協力を得る方法）」という記事を書きました。

ykmc09.hateblo.jp

「TL;DR : ひとことでいうと」を抜粋すると以下のような感じです。

  • 決定事項になる前に早めに巻き込もう
  • 巻き込むときは、
    • その意図や相手に期待することを伝えよう
    • 特性を理解して、ちょっとした工夫（最初の一声はチャットなどの非同期コミュニケーションを使う、etc）をしよう

この記事では、「はやめに巻き込もう」ということを中心に書きましたが、最低限こういったことを考えて書いておくと、話がよりスムーズになるよ、というものを挙げてみようと思います。

プロダクトマネージャーが用意するリスト

  • 目的の概要（なぜそれをやる？）※もっともだいじ。これが無いとかなりキツイ。
    • 誰のための企画？（基本はエンドユーザーになる。）
    • その人のどういう課題を解決したい？
    • その課題はどうやって導いた？（根拠となる情報やデータなど）
  • 企画内容の概要（なにを提供する？）
    • どういったソリューション（機能など）を検討している？（実装前の現段階ではただの仮説。細かい仕様はむしろ無いほうがいいが、UI の手書きラフスケッチくらいはあるとやりたいことがイメージしやすくなる）
      • どのへんの既存機能に手が入りそう？とかもあるとよさげ
    • 現状なぜそのソリューション（仮説）が妥当だと考えてる？（根拠となるデータや情報、市場分析や競合分析結果など）
  • 戦略との整合性（なぜそれをやる？の追加情報）
    • プロダクト戦略や、事業戦略との関連性はなにか？（ダイレクトに効いてくる？周辺領域？）
    • ソリューションが実現された場合の想定インパクトは？（どんなメトリクスにどれくらい寄与する？ざっくり。取らぬ狸の皮算用だが、投資価値があるかどうかのざっくり判断などにつかう）
  • スコープやスケジュール（いつ、どれだけ提供する？）
    • ソリューションに対するスコープの選択肢は？（特にミニマムスコープ。「これさえあれば課題を解決できる！」という削ぎ落とされたソリューションの範囲は？）
    • スケジュール特性は？（早さよりも、期日を設定してそれを守ることが重要？もしくは その逆？）

こういったものがあると、できるようになる話

こういったものがあると、以下のようなものが双方納得感を持って議論しやすくなります。

  • 技術的実現性やリスク
    • そもそも実現可能かどうか
    • 懸念やリスクについて
      • 技術的難易度が高そうなところ（高コストになりそうなところ）
      • 考慮漏れしそうな部分、既存仕様と競合しそうな部分（慎重に考慮したほうがいいところ）
  • 代替手段やスコープの案
    • もっと簡単にその課題を解決する方法
    • こういったミニマムスコープもありそう、みたいなもの
  • ざっくりとした見積もり
    • やるべきかの判断のための、ざっくり開発規模感（Not 納期の約束。この時点ではとてもじゃないけどできません）

そんなに書けない、決められない・・・！

もちろん先に述べたものがすべて完璧揃っていないと議論してはいけないわけではないです。一緒に考えられるところもあるはずです。

ただその場合でも、「まだこれは明確になっていない」「まだこれは直感レベル」というように、揃っていないこと自体を明確にしておくと、お互いの期待値が揃って良いと思います。（話を受ける側も「データ無いからダメ。話聞かない」みたいに、一蹴しちゃうのも微妙だと思います）

最後に

ちなみにタイトルで「エンジニアと」と限定してしまいましたが、デザイナーや QA など、開発にかかわるロールすべてにいえることだと思います。

「うちではこういうリストにしてるよ！」みたいなものがあったらぜひ教えて下さい。