2021.02.19

小原 聡

プロダクトマネジメントトライアングルの考えを中心してPM(プロダクトマネージャー)のチームを立ち上げた頃を振り返る

WRITER

小原 聡

株式会社PLAN-B システム開発本部 テック&データラボ マネージャー

2014年に中途として入社。LP専属の制作ユニットを経て、クリエイティブユニットのWebディレクターとして従事。広告事業の社内プロダクト開発に従事した頃から徐々に自社プロダクト開発に携わるようになり、2019年から自社開発プロダクト「SEARCH WRITE」のPM(プロダクトマネージャー)として、プロダクトの立ち上げを進める。現在は新しい機能開発や改善などを進めながらプロダクトのPMFを目指し奮闘中。

目次
    1. プロダクトマネージャーのチームを立ち上げる
    2. プロダクトマネージャーのスキルセット
    3. 社内でプロダクトマネージャーのチームをどのように組織化したか
    4. プロダクトマネージャーへのキャリアパス
    5. さいごに

自社開発プロダクト「SEARCH WRITE」のPM(プロダクトマネージャー以下、略)を1年半ほど経験しながら、改めて、自分の役割を振り返る意味でも、 PMの役割としてのチーム立ち上げや必要だと感じたスキルセットについて、整理してお伝えできればと思います。

プロダクトマネージャーのチームを立ち上げる

私はもともとウェブ制作のディレクターやらウェブ担当者を10年ほどやっており、自社開発のプロダクトサービスに携わったことをきっかけに、徐々にPMという職種の役割を任されるようになったのが2年ほど前です。社内にてプロダクト開発に力を入れるため、PMチームを組織化するということでチームに加入し、まず何が必要なのかをメンバーたちと模索しながら、PMが今の社内で行っていく役割はなんだろうというところからのスタートでした。

PMという職種が世間にも徐々に浸透や認知されてきており、 noteやTwitter、各メディア媒体でも情報を発信される人も増えて、ありがたく、さまざまな方々の情報発信をもとにチームの役割を模索していきました。

チームの立ち上げとして、取り組んだことは、PMに必要な「スキルセット」の整理です。
PMをやる人は、どんなことをする必要があって、そのためにはどのうようなスキルが必要なのか。

そこで、基本とした考え方は、PM界隈の方々には有名な「プロダクトマネジメントトライアングル」です。ここにたどり着けた時にはすごく感動を覚えました。PMを体系的に自分で理解するにも、誰かに説明するにも、非常にわかりやすい考え方です。

プロダクトマネジメントトライアングル

引用: https://productlogic.org/2014/06/22/the-product-management-triangle/
訳: https://ninjinkun.hatenablog.com/entry/the-product-management-triangle-ja

このトライアングルを見ていただいてもわかるように、非常に守備範囲が広く、当時は「いや無理ゲーやん」って何回も思いました。これを1人でこなすPMという職種は化け物かとも思いましたね(笑

PMの役割は、自分の言葉でいうと「プロジェクトをユーザーに届け、提供する価値を最大限に発揮させること」だと思います。

プロダクトのフェーズ(立ち上げなのか、グロースなのかといった)により細かくより役割は変わると思いますが、現在、私が担当するプロダクト (SEARCH WRITE)は、ゼロからの立ち上げだったため、特に「届けること」意識してたなと思います。

では、プロダクトマネージャーに必要なスキルセットを私たちの会社ではどのように考え方、自社にフィットさせていったかをご紹介いたします。

プロダクトマネージャーのスキルセット

守備範囲が広いPMですが、どんなスキルセットが必要なのかを、まず自分自身の言葉で整理してみることで、学ぶ範囲も明確になると思いますし、所属される企業によっても変わってくる場合はあると思います。

私は想像できる範囲が自社の中でしかなかったので、まずは自社のプロダクトマネージャーに必要なスキルセットを「ジョブディスクリプション 」として落とし込んでみることにしました。

ジョブ・ディスクリプション

結果としては、業務内容を明確化して、具体的に何をするか、を自分なりの言葉で書いてみることで、すごく頭の中が整理できたなという思いと、「身に付ける必要なスキル多すぎて、どんなキャリアなん」っていうちょっとした絶望感を味わいましたね。

一部、社内独自での必要なスキルセットも含まれますが、ざっくりとお伝えすると

  • ビジネス領域・・・マーケティングフレームワークを用いたユーザー調査、市場調査を含む事業戦略立案
  • 開発領域・・・プロダクトを開発するために必要な開発手法(開発マネジメント)やプロダクト仕様を固めるための要求要件定義
  • UX領域・・・プロダクトとユーザーをつなげるためのUIデザインやUX(顧客体験)を生むためのサービス設計

この3つの領域に対しては、「知識」として身についている必要はあるなと思います。 各領域でも1つの職種ですが、その3つぐらいの領域を跨ぐスーパー上級職。それがPMですね。
うーん、すごい。

もちろん細かくお伝えするとかなり細かくなっていくので、また機会があれば別の記事にて紹介していきます。

社内でプロダクトマネージャーのチームをどのように組織化したか

よくPMの役割は、プロダクト の「Why(なぜ作るのか)」を考え、「Who(誰に向けて)」「What(何を作るのか)」にまで落とし込むことを主な業務として、その後の「How(どうやって)」「When(いつまでに)」といった、プロジェクトマネージャーの領域も行う方は多いかとおもいます。

プロダクトをサービス・ビジネスとして提供するためにすべてを網羅的に関わる必要があるため、本当にその活躍の幅は広く、必要なスキルも膨大にあります。別職種のキャリアチェンジからPMになっていくかと思いますが、自身でもっていたスキルセットだけでは、網羅できない領域があるところをどう担保すべきか。PMになりたての方はまずここにつまずくのではないかなと思います。

私もこの壁に半年ほど悩みながら模索していたように思います。その中で1年半ほど前に「新しいプロダクト 」を作るプロジェクトにアサインされたことで、そのモヤモヤは徐々に解消されていきました。
自分でなかなか経験値があがらずに苦しんでいた「ビジネス設計」を担当できる事業責任者と進めることになったからです。

プロダクト の「0」からの立ち上げですので、「Why・Who」の部分が強く必要となるフェーズで、このビジネス設計が得意な事業責任者(五十嵐)がチームに加入し、次にマーケティング領域が得意なメンバー(百々)も入ってきたりと、プロダクトを作っていくという組織的な変化もあったので、チームのあり方を考えるきっかけになったかなと思います。

「What」の部分が形になるまでには3ヶ月ほど模索した時期もありましたが、プロダクトを立ち上げていく過程で必要になるスキルセットをもちよって 「プロダクトマネジメントトライアング」の領域をお互いが補完していく。各自がこれまでに得ていた経験やスキルといったものを集めて、パズルのようにうまく組み合わせる。
そうすることで、幅広い領域を網羅するPMの役割がカバーできてくる。

スキルセットでカバーする

もちろん自分以外がカバーしている領域の経験を、お互いが身に着けていくことで、短時間で組織内にプロダクトマネジメントのチームを組織化していくことができました。

プロダクトを作ることをすすめている会社さんでは、この「ビジネス領域」「開発領域」「UX領域」といったところを少なくとも行なっている方々は存在すると思うので、その散らばった「個」を組織的に再編し「プロダクトの成長」にコミットしたチームを作り、プロダクトマネジメントトライアングルを意識した役割分担をチーム内で行う。チームといっても会社的な組織も存在するとおもうので「プロジェクトチーム」として組織とはまた違ったチームを作るのもおすすめです。

もちろん全ての領域がすぐに埋まることは珍しいと思いますが、すでに大きくなったプロダクトをもたれてる企業などは、1人が複数の領域をカバーしてチームでもカバーして、徐々に組織が大きくなっていってるんだろうなと想像し、実感できるようなところまで、ようやくたどり着きました。

現在は、PMのチームもまだまだ成長過程ですが、徐々に「代理店」的側面だけだった組織から「事業会社」としての顔も持つ組織に変わっていく過程にも携わることができてきており、PMとしての成長をここ半年ではすごく感じています。

プロダクトマネージャーへのキャリアパス

プロダクトマネージャーになるにはどのようなキャリアが必要かという記事もたまに見かけます。キャリア系メディアやnoteなどにもPMとして有名な方々の話がまとまっているので、恐縮するところはありますが、、、
自身の経験としては「プロダクトマネジメントトライアングル」のどこかのキャリアを経験している方がスムーズに入ってくると思います。

1つの領域のスキルが伸びてくると、他の職種のスキルとも協力しないと進まない仕事が舞い込んでくることが経験上多かったかなと思います。1つの職種で仕事ができるようになると、自然と他の職域の人がどんな仕事をしているのかも理解できるはずです。そこからPMを目指していくとPMの役割のイメージが付きやすいのかなと。

RPGでいうと、いきなり「賢者」にはなれないので、まずは「魔法使い」をマスターしましょうという感じです(笑

僕はウェブディレクターからのPMへの転身の際に、当初はエンジニアの経験が必要だ!とは思っていたので、プログラミングを学ぼうと思った時期もありましたが、正直必要はないと思います。

ただ、エンジニアさんたちと一緒にプロジェクトを進めることになるため、メンバーからの信頼を得るという点で、彼ら・彼女らが大切にする価値観や技術の話や技術選定をどうすすめていくのか、開発の進め方はどのようにするのかと言う「議論」をする必要はあります。「議論」するにはコミュニケーションを取る必要があり、その辺りは常に情報交換したり、教えてもらったり、勉強したりという自身でのインプットは常にするようにしています。本当にコミュニケーションできるぐらいの知識量でいいという感覚です。これはウェブディレクターの時にも同じことを経験していた私としてはスッと普段の日課のようにすすめていくことができました。

それよりも、PMとしてはまず何よりもプロダクトのユーザーを理解することだったり、事業=プロダクトならばその事業を理解することは、絶対にやるべきだと思います。私が携わっているプロダクトは「コンテンツマーケティング」「SEO」といった領域ですが、何度も「PINTO!(本サイト)」の記事を読み返したり、事業を理解するためのインプット、GA・GSCといった解析ツールの理解には時間を使いました。

同じチームの後輩が、別のプロダクトを立ち上げる際に、一度、事業の業務をすべて自分でやってみると言ったときには、PMのコアの部分を理解してると思い、すごい頼もしかったことを強く覚えています。

さいごに

PMという役割を任されるようになってからこうやって改めて振り返ることはなかったのですが、やはり転機になったのは、1つのプロダクトを「0」から立ち上げた際の経験。そしてその時に集まったメンバーが偶然にもうまくはまったこともありますが、おかげで自社のPM組織づくりのヒントを得ることができ、うまく拡大していくことができたんだなと思いました。

今回のお話が絶対の正攻法だとは思いませんが、今、まさにPMの役割に悩まれていたり考えている方へは、1つのPM組織の事例として参考にしていただけますと幸いです。

私もプロダクトもまだまだヒヨッ子ですが、PMとしてより良いプロダクトを世の中に提供し、届けるべきユーザーさんの課題を解決していければと思います。