プロダクトマネージャーの最低限の3つの業務【業務フォーマット付き】
1万文字オーバーの記事のため、要点だけお読みになりたい方は、一番最初の「プロダクトマネージャー役割と業務内容」というチャプターをお読みください。
はじめに
昨今ではプロダクトマネジメントの教科書といえるような本や記事が増えています。しかし、そういった記事にいいねを推しつつも、こんな事を思ったことありませんか？
「プロダクトマネージャーの仕事多すぎる。。。」
そう感じられているプロダクトマネージャーの方は多いのではないでしょうか。（もちろん自分もその1人です。）
そして、プロダクトマネージャーの採用活動を進めるとこの事実にも気付きます。
「教科書通りのプロダクトマネジメントを実践している人はいない。」
「面接でここまで広範囲の業務能力を評価しきれない。」
そのような事を感じた事のある方向けに、プロダクトマネージャーとして最低限果たすべき3つの業務を提言したいと思います。
私は、GENDAという会社でCPOをしています。（プロフィールと業務内容は、2021年のiOSDCの発表資料を御覧ください。）
CPOとしての失敗経験の一つに、プロダクトマネージャーの具体的な業務を定義出来ず、プロダクトマネージャー採用とオンボーディングに失敗した事が何度もあります。（今は自分よりも素晴らしい能力と経験を持つプロダクトマネージャーの方にジョインしていただきフォローしていただいています。）
そのような失敗を経て、最低限プロダクトマネージャーに求める業務を3つに絞りました。最低限の業務に絞り込むことで、以下のようなメリットが生まれます。
・PMロールへの期待値のズレを大幅に小さくできる
・PM業務をシンプルにすることで、標準化・効率化しやすい
最低限の業務と記述していますが、実際はプロダクトマネージャーがやるべき業務の全てと言っても過言ではありません。それだけ一つ一つは奥が深いものだと思っています。
プロダクトマネージャーの役割と業務内容
プロダクトマネージャーはmini CEOや、プロダクトを成功に導く役割と定義されますが、ここでは以下のように定義します。
プロダクトマネジメント ＝「開発工数」を「顧客価値」に変換する機能
つまり、プロダクトマネージャーのミッションは、エンジニアの貴重な工数を有効活用し、顧客価値を生み出すプロダクトを創ることです。もう少し具体的にプロダクトマネージャーの最も重要な業務を定義すると、「顧客の課題を解決するバックログを用意すること」です。
これらを踏まえて、プロダクトマネージャーの最低限の業務を以下の3つと定義しました。順番に解説します。
1. KGI/KPI責任と説明責任
プロダクトマネージャーは、開発工数を顧客価値に変換する機能を担います。そのため、プロダクトの結果指標に責任を負うことが求められます。プロダクトの責任≒事業責任となるケースも少なくありません。責任の範囲の広さは組織図やプロダクト特性、本人のスキルにも依ります。共通して言えることは、KGIまたはKPIの目標値を設定し、その目標値を達成する責任を持つ事です。
逆にKGI/KPI責任を持たずに、開発要望を形にする事をミッションとしている場合はプロダクトマネージャーではなく、ディレクター職と定義しています。
また、プロダクト開発は常にヒットが出るほど簡単な仕事ではありません。むしろ、想定よりも成果が出ない、というか全く変化がないケースのほうが多いのではないでしょうか。そのため、企画が外れて思うように成果が出ない時でも、経営陣やエンジニアの信頼を勝ち取り、バッターボックスに出来るだけ立ち続ける事が大事です。
信頼を得るためには、空振りした時には空振りした原因の説明と、次にヒットを打つためのアクションプランを周りに説明することです。施策の結果を報告し、学びを共有することで、「失敗を糧に次は成功に繋げてくれるはず」という期待をかけてもらえます。
また、周りに対する説明責任を果たすことで自分自身のスイング(企画)に対する良い振り返りになるため、コミュニケーションコストと捉えるのではなく、学習機会として捉える事をおすすめします。
シンプルなKGI/KPIの目標設定の方法
まずは、KGI/KPIの目標を設定することが必要です。尚、ここでは成熟事業ではなく、成長事業の目標設定を想定しています。成長期の事業計画やKPI目標を決めるのは非常に難しいトピックです。なぜなら、成熟事業よりも成長事業のほうが不確実性が大きいからです。そこで、以下のようなシンプルな目標設定の手法を提案します。
まず、行動計画についてです。目標設定するためには、行動計画を必ず策定します。よくある年間行動計画を策定する手法は、プロダクトロードマップを作ることです。（以下プロダクトロードマップ例）しかし、私はプロダクトロードマップを必ずしも作らなくても良いと考えています。
Asana 「プロジェクトロードマップ: その概要とそれが必要な理由」
<https://asana.com/ja/resources/project-roadmap>
代わりに、地味ですが、以下のように来期必ずやりたいバックログを何個かピックアップする程度で十分です。
というのも、ロードマップはウォーターフォール型の開発に適しています。実行に重きが置かれていて、納期が重要となるプロジェクトでは有効です。しかし、プロダクトマネージャーの役割を改めて考えてみると、プロダクトの成功のために何を作るべきかにフォーカスすべきです。そのため、実行計画を詰める時間よりも、企画の質や精度を高めるための工数を割くべきです。
また、分量も半年間程度で終わってしまう分量で問題ありません。それには、以下のような理由があります。
・年間計画の後半のバックログは質が低くなりがち
・上手くいかなかったバックログをリカバリーするための期間が必要
補足をしておくと、半年間分のバックログだけ用意しておけば良いという意味ではありません。プロダクトマネージャーたるもの、3年後5年後のプロダクトビジョンを言語化しておくことも重要です。また、筋の良さそうなプロダクトアイディアのストックは常に増やし続けるべきです。要は、プロダクトビジョンに向かって、一直線で行ける訳ではないので、長期の理想状態を見据えつつも、局面に応じて最適な選択をすべきです。
次に事業計画についてです。年間行動計画をベースに、毎月のKGI/KPI目標値を設定していく手法が一般的ですが、その手法は、正確性の高い行動計画を策定出来るのであれば有効です。しかし、成長事業のプロダクトマネジメントにおいては、正確性の高い行動計画立案は困難であるため、仮定に仮定を重ねすぎてしまう傾向があります。
代わりに「今期末に比べて、来期末は何％成長しているか？」を予測する手法をおすすめします。例えば、3月決算の場合「2022年の3月の業績に比べて、2023年の3月の業績は何％成長しているか？」を予測します。従来の手法の場合は、12ヶ月分、12地点の目標設定が必要ですが、後者の場合は、今期末の1ヶ月、1個の目標設定で済むので、目標設定の複雑さを大きく減らすことが出来ます。
来期末時点の成長率を計算した後は、以下の式で年間成長率を計算します。
年間成長率 ≒ 来期末時点の昨対成長率 ÷ 2
なぜ来期末時点の成長率を÷2するかというと、以下の図の通りです。年間10％成長するためには期末時点で20％成長している必要があります。
年間の線形の成長計画が建てられた後に、必要であれば、各月の明らかな変動要因（季節要因や確定している計画等）を多少調整すると良いです。
尚、年間行動計画や精緻な事業計画の策定を否定しているわけではありません。やらないよりは、やったほうが実現可能性が高まるのは言わずもがなです。また、それらの必要性はプロダクトのフェーズや特性によります。ここでのメッセージは、実行計画を精緻に組み立てるよりも、企画やバックログの質や確度を高める事に時間を割く方が、目標達成率は高まるのではないかという事です。
レポートフォーマット
KGI/KPIの目標値を決めた後は、週次等でレポーティングする事をおすすめします。私は以下のフォーマットで週次でレポートしています。レポート指標は、プロダクトや関わり方によって異なります。
責任範囲が広くなると、指標の数が多くなりすぎます。そこで、ポジティブ変化のあった指標は青文字で、ネガティブ変化のあった指標は赤文字で記述します。そして、変動要因や予実差要因などを都度説明します。経営陣に対して説明するだけでなく、エンジニアなどにも共有することで、自分たちの開発している内容が、どうインパクトにつながっているか等を理解してもらえるので、モチベーションアップや目線合わせにも繋がります。
また、数値のレポーティングだけでなく、リリースした機能の効果検証結果や、今後開発する機能の説明なども実施します。以下は施策振り返りフォーマット例です。
振り返りでは、期待した行動変容が起こせたかどうかが重要となります。行動変容を起こせたけど、KGI（経済効果）にはつながらないケースもよくあります。しかし、経済効果につながらなかったとしても、顧客の求めている機能をリリースできているかどうかが重要です。経済効果が生まれなかったのであれば、次はターゲット設定や起こしたい行動変容といった、ゴール設定を変えれば効果はいずれ出るはずです。
レポーティングフォーマットを統一し、週次等で作成することで、あとから入ってくるプロダクトマネージャーが歴史をキャッチアップしやすいというメリットもあります。特に施策の振り返りを資料に残しておかないと後悔します。自分もダッシュボードをその場で開いて、口頭ベースで説明していた事も多かったので後悔しています。
Appendix）開発投資のROI測定
このセクションは、アディショナルです。
複数プロダクトのモニタリングや予算管理をしていたり、開発投資のROIを可視化したいと思っている方向けの内容です。 まずは、KGI/KPIの週次のレポーティングと施策の振り返りが出来れば十分です。
私も複数プロダクトの予算管理や、ROIの可視化は模索している段階ではありますが、今の所ワークしている評価方法を説明します。ちなみに、この開発投資のROI測定の手法は、rakusul COOの福島さんのPodcastで学びました。
まず、やりがちな失敗例として、一つ一つのリリースした施策の開発工数とリターンをボトムアップで集計し、全体の開発投資のROIを測定するのは無理があります。自分もチャレンジしましたが挫折しました。そこで、試行錯誤の末に、以下のようにシンプルに可視化して判断しています。 以下の図は「成長事業A」のサンプルチャートです。
赤棒が「開発投資」、青棒が「EBITDA」で、緑線が「ROI＝EBITDA / 開発投資」です。 このグラフは、開発投資額が一定で、EBITDAが右肩上がりです。開発投資に対するEBITDAの比率も高まっています。
このグラフから何がわかるかというと、開発投資がEBITDAの成長につながっている可能性が高いということがわかります。一方で、開発投資に対するROIが高すぎるので、もっと開発投資を増やすべきという判断が出来ます。さ
次に「伸び悩み事業B」の開発ROIチャートを見てみます。
2021年10月頃までは順調に事業が成長しています（開発投資が成長につながっている）が、それ以降は成長が寝てきていることがわかります。直近半年間の開発投資がプロダクトの成長につながっていない可能性が高いです。このように開発投資が事業成長につながっていないと見受けられるときは、戦略、またはデリバリーのどちらかで問題を抱えているケースが多いです。従って、介入してテコ入れする必要性を判断できます。 介入する余裕が無い場合は、より開発投資額を抑えて、他の事業に開発予算を回す等の意思決定も有りえます。
ここで注意すべき事は、開発投資は1ヶ月で事業成果につながるものもあれば、システムリプレイスのように、1年以上後に事業成長につながるケースもあります。伸び悩んでいるのか、ロングタームの施策を行っているかで判断は変わります。
また、当たり前ですが、事業成長のドライバーは開発投資の良し悪しだけではありません。プロモーション施策がものすごく当たることもありますし、仕入れた商品が大ヒットになる可能性もあります。とはいえ、長期タームで見ると、プロダクトが良くなることで持続的な事業成長が実現できます。そのため、プロダクト投資以外の変数はあれど、プロダクトの投資額が増えて、その後に持続的に事業が右肩上がりを実現できていれば、プロダクト投資の成功とみなします。
ただし、プロダクトの立ち上げフェーズの場合、利益で評価する事が難しいケースがあります。その場合、成果指標をEBITDAではなく売上で評価すべきケースもあります。また、ARPUや不具合発生率などのより直接的な指標を追いかける事も選択肢の一つですが、長期的に追えるかつ、横串のプロダクト毎に比較できる指標が望ましいです。
上記の開発ROIダッシュボードは、特に複数プロダクトで横串で見たときに、上手く行っているプロダクトとそうでないプロダクトがはっきりと分かりますので、余裕があれば試してみてください。
2. バックログの新規追加
プロダクトマネージャーの本質的な業務は、「顧客の課題を解決するバックログを用意すること」です。そのため、バックログを創ることはプロダクトマネージャーにとって最も重要で、難易度の高い業務です。
バックログとは開発案件の在庫のことです。在庫が切れると、開発チームはやる事を失います。また、質の低い在庫ばかりを揃えてしまうと、事業やプロダクトは成長しません。いずれも事業としてはコストのみが発生している状態ですし、貴重な貴重な開発メンバーのリソースを無駄にする事は、プロダクトマネージャーの大罪です。
バックログのフォーマット
バックログというと、JIRAやAsanaなどでチケットを切る程度を想定されると思いますが、ここでいうバックログはもう少し広い意味で、企画と仕様も含みます。要は、何のために、何を作れば良いのかをまとめたものです。
バックログのフォーマットは固めていませんが、自分なりに意識している項目をリストアップしておきます。以下の項目を1枚のConfluenceページにまとめています。
■ バックログフォーマット例
・タイトル：○○機能の開発
・概要：その機能の概要
・目的：その機能を開発する自社にとっての目的
（例：ライトユーザー層の獲得、リテンション強化等）
・ターゲット：その機能を求めているターゲット層と出現率
・インサイト：ターゲットユーザーが潜在的に感じている課題、ニーズ
・提供価値：その機能の便益（顧客が主語であるべき）
（NG：リッチな検索機能、OK：欲しい商品がすぐ見つかる）
・サクセスクライテリア：その機能開発の成功条件、KPI目標
・開発工数：見込みと実績を入力し、ROIなどを算出
・要件定義：仕様やデザイン等
バックログを起案する前工程には様々なリサーチや分析、戦略プランニングなどのプロセスを経ることが多いです。しかし、前工程はどんなものでも、結局は質の高いバックログが生産できればOKです。ただし、一定の説明責任は発生しますので、思いつきベースは好ましくありません。
なぜ前工程に拘らないののかというと、企画立案のスタイルは三者三様で良いと思っています。定量調査が得意な人もいれば、ユーザーの心の機微を掴み取るのが得意な人もいますし、新しい技術を応用するのが得意な人もいます。そのため、前工程のスタイルに囚われずに、説得力のある企画やバックログを生産できれば問題ありません。また、企画のプロセスを標準化しようとすると、整えるべきフォーマットや管理コストも増えますし、良い企画はフレームワークで生み出せるものでもありません。 その一方で、要件定義やデザインに依頼するときのプロセスはある程度型があるので、標準化することは効果があります。
企画立案のスタイルは多様でも良いですが、ヒットを生み出す企画の条件はある程度決まっていて、以下の3つの観点を満たす企画は筋の良い企画だと判断します。
・顧客が求めている機能か？
・それは他社とは違う自分達らしい機能か？
・利益は出るのか？
シンプルではありますが、3条件を満たす企画を立案することは非常に難易度が高いです。
企画の成功確率を高める3つのポイント
企画の成功確度を高めるために、自分は以下の3つの事を意識しています。どれも当たり前のことですが、改めて言語化します。
① 課題は必ず顧客が持っている
② 実装する前に実験する
③ 様々な業界の事例をインプットする
① 課題は必ず顧客が持っている
企画を立案する前提には必ず顧客の課題やニーズがあります。解決すべき課題やニーズが明らかであれば、あと数回試行錯誤を回せば上手く行く可要性が高いです。しかし、企画を立案する時は大抵「顧客の一番の課題はなんだろうか？」と悩みます。
顧客の課題やインサイトを掴めていないなと思ったときは、ユーザーインタビューを10セット入れる事をオススメします。朝起きれなかったら腕立て10回みたいなテンションで、インタビューをひたすら入れる事をおすすめします。
他にも、様々な角度、様々な手法で定量調査することも有効です。毎日同じKPIを見て考えてはいけません。自分でSQLやExcelを弄り倒して、違った確度から数値を出してみたり、アンケート調査を実施したりするなど、様々な確度から顧客を理解することが一番大事です。
※ この辺りの話は別記事で紹介します。
② 実装する前に実験する
良い分析ができて、良い企画を思いついたらすぐに実装して試してみたくなるのがプロダクトマネージャーの人情です。しかし、そこをぐっとこらえて、簡易的なテストを挟めると、企画の打率は大幅に上がります。簡易的なテストというのは、コンセプトテストを実施したり、今ある機能で簡易的に試してみる等があげられます。
その分、プロダクトマネージャーの工数は数倍に膨らみますが、プロダクトマネージャーが1週間我慢して検証し、仮説の精度を高めるプロセスを挟むことで、全体の工数で言うと数十分の一に圧縮されますし、事業計画を達成する確率は大幅に上がります。
当たり前ですが、コンセプトテストよりも、実際に簡易的に実験した結果の方が正しいので、出来れば実際に手運用で機能提供してみることがベターです。一方で、実験よりもコンセプトテストの方が、ユーザーの心理は掴みやすい（行動ログだとなぜ反応したのかは掴みにくい）のと、トライアル意向の高さを測定できるので、実施自体はオススメです。
基本マインドセットとして、イチローのバッティングのように、自分の企画に満足せずに、企画の打率を1%でも上げる方法はないかと模索する探究心と粘り強さが最も重要です。
③ 様々な業界の事例をインプットする
アイディアは、既存のアイディアのアナロジーです。つまり、様々な事例をインプットしない限り、新しいアイディアは生み出せません。また、近い距離の競合を研究しているだけでは斬新なアイディアは出ません。アプリビジネスであれば、SNS、ゲーム、海外、EC、ストリーミングサービス等の様々なプロダクトの成功事例や失敗事例を知ることで、自社に活かせそうな斬新な企画を思いつくことが出来ます。もっと幅広く、IT業界以外のビジネスの戦略や考え方を知ることもインスピレーションを受けます。
例えば、マクドナルドのマーケティングの事例を勉強すると、IT業界のマーケティングのスタイルと全く違うことがわかります。最近は変わりつつありますが、IT業界はデジタルマーケティングが主体で、広告のパフォーマンスを数値で管理することには長けています。しかし、プロモーション企画力という側面では、成熟産業の勝ち抜いてきた企業に比べると圧倒的に遅れていると思います。もちろんそれはビジネスのKSFがプロダクトかプロモーションなのかの違いや、プロモーションに掛けられる予算の違いもありますが、IT業界も作れば売れる時代は終わっているので、他の業界からマーケティングを勉強することは有意義です。
3. バックログの優先度決め
プロダクトを成功させるために、どの順番で開発をすべきかの意思決定をします。その際、以下の3つの観点をバランスよく取り入れることが重要です。
大前提としては、顧客に独自の価値を提供することで、中長期的な利益最大化を目指します。なぜなら、利益が増えない限り、事業投資額が増えないからです。事業投資額を増やせないと、競合の進化のスピードに遅れを取り、顧客が離れていくからです。もちろん、不健全に経済効果を追求するのは間違いです。また、PayPayのように初期はマネタイズを考えずにとにかくシェア獲得を目標とするケースもありますが、基本的には、経済効果を最大化するように優先度を決めるべきです。
① ビジネス観点の機能開発
ビジネス観点の機能開発というのは、直接的に収益向上、あるいはコスト削減が見込まれる機能開発を指します。具体的には、以下のような開発案件です。
・マネタイズ機能：Adや課金サービス導入
・コスト削減：サプライチェーンを効率化・最適化
・パートナーシップ：他社との共同案件や受注案件
ビジネス観点の施策は比較的優先度を決めやすいです。経済効果と開発工数を見積もり、開発費用の回収期間などを見積もれば、優先度を決めることが出来ます。
② ユーザー観点の機能開発
ユーザー観点の機能開発とは、顧客のニーズに応える事を目的とした機能開発です。具体的には、以下のような開発案件です。
・新規顧客獲得：潜在顧客の求める機能提供・プロモーション目的
・既存顧客維持：既存機能の満足度向上・リテンション施策等
・CS問い合わせ対応：CSの問い合わせの解決
ビジネス観点と同じく、ユーザー観点の機能開発も比較的優先度を決めやすいです。ビジネス観点のバックログと同じく、経済効果と開発工数からROIや回収期間で比較することが可能です。
しかし、ユーザー観点の場合は、経済効果は間接的効果であるため、式は少し複雑となります。以下のように、2段階で計算する必要があります。
■ ユーザー観点のバックログの経済効果の計算
顧客の行動がどの程度変わるか？（継続率○％向上）
→ その結果、経済効果はどの程度か？（売上○%向上）
また、この中でもCSの問い合わせ対応だけは、経済効果を試算しにくいです。というのも、どこまで対応すべきかは経済観点で決めるというよりも、モラルによって決まる側面が強いからです。私はまだ作れていませんが、優先度決定の基準をチーム内で作っておくとスムーズでしょう。
③ チームメンバー観点の機能開発
チームメンバー観点の機能開発というのは、チームメンバーの生産性を高めるための機能開発です。ビジネス観点のコスト削減で評価できるケースもありますが、もう少しファジーな、精神衛生上の文脈で意思決定することも多いです。具体的には、以下のような開発案件です。
・技術負債解消：技術負債の解消や技術的チャレンジ
・業務ストレス軽減：運用自動化、問い合わせ根本解決、管理画面改善
・データ可視化：ツールの導入、データ基盤構築、データレポート自動化
上記のいずれも、計算しようと思えば経済効果まで計算する事ができますが、それぞれの課題の特性上、合理的にROIを測定することが難しい場合が多いです。
技術負債解消は、病気の予防のようなもので、問題が顕在化したタイミングで対処してはコストが高くつく、場合によっては取り返しがつかなくなることもあります。そのため、常に少しづつ返済し続けることが大事です。もちろん負債の返済だけでなく、将来のための技術投資（新しい技術導入）なども重要です。
業務ストレス軽減は工数削減で比較できそうです。しかし、一つ一つの開発は数時間で終わるケースも多く、一つ一つのバックログの見積もりをする暇があれば、上から順番に解消した方が楽です。また、本気でインパクトを出そうとすると、業務効率化をした上で、人件費削減に繋げないといけないので、そう簡単に手を出せません。どちらかというと、運営業務のストレスを軽減し、モチベーション高く業務に取り組んでもらう目的で対処するのが良いでしょう。
データの可視化は、経営や経理にレポーティングするために必要だったり、社内で分析するために必要です。これの経済効果を試算するのはほぼ不可能でしょう。しかし、データを見ないとPDCAを回せないので、基本的にはなるべく優先度を高めて先に対処すべきです。（といっても中々工数を割り当てできないのが常ですが。。）
バックログの種類ごとのチーム分け
上記で述べたように、ビジネス視点の開発と顧客視点の開発は優先順位を定量的につけやすいです。しかし、チームメンバー視点の機能開発を、ビジネス観点や顧客観点と同じように優先度判断することは困難です。
したがって、リソースのx%をチームメンバー視点の機能開発に割り当てる事を決めたり、業務改善チームや、技術負債返済チーム等といった専属のチームをつくり、ビジネス・顧客視点の開発とは分けて管理したほうが、意思決定・調整コストも下がるのでオススメです。
チームを分けるデメリットとして、その領域の開発が専属メンバーに属人化・ブラックボックス化してしまうリスクもあるので、ローテーションを活用したり、情報共有の仕組みを考える等の工夫は場合によって必要です。
まとめ
ここまでで、最低限のプロダクトマネージャーの業務をまとめました。プロダクトマネージャーのミッションは、プロダクト成功のために最高のバックログ（開発在庫）を揃えることと言っても過言ではありません。もちろん、ここであげた業務以外にも、開発やQAのプロセスマネジメントや、他部署とのコミュニケーション、BizDev、分析ダッシュボード作成、PMM、様々なマテリアルづくり（プロダクトロードマップとか、カスタマージャーニーマップとか、リーンキャンバスとかあれこれ）等、プロダクトを成功に導くための業務をあげたらキリがありません。
もちろん、アディショナルでカバー範囲を拡げる事は問題ありませんが、根幹業務が疎かになったり、根幹業務のスキルが不足しているのは元も子もありません。故に、この記事が、最低限やるべき業務領域の共通認識を獲得する手助けになれば幸いです。