こんにちは、estie（エスティ）VP of Productsのtakuya__kuboです。
今回は、「コンパウンドスタートアップに不可欠なテクニカルプロダクトマネージャーの正体」について書かせていただきました。
昨今、テクニカルプロダクトマネージャーという役割が存在感を増しているように思える一方、本ポジションは企業によっても役割定義が異なっており、日本ではまだまだ未成熟な部分が残されているように感じます。
本ブログでは、「estieがテクニカルプロダクトマネージャーに対して求める役割と期待・可能性」についてお伝えをしたいと思っています。
テクニカルプロダクトマネージャーの一般的な定義
こちらの記事を参照すると下記のように書かれています。
A technical product manager (PM) is a product manager with a strong technical background that is typically focused on the more technical aspects of the product. A technical PM works more closely with the engineering team than the business, sales, and marketing teams of the organization.
テクニカルプロダクトマネージャー（TPM）は、通常、製品の技術的な側面に焦点を当てた、強力な技術的バックグラウンドを持つプロダクトマネージャーです。テクニカルPMは、組織のビジネス、営業、マーケティングチームよりもエンジニアリングチームと密接に連携し、製品の技術的な側面により注力します
プロダクトマネジメントはビジネス・テクノロジー・顧客に対して広範囲な業務を含有しています。そのためプロダクトが大規模なものに成長すると、それぞれの業務を少しずつ2-3名のプロダクトマネージャーで分け合うことになります。
そうなった際に、他の文献でもあるように「ビジネスやユーザー領域に重心を置くプロダクトマネージャー」と「テクノロジー領域に重心を置くテクニカルプロダクトマネージャー」に分かれていくという1つの方法論として、その存在が示唆されています。
この考え方はとても合理的である一方、プロダクトマネージャーのキャリアラダーの考え方やJD等の制度設計も含めて極めて慎重に行う必要があると思っています。
日本は元来メンバーシップ型の雇用が一般的であり、その内面的な要請としてジョブディスクリプションに描かれていないことも要求しがちです。このJD分割を行うのであれば、企業の評価や職務の在り方も含めて細部にわたって変えていく必要があります。
また、記事にも書かれている通り「プロダクトに対してテクノロジー領域を担う」という役割分担が最適になるということは、それ相応の企業サイズ・組織サイズが要請されます。またそこに加えて、技術的な専門性を持つプロダクトマネージャーがいることで、プロダクトの価値やあり方を次のレベルに到達させられることが条件になります。
そういう意味では、十分な規模や技術的な専門性でプロダクトを昇華できない企業においては、テクニカルプロダクトマネージャーは不要と言えるでしょう。
これらは話し出すととても長くなりそう＆少し脱線してもいるので、PM組織論やJDの分化についてのブログをいつか書きたいと思うので、後の自分に託します。笑
estieでも同様に「テクニカルプロダクトマネージャー※」を採用しておりますが、上記のような定義（既存のプロダクトマネジメントを分化させた結果として「テクノロジー領域に重点を置くプロダクトマネージャー」）にはしておりません。
※現在の職種名は「プロダクトマネージャー（データ基盤／API基盤）」
estieでは「規模拡大の結果、テクノロジー領域に特化する」という役割ではなく、「コンパウンドスタートアップ」や「マルチプロダクトを保有する企業」において不可欠な人材であると考え、別の役割を設定しています。
今回ブログを書こうと考えたのも、今後、より一層必要とされるであろう本ポジションについて積極的に意見交換し、議論していきたいという意図から始まったものです。
estieにおけるテクニカルプロダクトマネージャーの役割
estieにおけるテクニカルプロダクトマネージャーは、コンパウンドスタートアップにおいて鍵となる「プラットフォーム領域」を担うプロダクトマネージャーであると定義しています。
Whole Productとプラットフォーム領域について
estieはコンパウンドスタートアップとして、創業期からマルチプロダクトを構想していた企業です。その実現に向けて「Whole Product構想」を掲げ、昨年11月から「Data Platform（基盤データ）」と「ミドルウェア」の開発に着手してきました。 コンパウンドスタートアップとして、どのような観点がポイントになるかというお話の詳細は、estieが追い求める「Whole Product構想」-マルチプロダクト戦略から1年後の今- - estie inside blogや【実践編】コンパウンドスタートアップの作り方 - estie inside blogでも記載されているので是非ご覧いただきたいのですが、ここでもプラットフォーム領域がいかに重要であるかを簡単にお話させていただきます。
- コンパウンドスタートアップは、「基盤データ」と「ミドルウェア」を活用することで統合的な体験を実現する
- コンパウンドスタートアップは、「基盤データ」と「ミドルウェア」を活用することでスケールメリットを生かし、複数SaaSを導入するよりも割安に利用できる
- コンパウンドスタートアップは、「基盤データ」を活用することで新たなサービスや価値をユーザーに提供する
このように、「基盤データ」と「ミドルウェア」といったプラットフォーム領域がいかに重要かがわかるかと思います。
プラットフォーム領域でこの1年間で取り組んだアジェンダ
上記のWhole Productの図にある、Data PlatformからMiddlewareにかけて、この1年で取り組んだ3つの事例を紹介させていただきます。
データプラットフォームの構築に向けた、基盤の再構築
2022年までは、estieマーケット調査（旧estie pro)という単一プロダクトの為に構築されていたデータパイプラインを、複数のプロダクトで活用で可能な形にするために基盤の移行を実施しました。
これにより今後estieで創出された新たなプロダクトは、estie内に保有するデータを活用可能な体制になっています。これはコンパウンドスタートアップの基本となる「インテグレーション」を支えるものであり、estieのデータを「複利」で活用可能なものにするという取り組みです
共通ミドルウェアの概念整理と開発着手
そもそも「共通ミドルウェア」とはどの範囲なのかといった構想の整理や、技術課題の洗い出しなどからスタートし、その中でも特にインパクトが強いものを次々に着手しています。
その中でも、代表的なプロジェクトが認証・認可の基盤化です。
今まで認証・認可の基盤は各プロダクト別に異なるものでしたがそれを23年に共通化していきました。実際にestieには6つのプロダクトが社内に存在していますが、すでに4つは載せ替えが完了しています。
ミドルウェア基盤の中でここに一番最初に着手したのは、ユーザーへのデリバリー速度の加速と利便性の向上の2つが理由です。
estieは23年度に新たに6つのプロダクトに着手し、うち5つを既にリリースしており、コンパウンドスタートアップとしてものすごい速さでプロダクトをユーザーにデリバリーしております。
認証・認可の基盤構築により、新たに生まれたプロダクトは既存の顧客基盤を活用可能になっており、テストマーケ・クロスユース促進が加速度的に進んでいます。
ユーザーにとっても複数のプロダクトを共通のユーザーアカウントで活用可能なるため、今後の利用も非常に便利になると思っています。
プロダクト立ち上げ速度を10倍にするための開発基盤の構築
前述のとおり、estieは半年で4つのプロダクトを新たにリリースするほどにビジネスオポチュニティに溢れた企業になっています。同時に、そのオポチュニティをどれだけ生かせるかというのは重要なテーマです。
如何に早くプロトタイプ構築を行い、ユーザーデリバリーするかは認証・認可のお話し同様重要であり、その期間を短縮するということはestieにとって至上命題の一つになります。
開発基盤の構築でチャレンジしているのは、「現在平均2カ月程度かかるプロダクト開発を1週間で出来る環境にする」ということです。
インフラの立ち上げ、認証・認可等のミドルウェアのプリセット、テンプレートやコンポーネントの整備など広範囲における開発基盤を作ることで、開発チームがカンタンにプロトタイプを作り、ユーザーに使ってもらえる状態を作りに行っています。
上記のように、estieがコンパウンドスタートアップとしてWhole Product構想を実現するためにレバレッジの効かせられるテーマがまだまだ存在しています。同時に現時点では我々に見えていないテーマが複数存在していると考えており、これからジョインいただくテクニカルプロダクトマネージャーの方がきっとディスカバリーをしてくれると思っています。
プラットフォーム領域を担うのはテクニカルプロダクトマネージャーがふさわしい
このプラットフォーム領域のプロダクトマネジメントは、技術バックグラウンドを保持する「テクニカルプロダクトマネージャー」がふさわしいと考えています。
プラットフォーム領域は、ドメインが要求するビジネスロジックを踏まえながら、互換性や保守性や性能効率性などのシステム品質（品質特性・アーキテクチャ特性）をどこまで持たせるかといった技術側面での意思決定を適切に行っていく必要があります。
現状、ミドルウェアのプロダクトマネジメントは私が兼務しており、データプラットフォームのプロダクトマネジメントはVPoEのShinが兼務しております。
私は、元々ビジネスバックグラウンド（入社エントリ）ということもあり、技術領域の知見に関しては「自らがこのポジションに要求したいと思っている水準」に達していないと自認しています。
エンジニアリングセクションと共に課題のディスカバリーをしたり、目指したい成果を定義することはある程度できますが、テーマ間の依存関係の整理や、ロードマップ構築、アウトプットや解法の特定・意思決定に苦労するシーンが多くあります。
また、Shinは元々エンジニアバックグラウンドではあるものの（入社エントリ）、プロダクトマネジメントだけではなく、エンジニアリングマネージャーとしての役割や、事業部CTOとして技術的な意思決定をリードするなど複数の役割を持っているため、どうしても手薄になりがちです。
上記の背景もあり、プラットフォーム領域を支えestieのプロダクトにおけるスケーラビリティとスピードをより一層広げていただく人材が不可欠だと思っています。
テクニカルプロダクトマネージャーに求められる要件
estieにおけるテクニカルプロダクトマネージャーは、エンジニアリングバックグラウンド、特にデータ基盤やAPI基盤の設計・開発・マネジメントを行ってきた方がふさわしいと考えています。
一方で、エンジニアとしてそれらを担ってきたことに限定されるというよりは、プロジェクトマネジメントやアーキテクト、データアナリストとしての関わり方も該当すると考えています。
そういったご経験をお持ちの方は、大企業のプロダクトカンパニーやコンサルティング会社に多く在籍されているのではないかと思うのですが、「これからのテクニカルプロダクトマネージャーの可能性」に賭けて、チャレンジしていくファーストペンギンになれる方が必要なのではないかと考えています。
プラットフォームを支えるテクニカルプロダクトマネージャーはこの先より必要となる
マルチプロダクトを展開するコンパウンドスタートアップには必要不可欠
海外の巨大なプロダクト企業と比較するのは流石にスケールが異なるものの、Salesforceはじめ各社には必ずプラットフォームチームが存在します。すなわち、マルチプロダクトを中心に成長する企業にとってそういったPMは絶対に必要です。
日本においてもメガベンチャーや大きなプロダクトカンパニーではそういったチームがもちろん存在していますが、これまでは、①プロダクトが複数生まれる→②効率化の観点で基盤を作りたくなる→③プラットフォームチームが構築されるという順番で生まれていました。
しかし、これからは違います。弊社の様に初期からマルチプロダクトを展開し、より大きな課題解決を実現しようと考えるコンパウンドスタートアップが次々に生まれはじめています。そういった企業には初期から「プラットフォームチーム」が必要であり、そこにはテクニカルプロダクトマネージャーが求められます。
これからのプロダクトカンパニーには必須と言える存在ではあるものの、現状はまだまだ未開拓な領域であることも事実です。ある種マーケットを広げる可能性のある人材といえます。
将来的にはVP of Platformなどという役割になっていくでしょうし、今後のプロダクトマネージャーの主要なキャリアの一つになるのではないかと思っています。
さいごに
ここまで拙いながらもこの1年を通じて見えてきた「テクニカルプロダクトマネージャーの正体」について述べてまいりました。
まだ未開拓な領域ですが、この可能性のある大きなチャレンジをしてくれる人がマーケットに増えてほしい。そしてestieにめっちゃ来てほしいと心から思っています。
「まだちょっとよくわからないけど、面白そうだから話してみよう」という方、また、「候補者にこういうキャリアオポチュニティがあるのだということを伝えたい」と思うエージェントの皆様も是非お話させてください。
一緒にこの新たな役割の可能性を広げていきましょう。
