新規プロダクト開発でプロダクトマネージャーが作るべき３つの成果物
エンジニア出身プロダクトマネージャー（以下、PM）のjunpeiです。
新規プロダクト開発を進める上で、PMは何を決めるのかを網羅できているか心配になることありませんか？もしくはドキュメントを書いたけど、結局何が進んだのかがわからなくなることはありませんか？
今回は、新規プロダクト開発に最低限必要な状態から逆算して、PMが作るべき成果物（ドキュメント）に着目していきます。
注）PMが作ると書いていますが、一人で作成する必要はないです。
まずPMの仕事とは？
新規プロダクト開発時におけるPMの仕事は、Why、What（いわゆる要件定義）だと思っています。ウォーターフォール、アジァイルどちらであっても、基本要件を決めずには開発は進められません。
私はエンジニア出身なので、自分が詳細の設計や開発を進める上で最低限ここまで決まってたら、後は勝手にやっとくよといえる状態を考えました。
注）この記事での想定は自社SaaS事業です。
受託開発のようなキッチリとした要件定義は想定していません。
その場合は非機能要件やらなんやら、問題を起こさないためにも顧客と詳細に詰めておく必要があると思います。
では要件定義とは何をやるのか？
では、要件定義とは具体的になにをやるかですが、私は最低限以下３点の成果物を決めることだと思っています。
1. リーンキャンバス
2. 画面遷移付きワイヤーフレーム
（≒プロトタイプ）
3. ユーザーストーリー
（≒プロダクトバックログ）
1. リーンキャンバス
リーンキャンバスを書くことで、ビジネスとして抑えておくべきところを確認することができます。リーンキャンバスを用いて、開発チームにも概要としてビジネスを伝えることができます。書き方については、Tablyの小城さんの記事が非常に参考になりますね。
リーンキャンバスを書くと簡単に書いていますが、ここは非常に難しいですね。ペルソナを考えたり、課題インタビューをして、ユーザーの課題が正しいのかなどを確認するなど、手法は様々あると思います。また、一度書いても何度も書き直すものかと思います。
開発者視点でも、このレベルの概要はしっかり抑える必要があります。
2. 画面遷移付きワイヤーフレーム（≒プロトタイプ）
次に、欲しいのが画面遷移付きのワイヤーフレームだと思っています。
イメージは以下のようなものです。
#これでフォロワーさん増えました
— マリコ (@marimamiac) February 7, 2021
フワッとした案件は、見積り＋ワイヤーフレーム（画面遷移図）＋質問をつけた資料を1セットで出しちゃうことが多い。
「こういうものが含まれてますけど、認識合ってますか？」
という、プチ要件定義！
LPなら1時間もあれば作れるし、話が進むし、決まるよ🐣💓 pic.twitter.com/6iyp3ZYLGO
開発者視点でも、ワイヤフレームがない場合PMの思い描いているイメージとかなりずれてくるので、お互い不幸になります。
では、ワイヤーフレームを書くには、何が必要でしょうか？
情報設計と画面遷移図が必要だと思っています。
情報設計（IA）とは、項目の情報単位の設計で、構造を作る部分になります。また構造を作るには、完璧ではないにしろ、項目の一覧も必要になります。
しかし、開発者がドメイン知識を持っている場合は問題ありませんが、どうしてもビジネス側の人間の方がドメイン知識を持っていることが多く、PMやビジネスサイドの人が項目の一覧を洗い出す必要があることが多いです。
画面遷移図は、機能を実現する画面の遷移パターンはいくつかあり、決まっていないと、ワイヤーフレームが書けないので必要です。
会社ではdrow.ioを利用して、まずは箱で画面の遷移を事前に考えています。
イメージ図（適当なECの例。でたらめです。）
3. ユーザーストーリー（≒プロダクトバックログ）
最後に欲しいのが、ユーザーストーリーの一覧ですね。
ユーザーストーリーとは、以下のようなフォーマットで、ユーザーができることをまとめたものです。
（ペルソナ）は〇〇ができる。なぜなら、△△だから。
注意点としては、ここにはHowになるような、具体的な方法については記載しません。
現在の会社では、このユーザーストーリーをプロダクトバックログとしてJIRAに登録して、スクラムを進めています。
開発者視点でも、スクラムを回していくには、プロダクトバックログが必要なので、こちらも必須かと思います。（将来まで全てある必要はないが、必要な要件が漏れているのは問題）
では、ユーザーストーリーの一覧はどうやって必要な要件を網羅的に抑えるのでしょうか？
こちらはユーザーストーリーマッピングで網羅的に考えていきます。
ユーザーストーリーマッピングとは、以下の記事が参考になります。こちらで、ユーザーストーリーの抜け漏れや、初回リリースに必要な対象決めができます。
では、ユーザーストーリーマッピングを決めるにはどうしたらよいか？
ここでさらに、カスタマージャーニーマップが必要になってきます。
カスタマージャーニーマップで、ユーザーの接触前からのジャーニーを描くことで、ユーザーとの接触点や課題や感情を確認します。これらをユーザーストーリーマッピングに活かしていきます。
カスタマージャーニーマップを考えるには、ペルソナを定義しておく必要があります。
カスタマージャーニーマップやペルソナの設定方法については、
他のたくさんの記事があるので、ここでは説明しません。
まとめ
新規プロダクト開発におけるPMが作るべき最低限の成果物と、それを作るためのフローをまとめました。
上図の、左をINPUTに、右のOUTPUTを作り、開発に向かっていくというイメージで考えています。
青枠になっている３つが決まれば全ての成果物はなくてもいいかなと思っています。
（ただ、漏れなく一貫性をもってプロダクトを作ろうすると必要になってくるケースが多い気がします。）
色々と全ケースを網羅したわけではないので、
これもやったほうがいいとか、これは間違っているんじゃないとかありましたら、気軽に質問いただけたらと思います。
この記事が気に入ったらサポートをしてみませんか？