エンジニアは「How」、PMは「Why & What」ならばTPMは？メルカリのプロダクト開発における“位置づけ”

「テクニカルプロダクトマネージャー（以下、TPM）」とは、プロダクトマネジメントにとどまらず、テクニカル面からプロダクトを管理・進行する役割。メルカリグループでも2020年から本格的に導入し、現在も多様なメンバーがTPMとして活躍しています。

しかーし、気になるのはその“位置づけ”です。TPMという言葉から「プロダクトマネージャー（PM）とエンジニアの間に立つ」ようなイメージは持てるものの、具体的にどんな業務を行っているのかはまだわかりにくい印象もあります。

そこで今回は、メルカリへTPMとして入社し、現在はFoundation ProductチームとPlatform Productsチームでそれぞれプロダクト開発に関わる丸山素良（@Sora）とCamy Tsukamoto（@camy）に話を聞いてみました。

各チームで働くTPM同士で定期的に情報をシェア

ーお2人とも、前職までずっとPMをしていましたよね？ TPMとしてメルカリへ入社することになった経緯は何だったんですか？

@Sora：私はこれまで外資系IT企業でPMとして働いていました。なので、ロールモデルになるような多種多様なPM像を見てみたいと思っていたんです。そのなかでもTPMは、エンジニアのパートナーとして問題解決するポジションだと認識していました。

メルカリへの入社を決めたのは、CTOである名村さんがエンジニア組織に関して「モノづくりにベストな組織体制へ変えていく」と話していたことに興味を持っていたから。「メルカリなら、PMのロールモデルも、モノづくりにベストな組織もすべて体験できる」と感じたんですよね。また、Eコマース事業も経験しておきたかった気持ちもあり、メルカリへジョインしました。

丸山素良（Foundation Productチーム、@Sora）

@Sora：現在、メルカリではProduct/Foundation/Platformに分かれたCamp体制（エンジニアリング組織の生産性を高水準に保つためにメルカリで取り入れている独自の組織構造）で開発を行っています。私はその中にあるCamp4のFoundation Productチームで、おもにメルカリからお客さまへ送信されるメッセージをカスタムできるツールを提供。メッセージング体験の多様化やパーソナライゼーションに関する機能開発に携わっています。

ー@camyさんはどうですか？

@camy：私はメルカリのヘビーユーザーでした。だから「より使いやすくするためにはどうすればいいか？」のアイデアを勝手ながらいろいろ考えていたんです（笑）。そして、思いついた機能を実装できたら楽しいだろうなぁと思い、メルカリへ入社しました。データ周りの経験があったため、面接時で「TPMのほうが向いている」と言われ、TPMへキャリアチェンジ。今は直接的に機能開発しているわけではなく、Platform Productsチームで、データドリブンに開発ができるようサービス基盤を整える業務を担当しています。

@Soraさんと私は、チームは異なりますが、業務の中で重なる部分も多いです。そこで、プロダクト開発での知見をシェアしあったり、テストの方法・結果を報告するなど、わりと密にコミュニケーションしています。ランチやコーヒータイム、TPMの集まりなど、会う機会も多いです！

Camy Tsukamoto（Platform Productsチーム、@camy）

@Sora：メルカリでは、TPM同士で困ったことを話し合える風土が根付いています。私と@camyさんはもともと知り合いだったこともあり、週1回ペースでキャッチアップしています。プロダクトで悩んでいること、日々のプロダクトマネジメントのアクティビティについて、エンジニアとのリレーションシップについてと…。キャリア視点から今後取り組んでみたいことなど、わりとなんでも話しています。

@camy：私はメルカリグループが原則在宅勤務体制になってからオンラインで入社しました。@Soraさんが週次でキャッチアップしてくれたり、わからないことをサポートしてくれたりして、スムーズに馴染めましたね。

TPMは「プロダクト全体の本質を追求」「エンジニアとペアになり、より良いものをつくる」

ーお2人とも当初からTPMとしてメルカリへ入社していますが、ご自身の位置づけをどう考えていますか？

@Sora：私にとってTPMは、情報を理論的に整理し、プロダクト全体の本質を斬新な視点から追求する役割だと考えています。同時に、この職種はPM全体のレベルを底上げする存在でもある。ただ、現状では、TPMは集団としての体系的な認知が低いので、存在意義自体をブランディングする必要があると思っています。

私がメルカリへ入社したときも、社内でのTPMの認知度は高くありませんでした。だから、当時は今よりもTPMを求めているチームも少なかったんです。そのため、入社してすぐのころは、「自分は何ができるのか」「チームに貢献できることはなにか」を考えながら課題解決の手伝いをし、信用を少しずつ得るように意識しましたね。

ー@camyさんは？

@camy：私の場合、TPMは、エンジニアとペアになっていいものをつくっていく位置づけです。PMは「Why & What」のパート、エンジニアは「How」のパートと言われていますが、「なぜこのプロダクトが必要なのか」「どうやって誰が使うのか」「他のユースケースがあればさらに理解を深める」という役割をTPMが担っています。

入社してすぐは、最初の段階でいかに信用を勝ち取るかが勝負どころだなと思っていました。私の場合、入社してアサインされたチームのエンジニアたちがとても優秀で、正直に言ってしまうと、TPMの存在価値を感じにくい場面も多かったんです。だからこそ、信頼してもらうためにしっかり時間をかけましたね。「信頼」と言っても、エンジニアリングのリーダーシップの信頼や現場のエンジニアの信頼、ほかのPMを含むいろんなステークホルダーの信頼があり、すべてを獲得するのは難しいところもありますが。

ーTPMに限らず、業務を進めるうえでメンバー同士の信頼関係は必要不可欠ですよね。特に話し合う機会の多いエンジニアとのコミュニケーションで心掛けていることは？

@Sora：私の場合は、物事を言い切らないようにしたり、「あなたの意見は？」と聞くことは大事にしたりしています。エンジニアがどのように物事を実行するかについて「私は踏み入らないように注意するべきで、踏み入るべきじゃないと思っている」というスタンスを要所要所で表明していますね。

@camy：@Soraさんと同じく、コミュニケーションをするうえではエンジニアの意思を尊重し、お互い気持ちよく仕事ができるよう心がけています。本当に良いプロダクトをつくるためにはエンジニア、PM、デザイナーのコラボレーションは欠かせない。エンジニアとデザイナーの合意を取りながらプロダクトビジョンにまとめるために、相手に合わせたコミュニケーションにアジャストするのは重要ですね。

お客さまに合わせて、社内メンバーも多様にしたほうがいい

ーお2人が入社したばかりのころは「社内でもTPMの認知度が低かった」と話していましたよね。では、今後は社内での認知度を上げていく？

@Sora：TPMは、PMという広域な役割の1つです。いろいろな定義や解釈があるので、どんな価値提供ができるのかがわかりにくい。だからこそ、私は「TPMにはものづくりにおけるパートナー」と認識してもらいたい。機能改善に特化した開発についても、今までのメルカリではエンジニアのみで進められているところがありました。機能改善で行う削る作業（使われていない重複したロジックを消す、終了した機能を取り除く）は、機能追加と同じくらいプロダクトに影響する大事な部分。今後はもっと、企画段階から混ぜてもらえる機会を増やしたいですね。

@camy：私も、@Soraさんと同じように、プロダクトに影響するものにはなるべく初期段階から関わりたいというのが本音です。また、TPMの多様性はバラエティに富んでいますが、女性メンバーはまだまだ少ない。プロダクト開発をリードする観点に多様性を取り入れることはとても大事なので、もっといろいろなバックグラウンドを持つメンバーを巻き込んでいきたいです。

@Sora：進太郎さん（メルカリ代表取締役CEO、山田進太郎）が言うように、お客さまに合わせて、メルカリ社内も多様性をもっと高めていったほうがいい。現場だけでなく、経営層でも女性比率が高くなれば、もう少し議論が活発になり、スピーディーに変革がもたらされるように思います。

ーそんなメルカリのTPMには、どんな人が合っていると思いますか？

@camy：自分で課題を見出すプロアクティブなマインドセットの人、エンドユーザーの課題を解決しようとする際にブロッカーがあっても諦めず、良いプロダクトをつくりたいと言う気持ちを強く持てる人でしょうか。加えてビジネスや数字に強く、熱意がある人がTPMに向いていると思います。

@Sora：TPMって何かの才能に長けているというよりも、人よりちょっと情熱的であることの方が大事だと思っています。そして、過去のポジションに関わらず自分で現場に飛び込み、道を切り拓いていける人の方が向いているかな、と。本当の意味で価値があるプロダクトは何かと常に考えて追求する姿勢、俯瞰した視点を持つことこそTPMには必要だと思っています。