PM、PjM、EM、TLの役割を定義した話
PIVOTのプロダクトマネージャー / プロダクト組織の責任者の蜂須賀(@PassionateHachi)です。
PIVOTは2024年8月に200万チャンネル登録を達成しました。
事業の成長に合わせて、組織も着実に成長してきています。
PIVOTのプロダクト組織も2022年10月の私の入社から約2年がすぎ、今では17名(業務委託、アドバイザーの方含め)となりました。
[2022年10月当時のnoteがこちら]
これまではそれぞれの得意分野が明確で被りが少なく「これはこの人だよね」とある意味お互いが期待値を分かった上で前のめりに役割を全うできる状態でした。
しかし、組織が大きくなるにつれて、3つの課題が生まれました。
ということで、この機会にマクロな視点での「役割における期待値」とミクロな視点での「開発ライフサイクルごとのRACIチャート」を作ることで役割の定義を明確にしました。
今日は、その中のマクロな視点における「役割の期待値」をどう定義したかをお話しします。
事業x技術x組織」の重みづけで役割は決まる。
まず、前述の悩みはシリーズA~Bくらいでは「あるあるな課題」だなと感じていたので、多くの記事や資料を漁ってみました。
その中で一番しっくりきたのが、こちら
(ちなみにWebで偶然辿り着いた資料でしたが、そんなあらたまさんは今身近な存在です。)
この三角チャートをもとにPIVOTの中での役割を表したのがこちら
期待する効果としては、現状の明確化のみならず、キャリアラダーと照らし合わせることで、「ICの自分が、TLになるには事業と組織の感度を上げよう」といった、キャリアの道標になることも期待しています。
そしてこの抽象的な概念では表現できない具体の職務などはこのように定義しました。
(ここで参考にしたのがこちらの記事)
特に、「開発者が開発に注げる時間」x「無駄にならないコードの量」x「機能が実際に使われる頻度」という箇所への共感が強く、「+」ではなく「×」。つまり、どれか一つでも0やマイナスになると他の要素が無に帰すというところがプロダクト開発のリアルだなと痛感しています。
プロジェクトにおける責務
マクロな視点から徐々に、目線を日常に移します。
現状のPIVOTで特に重複と無駄を感じているのが、「プロジェクトにおける責務の被り」です。これが理解した上で意図したものであれば良いものの単純な重複が多く見えたのが課題でした。
具体的には、プロダクトマネージャーの私とプロジェクトマネージャー、EMのプロジェクト進行における役割の重複が「都度うまくやろうぜ」以上に何かできないかと感じていました。
そのヒントは建築業界のメタファーで解消できました。
(建築業界に明るいわけではない自分が参考にしたのがこちら。)
一見、似て非なるものでありながら、この時間軸(=視野)における責務(=視点)の違いはとても実感があるものでした。
私たちの身近な書籍で言うと「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」にあるこのグラフを前職で複数人のPMのリーダーをしている時に痛烈に意識していたためです。
さらにここで出てくる"戦略"や"戦術"の概念を正しく理解することもとても大事だと考えます。
開発ライフサイクルにおける具体的な責務
PIVOTの開発ライフサイクルは以下の通りです。
この各ステップに対して RACIチャートで役割ごとの権限を明確化しました。
この各工程の詳細とRASIチャートに関してはEMの黒澤さん主体なので、きっと別のnoteで記載すると思うので、次回予告として詳しくはそこに預けます。
最後に
スタートアップで属人性の高い状態から、組織になる過程はどの組織でも辛さと面白さがあります。ただ、フェーズが進んでも組織になりきれず綻びが出てきている様子も多く見受けられます。
我々はこれからテクノロジーカンパニーになるためにまずます盤石な事業体制を支えるプロダクト組織を強化していきます。
(反響が大きかったテクノロジーカンパニーへの意気込みはこちら)
そんな私たちは継続して仲間を募集中です。私の入社からコンスタントに2ヶ月に1名のメンバーを迎えています。
興味を持って頂けたら是非ご連絡ください。私へのDMでも大丈夫です。
現在の採用情報:Androidエンジニア、Webエンジニア etc.
PIVOTメンバーの技術ブログはこちらのマガジンから
主にPjM、PO、セールスエンジニア、AWS ソリューションアーキテクトなどを務める。「映像業界の働き方を変える」をモットーにエンジニア組織を超えたスクラムの導入、実践に奔走。DevLOVEなど各種コミュニティーにおいてチームビルディングやワークショップのファシリテーションを行う