「価値の検証」を構成する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は仮説と検証を繰り返し、不確実性を下げながら企画を固めて、ムーンショットを狙っていく。
次回は「選んだ解法」を現実のものにする「製品の実装」フェーズについてポストする。
PMポジションに応募するときの8つのTips
これはなにか
SlackのGroup Product ManagerであるFareed Mosavatがポストしていた、PMのポジションに応募する際のTipsを、本人の許可を得て翻訳したものである。
Once again, I'm in the midst of reading dozens of resumes for a new PM role we just opened. Some advice if you want to try and get a job through the front door without a referral:
— Fareed Mosavat (@far33d) 2018年7月20日
オープンになったばかりのPMポジションへのレジュメの山を読んでいる最中なのだが、もしあなたが、紹介なしに正面玄関からポジションを得ようと思うならいくつかのアドバイスがある。
わかりやすさを優先して一部、語順を変えたり意訳をしたりしているので、正しく理解したい方はぜひ原文を読んでみてほしい。
PMポジションに応募するときの8つのTIips
- 職務内容を理解していることを伝える
- 過去の経験とPM職の関連性を語る
- バズワードや頭字語を使わない
- 過去に「どの指標を何%上げたか」を書く
- 無駄な文を削って簡潔に書く
- 誤字脱字は厳禁
- 奇妙なレイアウトにしない
- キャリアと担当したプロダクトについて語る
以下、原文を引用して紹介する。
1. 職務内容を理解していることを伝える
1) Write a cover letter. A brief introduction that shows you read the job description and specifically applied for this role goes a long way and can be the difference that gets you to the first step.
— Fareed Mosavat (@far33d) 2018年7月20日
1) カバーレターを書こう。あなたが職務内容を読んだうえで、この仕事に応募しているということを、簡潔な導入文で伝えよう。そのポジションへの第一歩をもたらす差別化ポイントになるはずだ。
2. 過去の経験とPM職の関連性を語る
2) If you are making a career change or are just out of school, use to cover letter to bridge between the experience you have and the job you are trying to get.
— Fareed Mosavat (@far33d) 2018年7月20日
2) あなたが新卒か、もしくはキャリアを変えようと思っているのであれば、カバーレターを使って、得ようとしている仕事と自分の過去の経験を結びつけよう。
3. バズワードや頭字語を使わない
3) Unless you are applying for a role in the same industry, don't use buzzwords or unexplained acronyms anywhere in the resume. I have no idea what you are talking about.
— Fareed Mosavat (@far33d) 2018年7月20日
3) あなたが同じ業界のポジションに応募するのではないなら、レジュメの中でバズワードや、説明のない頭字語を使うのをやめよう。何を意味してるのか読み手に伝わらないので。
4. 過去に「どの指標を何%上げたか」を書く
4) IMPACT. Always show impact in each role, ideally in the form "moved metric X by Y%". Try to use industry standard metrics and definitions whenever possible (revenue, users, retention, activation, etc).
— Fareed Mosavat (@far33d) 2018年7月20日
4) インパクト。常にそれぞれのポジションでの成果の大きさを示そう。理想としては「Xという指標をY%伸ばした」といったフォーマットで書くと良い。その際、必ず業界の標準的な指標と定義を使うように。
5. 無駄な文を削って簡潔に書く
5) One of the core requirements for a product manager is clear, concise communication. Have someone review your resume and cover letter. Every sentence should be there for a reason.
— Fareed Mosavat (@far33d) 2018年7月20日
5) プロダクトマネージャーに必要なコア要件のひとつに明確で簡潔なコミュニケーション能力がある。他者にあなたのレジュメとカバーレターを見てもらおう。意味のない文章や無駄な一文があってはいけない。
6. 誤字脱字は厳禁
6) Related to #5, basic spelling and grammatical errors are unacceptable and show a lack of attention to detail. This isn't Twitter!
— Fareed Mosavat (@far33d) 2018年7月20日
6) 5番に関連して、基本的な誤字脱字や文法のミスはいただけない。細部への注意力がないことの証明になってしまう。なによりレジュメはツイッターじゃないからね!
7. 奇妙なレイアウトにしない
7) Don't use weird layouts unless you are really good at graphic design. The typical hiring manager is going through dozens at a time, don't make it hard for me to read!
— Fareed Mosavat (@far33d) 2018年7月20日
7) 奇妙なレイアウトを使うのはやめよう。グラフィックデザインがとても得意なら話は別だが。一般的な採用マネージャーは同時に大量のレジュメを見る。奇妙なレイアウトで、読みにくくしないでほしい。
8. キャリアと担当したプロダクトについて語る
8) Ask yourself if your resume tells the story of your career and the products you've been responsible for.
— Fareed Mosavat (@far33d) 2018年7月20日
8) あなたのレジュメが自分のキャリアと担当してきたプロダクトについて、きちんと説明できているかを自問自答しよう。
まとめ
過去の経験を具体的な数値で、伝わりやすいフォーマットにて簡潔に述べる。 基本的なことではあるけれど、すべての条件をきちんと満たしているレジュメに出会うことは稀である。
また、7番で述べられているように、採用マネージャーは一度に大量のレジュメを見るため、そのなかから自分のレジュメに目をとめてもらわねばならない。
よって、情報の受け手となる採用マネージャーの視点に立ち、読みやすい表現、目にとまりやすい内容で、簡潔に伝えていく工夫が肝要である。
「課題の選択」を構成する3つのステップ
これはなにか
「企画における5つのフェーズ」のフェーズ1「課題の選択」の進め方をまとめたものである。 kyosu-ke.hatenadiary.jp
自分が普段どのように企画を立てているのかを、一度客観的に見てみようと思い、書くことにした。
今回もバリバリのPMの皆様からすれば、至極当たり前のことしか書いていないため、そういった方のお役には立てそうにない。 一方、PMの考えに興味がある他職種の方にとっては、企画の初期フェーズの輪郭がはっきりするかもしれない。
文中には、職種・業界特有の抽象的な概念や横文字も出てくるが、極力具体例を上げてイメージしやすいようにまとめる。
課題の選択の3つのステップ
課題の選択とは、「解くべき問を見つけること」である。
企画の5フェーズの中で最も重要なフェーズであり、「解決したときの伸びしろが最もある課題はなにか」を突き詰めるフェーズである。
- 分解する
- 評価する
- 深掘りする
以降、この1~3について「とあるECサイトの売上をxxxx円増やす」という具体例を用いて、詳述する。
1. 分解する
目標を達成するために、課題を小さく分けていくことである。
分解の方法は2パターンある。これらは順番に行っていく。
1-1. ロジックツリー分解
大きな目標をより小さなブロックに、樹形図状に分けていくである。 例えば「ECサイトの売上をxxxx円増やす」ためには、下記のような式に分解ができる。
このように、売上を増やすという大きな目標を、樹形図にそって、より小さく解きやすそうなブロックに分解する手法を、ロジックツリーと呼ぶ。
1-2. セグメント分解
樹形図状に分解したブロックをさらに、特定の切り口で区分けすることである。
例えば、ECサイトの例のうち、購入者数の部分をセグメント分解してみる。 切り口は「年齢」、「性別」、「購入点数」、「購入金額」「登録後の経過日数」など様々なものが考えられる。
仮に購入点数で考えると、下記のような区分ができる。
- 過去1点もない … 未経験者層
- 1年の購入点数: 0点 … 休眠・離脱層
- 1年の購入点数:1〜3点 … ライト層
- 1年の購入点数:4〜8点 … ミドル層
- 1年の購入点数:8点〜 … ヘビー層
また、区分けする際には、なるべくMECE(モレなくダブりなく)に考えることが重要である。
2. 評価する
「分解する」で区分けしたセグメントのうち、どこが最もポテンシャルがあるかを見極める。その際の評価基準として2つの観点で考える。
ポテンシャル x フィジビリティ
- ポテンシャル: どこに手を打つと最終的な目標への影響が最大化するのか
- フィジビリティ: 現実的に実現の可能性はあるか
つまり、伸びしろが大きくて実際に伸ばせそうなところを選ぶ、ことが重要である。 また、ポテンシャル評価の方法は2パターンあり、どちらか扱いやすいほうを選ぶ。
2-1. 自サービス内ポテンシャル
自分のサービス内の数字を比較し、ポテンシャルを図る考え方である。
例えば、購入経験のないユーザー数と全体のユーザー数を比べると、未経験者率は80%もあり、購入者増加の伸びしろが多いと判断する場合がこれに当たる。
この判断には、データをどう解釈するか、という主観が含まれるため、人によって結論は異なる。
2-2. 対競合ポテンシャル
他サービスとの比較で、ポテンシャルを図る考え方だ。
他社サービスのセグメント分析の結果が手に入る場合、自社のセグメントと他社のセグメントの数値を比較すると、差分によりポテンシャルの把握ができる。
3. 深掘りする
評価を通じて発見した、見込みのあるセグメントに関して、深掘りをして課題を決定する。
深掘りの方法は3パターンある。いずれかの手法で「解くべき問」が見つかればよい。 また、最終的な「解くべき問」の形は「〇〇するにはどうしたらよいか?」という形式になる。
3-1. ファネル分析
特定のアクションに至るまでの、各ステップの突破率を分析する手法である。
例えば、先のECサイトを例で未購入者層が大きく、0⇢1への購入転換にポテンシャルがあると判断し、これを深掘りする場合、ユーザーがサービスにアクセスしてから購入するまでの大きな流れは下記のようになる。
- サービスにアクセスする
- 欲しい商品を見つける
- 商品情報を理解する
- カートに入れるボタンをクリックする
- 会員登録をする
- 配送先を入力する
- クレジットカードの登録をする
- 購入する
このステップごとに、何人のユーザーがアクションを行ったかのデータを収集し、突破率が悪いところをあぶり出す。
例えば、会員登録のステップで突破率が悪いことがわかったとすると、「解くべき問」は「未購入者が新規購入転換する際、会員登録ステップでの離脱を防ぐにはどうしたらよいか?」という問になる。
3-2. 相関分析
2つの異なる指標の相関関係を調べる手法である。
相関関係にある2つの指標は一方が増えれば、他方も増えるため、見込みのあるセグメントの特定のアクションと相関関係にある指標を見つけ、その指標の増加を「解くべき問」とする考え方である。
例えば、「未購入者の購入転換率」と「商品の閲覧数」に相関関係があれば、「解くべき問」は「未購入者により多くの商品を見てもらうにはどうしたらよいか?」という問になる。
しかし、相関分析を行う際は注意が必要であり、相関が見られるからと言って、かならずそこに因果関係があるわけでない。 これを見誤り、「相関の罠」にハマってしまうと、成果の出ない問の立て方となってしまうため注意が必要だ。
「相関の罠」については別の機会に詳述したい。
3-3. インサイト分析
ユーザーインタビューやアンケートなどの手法を使ってインサイト(洞察)を導き、そこから「解くべき問」を抽出する方法である。
ECサイトの例で説明する。 実際に未購入者の会員に対して、メールアンケートで回答を得たり、対面でユーザーインタビューを行い、下記のようにユーザーが最も課題に感じている部分を抽出する。
- 商品が探しにくい
- このECサイトに対する安心感がない
- 会員登録で入力する項目が多すぎる
- 配送料が高い
仮に、このECサイトに対する安心感がない、という点が一番の課題だった場合は、「未購入者がこのECサイトに対して安心感を持てるようになるにはどうしたらよいか?」という問になる。
実際のユーザーから得られる情報は貴重で、ファネル分析や相関分析と合わせて実施すると「解くべき問」がシャープになっていく。
まとめ
「課題の選択」のフェーズでは下記のフローで行われていく。
- 分解する
- 評価する
- 深掘りする
PMそれぞれで企画の立て方、作り方は異なるため、ここで上げたのは、ほんの一例である。 ここで取り上げたフローを踏まずに、アイデアベースで鋭い企画を出し、成果を上げるPMもいるので、画一的である必要はない。
どんな方法で企画を出すにせよ、成果が最大になる「解くべき問を見つけること」が肝要である。
次回は、「解くべき問」を実際に解いていく、「解法の選択」についてポストする。
PMに必要な13の能力とフェーズ別の重要度
これはなにか
これはPMの能力として重要だが定義が曖昧な、PMの能力を類型化して整理したものである。
過去に、採用や能力開発の相談を通じて「PMに必要な能力とは何か」について考える機会がたびたびあり、まとめてあったものを、再編集した。 検討が甘い部分はあるが、PMの採用に携わる方、能力開発を考えている方、またはこれからPMを目指す方に、少しでも役立つと嬉しい。
本記事で取り扱うスコープ
本記事では、なるべく具体的でテクニカルな部分に着目してリストアップしている。
ソフトスキルやマネジメントスキルは職種を通じてある程度共通する要素であるため、本記事のスコープ外とする。 個人的には、テクニカルなスキルよりもソフトスキルのほうが重要な局面が多いと考えるが、それはまた別の機会で扱おうと思う。
具体的な能力
具体的な能力については下記13の能力を4つの枠組みで整理したい。
※チャートのスケールはイメージです
調査・分析系
- 1)課題発見力
- 2)分解・分析力
- 3) ユーザー調査力
着想・発想系
- 4)解決提案力
- 5)他社サービス把握力
- 6)技術トレンド把握力
ビジネス・折衝系
- 7)外部交渉力
- 8)PL設計力
計画・実行系
- 9)戦略立案力
- 10)開発プロセス・技術理解力
- 11)プロジェクト管理力
- 12)調整力
- 13)執着力
上図は、これらの能力を、「企画における5つのフェーズ」の各フェーズごとに重要度でマッピングしたものである。 kyosu-ke.hatenadiary.jp
以下、各系統別に能力を詳述する。
調査・分析系
ここで取り扱う能力は『1. 課題の選択』や『5. 価値の検証』のフェーズで必要となることが多い。
この系統には下記の能力が属する。
1)課題発見力
- 量的・質的情報から課題を発見する力
- データを見て課題を発見できる力
- ユーザビリティテストからの課題発見できる力も含む
2)分解・分析力
- 発見した課題を解決できるサイズのイシューまで分解する力
- 分析を行う上での軸の整理や比較対象の整理ができる力
3) ユーザー調査力
着想・発想系
ここで取り扱う能力は『2. 解法の選択』『3. 製品の実装』『4. 製品の伝達』のフェーズで必要となることが多い。
この系統には下記の能力が属する。
4)解決提案力
- 課題に対して論理的に解決案を出せる力
- アイデア力も含む
5)他社サービス把握力
- 他社のサービスの施策や事例からケーススタディを導き出す力
6)技術トレンド把握力
- 業界の技術トレンドを把握し、自社・自プロダクトが進むべき方向に取り入れる力
ビジネス・折衝系
ここで取り扱う能力は『2. 解法の選択』のフェーズで必要となることが多い。
この系統には下記の能力が属する。
7)外部交渉力
- 外部パートナーとの交渉を適切に進める力
8)PL設計力
- ユニットエコノミクスが成立するように事業の収支を設計できる力
計画・実行系
ここで取り扱う能力は『3. 製品の実装』『4. 製品の伝達』のフェーズで必要となることが多い。
この系統には下記の能力が属する。
9)戦略立案力
- 自社・競合の状況、時系列、トレンドなど複数の情報をもとに、勝ち筋を描き、目標達成のための計画を立てる力
10)開発プロセス・技術理解力
- デザインを含む広義の開発・技術に関する理解の度合い
11)プロジェクト管理力
- プロジェクトリスクの洗い出しと対処を行い、予定通りプロジェクトを進める力
12)調整力
- 組織やチームの中で達成に必要な調整をやりきる力
- リソース調整や優先度調整などコミュニケーションを必要とする複雑な調整が対象
13)執着力
- 目標達成に対して粘り強く取り組む力
- 計画頓挫時のリカバリープランを素早く立て、実行できるかも含む
まとめ
以上、PMに必要な13の能力と企画フェーズごとの重要度をまとめた。
企画のフェーズによって、PMが駆使する能力は異なっており、PMはフェーズごとに役回り立ち回りを変えながらプロジェクトを進めていく必要がある。 一部の能力が他職種によってカバーされているチームの場合や、必要な能力が自身に足りない場合は、他者の協力を得ることで能力を補完し、ミッションを完遂していくことが求められる。
PdMの業務内容と企画における5つのフェーズ
これはなにか
Product Manager(以下、PdM)とはどんな仕事か?についての私見である。
最近、複数の知人から上記を問われることが続いたので、そういったときにポンと渡せるまとめを作ろうと思ったことがきっかけだ。
読者はPM未経験者を想定しているため、すごく初歩的で基本的なことにとどまる。 よって現場でゴリゴリ活躍しているPdM諸兄姉にとっては、得るものが少ないと思う。
「どんな仕事か?」これを説明するために「目的(=ミッション)」と「手段(=業務内容)」にわけて話したい。
PdMのミッションは?
「ユーザーの課題を特定し、解決策を実行し、KPI目標を達成すること」である。 新規プロダクトの立ち上げ、既存プロダクトへの機能追加、UI/UXの改善、CRMなど、PdMが関わる分野は多岐にわたるが基本はどれも同じである。
このミッションを遂行するために、PdMは関係各所と連携しながら業務を進める、プロジェクトのハブ、プロジェクトリードの役割を務める。
PdMの具体的な業務内容は?
ではPdMとは具体的になにをするのか? PdMの業務は企画の進行フェーズに沿って下記のように分類できる。 ただし、開発組織の体制、業界によっては、エンジニアが担う領域も存在する。
企画における5つの進行フェーズ
企画を進行フェーズで区切ると以下の5つに分けられる。
- 1.課題の選択
- 2.解法の選択
- 3.製品の実装
- 4.製品の伝達
- 5.価値の検証
抽象度が高いため、説明とともに、具体例を上げる。
1.課題の選択
ユーザーが抱える複数の課題のうち、どの課題を解決するかを決めるフェーズである。
このフェーズが一番重要だ。ここを間違えると、いくら頑張っても最終的に成果がでないという非常に残念な結果になる。
例えば、あるECサービスで購入者率(※)を増やすために施策を考えるとする。
※購入者率 = 一日の訪問者に占める、購入者の割合
そのときにユーザーが抱えうる課題は、
- そのサービスを知らない
- そのサービスにたどり着けない
- 商品を探しにくい
- 商品を比較検討しにくい
- 希望する支払い方法がない
といった具合に、パッと思い浮かぶだけでも複数ある。 その中で、どの課題が「解決できるサイズの課題」で「解決したときに一番インパクトが大きいか」という観点で考え、解くべき課題を見極めるフェーズである。
ここでの具体的な業務は以下である。
- ユーザーインタビュー
- 公開統計情報を用いた調査結果の収集
- 他サービスの調査
- 仮設の立案
- 行動ログデータの分析
- 主要KPIの分析(推移・比較・割合)
2.解法の選択
「1.課題の選択」で決めた解くべき課題に対して、どうやって解決するかを考えるフェーズである。
ここでは、他サービスでの事例の引き出しや、発想の転換が必要となってくる。
例えば、「商品の比較検討がしにくく、離脱してしまう」を解くべき課題と定めたとする。 そのときの解法は、下記のように複数存在する。
- 商品一覧の画面の情報量を増やす
- 比較検討機能をつける
- お気に入り画面を比較しやすいUIに変更する
- そもそも自サービス内で比較検討をしなくても良い状態を作る
その中で、最も費用対効果がよく、速やかに、より多くのユーザーに向けた解決策になる解法を選択する。 このときの選択の観点は、コスト(工数), リーチ(対象ユーザーの広さ), インパクト(解ける度合い)だ。
ここでの具体的な業務は以下である。
- 他サービス等での類似事例の調査
- サービス企画立案
- 企画のフィジビリティ調査
- 要求仕様の整理
- スケジュール・マイルストーン・ロードマップ策定
- 最低限の仕様への絞り込み
3.製品の実装
「2.解法の選択」で決めた解法を実装していくフェーズである。
PMは全体の進行を管理し、最終的にローンチまで漕ぎつけることに責任を持つ。
エンジニアリング経験や開発プロジェクトマネジメント経験のあるPMはここで強みを発揮する。
ここでの具体的な業務は以下である。
- 要求仕様の共有と認識合わせ
- プロジェクト進行管理
- プロジェクト進行上の課題発見と解決
- チーム外のステークホルダーとの連携と期待値調整
4.製品の伝達
「3.製品の実装」で開発したプロダクトや機能をユーザーに届けるフェーズである。
例えば、比較検討機能を新規機能として追加したとする。 それだけではユーザーは新機能の存在にも気づかないし、ましてや利用しない。
そこで、アプリ内の通知機能などで、ユーザーに新機能が追加されたことを伝え、「比較検討機能を利用するとクーポン付与」など、利用の機会を作る。
ものづくりが好きなPdMはこのフェーズを軽視することがままあるが、製品の実装と同等かそれ以上に重要である。 また、チームによってはPdMではなくマーケティング担当が実行する場合もある。
このフェーズにおける具体的な業務は以下である。
5.価値の検証
「1.課題の選択」で選定した課題が解決され、その結果としてKPI目標が達成できているかを確認するフェーズである。
例えば、新規実装した、比較検討機能の結果を検証する場合、 何人がPUSH通知を開封し、アプリ内の告知文を読み、その中の何人が利用し、その利用率は何%であったのかを分析する。 また、最終的に、KPIである「購入率」が上がったかどうかを検証する。
ここでの具体的な業務は以下である。
- 検証する項目と検証の軸の選定
- リリース直後の速報分析
- 行動ログを用いた各種指標の分析
- 分析チームとの連携
まとめ
PMの業務は下記の5フェーズを通じて、「ユーザーの課題を特定し、解決策を実行し、KPI目標を達成する」ことと言える。
- 1.課題の選択
- 2.解法の選択
- 3.製品の実装
- 4.製品の伝達
- 5.価値の検証
またそれは言い換えると、プロダクトを通じて、自らの仮説を世に問い、検証する作業でもある。
プロダクトを科学し、仮説と検証を繰り返していくPdM業は、とても面白くやりがいのある仕事である。
開設テスト投稿
H1.テスト
* 開設につきテスト
これから投稿していきたい気持ち