Zenn
🐕

プロダクトマネージャーの業務リスト（PdMの存在理由、責務、具体的なアクション）※随時更新

に公開
プロダクトマネージャー
pdm
Product management
idea

PdM がなぜ存在すべきなのか（Why）、何をすべきなのか（What）、どのようにすべきなのか（How）を軸に PdM の業務リストをまとめます。本ドキュメントは以下のような目的で作成します

  • 業務改善
    • PdM業務のリスト化を通じて、自身の改善余地を発見し、業務に活かします
  • 自己紹介
    • PdM経験の棚卸し・体系化を通じて、筆者の名刺っぽいものを作成します

自己紹介

舩尾（@ofunaaaaa）といいます。音楽と旅行が好きで、好きなバンドを追いかけて遠征し、ついでに旅行も楽しむというのが最近の満足度の高いお金の使い方です。
サービス企画や開発は昔から好きで大学生の頃から closedcafe.com みたいなサービス作りを続けてきていて、今も気の良い同期とサービス開発を続けています。

職務経歴は以下のような形です

  • 2017/04
    • 大手のIT企業に新卒として入社し、データ関連の部署に配属
    • 社内の分析ツール立ち上げにフロントエンドエンジニアとして参加
  • 2020/04
    • 同プロダクト内でロガーSDK開発業務（JS, iOS, Android）にスライド
    • 3人チームのリードとして新機能の開発・テスト / 関連ツールの開発 / 保守を実施
  • 2022/03 ~
    • 同プロダクト内でPO, PdMとしてマネジメント業務にスライド
    • 14人のチームを率いてサービス保守 ~ 新企画まで実施
    • ユーザー満足度（NPS）を -36.0（22H1） から -19.6（24H2）へと改善することができました（24H2のNPS回答者数: 350人弱）

会社以外では副業としてiOSアプリの開発なども実施していました。今はPdMとして経験を積みたいので、もしPdMの副業案件いただけるようでしたらXにDMいただけると嬉しいです

PdMの存在理由（Why）

まずはPdMの存在理由（Why）を考えていきます。常に「Why（≒ゴール）」を考えることで間違った方向に進んでいないか、目的と手段を取り違えていないか、世の中や組織に価値を提供できているかを確認することが出来ると思っています
本資料を作成するにあたり方向性を間違えないために、まずはなぜPdMが存在しているのか、なぜPdMが組織内に必要なのかを検討していきましょう。

（以下で語るのはあくまでも一般論としての Why です。個別具体の組織内でのWhy（≒期待値）は上長や周囲のメンバーとすり合わせを行う必要があります）

PdMの存在理由はシンプルに言えば 「顧客ニーズに応えられる商品を継続的に提供するため」 です

さらに解像度を上げると 「組織には顧客ニーズに応えられる商品を継続的に提供したいというニーズがあり、そのニーズに応えるために必要なアクションループの "質とスピード" を高い水準で保つために専門的な人間を配置することが必要なはず」 という仮説が組織内にあるからです

上記の考えに至るロジックは以下の通りです

  • 企業として実現したいこと（≒ Want）は利益の最大化 もしくは、社会課題の解決
  • 企業の Want を継続的に叶えるには、顧客ニーズに応えられる商品（≒ 売れる商品）の作成と継続的な提供が必要
  • 売れる商品を作るフェーズ（PMF以前）でも、継続的に提供するフェーズ（PMF以後）でも、必要なアクションは「情報整理（Summarize） & 計画立案（Plan）」し、「実行（Execute）」するというSPEループを回すこと
  • SPEループには「質」と「スピード」という指標があり、2つの指標はいかに顧客ニーズに応えられるためのアクションができているかを指します
  • この「質」と「スピード」という指標を担保・改善するための How が山ほどあります
  • 社長や開発者が兼業することも可能ですが、専門的な人間を配置することで「質」と「スピード」を高い水準に保つことできるはず

という仮説のもと PdM は配置されていると自分は思っています。

※「SPEループ」という言葉は自分が作った造語なので外で話しても通じないのでご注意ください！スペループと名付けました。

PdM の責務（What）

アクション

PdMの存在理由（Why）の検討したことで、自然と PdM がすべきこと（≒ What）が「SPEループの運用と改善」であるという整理がつきました。
それぞれの詳細についても記載しておきます。

  • Summarize: 情報整理
    • 計画立案に必要な情報（リスク・ニーズ・コスト・課題）を収集し、使いやすいように整理するフェーズです
    • 情報整理をする目的は、プロダクトを取り巻く短期 ~ 長期の情報を集め、適切な優先度をつけられる状態にすることです
    • 情報整理と計画立案は行ったり来たりしながら確度を上げていきます
  • Plan: 計画立案
    • 整理した情報を元に次に取り組む課題の選定と完了条件を定めるフェーズです
    • 計画立案をする目的は、どんな目的のために、何に取り組むべきか、どの状態になったら完了かを定め、実行時に集中できる状態にすることです
  • Execute: 実行
    • 立案した計画を自分、またはチームで実施するフェーズです
    • 実行する目的は、立てた計画を遂行し、目的を達成した状態にすることです

スコープ

一般にPdMに期待されているスコープは「戦略策定 ~ マーケティング」です。
戦略を決めて、開発し、ユーザーに届けるまでが責務です。

  • 戦略策定
    • 市場調査、競合分析、ユーザーニーズの把握、リスク管理、プロダクトビジョンの定義、ロードマップ作成
  • 開発
    • 開発チームとの連携、要件定義、進捗管理、品質管理
  • マーケティング
    • マーケティング戦略の立案、集客、セールス

PdM の具体アクション（How）

「SPEループの運用と改善」のために以下の 3x3 のカテゴリで PdM に必要なアクションを定義します

  • Summarize（情報整理） & Plan（計画立案）
  • Execute（実行）

x

  • 戦略策定
  • 開発
  • マーケティング

戦略策定

Summarize: 情報整理

存在意義の把握

プロダクトが何のために存在するのかを確認します
解決する課題、課題の難易度、課題の解決方法などを深掘りし、Mission, Vision, Value の作成に繋げます

  • 存在意義の把握
    • なぜなぜ分析
      • 解決する課題は？ から掘っていく
      • 課題はなぜなくならない？ から掘っていく
      • 課題解決にこのプロダクトが適している理由は？ から掘っていく

リスクの把握

リスクケアの対応は最も優先度の高い割り込み案件です
割り込みが発生する可能性を把握し、計画的に対応することで、継続的なユーザー価値提供を実現します

  • プロダクトクローズ・停止リスクの把握
    • 法的リスク（個人情報保護法・GDPR等の違反、ライセンス違反（OSS含む）など法務確認）
    • 運営ポリシー変更リスク（上位組織によるクローズ判断、サービス統廃合などの情報収集）
    • 依存リスク（依存PF, 外部API, 提携先, 業務委託先のリスト化と情報収集）
    • セキュリティリスク（脆弱性検知の仕組み導入、不正検知の仕組み導入）
    • 単一障害点リスク（冗長化できていないシステムのリスト化と計画的な対応）
  • プロジェクト中断リスクの把握
    • 期限付き案件の把握
      • 言語, フレームワークのEOL
      • 依存PFのマイグレーション依頼
      • OSのバージョンアップ
      • 全社的な取り組み・宿題
      • OSSの脆弱性対応
    • リソース的リスク
      • キーパーソンの離脱や異動（属人化問題）
      • 業務委託先の契約終了
    • コスト的リスク
      • 想定以上の開発・運用コスト増大
      • 顧客要望の大幅変更
      • 工数膨張

チャンスの把握・整理

どんな勝ち筋があるかを把握することで、ROIの高い意思決定やリソース配分の最適化を実現します。集めた情報を使いやすく整理することで、質の高い意思決定を、早い速度で実行できる環境を作ります

順番としては外部環境から内部環境へと情報を集め、勝ち筋の整理を行なっていきます。（全部一気にやるってよりは、直近の仕事を進めながら、必要なものから、地道に作っていきましょう・・！）

  • 外部環境: マクロ分析（PEST分析）
  • 外部環境: ミクロ分析（5Forces分析）
  • 外部環境: 競合分析（競合リスト作成、競合の新機能一覧）
  • 内部環境: ユーザー定性分析（NPS, アンケート, インタビュー）
  • 内部環境: ユーザー定量分析（KGI, KPI, KSF分析）
  • 内部環境: コスト分析
  • 内部環境: 流入・流出分析（アクセス分析, GA4分析, Clarity分析）
  • 内部環境: 競争優位性分析（VRIO分析）
  • 内部環境: 組織内の期待値把握
  • 内部環境: 改善案リスト作成（競合分析, ユーザー要望, 企画会議）
  • 勝ち筋の整理（SWOT分析, クロスSWOT分析）
  • 勝ち筋の整理（STP分析）

Plan: 計画立案

情報整理によって集まった存在意義、リスク、勝ち筋を参考に、チームが集中するための短期 ~ 中長期的な目標を設定します。

  • 中長期: Mission, Vision, Value, NotToDo の策定
  • 中長期: ロードマップの策定
  • 短期: 半期の目標設定
    • マイルストーン目標の決定
    • ユーザー価値目標の決定
    • コスト削減目標の決定
    • 達成後の姿の設定
  • 目標についてのレビュー会実施（チーム・上位組織）

Execute: 実行

立てた計画を実行に移すために情報を流通させ、周囲とコミュニケーションを取ります。
また立てた計画を実行するためのチーム運用を実施します

  • 情報流通
    • 上位組織の承認
    • チームメンバーへの浸透
    • 他チームへの共有
  • 実行するチーム運用
    • チームビルディング
      • スキルマップ作成
      • 案件サイズへのチーム分割
      • 企画会議
      • 「HRT / 有害な振る舞い」の浸透
      • 「Yes And > Yes But >>> No XX」的コミュニケーションの浸透
      • 「打率の話（ 1/1 より 2/10 が偉い）」の浸透
    • 進捗確認
      • 2週間ごとの目標設定
      • 朝会
      • 毎朝一言投稿するSlackチャンネル運用
    • 課題解決
      • 朝会後の相談タイム
      • ハドルの推奨
      • 投稿ハードルの低いSlackチャンネル運用
    • 情報収集
      • メンバーと1on1
      • 割り込み案件の追加ルール
      • リリーススケジュール表の作成
    • 生産性改善
      • KPT振り返り
      • 生成AIを活用した業務改善会
    • 情報流通
      • アーキテクチャ図の作成
      • PRDの作成
      • MTG内容のドキュメント化（生成AI）

開発

Summarize: 情報整理

PoCや設計書作成に必要なイメージを共有するための情報を整理します

  • 企画書の作成
    • 「概要、概要（画像）、解決する課題、解決方法、ユーザー価値、いま実施すべき理由、MVVとの整合性、完了までのステップ、初期コスト、運用コスト、リスク、完了条件、KPI、関係者」を記載する

Plan: 計画立案

Execute: 実行

  • PoC
    • 実現可能性の検証
      • 実現可能なことが分かりきっているものは省略化
    • 価値の検証
    • 事業性の検証
      • 提供コスト
      • 工数見積もり
  • デザイン
    • プロトタイプ作成 / レビュー
      • 修正内容が期待通りのUI/UXになっているか、余計な手間が増えていないかを検証する
    • A/Bテスト案作成
  • 開発
    • XX駆動開発の導入（デフォルトはチケット駆動開発）
    • コードレビュー
      • 生成AIによる一次レビューを入れると生産性が向上する
    • ビルド
      • CI/CDによる自動化をすると生産性が向上する
  • テスト
    • 単体テスト
      • 予期せぬ箇所にデグレが発生していないことをテストコードで担保する
    • 結合テスト
      • 修正範囲が期待通り動作するかを検証する
    • 数値テスト
      • 数値を扱うプロダクトである場合、テストケースを作成し、数値誤差がないことを検証する
    • リリース前の全件テスト
      • 本番環境でも正常に動作するか、予期せぬ箇所にデグレが発生していないかを本番同等環境にて検証する
  • リリース
    • カナリアリリース

マーケティング

Summarize: 情報整理

  • STP分析
    • セグメンテーション
      • 顧客や市場を特徴ごとに分類するプロセス
      • 主な切り口：地理的、人口統計的、心理的、行動的
      • アプローチ方法
          1. 目的の決定
          1. データの収集・整備
          1. クラスタリング
          • 前処理
            • 特徴抽出・次元圧縮（PCA, t-SNE/UMAP）
          • クラスタリング
            • K-means: セグメント数が明確
            • 階層: 全体を把握したい
            • DBSCAN: 外れ値が多い
          1. ラベリング
          • 人力で名付ける
          • 生成AIにクラスタリングのラベル付と説明を求める
    • ターゲティング
      • セグメントの中から最も魅力的な市場を選定し、リソースの配分を決めるプロセス
      • 分類
        • 無差別型マーケティング: 全てのセグメントに同じマーケティング
        • 差別型マーケティング: 各セグメントに異なるマーケティング
        • 集中型マーケティング: 特定のセグメントのみに集中してマーケティング
    • ポジショニング
      • 選定したターゲット市場に対し、競合と差別化された位置づけを行うプロセス
      • 実施内容
        • 4P分析: Product（製品） Price（価格）, Place（場所）, Promotion（プロモーション）
        • 4C分析: Customer（顧客の視点）, Cost（顧客にとってのコスト）, Convenience（購入の利便性）, Communication（双方向コミュニケーション）
        • ポジショニングステートメントの作成
          • 例）「〇〇なニーズを持つ××に対して、△△という価値を提供し、◇◇と差別化します。」
  • ダブルファネル分析の数値
    • 流入分析
      • GA4分析
      • 広告分析
      • SEO分析
      • ABテスト分析
    • 離脱分析（CVR分析）
      • GA4分析
      • Clarity分析
      • ABテスト分析

Plan: 計画立案

  • STP, 4P, 4C分析による戦略の構築
  • ダブルファネル分析による改善計画

Execute: 実行

  • ダブルファネル分析のフェーズごとの打ち手を実行
    • 認知
      • プレスリリース, SNS, 広告（Web・マスメディア・ペイドメディア）, オウンドメディア, イベント（展示会・セミナー・スポンサー）, SEO, アフィリエイト（代理店販売含む）, 営業（飛び込み営業・テレアポ・DM）, 紹介
    • 興味
      • コピーライティング, コンセプト（魅せ方・切り口）, デザイン, ホワイトペーパー, コーポレートサイト, サービスサイト, メルマガ, 事例, ユーザーの声, リターゲティング広告, セミナー, オウンドメディア, SNS
    • 意思決定
      • 機能表, 料金設定, 無料トライアル, デモ, 権威性（メディア掲載実績・導入数・大手導入実績・上場の有無・セキュリティ・市場シェア・表彰実績）, 事例紹介, ユーザーの声
    • 購買
      • サポート体制, 営業, 無料キャンペーン, 割引キャンペーン, 広告 / LP連動, ポップアップ, CTA設計, CTAの改善, 商品詳細ページ, フォーム最適化, KVの改善, コピーの改善, 事例紹介, ユーザーの声

（後半は後ほど記述）

参照: BtoBマーケティングの打ち手一覧

おわりに

ずっとやりたかったんですがこの土日にやっとPdMの業務リストを書き出すことができました。
業務量が可視化されるとPdMという職種が専業化される理由もわかります。

まだまだチームメンバーの皆さんに迷惑をかけつつ、助けてもらいながら運営できている状態ですが、この業務リストをベースに改善、省略、追加したりしながら、徐々に質の高いPdMを目指していきたいと思います。

PdMにこだわって書いてきましたが「顧客ニーズに応えられる商品を継続的に提供」出来ることが重要だと思うので、PdMのスコープは認識しておきつつ、結果を出すために必要な範囲には染み出しながらキャリアを作っていけたらと思います。

もっといい手法があるよとか、この観点が抜けてるんじゃない？などあればコメントいただければと思います。

Discussion