PdM職の細分化 3つのロール
これはなにか
Product Manager Advent Calendar 2018の16日目の記事です
この記事は、定義が曖昧なPdMという職種の役割を、構造的に分解した記事である。
ソフトウェアエンジニアに様々なサブカテゴリーがあるように、PdMも細分化されたサブカテゴリーがあると考えており、本記事ではPdMのサブカテゴリーを構造的に分解する。
なお、ハード面への言及に限定し、リーダーシップなどソフト面については扱わない。
誰に向けたものか
この記事はこんな方に読んでもらうことを想定している。
- PdMらしき仕事をはじめた駆け出しの企画職
- PdMを育成する立場になった新任マネジャー
- 役割に合うPdMが採りたい採用担当者
解決したいことと目的
この記事では、職種としての全体像が不透明なことに由来する、下記を解決することを目的としている。
- PdMという職種にどんな方向性があるかわからなく、将来設計やキャリアの指針が定まらない
- いまの業務が全体のどこに位置するかわからなく、徒労感がつのる
前置きが長くなったが、本編に入る。
PdM職のロールマップ
PdMをロール別に3つのサブカテゴリーに分解し、企画のバリューチェーンの上流から下流までマッピングすると、下記の図のようになる。
また、ここでは企画に関連する他専門職種についても、その相対的な位置を示している。
ロールは3種あり、詳細は次項目以降で詳述する。
企画のバリューチェーンは、調査分析〜リリースするまで、企画の流れを上から下にマップしたものである。
また、企画のバリューチェーンについては下記の記事に詳しく書いている。興味のある方はこちらからどうぞ。
また、役割を便宜上3つの職種ラインに分けているが、実際の現場では複数の役割を兼ねて働くことのほうが多いため、一人のPdMが必ずしも一つの役割しか持たないというわけではない。
PdMの3つのロール
ここからは、前出の図に則って、PdMの3つのロールについて詳述する。
機能プランナー | Feature Planner
このロールは新規機能の追加、既存機能の改善、など機能を企画する役割だ。
新規アプリの立ち上げもこのロールに含まれる。 PdMといって、真っ先に思い浮かぶのはこの役割だろう。
具体的には、ユーザーの課題やニーズを捉え、その課題やニーズに対して、適切な解法として機能を考えて、ユーザーに届けるところを担う。
アプリ内マーケター | In-App Marketer
このロールはサービス内でのキャンペーンやコミュニケーション設計を企画・実行する役割だ。
具体的には、ポイント配布キャンペーンやセール等のインセンティブキャンペーンや、Push通知やお知らせ配信などのノンインセンティブコミュニケーションを中心として、ユーザーセグメントに応じた適切なコミュニケーションを図ることを担う。
コンテンツマネジャー | Contents Manager
このロールはサービス内のコンテンツを更新、拡充させていくことを担う役割だ。
具体的には、オウンドメディアの運営や、メディアであれば記事の編集、動画系サービスであれば番組企画などを担う。 ECサイトでのトレンドランキングやメルマガ運営や、CGM系のサービスであれば、コンテンツを投稿してもらうためのトピック運営などもここに該当する。
3つのロールと企画工程によるタスクマップ
ここまで、ロールマップの説明を展開してきたが、これらの理解をベースにもう一歩、構造化を進める。
PdMの業務は3つのロール x 企画工程でマッピングすることができる。（※図内の①〜⑨はイメージを掴むための一例である）
企画工程はシンプル化するために3つにまとめているが、任意の切り方で捉えて構わない。
そして、このマッピングを利用して、下記の3点を考えることができる。
- [過去]これまでの業務経験は、マップのどこを埋めるものだったのか？
- [現在]いま取り組んでいる業務は、マップのどこに当てはまるのか？
- [未来]これからどんな業務を選択し、マップのどこを埋めたいのか？
今後どういった方向を目指すのかを考えた上で、このタスクマップを使うことで、これまでの経験を棚卸しし、いまの業務に意味を与え、今後の業務選択の指針を作ることができる。
こういった整理により、曖昧で見通しの立ちにくいキャリアイメージを構造的に捉えることができるのではないかと思う。
キャリアパスのあり方
最後にほんの一例に過ぎないが、キャリアパスについてまとめる。 上述のPdMの3つのロールでの経験を積んでいくと、掛け合わせで新たなキャリアパスが見えてくる。
1/ グロースハッカー | Growth Hacker
上記の分類に従えば、アプリ内マーケターとしての経験および、機能プランナー、コンテンツマネジャーとしての企画設計の経験が必要なキャリアであろう。 加えて、ユーザー獲得マーケティングの経験もあると立体的に業務が遂行できるだろう。
2/ UXデザイナー | UX Designer
機能プランナーを経て、定性調査への適正や興味が強くある場合、ユーザーニーズを紐解き、それを実現する設計に注力するためにUX Designerになるという道がある。 ユーザー体験を作るために、インターフェース設計が必要になる場面が多いので、ユーザーインターフェース(UI)への深い理解と経験も必要になる。
3/ プロダクトオーナー | Product Owner
プロダクトのすべてを司る "Mini-CEO"としての役割である。 プロダクトによって必要度合いの濃淡はあれど、このキャリアのためには、前述のPdMの3ロール全領域に精通する必要があるだろう。 またそれだけではなく、オペレーション構築・最適化、事業計画・会計、組織開発・採用等も重要なため、それらの知識と経験も同時に必要になる。
まとめ
エンジニア、デザイナー、会計、マーケティング、リーガルなど他職種は学問として存在するが、PdMには学問が存在せず、俯瞰して体系的に全体像を学ぶ機会は少ない。
私自身が暗闇の中を進む中で、手探りで描いてきた地図であるが、だれかの役に立つと幸いである。
プロジェクトマネジャーからプロダクトマネジャーへの転向に必要な3つの変化
これはなにか
本記事はプロジェクトマネジャーがプロダクトマネジャーに転向する際におさえるべき重要な点をまとめたものだ。
私自身、プロジェクトマネジャーからプロダクトマネジャーへと転向しているが、その際にいくつか重要なポイントが存在した。 この記事が、同じようにプロジェクトマネジャーからプロダクトマネジャーへ変わったばかりの方や、これから転向しようと思っている方の助けになれば幸いだ。
以降、プロジェクトマネジャーをPjM、プロダクトマネジャーをPdMと略称表記する。
PdM は PjMの延長線上にはない
字面が似ているせいか、「PdMはPjMの延長線上にある」と考えている方も一定数いると思う。（私自身そう思っていた）
しかし、そうではない。
共通する部分はあるが、PjMとPdMでは、それぞれの役割に求められるものが異なるため、転向する場合、3つのポイントについて大きく認識を改める必要がある。
- 実行の担保 → 結果の担保
- 管理・調整 → 方針・意思決定
- 開発現場視点 → ユーザー視点
まずは、議論の土台となる、PjMとPdMそれぞれの役割について記述し、のちに各ポイントについて詳述する。
PjMの役割と主な業務
役割
PjMは割り当てられたリソースで期日までにアウトプットを出すことにコミットする役割である。 よって、プロジェクトの進行上の課題に対してのアクションがメインになる。
たとえば、新規プロダクトと運用プロダクトでは下記のようなミッションを持つことになる。
- 新規: プロダクトを期日までにリリースすることに責任を持つ
- 運用: プロダクト改善施策を期日までにリリースすることに責任を持つ
主な業務
PjMの主な業務としては下記が挙げられる。進行の管理および調整ごとの占める割合が多い。
PdMの役割と主な業務
役割
一方、PdMの役割は、プロダクトが生み出す成果にフォーカスしている。 プロダクトをリリースした先にある「成功」を担保する役割である。
当然、一口に「成功」と言っても、定義がなければ判断がつかないため、「なにが成功であるか」を定義することも重要な役割の一つである。
例えば、新規プロダクトと運用プロダクトでは下記のようなミッションを持つ。
- 新規: プロダクトがPMFに到達することに責任をもつ
- 運用: プロダクト改善施策により目標KPIを達成することに責任を持つ
主な業務
よって主となる業務としては、方針決定・意思決定が中心になる。 また、意思決定を行うにあたり、必要な情報を集めるための分析も広義として当てはまる。
- 戦略方針の決定
- 仕様の策定
- 分析・振り返り
3つのポイント
前置きが長くなったが、ここからPjM → PdMに転身する際の3つのポイントについて詳述する。
実行の担保 → 結果の担保
5W1Hでたとえるなら、When, HowからWhat, Whyへの視点の変更である。
PjMは担当しているプロジェクトを期限内(When)に限られたリソースで(How)させることに責任がある。 一方PdMは担当プロダクトの成長に責任があるため、実行だけでは役割を果たせない。
実行レベルから業務領域をストレッチして、実行の前段階に存在する、なにをやるのか(What)、そしてそれはなぜか(Why)を明確にしなければならない。 また、最後にその結果がどうであったのかを分析により確認し、次のWhat, Whyにつなげていく。
管理・調整 → 方針・意思決定
上記の責任領域の変更に伴い、帳尻を合わせや整理からロードマップ作成、製品仕様の意思決定にウェイトをよせる必要がある。
PjMであれば、進行に問題が合った場合に、仕様のスコープ削減を提案したり、リソースを要求するなど、整合性が取れない部分の最終意思決定をエスカレーションできる。
一方でPdMになると、そのエスカレーションを受けて、意思決定を行う側になり、理想と現実のギャップに対して、最終的な結果責任を引き受ける役割を担う。
開発現場視点 → ユーザー視点
PdMはより視点をユーザーにフォーカスさせる必要がある
PjMの視点では、いかに期待された機能を、期待された期日に出すかという視点になるため、最終的には期待値を調整することで整合性を保つことができる。（ ex. 仕様のスコープを削ってもらう、リソースを追加してもらう、期限を延ばしてもらう）
よって、要求仕様とリソースがマッチしない場合に、収めることを優先して考えるインセンティブが働きやすい。
一方、PdMの視点では、ユーザーに届ける価値が全てとなるので、開発している機能の中心的な価値がなにかを見極め、仕様削減や必要に応じたリリース延期等の意思決定を行う必要がある。 「収めること」ではなく「どんな価値を届けるか」にフォーカスする必要がある。
PjM から PdMになるには
ではPjMからPdMになるには、具体的にはどうしたらよいのか？
主に3つのパターンがある。
- 1) 急拡大中の組織に入る
- 2) 新規立ち上げの組織に入る
- 3) 既存のチーム内で転向させてもらう
1) 急拡大中の組織に入る
急拡大中の組織では、関わる人が増えていく中で、ステークホルダーをまとめ上げながら、実行を推進する力が重宝されるタイミングがある。
また、業績がよく、急拡大している組織であれば、やることが山程ある状態が想定されるので、ポジションへのニーズが強い可能性がある。
2) 新規立ち上げの組織に入る
設立間もないスタートアップ等の組織の場合、人材ニーズによっては近接領域であるPjMからPdMへ転向するチャンスが開ける可能性がある。
採用力のある組織の場合は、PdM経験のある人が採用できてしまうため望みは薄いが、一般的なスタートアップであれば道はあるはずだ。
3) 既存のチーム内で転向させてもらう
自社内や既存チームであれば、PjM業務で組織内の信頼・評価を重ねることで、チャンスを掴める。
所属する組織のカルチャーにもよるが、可能であればこの選択肢が一番無難とも言える。 なぜなら組織内評価を引き継ぐことができ、これまでのステークホルダーとの関係値をもとに成果を上げやすい状態で始めることができるからである。
まとめ
PjMとPdMは似ているようで、実は全く異なる役割を担っており、転向する際には大きな視点の変更が強いられる。
また、PdMはPjMの延長線上にはないため、転向を目指す場合は戦略的に行動を起こす必要があるといえる。
企画の議論が噛み合わなくなる4つの要因
これはなにか
企画会議などで施策の議論を行う際に、議論が噛み合わないことの要因を4つにまとめたものである。
上長、メンバー、メンター、メンティー、同僚、他部署など、バックグラウンドや立場が異なる人と議論をする際に「なぜそういう結論になるのか？」「そうですね…（話が全然伝わらない）」といったような議論が噛み合わない瞬間が発生しうる。そういった状況の背景に、なにが潜んでいるかを分解した。
PMという職種は他職種に比べて、業務に占めるコミュニケーションの割合が多くなる。この分解が今後の議論に役立てば幸いだ。
議論が噛み合わなくなる4つの要因
『議論が噛み合わない』とはなにか
通常、議論は参加者の主張から始まり、反駁を通じて論理を積み上げて、最終的にひとつの結論にたどり着く、という形で終了する。
ところが、論理的に積み上げていっても、収束せずに、お互いの主張が平行線のままで、結論に到達しないケースがある。 そのような場合、どちらか妥協をするか、次回の議題として解決しないまま終了をするということになる。
議論が噛み合わない要因
論理的な思考能力を持ち合わせているはずの、大の大人が複数人もあつまって、なぜこのような結末になるのか。
それは下記の4つの要因のどれか、ないしは複数が、その議論に当てはまっているからである。
今回は、議論が噛み合わなくなる要因を、『議論を開始する前後』x『知識・理解』という2軸をもとに、下記の4つに分類した。
- 前提条件の違い
- 事例知識の違い
- 立場・目線の違い
- 解釈の違い
以降、議論のすれ違いを生む、4つの違いについて詳述する。
前提条件の違い
議論の前提となる基礎情報を指す。
例えば、機能開発の議論であれば、解決すべき課題や、当該プロジェクトに掛けることができる期間や、投資できるコストなどがこれに当たる。
議論を始める前から決まっているものであり、議論の出発点、土台であるため、議論を始める前にすり合わせておきたい要素である。
事例知識の違い
過去事例や競合事例などの知識の量の差を指す。
これらの知識に差があると、事例知識の乏しい側から見たときに、議論の途中で論理の飛躍があるように感じられることがある。
議論の途中で、隠れた前提として、類似するケースや事例を前提・参考に議論が展開される場合に起こりやすい。
このケースを防ぐには、相手の中での成功体験や、よく使うフレームワークなどを理解することが肝要だ。
立場の違い
立場が違うことで、同じ事象を見ていても注目している要素が異なる場合がある。
例えば、担当者レベルでは会員登録数を見ているが、上長レベルではLTVを重視していて、結局はLTVによった議論が展開される場合などである。
このケースを防ぐには、すり合わせた前提以外にも別の論点が含まれていると感じた時点で、重要論点の整理を行うことが必要である。
解釈の違い
解釈の違いとは、事象の捉えかたの違いを指している。
同じ事象や数値を見ていても、人によって解釈に差が出てくる。
具体的には、ある数値を見たときに、その数値を大きいと見るか、小さいと見るかという違いや、複数のKPI間の重要度に関する見解の差などを指す。
「解釈の違い」以外3つの要因では、「議論の開始前」であるか「知識ベース」であったため、事前の対処ないしは、知識量の増加で対応できた。
しかし、この「解釈の違い」については、物の見方の違いであるため、双方のチューニングが合うまで、どこまでも平行線になる。
※「価値観の違い」や「宗派の違い」とも言い換えることができる
双方のチューニングが合っていない状態においての議論は、最終的に「キメの問題」として処理されるか、お互いの違いを認め、どちらかの歩み寄りによって結論づくことが多く、短期的な解決は難しい。
まとめ
議論が噛み合わない場合は、大抵この4つのに当てはまっている場合がほとんどである。
建設的な議論を行うためには、「解釈の違い」以外の項目について極力事前に差分がなくなるように努めることが重要である。
一方で「解釈の違い」だけが議論の噛み合わなさの原因と言い切れるまで、議論を煮詰めることができていれば、最後はキメの問題として議論を進展させ、意思決定を行うことができるだろう。
PMの志向の3類型
これはなにか
PMが持つ志向を、大きく3つに類型化したものである。
各志向には特徴があり、企画の進行フェーズに沿って、活きるフェーズ、欠けやすい視点、フォローの方法が異なる。
読まれた方が、自分はどんな志向なのかを考えるきっかけになれば幸いである。
PMの志向の3類型
なにを重視し、どういった志向なのかは、ひとりひとり異なる。
それらの志向について、下記の3つの類型に大別した。
- 開発志向
- 体験志向
- マーケティング志向
また、これらの志向は「どういったことに意識が向きやすい状態か」を表しているため、経験を通じて、変化していくものである。
よって、生まれ持った性質を表しているわけではない。
なお、今回は単純化して類型化しているため、一部例外が存在しうる点を、ご了承いただきたい。
以降、3つの志向を詳述する。
開発志向
ものを作っていくプロセスに明るく、開発のプロセスに意識が向きやすい状態を指す。
特徴
元エンジニア、元Webディレクターといったバックグランドを持っている場合が多い。 テーブル構成やスキーマ、APIのレスポンス、などの具体的なイメージを持つことができ、提案することがある。
活きるフェーズ、欠けやすい視点
「解法の選択」や「製品の実装」のフェーズが、その特徴を一番活かせるフェーズである。 また、「価値の検証」のフェーズでも自身で分析を進める力があるケースが多い。
一方、この志向単体だと、どこが課題でなにを解くべきかを決める「課題の選定」や、それをどう伝えていくかを扱う「製品の伝達」の視点が欠けやすい。
欠けやすい視点をフォローするには
データアナリストの協力を仰ぎ、「解くべき課題」を見つける部分を支援してもらうと良い。
データアナリストが存在しないチームの場合は「課題の選定」に強いPMに協力を仰いぐのもよい。
こちらの記事で取り上げたように、「課題の選定」はPMが担保しなければならない要素の中でも、最も重要なもののひとつである。
体験志向
ユーザーがどういった体験を得るかにフォーカスしやすい状態を指す。
特徴
ユーザーがなにに課題を感じていて、それをどう解決するか、ということが意識の中心にある。
ユーザーがその機能を必要とする背景から、その機能を触れるまでの流れ、および触れたあとの行動・感情の変化までの一連のストーリーを考える視点を持つ。
デザイナーとしてのバックグラウンドや、スタートアップのCEOなどプロダクトオーナーの役割を持っている場合が多い。
活きるフェーズ、欠けやすい視点
「課題の選定」および「解法の選択」に強く、企画の上流工程が、最もその特徴を活かせる。
一方で、この志向単体では、どう作っていくかという視点や、KPIと施策のひも付きを精緻に詰める視点を欠きやすい。
欠けやすい視点をフォローするには
Tech Leadの役割を担ってもらえる開発パートナーを見つけることが最も良いと考える。
Tech Leadというポジションやロールが正式に存在する組織であれば、Tech Leadを頼ると良い。
Tech Leadという役割が存在しない組織であれば、そのプロダクトに詳しく、自領域だけに閉じない視野の広さと、総合的に課題解決にあたれる視座の高さを持つ、開発者を頼るのが良い。
マーケティング志向
どうやってユーザーを動かすのか、ということに意識が向きやすい状態を指す。
特徴
マーケティング業務のバックグラウンドを持っている場合が多い。
ユーザーがなにを欲しているかを把握し、どういった魅せ方伝え方をすることで、ユーザーに行動を起こしてもらうのか、ということに意識が向いている。
活きるフェーズ、欠けやすい視点
その特徴から、「課題の選定」と「製品の伝達」のフェーズが、この志向が最も活きてくるフェーズである。
一方、この志向単体では、体験志向と同じく、どう作っていくかという視点に欠けることが多い。
また、「解法の選択」の面でも、なにを作るかの視点が弱くてインプットが少ない場合がある。
欠けやすい視点をフォローするには
体験志向と同じく、Tech Leadの役割を担ってもらえるパートナーを見つけることである。
また、なにを作るかの視点については、日々のインプットを増やすという中長期的な努力は重ねつつ、短期としては、引き出しの豊富な他のPMにアイデア出しに協力してもらうといった方法でフォローができる。
今後の見通し
組織の規模・状態やチームの体制によってことなるが、個人的には、今後は体験志向がより重要になると考えている。
ユーザーの体験が重視され、Tech Leadという役割の浸透を背景として、PMが解くべき課題を明確に定め、
- なぜ必要か(why)
- なにを作るか(what)
- いつリリースするか(when)
という3点の精度をあげることに集中し、どう作るか(how)については信頼できるパートナーに任せる、という流れが強まるからである。
まとめ
PMの3つの志向について述べてきた。
それぞれの志向において、良い点や欠けがちな視点が存在するが、最終的に重要なのは、チームとして期限内に高いクオリティでアウトプットを上げることなので、周囲に協力を仰ぎ、最終アウトプットを高めれば良い。
また、これらは生まれ持った性質ではないので、意識的に志向を変えて新しい強みを習得することができる。 欠けがちな視点があったとしても、重心の置き方次第で、その視点を身につけることが可能である。
自分の志向を認識し、潮流に合わせてその志向を変えながら、足りない部分は補い合いながら、チームとしてのアウトプットを最大化することが重要である。
企画分析の4象限とPMに必要な分析力
これはなにか
企画にまつわる分析、およびその中でPMに必要な分析の種類についての、私見をまとめたものである。
前回、『「価値の検証」を構成する4つのステップ』で、企画のリリース後の分析についてまとめた。 上記の記事では、事後の分析のみにフォーカスしていたが、この記事にも書いたように、企画の前半のフェーズでも、分析を行うことが多いため、今回は企画のフェーズを横断して、「PMが担う分析」について書く。
また実際に、分析はどこまでやればよいか？どこまでの能力が必要なのか？どの程度のスキルがないといけないのか？といった質問を受けることも多く、その際によく話すことをまとめている。
なお、本記事で想定しているのは、分析担当のメンバーがいるチームを想定している。 よって、分析専任官などいないスタートアップであれば、CEOでもPMでもエンジニアでも強い人を中心に一丸となってやるしかないし、場合によっては分析に時間をかけること自体がが正しくないケースもあるため、本記事はあまり参考にならない。
企画にまつわる分析の4象限
企画にまつわる分析を、「施策実行の前後」、「分析の複雑さ」の2軸で分類する。 2つの軸の判断基準は下記とする。
- 施策実行の前後:
- 前＝「課題の選択」や「解法の選択」フェーズ
- 後＝「価値の検証」フェーズ
- 分析の複雑さ:
- データ抽出の難易度、分析軸の多さ、統計学的知識の必要有無など
「施策実行の前後」を縦軸に、「分析の複雑さ」を横軸に取ると下記の図のようになる。
- 第一象限: 施策前に行う複雑な分析
- 第二象限: 施策前に行うシンプルな分析
- 第三象限: 施策後に行うシンプルな分析
- 第四象限: 施策後に行う複雑な分析
以降、第一象限〜第四象限について、詳述する。
1. 第一象限: 施策前に行う複雑な分析
プロダクト全体の成長戦略を描くような分析や、「nカ年計画」のような、個々の施策を束ねる根幹の戦略を作るための分析がこれにあたる。
また、そこまで規模の大きくないものとして、相関分析やヘルスチェック分析などもこの象限に含まれる。
どちらにせよ、分析を生業に生きてきたプロフェッショナルにお願いするのがベストである。 バックグラウンドが元データアナリストなPMで無い限り、この象限に着手するのは避けたい。
2. 第二象限: 施策前に行うシンプルな分析
簡単なファネル分析や、影響範囲の調査、対象者数の確認など「課題の選択」や「解法の選択」のフェーズで必要なデータの収集が該当する。
例えば、ECサイトで特定の導線の削減を検討している場合に、対象となる導線経由で発生している購入の件数および金額を調べるケースなどである。
また、別の例を上げると、チュートリアルやオンボーディングのフロー改善を行う場合に、各ステップでの離脱率を調べるケースなども該当する。
これらを抽象化すると、企画のおおまかなポテンシャルや、施策の仕様決定を行うためのデータなど、粗くても良いからクイックにデータが必要なケースで行う分析がこの象限にあたる。
そういったケースの場合は、PM自身がクエリを書いたり、BIツールなどを利用して分析ができると良い。 粗くともスピーディーにデータが必要な場面では他者と連携するよりも、さっと自分でデータを出せるほうが早くアウトプットにつながるためである。
3. 第三象限: 施策後に行うシンプルな分析
施策がリリースされてから数時間後、翌日レベルでの速報分析がこの象限に該当する。
リリース直後は、深い洞察や分析でなくともよく、多少粗くともスピードを優先してチームに共有を行うことが大切である。
なぜならば、チームは貴重な時間というリソースを使い、PMの立てた企画を実行に移しており、その結果がポジティブなのかネガティブなのか、またはジャッジにはもう少し時間経過が必要なのかなども含めて、知る権利があるからだ。
この場合も第二象限と同じで、粗くともクイックな分析が求められる。 よって他者に依頼するよりも、PM自身でクイックに分析できたほうが良い。
新しく追加した機能の分析を行う場合など、既存の分析ダッシュボードには当該機能の分析項目が乗っていないことも多くあるため、最低限のクエリやBIツールを駆使する技術を身に着けておくと良い。
4. 第四象限: 施策後に行う複雑な分析
施策をリリースしたあとに、その施策が良かったか、悪かったのかを評価するための本格的な分析である。
具体的には、リフト分析やABテストの分析などがあり、統計的な有意性のジャッジを求められるケースがあり、専門性の強い象限となる。
施策後にその結果の良し悪しを判断するという状況においては、スピードよりも、結論の確からしさや、メッセージの明瞭さが重視されるため、拙速な分析ではいけない。
この領域も分析専門のメンバーにお任せするほうがベターである。
まとめ
PMが関わる範囲での分析について「施策実行の前後」と「分析の複雑さ」という2軸で、4つの象限に分けた。
その中でも、精度以上にスピードが重視される、第二、第三象限のシンプルな分析をPMは扱う必要があり、その程度に合わせて、最低限の分析の技術を身につけておく必要があるだろう。
「価値の検証」を構成する4つのステップ
これはなにか
「企画における5つのフェーズ」のフェーズ5「価値の検証」の進め方をまとめたものである。
フェーズ2「解法の選択」をまとめた『「解法の選択」を構成する4つのステップ』で、「次回は『製品の実装』について取り上げる」と書いたが、開発プロセスやプロジェクト管理フレームワークなどは、すでにわかりやすく有名な書籍が沢山あるため、本ポストではフェーズ5「価値の検証」を取り上げることにした。
今回も、これまでと同様に概要をざっくりまとめる方針で、書き進める。
価値の検証の4つのステップ
価値の検証とは、「企画の結果、当初の課題が仮説に沿って解決されたかを確認すること」である。
この価値の検証は、平たく言い換えると「立てた企画がどれくらい上手くいったかを測る」フェーズであり、以下の4ステップで構成される
- 分析軸の決定
- 初速の共有
- 数字の抽出
- 数字の解釈
以降、1~4を前回と同様に「とあるECサイトの売上をxxxx円増やす」という事例とともに、詳述する。
1. 分析軸の決定
実行した企画が、元の仮説に対して結果を出したことを証明できる指標を考える。
また、このときにポジティブな影響だけでなく、企画によるネガティブな影響がある可能性を考慮して、悪影響の有無を確認できる指標についても考えておく必要がある。
例えば、「とあるECサイトの売上をxxxx円増やす」というミッションを背負ったPMが「商品検索機能の使い方が理解されていない」という仮説に対し、「初回アクセス時に商品検索機能の説明動画をいれる」という解決策を行った場合、下記のような指標が考えられる。
ポジティブな影響が見られうる指標として
- 検索実行者率
- 1ユーザーあたりの検索実行回数
- 検索経由のコンバージョンレート
ネガティブな影響がありえる指標として
- 継続率
- 検索実行者率
この例では、初回アクセス時に動画が再生され、期待していない動画を見せられるという体験から、ユーザーが離脱してしまい、その後戻ってこないというシナリオや、高機能をアピールする動画を見ることで、ユーザーが検索自体を難しいものと感じてしまうというネガティブシナリオを想定して、継続率や検索実行者率をネガティブチェック項目として設けている。
2. 初速の共有
企画がリリースされてから数時間後、1日後、数日後の効果を共有することである。
この時点では、深い洞察や分析でなくともよく、多少荒くともスピードを優先してチームに共有を行うことが大切である。
なぜならば、チームは貴重な時間というリソースを使い、PMの立てた企画を実行に移しており、その結果がポジティブなのかネガティブなのか、またはジャッジにはもう少し時間経過が必要なのかなども含めて、知りたいと思うことが多いからだ。
それゆえに、この時点では、プロダクト全体でデイリーでウォッチしているデータの中で、関連するデータをピックアップして語るだけでも十分である。
SQLクエリが書けない場合でも、初速の共有を疎かにしてはならない。
3. 数字の抽出
ここからは具体的な分析の実作業に入る。大きな組織に所属していて、分析の専門チームがある場合は、1で決定した分析軸をもとに、担当分析官が行うことが多い。
SQLクエリを書いて、データベースからデータを抽出してきてもよいし、TableauやRedashとといったBI(ビジネス・インテリジェンス)ツールから抽出してもよい。 または、スプレッドシートに落とし、ピボット分析をかけるなどして、必要な数字を抽出してもよい。
数字を抽出したあとは、分析の軸やその傾向に合わせて、差分がわかりやすいように、グラフやチャートにビジュアライズしていく。
4. 数字の解釈
抽出してきた数字に対して、良し悪しのジャッジメントをする。
数字自体は客観的なものであるが、その数字をどう解釈するかは、実に主観的な行動である。 そのため、企画の結果としての数字に対して、それが良かったか悪かったかの解釈を加えて、判断を行う必要がある。
例えば、1ユーザーあたりの検索実行回数が10%伸びたとしたときに、その事象を「10%も伸びた」と捉えるのか、 逆に「10%しか伸びなかった」と捉えるのかで意味合いは全く異なる。 また、1ユーザーあたりの検索実行回数が10%伸びたとしても、検索実行率に-5%の悪影響が出ていたとしたら、これらの事象をどういった意味合いで捉え、解釈するのか。
こういった「数字のかたまり」を「意味のかたまり」へ変換していくステップが、この「数字の解釈」のステップである。
まとめ
「価値の検証」フェーズでは、下記4つのステップを通じて、世の中に出した企画が良かったのか悪かったのかのジャッジメントを下す。
- 分析軸の決定
- 初速の共有
- 数字の抽出
- 数字の解釈
課題を選定し、仮説をもとに解決策を見出し、実行を通じて、価値を検証していく、企画の一連の流れの最終フェーズである。
仮に実行した企画の結果が悪かったというジャッジになった場合は、そこからの学びを元に、また課題の選定フェーズや、仮説の設定ステップに立ち戻り、再び企画を立案し、仮説の検証を行っていく。
「解法の選択」を構成する4つのステップ
これはなにか
「企画における5つのフェーズ」のフェーズ2「解法の選択」の進め方をまとめたものである。
フェーズ1「課題の選択」をまとめた『「課題の選択」を構成する3つのステップ』の続編となっているため、前回の記事も合わせてご覧いただきたい。
また、今回もわかりやすさを重視し、基礎的な内容となっているため、シニアなPMは対象読者として想定していない。
解法の選択の4つのステップ
解法の選択とは、「見つけた問の解決方法を決めること」である。
この解法の選択は問が解ける度合い、すなわち「どれくらい数字が伸びるか」を担っている。
- 仮説を立てる
- 解決策を出す
- 評価する
- 検証する
以降、1~4を前回と同様に「とあるECサイトの売上をxxxx円増やす」という事例とともに、詳述する。
1. 仮説を立てる
解くべき問に対して、なぜその課題が発生しているかを考える。
ここでは明確な理由がわかっていない場合でも、仮説として理由を考えて仮置きする。
なぜなら、仮説がない状態でアイデアを考えてしまうと、もし施策が失敗した場合に、仮説に立ち戻る事ができず、適切な振り返りを行うことができなくなるからである。
例えば、解くべき問が「未購入者が新規購入転換する際、会員登録ステップでの離脱を防ぐにはどうしたらよいか？」だった場合、いくつかの仮説があげられる。
- 会員登録時に入力すべき項目が多い
- 会員登録時点で手元にない情報の入力を求めている
- 会員登録の進捗状況が不透明で進める気が失せる
- 画面遷移が多くて離脱の機会が多い
どの仮説が正しいかは、明確にはわからないため、この段階では最も確からしいと思えるものを選択する。
2. 解決策を出す
1で立てた仮説をもとに、アイデアを出すことである。
この段階では、案の良し悪しは構わない。 そのアイデアが良いかどうかは、次のステップで評価するためである。
2つのパターンを列挙する。
2-1. ひらめく
立てた仮説によって、問は解けるサイズまで小さくなっているので、あとは解決策を考える。
シンプルなブレインストーミングからはじめてもいいし、単なる思いつきでも良い。可能性のあるものをあげていく。
2-2. 他サービスから探す
自分で考えてひらめく以外にも、類似のサービスの解決策を見て、自サービスに適応させるという方法もある。
例えば、選んだ仮説が「会員登録の全体でどこまで進んでいるかがわからない」だった場合、他サービスの会員登録フローを研究し、「会員登録フロー内の各ページに進捗を示すゲージを表示する」、という解決策を見出す事ができるかもしれない。
ひらめく場合でも、見つける場合でも、日々の他サービスからのインプットが重要である。
3. 評価する
出てきたアイデアを評価する。
ここでも「課題の選択」時に使用した、フィジビリティとインパクトの掛け算を用いる。 ここでは、出てきたアイデアの中で、問を解ける可能性が最も高いものを見極める。
ポテンシャル x フィジビリティ
- ポテンシャル: 課題を解決できる可能性が最も高い方法はどれか
- フィジビリティ: 現実的に実現の可能性はあるか
4. 検証する
実現可能性が高く、ポテンシャルがある解決策に絞り込めたら、次は仮説と解決策のペアが正しいかを検証する。
それなりのコストを投じて開発を進めるため、不確実性はできる限り下げたい。このステップは、ぶっつけ本番で大規模改修や新機能をリリースし、空振りに終わるという事態を避けるために行われるステップである。
なお、大きな機能改修や、大型の新規機能実装などのケースで必要になるステップであるため、小さな企画であれば省略しても良い。
2つの手法を紹介する。
4-1. スモールテスト
大規模な機能改修や機能追加の小型版をつくり、ユーザーの反応から、立てた仮説と解決策の方向性が正しいことを確認する。
例えば、ECサイトにおいて、商品閲覧数を増やすために、下記の仮説と解決策を考えたとする。
- 仮説: 興味を持ちやすい商品をリコメンドすることで、商品の閲覧数が増える
- 解決策: 商品詳細画面で関連性の強い、別の商品へのリンクを表示する
この場合、まずは特定の商品郡のみを対象として、決まった商品のリンクを表示し、ユーザーの反応を見る。 この検証でポジティブな数字の変化が見られれば、これらの仮説が検証されたことになる。
このように仮説が検証されてから、バックエンドのシステムを作り込み、対象スコープを全商品として、機能を完成させて行くことで、企画の不確実性を下げることができる。
4-2. プロトタイピング
機能を作る前に、ProttやInVisionといったプロトタイピングツールを使い、ユーザーインタビューを通じて反応を確かめる方法である。
これらのツールを使わなくとも、紙に手書きで書いたラフをもとに行う、ペーパープロトタイピングという手法もある。 どちらにせよ重要なことは、実装を始めるまえに仮説や解決策の方向性が正しいかをユーザーに問うことである。
まとめ
「解法の選択」フェーズでは、下記4つのステップを通じて、仮説に基づき解決策を出し、評価・検証を通じて、最良の一手を決めていく。
- 仮説を立てる
- 解決策を出す
- 評価する
- 検証する
企画の中心とも言えるこのフェーズでは、PMは仮説と検証を繰り返し、不確実性を下げながら企画を固めて、ムーンショットを狙っていく。
次回は「選んだ解法」を現実のものにする「製品の実装」フェーズについてポストする。
