今回は、2月14日に行われたオンラインセッション「プロダクトづくりを円滑にするためのさまざまな仕組み」の模様をお届け。株式会社メルカリ、LINEヤフー株式会社、株式会社リクルートのPdMが集まり、プロダクトの成長に伴い煩雑になる組織のなかでプロダクトづくりを円滑に進めるための方法について語り合いました。各社の取り組みから見えてくる、プロダクトマネジメントにまつわる課題やモヤモヤを解消するヒントとは？

※2024年2月14日開催の「PdM Days DAY3〜プロダクトづくりを円滑にするためのさまざまな仕組み〜」から、内容の一部を抜粋・編集しています。

メルカリにおける「テクニカルプロダクトマネージャー」の役割とは？

永石：まずは登壇者の自己紹介をします。私は本日のモデレーターを務めます、株式会社リクルートの永石陽祐です。もともとネットワークエンジニアからキャリアがスタートし、そこからコーポレートITを経て、現在はリクルートでHR領域のプロダクトマネージャー（以下PdM）を担当しています。

丸山：メルカリの丸山素良です。私はSaaSプロダクトのマネージャーからプロダクトマネジメントのキャリアが始まり、エンジニアとやりとりをするなかで徐々にテクニカルな領域への理解が不足していると感じるようになりました。このままではプロダクトに対する責務が十分に果たせないと思い、シリコンバレー流のエンジニア養成コースで学び、それ以降はテクニカル面からプロダクトを管理・進行する「テクニカルプロダクトマネージャー」という形で自身をブランディングしています。メルカリ入社後は、Japan Regionにおける新規ビジネス全体のグロースに寄与するGrowth Platformをドメインリードとして引っ張りつつ、直近2年はプロダクトマネジャーをマネジメントする役割も担っています。

門田：LINEヤフー株式会社の門田勘太朗と申します。経歴ですが、最初はSlerとして十数年働き、6年前にLINEに転職しまして、そこでPdMという職種になりました。現在は『LINE公式アカウント』という、toB向けのソリューションを開発しています。

永石：みなさま、よろしくお願いします。ここからは「プロダクトづくりを円滑にするためのさまざまな仕組み」をテーマに、各社の特徴的な取り組みを紹介しつつ、ディスカッションしていければと思います。では、メルカリの丸山さんから発表をお願いします。

丸山：私からは、メルカリの「テクニカルプロダクトマネージャー（以下、TPM）」という職種について、普通のPdMと何が違うのか、プロダクトづくりにどう関わっているのか、といった点をご紹介したいと思います。

TPMというロールは2019年に導入され、現在もこの職種で採用が行われています。名称の通り、TPMはテクニカルな課題解決に対して強みを持っていますが、軸足はあくまでPdM。当然ながら、PdMとしての知見・スキルも求められます。

丸山：メルカリにおけるPdMとTPMの違いをもう少し詳しく説明します。私は主に3つの差別化ポイントがあると考えています。

1. TPMはプロダクトビジョンにAlignした設計を追求する

2. TPMは技術負債を「プロダクト負債」と考える

3. TPMはエンジニアに物申す

まず、1点目の「TPMはプロダクトビジョンにAlignした設計を追求する」について。これは、たとえばAPIやデータ、セキュリティ要件に関すること、また、その他の「プロダクトにとって重要なテクニカル領域の設計」について、テックリードやエンジニアリングマネージャーと一緒に追求するということですね。ただし、意見はしますがHowの決定についてはエンジニアに委ねるようにしています。

2点目の「TPMは技術負債を『プロダクト負債』と考える」ですが、ここでいう技術負債とは「効果的なソリューションではなく、簡単なソリューションを選ぶことで生じる追加作業のコスト」を指します。これを避けるには、TPMがエンジニアと一緒にテクニカル負債を課題視して、時にはco-workerのPdMにやり方を変えることを意見できるのも、TPMの特性といえます。

3点目は「TPMはエンジニアに物申す」。一般的なPdMの場合、自分自身が理解できない領域はエンジニアに一任するというケースも多いと思います。ただ、そうなるとエンジニアが粛々と決断しているやり方が、本当にプロダクトのビジョンとAlignしているのかどうか、PdM側が認識できなくなってしまう。その点、エンジニアリング方針や手法に対して突っ込んだ質問を投げたり、意見できたりするのもTPMならではだと思います。

丸山：つまり、TPMとはプロダクトのテクニカルな領域について、中長期目線でビジョンを持って課題解決するロールです。もちろん、TPMという肩書きでなくても、各社で似たような役回りをされている方もいらっしゃると思います。ただ、メルカリはグローバルテックカンパニーを目指していることもあり、あえてTPMという職種定義をして、採用戦略にも活用しています。

永石：丸山さん、ありがとうございます。確かに、自分が担当するプロダクトでテクニカルな部分の難易度が高い場合、一般的なPdMではカバレッジできない部分が出てくると思います。メルカリの場合、そこでTPMという役割のバリューが発揮されるわけですね。逆に言えば、そこまで技術的な難度が高くない案件など、あえてTPMをアサインする必要がないケースもあると思います。PdMとTPMのプロジェクトへの割り振りは、どのような基準で行われていますか？

丸山：おっしゃる通り、プロジェクトによってはArchitectがいたり、エンジニアマネージャーが優秀だったりすることで、TPMの必要性を感じない場合もあります。基本的にTPMがアサインされるのはエンジニアしかいない領域だったり、PdMの技術面の知識に不足があったりする場合などですね。

門田：私からもひとつ質問いいですか。PdMとの差別化ポイント3点目の「エンジニアに物申す」って、具体的にどんなことを物申しているんですか？　いくらTPMとはいえ、エンジニアリングの領域に踏み込んで意見するって、なかなか勇気がいることだと思うのですが。

丸山：たとえば、エンジニアがマイクロサービスを一つ追加する決断をしたとします。ただ、マイクロサービスやAPIの数はメンテナンスにも大きく影響を及ぼすため、そこはTPMとして「本当に新しいマイクロサービスが必要なのか？」というところから改めて吟味してもらったりはしますね。

門田：それはすごい。

丸山：ただ、それにはやはり信頼関係がベースにないと難しいですし、先ほどもお話しした通り、意見はしてもそれを受け入れるかどうかのチョイスはエンジニアに委ねています。ただ、少なくとも「専門家に遠慮して何も物が言えない」といった状況に陥らないよう、関係性を築くことが大事ですね。

組織が拡大していくなか、課題に合わせて最適なチームを編成するには？

永石：では、次に門田さん、LINEヤフー株式会社における「プロダクトづくりを円滑にするための仕組み」についてお話しいただけますか？

門田：私が開発を主導している『LINE公式アカウント』というサービスは、2012年に5人のチームでスタートしました。そこから大きなリニューアルを経ながらチームが拡大していき、現在では50人の組織になっています。ただ、組織が拡大していくと、そのぶん歪みというか、非効率な動きも出てくるようになったんです。

そのなかでプロダクトマネジメントを円滑にするために、組織長としてどうアプローチしていったのか、取り組みの一端をご紹介したいと思います。

門田：苦心したのは、50人をどのようなチームに編成するか。どんな分け方をすれば、プロダクトの進化スピードを最大化できるのか。そこに何度もトライしました。

たとえば、プロダクト内の機能ごとにチームを分けたり、KPIごとに分けたり。それでもうまくいかなければハイブリッドにしてみたり。半年に1回くらいの頻度で編成を変えながら、課題をその都度洗い出していきました。

たとえば、機能で分けると各チームが担当する機能の最適化にはつながるものの、横の機能と世界観が噛み合わなくなるなどして、トータルのUXはむしろ悪くなってしまうという問題が発生しました。そうした問題点をふまえつつチーム編成をアレンジするなど、1年半くらいずっと試行錯誤していましたね。

でも、こういう話って、我々の組織に限ったことではないんじゃないかなと。拡大してきたプロダクトマネージメント組織では、こうした課題は必ず出てくるのかなと思います。

永石：確かに。このあとお話ししようと思いますが、まさに私が所属する組織でも、ほぼ同じことが起きていて、とても共感しながら聞いていました。途中で口を挟んでしまってすみません。ひとつ質問いいですか。門田さんは、チーム編成でかなり試行錯誤されたということですが、これって何かしらの結論は出ましたか？

門田：結局は「その時々で最適な切り方をすべき」というのが答えになってしまうのですが……。つまり、その時に注力したいテーマ、課題になっていることを解決する分け方にするということですね。その際に大事なのは、チームのメンバーにちゃんと説明すること。なぜチーム編成を変えるのか、こういう分け方をしたことにより、僕は何を諦めて、何を伸ばしたいと考えているのかなど、全てを伝えるようにしていました。

永石：丸山さんからは何かご質問、ありますか？

丸山：こういうチーム変更が度々あると、現場からは「またシャッフルか……」とネガティブに捉えられてしまうこともあると思います。プロダクトの境目がしょっちゅう変わると、PdMとしてはその度に「作り捨て」をしているような気にもなってしまうのかなと。私だったら、せめてプロダクトを通して変わらない軸みたいなのが維持されていれば、シャッフルされてもさほど気にならないのかなと思いますが、そのあたりはいかがですか？

門田：おっしゃる通り、私たちもプロダクトとしてブレない軸が必要だと考えて、ほぼ全メンバーでワークショップを開き、ビジョンを固めました。その上で、全員でそこに向かっていくために、適宜、最適なアプローチをしていこうと。もちろん、それでも「また変わるんかい」みたいな声はどうしても出てきますし、実際、変えてやりづらくなるところも多々あるでしょう。ただ、逆にやりやすくなる部分や、ビジョンに対してよりアプローチしやすくなる側面があることも事実で。そこはもう、「チームを変えていくのも俺らの文化だよね」くらいの勢いでやっていますね。

横断目線でプロダクトマネジメントプロセスの効率化をはかる「プロダクトオペレーション」の役割とは？

永石：いや、そこは本当に難しい問題ですね。ちなみに、先ほど言った通り、私が担当している『リクナビ』内のプロダクトでも門田さんの『LINE公式アカウント』チームとほぼ同じ現象が起こっていましたので、少しだけお話しできればと思います。

永石：コロナ禍に立ち上がった「オンライン合同企業説明会」というプロダクトなのですが、急成長に伴い当初10名だったPdMが2年で40人になりました。それだけ急拡大すると、やはり組織の生産性という観点で様々な問題が生じます。たとえば、人が増えるとスキル面、知識面での偏りが生まれ、特定の人に業務が偏ってしまったり、「その人にしかできない」みたいな属人的な業務が増えてしまいました。僕らの場合、特にデータ分析の業務でそういうことが多く発生していましたね。

他にも、新しく入った人が過去に失敗した事例と同じような施策の企画案を出してきたり、複数のチームが同時に走ることで周囲の検討のプロセスが見えづらくなったり。たとえば、レビューのタイミングや粒度も人によってまちまちになるなど、プロセスがバラついてしまうという問題が生じました。

門田：すごく分かります。

永石：人が増え、チームが増えていくと、小さい組織だった頃には問題にならなかったちょっとしたことが、プロダクト全体の生産性にまで悪影響を及ぼしてしまうんですよね。

そこで私たちは、新たに「プロダクトオペレーション」という役割を立てることにしました。具体的には、プロダクトオペレーションが「データ活用促進」「ドキュメント整備」「プロセス最適化」を担うことで、プロダクトマネジメントサイクルを効率的に回そうと考えたんです。

永石：「データ活用促進」でいうと、たとえば、データ分析勉強会を開いて、実際にデータ分析を行う上で必要になる情報をみんなで学んだりしましたね。あとは実際にデータ分析を行う上でのスキルが伴わない人には、プロダクトオペレーション側からヘルプ窓口を用意し、得意な人間が伴走して自走できる状態まで持っていくといった取り組みを行いました。

これはほんの一例で、他にも様々な取り組みを行っていますが、いずれにせよプロダクトオペレーションが、横断目線でプロダクトマネジメントプロセス効率化のために動くことで、組織がうまく回り出したという実感がありますね。

永石：まとめです。今回のセッションのテーマは「プロダクトづくりを円滑にするためのさまざまな仕組み」ですが、本当の理想を言ってしまえば、そんな仕組みなんかなくても、メンバー各々が自律分散的に動いて最大のバリューを出せたら最高ですよね。

でも、組織が拡大していくほどそれが難しくなってくるので、何かしらの仕組みやルール、新たな役割が必要になる。今回の3社の事例を通して、今まさに組織のあり方に悩んでいるPdMの方々のヒントになれば幸いです。本日はありがとうございました。

お知らせ｜プロデザ室は仲間を募集しています

プロダクトデザイン室の募集情報は〈こちら〉のサイトからご確認いただけます。ぜひご一読ください☆
https://blog.recruit-productdesign.jp/

お願い｜noteのフォローをお願いします！

こちらのnoteアカウントをまだフォローしていない方！ぜひフォローしてくださいね。皆さんのキャリアやお仕事に役立つ記事を発信していますので、絶対損させませんよ！！！

お願い｜できれば公式X（旧twitter）もフォローをお願いします

プロダクトデザイン室の公式X（旧twitter）ではイベントの見どころやオリジナルコンテンツを更新しています。ぜひフォローしてください。
https://twitter.com/Recruit_PD_PR