このページを読む人へ

• このページを読んでも日常的ななPdMのお仕事のHowはあまり書いていません。
• 本質的に重要なPdMが担うべき役割を言語化したものです。

役割定義「プロダクトマネージャーとは何か。」

**

専光なりの定義 **

1. プロダクトの目指すvisionの実現、missionの達成を目指すチームの1員である。
2. 価値の創造/維持/拡張のためのプロセスを主体的に設計/構築しリードする役割を持つ。
3. 結果として、必要な水準のプロダクトを、必要なタイムラインで実現しすることがMissionである。

**

前提として **

• 関わる事業フェーズ、会社のフェーズ、一緒に働くメンバー構成によりPdMの役割範囲は結構変わる。
• 小さな組織でメンバーも潤沢ではない場合は、企画や要件定義やPDCAのいずれにおいても最下流の工程までPdMが手を動かすケースも存在する。
• ただ、必須役割は変わらず、状況に応じて任意役割を拾いまくるという感じなので、大事なことは変わらない。

誤解されやすいこと

PdMは事業部長ではない。(スタートアップなどの場合は例外あり。)

• スタートアップなどにおいては実質的に事業部長とプロダクトマネージャーが同一視されることも多いが、ある程度のサイズのある組織はPdMとは別途事業部長が設定されることがほとんどであり、PdMも1プロダクトに対して1人ではないことがほとんどである。
• エンジニア5名に対してPdM2名、事業部長1名みたいな体制はよくある。
• エンジニアやデザイナーなどと並列の1つの職能である。

PdMは要件定義担当者ではない。

• 事実として要件定義領域を担うことは多いが、人がいなければそこもやる、というだけで、PdMの担うmissionが「良い要件定義書を自分で作ること」という訳ではない。
• 結果的に組織として良い要件定義がされていれば良いのである。

PdMはなんでも屋ではない。

• 実質的な業務を見れば「なんでも屋」に見えやすいと、感じる人が多いのは確かである。 その状態は周囲の人間(pdm以外の人間)が、pdmの本質的役割を理解せず、何でも屋にしてしまっているだけで、良い状態ではない。

PdMはマネジメントするのはプロダクトだけではない。

• 例1
  • 「いい機能にするために、何ヶ月もかけて議論し、リリースした頃には二番煎じとなり期待した価値は発揮されなかった。。。」
  • 工程や意思決定の流れをマネジメントできない限りは上記問題は解決されない。
  • つまり、プロダクトバリューに関わる変数は多く、そのプロダクトの最終的なクオリティは1変数でしかない。
  • チームや開発プロセス、予算やコミュニケーションラインなどマネジメント範囲は多岐にわたる。

重要な役割

PdMとして重要な役割は3つだと考えている。

1. ロードマップマネジメント
2. プロジェクション
3. スコープコントロール

それぞれ解説する。

1.ロードマップマネジメント（Roadmap Management）

「ロードマップ」とは？

• プロダクト自体、またチームそのものが「どのような時系列で何を成し遂げて行くのか。」を可視化/共通認識化するためのモノである。
  • 「プロセス」と「タイムライン」を言語化したものである。
• 機能の追加や仕様変更に閉じてまとめた場合は、プロダクトロードマップと呼ばれることが多い。
  • 予算や中期経営計画も、事業の結果的指標から見た時のロードマップの1つである。

PdMの業務の全てはここから始まると言っても過言ではない。

「ロードマップ」をわざわざ作る意味、意義とは。

• 「組織全体が生産的に駆動できること」である。
  • ただし、「共通認識ができてスッキリした！」みたいな納得感を目的にしたロードマップ作成は、ロードマップの価値を矮小化しているので、要注意。
• 組織の生産性を抜本から底上げするためには、集中と選択のための意思決定が何よりも重要である。
• その意思決定の指針となるロードマップが作られるべきである。
  • 逆に言えば、頑張ってロードマップを作成したとしても、下記などに革新や影響がもたらされていないのであれば、それは良いロードマップではない。
    • 開発を見送る項目は何か
    • リソースの使い道や比重
    • 人員計画や育成計画
    • 販売戦略やターゲティング
    • プロダクトアーキテクチャ
    • などなど。

「ロードマップマネジメント」とは？

• (ロードマップに類するものが何もないのであれば、まずは作るべきだが)
• ロードマップは作成よりも「加筆修正」≒「マネジメント」が何よりも大事。
  • 組織の活動により半年あれば(早い組織なら1ヶ月あれば)、さまざまな学びを各メンバーが得る。
    • 例えば
      • 顧客のニーズ、インサイト
      • 新たな顧客候補、ユースケース
      • 競合の動きや構想
      • 法的規制やロビー活動の近況
      • 海外のトレンドや動き
      • 機能アイデアやアーキテクチャアイデア
      • デザインアイデア、インタラクションアイデア
      • インフラ課題や、規模対応課題
  • それらをもとにロードマップをより理想的に、また現実的に、加筆修正していくことがロードマップマネジメントである。
  • projectマネジメントとの違いも、本質的にはこの部分にあると考えている

良いロードマップマネジメントをするには。

• 学びの「獲得」と「共有」の双方を意図的に絶えず実行する必要がある。

• 情報流通やコミュニケーションのデザインはもちろん重要ではある。

• さらにはPOCや探索的活動や、アイディエーション機会などが定期的に行われていることもまた重要である。

  • vision実現へのマインドセットが低い組織ではここの活動が非活性となりやすい。

• 組織全体として、ロードマップを凝り固まったものではなく、より良いもの、より時代にあったもの、より自社らしいもの、より顧客にあったものにしていく前提を持ち話し合える文化のデザインもまた重要である。

• また、その上でPdMが担うべきこととしては。学びの「抽象化」と「追加調査」である。

  • 雑多な情報を解釈可能な状態に言語化すること
  • また、洞察や調査などのアクションを通じて、価値や影響を言語化すること
    • ここをやれるPdMがめっちゃ強い。
    • ここをサボるとメンバーの発見や意見が基本的には矮小化してい。
    • ロードマップの価値も高まることはなく、特定のカリスマ性のある1人の人間に依存したロードマップに身を委ねることになる。
    • いわば博打である。
  • そしてロードマップマネジメントをするためにも、pdmはフロントサイド、エンジニア、経営、顧客など「多様なステークホルダーとよく喋ること」がかなり大事。

2.プロジェクション（Projection）

プロジェクションの重要性

• アイデアや企画の価値や影響を投影することで、短期的/中長期的効果や影響範囲などを組織として解釈可能にする行為であり、戦略的な機能開発を意思決定を支える、重要な活動である。
• Projectionの能力が高いPdMがいる組織においては、着実な実行のための意思決定のスピードも担保され、ムーンショット（非連続的な大成長）のための仕込みも抜かりがない。

「プロジェクション（projection）」とは？

Projectionの辞書的な意味とは下記である。

「投影」「推定」「見積もり」

意見やアイデアやリスクに対して、短期的/中長期的にも「効果や影響」を組織として「解釈可能」にする行為である。

• つまりは「影響を投影する」ことである。
  • どんな影響が、いつの時点で、どれくらい発生し、組織にとってはどれくらい便益があるのか。
  • また、その対応のためにはどれくらいのコストがかかり、どれくらい難易度が高いのか。
  • などなど。

Projectionする力がない組織は、経営と現場の距離が開きやすい。

• 意見や企画に対して、双方の目線で解釈可能なように影響が投影されていないからだ。
• PdMは、両者の立場を理解した上で、どのように価値や影響を投影するかが試されている。
  • とはいえ、恣意的に操作された計算結果を投影しても価値はない。
  • 詳細は次のパートで後述する。
• また、いつまでも経営が現場レベルまで下りてくる場合も、チームのProjection能力が問題である場合もある。

Projectionを行うべき対象は「機能開発企画書」のみではない。

• 明確な1機能のROIを整理する場合はもちろんある。
  • この行為もPdMとして全うすべき行為ではあるが、これは比較的簡単である。
• ふわっとした業界動向からくるリスクを評価する場合もある。
  • こういった小さなシグナルを元にした、可能性の考慮が難しい。
  • そのシグナルが大きな現象になり、社会的に課題や可能性を認知するころには、競合は既にプロダクトを作り始めている可能性が多分にある。
  • 「小さなシグナル・蓋然性が整理されていない意見にどう向き合うか」はPdMの腕の見せ所である。
    • 日々、さまざまなことにアンテナを張り巡らせ、projectionすべき対象を見逃さないことが大事。
    • その上で、正確にスピーディにその意見や企画の価値や影響をprojectionする能力および行動習慣が重要である。

エンジニアやデザイナーの「やる気」の源を作るのもprojectionである。

• モノづくりをする人にとって「自分の仕事の意味」を自分で考えるのは難しい場合が多々ある。
  • 複雑性が高いビジネスにおいてはそれがより顕著である。
  • Projectionをする行為は、そのプロダクトや機能開発に関わる人の「働く意味の言語化」である。

良いプロジェクションとは？

1.理解可能であること

• まずは伝わらないと始まらないね。
• 「OO業界では当たり前で～。」「トレンドとして～」などのみでは専門性に差分がある場合は解釈不可能である。

2.客観的であること

• 「事実に基づいていること」である必要は必ずしもない。
• ただし、希望的観測になりすぎている予測を元にした投影は信憑性がなく、現場も経営も巻き込むことはできない。

3.ステークホルダーの興味関心を理解していること

• ここ結構大事。
• ステークホルダーとは下記などのことである。
  • 経営層、株主、従業員、顧客、アライアンスパートナーなどなど
• どのような立場にいるか？によって、同じ機能やプロダクトに対しても、価値や影響は大きく変わる。
• そのため、ステークホルダーにとっての便益や関心に沿っていない投影は意味を無さない。

4.時間軸が適切であること

• 想定している時間軸がすり合っていないと誤った意思決定となることは多々ある。
• また、有用に見える機能企画も時間軸を伸ばして考えた時に、実質的影響が小さいと判断できる場合も、多々ある。

良いプロジェクションをするために行うべきアクション

0.事業成長やビジョンの実現のための、「影響変数」を理解/構造化すること

• ここは大前提となる。
• 組織としてKPIやサービスグロースサイクルが整理されていない場合、価値や影響の評価や投影の難易度は高まる。
• 「何が変われば事業は伸びるのか？」「ユーザーにとっての価値が高まるのか？」を整理したものが下記などのツールである。
  • サービスグロースサイクル
  • KPIツリー
• 逆に、ここが整理されている場合は様々なアイデアや意見を多目的に照らし合わせて評価することが可能。
  • ここを言語化・構造化すればするほど、経営から自律した組織となる。
• 注意点
  • 誤ったグロースサイクル、本質的ではないKPIツリーを元に思考してしまう場合がある。
  • その場合は、本来は価値のある多くのアイデアが論理的に否定されてしまうことになる。

1.「目的と手段の整合性」で判断をしないこと

• 非論理的に見えるかもしれないが、目的と手段が整合された状態で、学び・アイデア・意見が発露されることは稀である。
• そのため、手段を起点にその価値をprojectionする場合も必要であるし、目的やテーマを切り取って、影響をprojectionすることも必要である。

2.仮説を重ねること

• 人は往々にして現在を起点にモノゴトを考えてしまう。
• 「if思考」を行おう
  • 「プロダクトがこうなった場合」「トラフィックがここまで増えた場合」など「if思考」をすることは必要になる。
  • そういった、プロセスを経ておくことで直近は重要ではないが、中長期的に重要な機能案などが的確にプールされていく。

3.Projectionのためのアクションプランを作ること

• 議論や思考だけで結論を出さないのもPdMの特徴だ。
• すべての仮設やアイデアに対してアクションする必要はないが、重要性が高い可能性があるが蓋然性が担保できないものや、コストが高いモノに対しては、議論や思考だけで解決しないこと。
• 何が明確になれば、適切なProjectionができるか、意思決定ができるかを取り決め、アクションプランを作ることが建設的だ。
• ここのアクションプランのアイディエーションは、PdMの腕が試される部分でもある。

4.「過去の評価」を見直すこと

• プロダクトのフェーズや、規模、顧客属性が変わったことにより、過去に否定された意見やアイデアやがリアリティや真実味を帯びてくるケースがある。
• チケットをプールし、四半期や年次で優先度を下げたカードを見つめることも重要である。
• サービスの危機を救う宝が眠っている可能性は多分にある。

3.スコープコントロール（Scope Controll）

「スコープコントロール」とは？

• スコープコントロールとは機能やUXのスペックの明確化、フェーズ分けとも言える。
• 端的に言えば、今回作るモノや機能に関して「どこまで作り込む？」という問いに対する、具体的なアンサーを整理または明示し、組織として意思決定することである。
• 概説は上記の通りであるが、実際に行うのはなかなかに幅広い観点が必要である。
• 同じようなモノを作るとしても、作り込みの程度はかなり幅がある。
  • 例えば
    • 営業活動上「その機能あります。」って言えさえすれば価値になるケース
    • 使い勝手は悪くとも、使えさえすれば価値になるケース
    • 競合の機能をまるパクリすれば価値になるケース。
    • 綿密にその機能の使われ方を想定してイレギュラーケースまで想定しないと、便利であるとは評価されず、価値にならないケース
• そう言った背景を踏まえて、今回のこの機能やプロダクトは、どんなケースまで想定し、どんな部分を、どこまで作り込むかを意思決定する行為がスコープコントロールである。

「正確なスコープコントロール」をするには。

• MVP(minimum variable product)という、「最小限の作りモノでリリースしていくのが正義だ」という(本当はそんな意味じゃないけど、社会的にそう解釈されている)定説がある。
• しかしながら、プロダクト戦略を考えると、如何なる時もMVPであれば、戦略上の価値を発揮できる機能になるのか？というと、そうではない。
• もちろん、最小限のリリースで価値を明確にすることが、正解の場合は多々あり、ほとんどがそうである。
  • 例えば
    • 新機能をまるまる作らずに新機能が使えるっぽく見えるボタンだけ、サイトに設置して、アクセス数を検証するし、ROIを明確にすると言う場合もある。
• とにかく最小化することが正解であるケースについては判断はさほど難しくない。
• 「小さくリリースする」という判断がプロダクト戦略に実際は沿っていない場合が潜んでいる。
  • それを見極めるのが難しいのである。

スコープコントロールの正確さを見極めるため観点とは？

1.顧客のニーズ/シーズ

• 「ooができればいい」と言った顧客の声があるとしても、本当にooさえできれば顧客は自社を選択するのか、使い続けるのか。

2.トラフィック、スケール速度

• その機能はどれくらいの時間軸で、どれほどのケース種類数、利用量で使われるのか。

3.オペレーションキャパシティ

• イレギュラーケースや問い合わせ対応が発生する場合に現在の組織はそれに対応しきれるか。

4.ブランドイメージ

• 顧客はどの程度の品質でその機能がリリースされることを自社に期待しているか。 また、それにより失望をしないか。

5.組織事情

• フェーズ1,2,3として分けたことにより最小化したその機能のフェーズ1のリリース後、フェーズ2を実装する時期はいつ頃になるのか。
• そのリソースは確かに確保されるのか。

6.機能の発展的展開

• その機能のリリース以降に展開される機能やプロダクトを鑑みた時に、想定してるユースケースや仕様は十分と言えるのか。
• 技術的負債化する可能性はないか。

スコープコントロールの正確さを担保するためのアクション

• 上記観点をもとにしたディスカッションはもちろん有用な行動ではある。
• しかし、PdMはもっとアクションドリブンであるべきだ。
• 具体的にはいくつか手法がある。

1.リサーチ

• ユーザーヒアリング、インタビュー、プロトタイプでの社内テスト、類似事業者との情報交換

2.デザイン

• 論理的に机上で考えられるリスクは、デザインや伝え方、システム設計などで解決される場合も多々ある。
• そのため、スコープやスペックの確定前の段階でエンジニアやデザイナーにもアイデアを募るプロセスが取れると有用的である。

3.シミュレーション

• あえてリサーチと分けている。
• トラフィックの推移や機能の発展的展開を時間軸に沿って定量的にも整理するべきであり、プロダクト戦略のストーリーとして接続性が担保されているかを確認するプロセスはとても有用である。
• この際にリリースするスペックの選択肢が複数あれば、それぞれの場合の影響をシミュレーションできると望ましい。

終わりに

以上。PdMの日常的な業務ではなく、抽象的で重要な役割について言語化した。

日本においては要件定義や工程管理をしている人間をそのままプロダクトマネージャーと呼ぶ風潮があるがそれでは不十分であると思い、この記事を言語化した。

読んでくれた人がプロダクトや組織に良い変革をもたらすためのきっかけになれれば幸いです。