「サイバー流！ PMスキル場」連載VOL,6
@Kei
PIGG PARTY プロダクトマネージャー
2015年に新卒でSIerエンジニアとしてキャリアをスタートし、2017年にサイバーエージェントに中途入社。エンジニアから企画職へ転身し、「アメーバピグ」の企画・開発やプロデューサーとして従事。2018年11月からアメーバピグのスマートフォン版アプリ「ピグパーティ」のPMとしてジョインし、事業グロースへコミット。
現在は同サービスのボードメンバー・プロダクトマネージャーとして組織・事業マネジメントしつつ、プロダクトのモデル改革をミッションとしている。
連載「サイバー流！ PMスキル場」 サイバーエージェントの各事業のプロダクトを担うPM（プロダクトマネージャー、プロジェクトマネージャー）達が、 「サービスフェーズ×ドメイン」で変化するPMの役割や経験談を語ります。
はじめまして、こんにちは。「ピグパーティ」というアバターコミュニティサービスでプロダクトマネージャーをやっています、Keiです。
私は熊本生まれ熊本育ちの田舎者でITやwebとは比較的無縁な環境で育ってきました。
就職活動のタイミングで、「世の中に影響がある仕事は何か」という軸で就職を考えていた私は、初めてそこでITやweb業界に興味を抱きました。
調べていく中でこの業界は世の中への影響度も大きそうで、利用している人の反応も分かりやすそうだと思い、今の道に進みました。
その感覚は今のところ間違っていなかったのかなと思います。
私は文系出身ですが、2015年に新卒でSI企業のエンジニアとしてキャリアをスタートしました。
事業やサービスをつくる上でエンジニアリングを学ぶことは必須だと勝手に思い込んでいたのもありますが、学生時代にプログラミングをやってみたら楽しかったのでエンジニアを選びました。
実際に働く中で技術自体への興味よりやっぱり事業づくりをする方への興味が強いなと感じました。
それから2017年にプランナー職へ転身しサイバーエージェントに入社しました。
開発経験もあったのでPMキャリアに進むことになり、約4年ほどPMとして働いています。
現在は、事業経営にも携わりながらプロダクトマネージャーとして従事しています。
本記事では、
・PMの役割とは
・プロダクトマネジメントとは
・PMが真価を発揮するために必要なことは何か
というテーマについて自分の経験を基に書いていきます。
こんな方にオススメ
● toCプロダクトのPMとして従事している ● エンジニア出身のPMである ● スタートアップやグロースフェーズの事業に属している ● 戦略→戦術→実装のプロセスに悩んでいる
PMの役割とはなにか
PMに必要な要素として柔軟性はよく挙げられますが、私も正にその通りだと思っており、変化への対応力は不可欠だと感じています。
「様々な環境の中で自分がPMとしてどの役割をどこまで担うか。そしてどう動けば組織/事業として最もパフォーマンスが出るか。そこに常に向き合い続けること。」
それがPMとしてのバリューの確立に繋がり、更に個としての競争優位性になると考えています。
私自身、自分が考えるPM像に固執してしまい悩んだことがあります。ですが、PMとはこうあるべきだということに固執すること自体、あまり意味がないことだと気づき、そこから変化に対応し続けることの大切さを学びました。
とは言いつつも、全てのPMに共通する役割を言語化するとすれば、
「プロダクトの価値を増幅させ、事業継続と発展への責任をプロダクトに持つ人」
だと私は考えています。
インターネットの総合商社と呼ばれることもあるサイバーエージェントは、様々な事業ドメインの様々なプロダクトフェーズの中で自分のビジョンや目指すロールにフィットしたポジションを選択できる会社だと思っています。
曖昧で柔軟性が必要なPMという職において、サイバーエージェントのPMで働けることは自分としては凄く恵まれている環境だなと日々感じています。
プロダクトマネジメントとは
全てのPMに共通する役割としてプロダクトの価値を増幅させ、事業継続と発展への責任をプロダクトに持つことだと書きましたが、では具体的に「プロダクトマネジメント」とは何なのでしょうか。
- プロダクト品質の担保？
- 開発をディレクションすること？
- 何を作るかを決めてロードマップを作ること？
様々思い浮かびますが、私は以下だと思っています。
「戦略と実装を一致させ、目標達成できるスピードとクオリティを持ってプロダクトへ反映させること」
では、なぜそう思うのか？について書いていきます。
PMが介在するタテとヨコのライン
全ての事業は、目的やビジョンはあれどユーザーに価値提供を行い、その事業を存続させて成長させ続けることが至上命題だと思っています。
事業の構成要素は組織とプロダクトと考えます。事業=組織×プロダクトというイメージです。
以下の図は、「至上命題である事業経営」とそれを構成する組織・プロダクトの関係性と成長ループを表したものです。
その時、事業経営から戦略→戦術→実装と伸びる「タテ」のラインと組織から、「タテのライン」の過程を経てプロダクトへ伸びる「ヨコ」のラインがあると考えます。（※赤線部分）
PMはこの「タテ」と「ヨコ」に介在しており、それぞれ以下が重要だと考えます。
- タテ → 戦略と実装の一致
- ヨコ → スピードとクオリティ
これが上述したプロダクトマネジメントの中身となります。
そしてPMが上記に向き合う上で、目標達成の確率が最も上がる2つのポイントが以下だと私は考えます。
- 戦略→戦術→実装のプロセスのシンプル化
- チームパフォーマンスの最大化
後にも先にもこの2つだけだと私は考えています。
ではなぜこの2つが必要だと感じたか、自身の経験を交えつつお伝えしていきます。
戦略の難易度に応じて複雑化するステップ
まず戦略とは何かという話なのですが、戦略とは「目標や理想状態を実現可能なステップに切ったもの」だと思っています。
描く未来のレベルが高い程、ステップ数は増えて戦略は複雑化します。
そうなると、理想状態と今やっていることにGAPを感じたり、何を目指しているのか、本来の目的を見失ってしまったり、チームも混乱してしまいます。
私が携わるアバターコミュニケーションという領域は、仮想空間上にアバターが溢れるサンドボックス要素の高いプロダクトなので自由度が高い特徴があります。
自由度の高さは勿論良い面も沢山ありますが、複雑化してしまう一面もあり、私自身これまでにチームを混乱させてしまったり、メンバーのひとりひとりの見ている方向がバラバラになってしまって議論が上手くできなかったり、悩んだ経験があります。
その結果、元々描いていた戦略から自分もチームもずれてしまい、戦略と実装の不一致が発生してしまうのです。
複雑化することは当たり前だけど、それをどれだけシンプル化できるかが戦略と実装の一致には重要だと肌で感じました。
私がシンプル化するために意識していることを少しご紹介していきます。
①プロダクトカルテ
プロダクトで今何が起きているのか地道に洗い出すという作業です。
プロダクトの健康診断をし、健康状態を把握します。この結果を持っていると、その後のシンプル化のしやすさが変わります。
②イシューマッピング
シンプル化するためにコントローラブルなものからアンコントローラブルなものまで仕分けていきます。
アンコントローラブルなものは捨てる訳ではなく、チャンスの大きさとの二軸で考えてマッピングし、そのバランスを把握することが大切だと思っています。
③センターピン
「目標はセンス、戦略は頭脳、実行は気合い」という社長の言葉があります。
センスというのは、つまりシンプル化だと私は考えています。
常に意識できるワーディングやネーミング、キリのいい数値感などが組織への浸透に通じ、強固なパワーになると思っています。
④アイデア転換
「アイデアとは、複数の問題をまとめて解決するもの」という言葉のように、イシューマッピングしたものを優先度順に並べて全部やろうとするのではなく、抽象化と本質化によってそれらをまとめて解決できるアイデアへ転換してシンプル化します。
⑤負債の可視化
負債は時間経過に比例し増加します。
経営資源は変化せずとも、プロダクトの成長性は下がっていきます。
主に以下の点で負債が増加していきます。
- 組織の変化
- 運用の蓄積による負の遺産
- ソースコード量の増加
- システムのレガシー化
負債は見えざるものである場合が多いため、可視化することでシンプル化に繋がります。
この5つを意識して「タテ」のシンプル化を行います。
PMはチームを下から支える
次にチームパフォーマンスを最大化することがなぜ必要かについてです。
まず自分の経験談を2つご紹介します。
昔、とある機能を作っていた頃PMである私はプロジェクトを早く進めようと必死になっていました。
何を作るか、要件や設計や仕様をPMが決めないと先に進まないと思ってしまっていました。モックなども作って何もかもやった後、それをチームに共有したのです。
それの何がいけなかったかというと、アウトプットがどうこうよりも、1番はチームから信頼してもらえなかったことだと思います。
1人で全部やってきて、これ作りましょうって言われても信頼できないのは当たり前です。
勿論、信頼だけでなくそもそも1人の脳で考えるより集合知で考えた方がクオリティは必ず高くなります。私は結果として早く進めようとしていたのにスピードとクオリティを下げてしまうようなことをしていたわけです。
開発に限った話ではないですが、プロダクトへ反映させるスピードとクオリティを上げるにはチームの信頼関係が重要だと思っています。
お互いを信頼し、やるべきことをやるべき人に任せ合う。その上でアイデアを出し合い、議論し、磨いていくことがスピードとクオリティに繋がります。
2つ目の経験をご紹介します。私はエンジニア出身のPMですが、エンジニアはアーキテクトやクラス構成のような「設計」を考えることが日常です。
その中で拡張性や冗長性がないかなどを常に考えながらコーディングするため、物事を構造的に捉えて仕組み化をしたり効率化をしたりすることが得意です。
そのため、Howを考える思考のクセがついています。
開発を進める上では進むほどに様々な制約が発生し、Howの前提条件が積み重なります。
その結果、最初はプロダクトを届けるユーザーを見ていたはずが、
いつのまにか
- いかに開発を効率よく進めるか？
- いかにスムーズにデリバーするか？
という思考になってしまい、開発現場しか見えてない状態になってしまうことがあります。
ユーザーの幸せではなく、現場の幸せに変わってしまっている状態です。
そうなるとアウトプットは必ず小さくなってしまいます。
でも本来見るべきことは、今やっていることや、やろうとしていることが、「勝てるかどうか」と「勝つための条件は何か」の2つだと思います。
「勝つ」という意味にはいくつかあります。
- 狙っている市場の中で
- 競合において
- 現在のプロダクトの価値と比べて
etc…
「何をやるか？」を決めるより「勝てるかどうかという目線をぶらさない」ことの方がPMとしては重要だと学びました。
この2つの経験を踏まえて、チームパフォーマンスの最大化がなぜ必要かをまとめます。
PMはポジション的にチームをリードする立場のイメージがあります。
しかし実際には、誰よりもプロダクトのことを考え抜きながら、チームを下から支え、メンバーが心置きなくパフォーマンスを出せるよう、泥臭く地に足を付けて走り回っていることが多いのではないでしょうか。
事業は組織であり、組織はチームプレーなので、チームパフォーマンスが戦略をプロダクトへ反映するスピードとクオリティに直結すると考えています。
現在はリモートワークが一般化していますがこれは今まで一緒に働いていた信頼関係があるからうまくいっていると思います。
コミュニケーションは量よりも頻度だと言います。一緒にいることで生まれる何気ない会話や挨拶などがベースの信頼関係を保つと思うので、リモートが一般化する中でコミュニケーションの頻度が落ち、信頼関係が保ちづらくなることは課題だと感じています。
そのような時代の変化をどう捉えて、どう行動するかもPMとして考えなければいけないことだと最近特に感じています。
最後に
はじめにPMの役割は、「プロダクトの価値を増幅させ、事業継続と発展への責任をプロダクトに持つ人」だと書きました。
事業をビジネスとして成立させ、「経営資源の増加」と「プロダクトの価値向上」を両立させることは沢山のトレードオフやジレンマが起きると思います。
その中で「戦略と実装を一致させ、目標達成できるスピードとクオリティを持ってプロダクトへ反映する」ことがPMが向き合う領域であり、
そこで真価を発揮するためには、「戦略→戦術→実装のプロセスのシンプル化&チームパフォーマンスの最大化」の2つしかないと私は思っています。
サイバーエージェントのミッションステートメントには人に纏わる言葉が数多く入っています。
「人こそ資本」という文化が根付いている会社であり、同職の中でも様々な人に相談できたり、フォローアップしてもらえる環境にも恵まれていると思います。
私自身まだまだ至らない点がたくさんあり、いつもチームの皆さんからアイデアやアドバイスをもらったり、助けられたりしています。この場を借りて感謝を伝えたいです。いつも本当にありがとうございます。
この記事を読んで、少しでも共感していただいたり、ご興味を持っていただけましたらお気軽にご連絡いただけると幸いです。
ぜひ、サイバーエージェントで「21世紀を代表する」プロダクトを、事業を、会社を一緒に作りましょう。
＞連載Vol,1 「ABEMAのプランナーからPMへ転向した話」
＞連載Vol,2 「入社1年目の新米PdMが大型機能をリリースした話」
＞連載Vol,3 「成果最大化に向けたグロースチームの作り方」