「サイバー流！ PMスキル場」連載VOL,3
加納謙吾（かのうけんご）
Amebaマンガ プロダクト責任者
2016年にサイバーエージェント新卒入社。同年株式会社AbemaTVへ出向、開発本部ディレクターとして配属。新機能開発とユーザーのアクティベーション向上に向けたグロース施策を中心に、ABEMAのプロダクト開発全般に従事。その後2021年1月にメディア統括本部へ異動し電子書籍サービス「Amebaマンガ」のプロダクト責任者に就任。現在はプロダクト全体を見つつ主に新規ユーザーの継続率向上にコミット。
連載「サイバー流！ PMスキル場」 サイバーエージェントの各事業のプロダクトを担うPM（プロダクトマネージャー、プロジェクトマネージャー）達が、 「サービスフェーズ×ドメイン」で変化するPMの役割や経験談を語ります。
はじめまして。「Amebaマンガ」という電子書籍サービスでプロダクト責任者をやっています、加納です。
本記事では「組織 / チームへグロース文化をどう定着させるか」というテーマで個人的に考えていることや実践していることについてご紹介させていただきます。
「グロース文化」と言われてもあまりイメージが湧かないと思いますが、主に以下で悩まれている方に向けて本記事を執筆させていただきました。何かしらのヒントになれば幸いです。是非ご一読ください。
本記事の読者ターゲット
● 「チームメンバーが成果に執着している状態」をどう作ればよいか悩んでいる ● 自分の熱がチームに伝わらず一人だけから回ってる状態に悩んでいる ● 全ての施策開発進行において自分がボトルネックになっており、PDCAのスピードが出ず悩んでいる
主導権を持つ功罪
前述した内容について、僕自身もかなり悩んでいました。今でも悩むことがあります。
じゃあなんでこんな悩むんだろう？と考えた結果「自分が主導権持ちすぎてるのでは？」という仮説に行き当たりました。
「自分が施策を決める」「自分が全体のスケジュールを引く」「意思決定は全て自分」などなど…。
その結果チームメンバーが「じゃあ加納が動いてくれるから任せよっと」と考えるようになり、結局前述した困り事が生まれてくるのでは？と。
もちろん、主導権を持ってプロジェクトを前に進める姿勢はとても大事です。
ただ、それが行き過ぎて独りよがりになってしまうと個人にも、チームにも、そして組織全体にも良くない状態です。
この状態になってしまうと、チームで働いている意味がありません。
チームメンバー全員が自分よりも優れたスキルや自分では気付けなかった考え方を持っているはずです。持っている価値観や日頃からインプットしている情報の種類と質は一人ひとり違います。
もしかしたら、ある仮説に対して自分が考えたアイディアとは別の角度で、より洗練されたアイディアを持っている人がいるかもしれません。
もしかしたら、自分で立てたスケジュールよりも2週間早くリリースできる方法を知っている人がいるかもしれません。
だからこそ
- 「チームの能力と集合知をフル活用して事業成果に繋げること」
- 「そのためにチームをどう引き込ませていくかを考え動くこと」
これがPMの最大ミッションだと思っています。
このことに入社したての頃に気付き、今でも念頭に置きながら仕事をしてます。
上述した内容はマネージメント業においてめちゃくちゃ当たり前なことです。
でも、頭では理解できていても実践まで落としきるのって結構難しいと思っています。
なのでこの記事では僕なりに実践していること、考えていることをお伝えさせていただきます。世のため人のためにプロダクト作りに勤しんでいる方の参考になれば幸いです。
チームメンバーが「考えやすい」環境を作る
- 「チームの能力と集合知をフル活用して事業成果に繋げること」
- 「そのためにチームをどう引き込ませていくかを考え動くこと」
上記を具体的に行動に落とす場合、大事なのは『チームメンバーが「考えやすい」環境を作ること』だと考えています。
チームメンバー一人ひとりが持っている創造的なアイディア、さらにいうと価値観や思想を引き出すためには「前提」と「考えるべきお題」が明確になっている必要があります。それら情報が整っていれば、チームメンバーが自発的に行動しやすくなり、経営 / 事業戦略への積極的な参加にも繋がってきます。
ただ、これだけだと「？？？」だと思うので、さらに以下ポイントに分解して具体例を含め紹介します。
①点で話さない。上流から全てをチームにインストールし、全体像を把握してもらう ②チームメンバーが「今何について考えればよいのか」を明確にする ③思考の流れを開示する。事実だけではなく、悩みも懸念も全て曝け出す
ポイント①：点で話さない。上流から全てをチームにインストールし、全体像を把握してもらう
当たり前ですが、全ての施策にはそれを実施したい意図 / 狙いがあります。
何かしらの施策を実施したい場合、皆さんは第一歩目としてチームメンバーとどんなコミュニケーションをとりますか？
あるあるなのが「施策の意図 / 狙いを十分に説明せずHOWからチームに展開してしまう」こと。これは言わずもがなチームとのコミュニケーションとしてはかなり不十分です。
では「このKPIを上げるためにこの施策を実施したい」のように施策の意図 / 狙いを展開した上でHOWを考えていく流れは？これも十分では無いと思っています。
個人的に大事だと思っているのは、上流のゴールから逆算してユーザー行動ファネルを可視化、それを基にチームメンバーに全体構造を把握してもらうことです。その上で解決すべき課題について話していく流れがベターだと考えています。
「上流のゴール」はサービスや事業の狙いによって異なると思います。それが売上かもしれませんし、DAUや利用継続率かもしれません。
「どれだけわかりやすいユーザー行動ファネルを作れるか」
これが施策を始める第一歩目として大事だと思っています。なのでまずはチームメンバーに全体構造を理解してもらうことから努めましょう。
↑これは僕が担当している「Amebaマンガ」というサービスで、新規ユーザーが会員化→課金化してくれるまでの一連の流れと重要なファネルを簡易的に可視化したものです。
アウトプットの仕方に決まった形はありません。カスタマージャーニーマップなど他の方法も色々あると思いますので、担当するチームがわかりやすい形であればなんでもOKだと思います。
意識したいのは「全体像の把握のしやすさ」と「全体の中で重要なポイントのわかりやすさ」です。
上のファネル図では実際のUIスクショを用い、ユーザーが会員化→課金化するまでの流れを表現していますが、実は全ての流れを網羅的に可視化しているわけではありません。チームメンバーがこのアウトプットを見た際にざっくりとした全体構造とユーザーの流れを把握しやすいよう、主要なファネルだけを意図的に切り出しています。
もちろん漏れなく全てをわかりやすく可視化できるに越したことはありません。が、詳細であればあるほどアウトプットは複雑化しチームへ説明する難易度が上がりますし、チームの理解度も薄まっていきます。
なので、個人的には「網羅性」よりも「わかりやすさ」を重視してアウトプットするよう意識しています。
「全体構造としてこうなっている→その中でもこの部分に課題 / チャンスがある→ここを改善できれば事業KGIに寄与するはずだ」
という思考の流れをまずチームメンバーに理解してもらうことで、この後やっていく仮説設計→アイディア出しの精度が高まっていきます。
逆にこの手順を踏まないと、
- 「そもそもなんで今この部分に対するアイディアを出してるんだっけ？」
- 「このアイディアが仮に良かったら結局どうなるんだっけ？」
とチームメンバーの納得感が薄い状態での仮説設計→アイディア出しとなってしまい、その成果物の精度は低くなる可能性が高くなります。
こういった「目に見てわかる状態」のアウトプットを通し、構造の全体像を把握してもらうことがチームでサービスグロースをしていく第一歩目だと考えています。
ポイント②：チームメンバーが「今何について考えればよいのか」を明確にする
チームメンバーの全体構造への理解がある程度進んだら、次に「ここから何について考えていけば良いか？」を明確にしていきます。
前述した内容と重複する部分はありますが、大事なのは「解決すべきお題を明確にすること」です。
↑これは前述したものとはまた別の構造図解になりますが、Amebaマンガでの売上を構成する要素の一部を切り出し、その要素ごとに解決したいお題を記載したものになります。
これも皆さんが担当するチームに合わせてフォーマットは決めていただければと思いますが、このように各要素ごとに「解決したいお題」と「その具体例」を明確にすることで、チームメンバーが仮説とアイディアを出しやすい環境を整えています。
例えば上記の図でいうと、「課金ユーザー数」を増やすための各ファネルを詳細化し、それぞれのファネルに解決したいお題を明記していますが、その中で「サイト訪問→興味のあるマンガ作品のページに来訪する」ファネルに関しては『滞在UUが多いページで購買意欲、試し読み意欲を高める方法は？』というお題を設定しました。
ただこれだけだとフワッとしすぎているので、補足として以下を記載しています。
- 滞在UUが多いページを明記
- アイディアの方針として、全く新しい情報や要素を追加するよりかは、今既にある要素をよりユーザーへ魅力的に伝わる方法がベターであることを明記
- 上記補足を基にしたアイディアの具体例を明記
こうすることで良い意味で選択肢を絞られ、何について考えてば良いかが鮮明になっていきます。
単純にKPIを分解して「このKPIを上げるための施策を考えよう！」だけだと仮説もアイディアも弱くなりますし、そもそもアイディアが出てきません。なので、解決すべき課題をお題として提示し、それに対してアイディアを出せる状態を整えることが大事です。
何かモノを考える際はある程度の枠組みが必要です。広すぎてもアイディアが霧散してしまいますし、狭すぎてもチームメンバーの創造力に蓋をしてしまいます。
塩梅は難しいですし、僕も試行錯誤しながらやっていますが「どこに頭を使えばいいか？その明確な方向性」をお題という形で指し示せれば最低限はクリアだと思います。
ポイント③：思考の流れを開示する。事実だけではなく、悩みも懸念も全て曝け出す。
このポイントは前述したポイントと比べると意識寄りな話ですが、要は「上手く加工しなくてもいいので、持っている情報と感情を全てチームに曝け出しましょう」という話です。
大前提として、自分発信で進めているプロジェクトや施策は他の誰よりも自分自身がそのことについて一番考えているはずですし、誰よりも情報を持っているはずです。
だからまずは自分が持っている情報と、それを元に考えていること、悩んでいること、チャンスだと思っていることを全てチームメンバーへ展開しましょう。
「こういう課題を解決するためにこういう思想でアイディアを考えているんだが、こういうところで壁にぶつかって悩んでる」
例えば上記のように、思考の順序を追って行き着いた悩みを打ち明けることで「じゃあその悩みに対する打ち手を考えてみよう」と集中するポイントが明確になりますし、逆に「そもそもそこで悩まなくてよくない？こっち路線で考えた方が良いのでは？」という意見が出れば、より良いアウトプットを出すための議論を巻き起こすことができます。
大事なのは「自分はこう考えたよ」と思考の流れをチームメンバーに共通認識として持ってもらうことです。流れを把握してもらえば良い意味でツッコミポイントが増え、議論が加速します。
あともう一点「全てチームに曝け出す」メリットとしては、場の心理的安全性が担保されるところです。
ファシリテーターなど、議論の場の主となる人がまず最初に全て曝け出せば、チームメンバーも「あ、これって結構なんでも言っていいんだ」と意見/発言のハードルがかなり落ち議論が加速します。
例えばその曝け出す内容が「自分はこう思ってる」とか「ここに悩んでてアイディアが思いつかない」だけでなく、今のプロダクトに対する不平不満でも良いです。
- 「なんでもっとこういう風にできないんだろう」
- 「なんでここってずっとこの課題を抱えたままなんだろう」
と、思っていることは全て吐き出してしまった方が良いです。少なからずチームメンバーも何かしら思う所はあるはずなので、それだけでも発言しやすい環境を形成できます。
(もちろんバランスは大事です。愚痴を言い合うだけの大会にならないように…)
発言しやすい、意見しやすい環境を整えることはチームメンバーの自発的行動の促進に直結します。
チームメンバー一人ひとりの創造力を引き出すために、意見を言いやすい環境を整えていきましょう。
PMの本懐
現在PMとして活躍されている方がこの記事を読んだ場合「いやいや全部当たり前なこと言ってんじゃねえか！！」と思うかもしれません。
そういう方は是非継続してそれをやり続けてください。世のため人のため、結果としては自分自身のために革新的なプロダクト作りをよろしくお願いします。
ただ、当たり前なことを当たり前にやるのって難しいんです。
当たり前なことを当たり前にできる人ってすごく優秀ですし、周り見てもほんの一握りだと思うのです。
僕自身まだまだ発展途上です。まだまだ当たり前にできることは多く無いです。
だから、僕は当たり前に当たり前なことをやれるPMが増えて、結果素晴らしいプロダクトが世の中に溢れて、社会が、世界全体がより楽しく豊かになることを切に望んでます。
この記事が皆さんの中でそのきっかけやヒントとなれたらとても嬉しいです。
これからも皆さんとより良いプロダクトを作っていきたいですし、切磋琢磨していきたいと思っています。
サイバーエージェントでは「みんなで寄ってたかってサービスを成長させていく」文化が根強く、だからこそチームの力を最大化させることがとても大事だと考えています。プロダクト作りにおいても誰か一人だけが主導権を持つのではなく、チーム全員で戦うスタイルです。
もし少しでも興味がある方は是非ご連絡ください。
一緒に最高のプロダクトを作っていきましょう。