プロダクトマネジメントざっくり整理

Transcript

1. プロダクトマネジメント ざっくり整理 久保 京介
2. • 筆者の考えに基づくものであり、所属組織は関係ありませ ん。 • プロダクトマネジメントは会社やステージによって⼤きく異 なるので、全てに⼀律に⾔えることはありません。 • とはいえ、型を知らないと型破りはできないように、ある程 度、⾃分の中で型を作ることは有⽤でしょう。 • このスライドは、筆者が学んだことをアウトプットするため に作成されてます。インプットした情報を再構築し、⾃分の 体系⽴った知識にすることが⽬的です。その過程で誰かの参 考になれば幸いです。 • 今後の成⻑次第でこのスライドの内容もアップデートしてい きます。 注意 ※このスライドのデザインは「デザインシステムの利⽤の⼿引き」（デジタル庁）を参考にしつつ、⼀部デザインの変更を加えて作成しました。
3. • プロダクトの成功 • プロダクトの未来を描く • 事業を理解する • ユーザーの理解を深める • 機能を企画する • プロダクト指標 • 提供終了を考える • PMとしての基本的スキル ⽬次
4. プロダクトの成功
5. プロダクトを⽤いてプロダクトビジョンに近づき、その中で事業 価値とユーザー価値が向上するということがプロダクトの成功で ある。 したがって、それぞれのバランスを考慮しつつ、プロダクトを成 ⻑させていく必要がある。 プロダクトビジョン、事 業価値、ユーザー価値 プロダクト ビジョン プロダクト （事業価値） （ユーザー価値）
6. プロダクトの未来を描く
7. プロダクトビジョンとは、プロダクトが全社ミッションに対し て、どの市場にどんな価値を提供することで貢献するのかについ てシンプルにまとめたものである。数年スパンでのプロダクトの あるべき姿を明確にして、どこに向かうのか、どこに注⼒するの かの共通認識を関係者間でとる。 プロダクトビジョンを 作る 全社ミッション プロダクト どこの誰にどんな価値を 提供することで
8. プロダクトビジョンを達成するために具体的にどのような開発を すべきか、ざっくりとした注⼒領域である開発テーマを作成す る。例として、「世界の⼈々を繋げる」というビジョンをもった チャットサービスで考えてみる。 開発テーマを作成する Product Vision：世界の⼈々を繋げる 開発テーマ1： 伝えたいことを直感的に伝えられる、 チャットのユーザー体験の向上 開発テーマ2： さまざまな⼈と繋がれる、アプリ外の⼈と やりとりできるゲスト機能の強化 開発テーマ3： さまざまな内容をやりとりできる、外部の アプリケーションとの連携強化
9. 開発テーマの下に具体的な要件を作成し、それぞれの優先順位を 出して、実施時期を暫定で出す。それに合わせて開発をスケ ジューリングする。 ロードマップを作成する 開発 テーマ1 開発 テーマ2 要件A 要件B 要件C 要件D 要件E
10. 事業を理解する
11. 事業の全体感を理解する上で、ビジネスモデルキャンバスを埋め てみることが⼿っ取り早い。作成してみたらどこに優位性がある のか、弱みがあるのか考えてみよう。 ビジネスモデルキャンバ スを埋めてみる 出典：ビジネスモデルキャンバス（BMC）とは 書き⽅‧事例‧ポイントを紹介
12. 事業に関わる関係者を社内外問わず洗い出してみよう。”事業”と して⾒ると⼤きく実体が無いように⾒えるが、⼈の活動が集約さ れているものであるため、どんな⼈が関わっているのかを理解す ることは事業を理解する上で重要だ。 ユーザーにもエンドユーザーや管理者、経営者など。社内におい てもセールス、CS、エンジニア、デザイナー、マーケなど。ま た、第三者としてパートナー企業もいるかもしれない。詳細に分 解して考えてみよう。 関係者を洗い出す ざっくりとしか ⾒えていない事業 ⼈の活動 ⼈の活動 ⼈の活動 ⼈の活動
13. 関係者の利害をざっくり考えてみよう。それぞれの欲求と逃避を 理解すると、誰にどんな価値が提供できるのかイメージしやすく なる。また、0or100のような極端な思考をせず程度を意識する。 ざっくり例としてユーザータイプに応じた欲求と逃避を記載して おく。（もちろん社内も含めて考える） それぞれの思惑を考える 関係者 こうでありたい （欲求） こうなりたくない （逃避） エンドユーザー 普段の業務を楽にし たい。 ↔ 使いづらい。 管理者 製品を導入する以 上、成功させたい。 ↔ 費用対効果が出ない。 経営者 事業上、必要なデー タなどを見える化した い。 ↔ 費用対効果が出ない。 事業に貢献しない。
14. ユーザーの理解を深める
15. ユーザーが喜ぶプロダクトを作る上で、ユーザーからのフィード バックを回収し、開発に落とし込むことはとても重要である。プ ロダクトライフサイクルのどのフェーズにおけるフィードバック なのか意識しつつ、フィードバックをもらえる体系を整える必要 がある。 プロダクトライフサイクルに 合わせたフィードバック回収 を設計する 導⼊ 試⽤ 利⽤ 解約 Log？ 顧客DB？ アンケート？
16. ユーザーからのフィードバックには、定性情報と定量情報が存在 する。ユーザーの理解を深める上で、それぞれの特性を理解する ことがとても⼤切である。 • 定性 ◦ 具体的 ◦ なぜその⾏動をしたのかがわかる ◦ あくまで特定の⼀⼈の意⾒の可能性があるので、全 ユーザーが感じてると錯覚しないように意識する ◦ ユーザーが回答するので、ユーザー⾃⾝に認識のズレ があった場合、事実とは異なる可能性もある ◦ 思いもよらない情報を得ることができたりする • 定量 ◦ 事実 ◦ 仮説検証に良い ◦ 全てのユーザー‧特定のセグメントにおける傾向など を出しやすい ◦ なぜその⾏動をとったのかはわからない 定性情報と定量情報
17. 製品は誰か⼀⼈のものではなく、触れる⼈全てに対して影響を与 える。したがって、PMは1ユーザーに対してだけではなく、抽象 度をあげて、ユーザー全体として理解を試みる必要がある。（た だし、1ユーザーの声から全体を考える動きも⼤切） 最⼤公約数的な理解を しよう PM ユーザー全体 △
18. 機能を企画する
19. 誰がどんなことに困っているのか、どんなことを期待しているの か、その課題を特定しよう。 重要なのは、事実から⾃分たちで課題を抽出して⼿段を考えてい くこと。ユーザーの声は時にユーザーの解釈も含んでいて、それ が課題として明確ではない場合も多い。あくまでどのようなシー ンで何がしたい、何ができないから要望をあげているのかという 背景をベースに機能企画することが本質的な課題解決に繋がる。 課題を特定する 出典：「無駄なものを作らない」 がアジャイル開発の⽬的【第3回】
20. 実現⼿段に関してはエンジニアの領域ではある。しかし、鵜呑み にするのではなく、PMとしても複数の解決⽅法を想定して⽐較検 討をする必要がある。実現コスト、検討コスト、ユーザーに受け ⼊れやすいかなどの観点を洗い出し、解決⼿段を松⽵梅で3つほ ど事前に想定できると、デザイナーやエンジニアの意⾒も引き出 しやすい。 ⼿段を複数⽤意する 課題 ⼿段1 ⼿段2 ⼿段3
21. プロダクト開発において、不確実性がつきものである。いきなり 機能を企画して実装しようと思っても、⾒えてなかった懸念やリ スクが出てくることは往々にしてある。今までやったことない領 域などは常に不確実性も実現を阻むものとして事前に考慮する必 要がある。 そして、不確実性の幅を下げるためには、学習と詳細化が必要で ある。短期的にはSpikeタスク、中⻑期的には考慮した優先順位 づけ‧PoCなどの取り組みが策として挙げられる。 不確実性を意識する 出典：プロジェクトの本質とはなにか
22. 仕様を決める際、最⼩機能で機能をリリースし、将来的なアップ デートを考慮することが重要である。最初から⼤きな機能を作る と、リリースも遅れてしまい、失敗した時のダメージがより⼤き くなってしまいがち。機能を絞ってシンプルに⼩さくリリースを 重ねていくことが⼤切です。 また、将来的にアップデートしていく点を考慮して開発しなけれ ばならない。「最終的な理想はこんな機能だが、価値を細分化し て1stではこの価値、学習した結果を踏まえて2ndはこの価値をリ リース」という流れで意識して仕様を決める必要がある。 仕様を決める 出典：MVP（Minimum Viable Product）とは？実践 するメリットと検証⽅法
23. プロダクト指標
24. 指標を設定する際、頭⽂字をとってSMARTという観点を意識する と良い。 • Specific（具体的） • Measureable（測定可能） • Achievable（達成可能） • Relevant（関連性が⾼い） ◦ 意外とここが重要 • Time-bound（期限付き） • Evaluate（評価） ◦ 数字を評価できないと意味がないので、虚栄の数字に 注意 どんな値が指標として 適切か
25. KPIと全体像 構造化した上でそれぞれのレイヤーに対して指標を設定し、定期 的に振り返り、ビジョンに近づいているか、事業価値が向上して いるか確認する。⼤事なのは、事業価値とプロダクトビジョンを 分離して考えないこと。全てが連動し、それぞれがうまく値に反 映されているかを検証していくことで、理想に近づくことができ る。 プロダクト ビジョン 開発テーマ1 開発テーマ2 開発テーマ3 施策1-1 施策1-2 施策2-1 施策3-1 施策2-2 施策3-2 事業価値 （売上げ‧利益等） KPI KPI KPI KPI KPI KPI KPI KPI KPI KPI KGI
26. 提供終了を考える
27. 提供終了するとなると、顧客に価値を届けることができなくな る。しかしながら、提供する上でのメンテコスト、オペレーショ ンコストはその分削減され、別の場所にリソースを投下できる。 このメリット‧デメリットを⽐較する。もちろん、これは開発視 点だけでなく、事業全体、各関係者の視点もインプットしてトー タルのコストを勘案する必要がある。 また、終了に関して相談する際に不利益を被る⽅もいるので、⽇ 頃の信頼と丁寧なコミュニケーションをいつも以上に意識する。 トレードオフで価値があ るか考える Cost Value
28. 今使っているものが明⽇使えなくなる！となったら誰もが困る し、怒りにつながるだろう。提供元としては、今まで使っていた だいている感謝を忘れずに、丁寧にコミュニケーションする必要 がある。 提供をやめた際にどのくらいの影響があるのか、その影響に対し てどのくらい準備すれば良いのか、そもそも顧客⾃⾝で気づける のか、段階踏んで告知をどのようにするか、などスケジューリン グする必要がある。 顧客影響を考慮してスケ ジューリングする 告知① 告知② 段階的 終了① 段階的 終了② 終了
29. PMとしての基本的スキル
30. 現象は観点、⽴場によってその姿を⼤きく変える。⾃分がどの場 所からものを⾒ていて解釈を付与しているのかを⾃分⾃⾝で理解 する必要がある。加えて、相⼿がどこから⾒ているのかについて も理解するようにし、⾃分との意⾒の差分がどのようにして⽣ま れているのか把握する必要がある。 多⾓的視点で現象を正確 に捉える ⻑⽅形に ⾒える 円に⾒える
31. 何かを選択するということは何かを捨てることである。意思決定 する際に必ず⽐較を意識し、決定したことに対して捨てているこ とは何か、他に選択肢がないのか、なぜそれは選択しなかったの かについて常に説明できる状態にする必要がある。 ⽐較を必ずする リソース 選択肢① 選択肢② 選択肢③ この⽐較を常にするイメージ
32. 物事の階層（レイヤー）を捉えて、議論しよう。抽象度合いを⾃ 分の中で調節して、事業‧プロダクトにどう影響するのか把握す ることを常に意識する。 レイヤーを捉える 抽象 具体
33. プロダクトが提供するValueを最⼤化することに責任をもつPMは 受け⾝の姿勢では必ず失敗する。常に「理想とは何か」について 考え、そこに向かう上での課題を明確にして解決する必要があ る。 ⾃ら課題を⾒つける 理想 現実 課題 着実に定義することから始める必要がある。
34. まとめ
35. プロダクトマネージャーは、上位戦略から戦術まで幅広いレイ ヤーを⾏ったり来たりしつつ、プロダクトの成⻑に対して責任を 持つ必要がある。 プロダクトを成⻑させる上では、事業観点とプロダクト観点の両 ⽅を広範囲に渡って検討する必要があり、多様な知識が求められ る。ただ、もちろん⼀⼈だけでできる必要はなく、チームで補完 しあうことも⼤切だ。 またそれだけではなく、様々なステークホルダーを巻き込んでプ ロジェクトを進める必要があり、その観点におけるソフトスキル も⾮常に重要だ。 まとめ