見出し画像

テクニカルプロダクトマネージャー(TPM)という職種と、TPMになるにはどうすれば良いか考えてみよう

mikaji

TPMは技術を軸にしたプロダクトマネジメントの専門家

テクニカルプロダクトマネージャー（以下、TPM）という職種・ロールはご存知でしょうか？この記事では、TPMとは何か、TPMはなぜ生まれるのか、キャリアパスについて話せればと思います。

TPMとは

TPMについて、まずはPerplexity に聞いてみましょう。

テクニカルプロダクトマネージャーは、通常のプロダクトマネージャーの役割に加えて、より深い技術的知識と経験を持つ職種です。主な特徴は以下の通りです：

1. 技術的な専門知識：ソフトウェア開発、システムアーキテクチャ、データベース設計などの技術分野に精通しています。
2. 開発チームとの橋渡し：ビジネス要件を技術的な仕様に落とし込み、開発チームとのコミュニケーションを円滑に行います。
3. 技術的な意思決定：プロダクトの技術的な方向性や選択肢について、informed decisionを下す役割を担います。
4. 課題解決能力：技術的な課題を特定し、効果的な解決策を提案・実施します。
5. ユーザー視点と技術の融合：ユーザーニーズを理解しつつ、それを実現するための最適な技術ソリューションを見出します。

テクニカルプロダクトマネージャーは、プロダクト開発において技術とビジネスの両面を理解し、両者をバランス良く統合する重要な役割を果たします。

Perplexity より

昨今、プロダクトマネジメントをするPMという職種はかなり知名度を上げ重要なポジションとなってきました。一方、組織のサイズやプロダクトのサイズによってPMも複数人存在しチーム化、各メンバーにも専門性を求めるようになってきました。

そこで最近はPMも職能に応じて分業化し、PM・PMMに分かれるようなこともあります。

  • PM: プロダクトマネージャー

  • PMM: プロダクトマーケティングマネージャー

PMMは、マーケティング、ビジネス面に関してのマネジメントを担当し、PMはより狭義のプロダクトマネジメント（開発、デザイン、運用など）を担当します。TPMは、この場合のPMに近く、その中でもより開発に比重を置いたのが守備範囲だと考えています。

TPMの守備範囲


TPMはなぜ生まれるのか

TPMはなぜ生まれるのでしょうか。大きく2つが挙げられます。

1. 組織内に技術的に明るい人物がいない

PMが企画をし、それをプロダクトにおいて実現しようとした場合、技術的に実装可能なのか、どれぐらいの工数がかかるのかわからないことがあります。そんなとき、TPMがいることで企画・案件のボリュームとプロダクトの技術スタックなどから工数をある程度は算出することが可能です（そのためにはTPMに技術的なスキル、素養が必要になってくる）。

2. プロダクトグロースによるPMリソースの増加とメンバーの専門性を見出す

グロースを進める中で、プロダクト1つを取ってもたくさんのやりたいことが出てきます。その場合、PMの人的リソースを増加を検討しますが、ファンクショナルベースで縦割りでわけることもあれば、職能において前述のPM・PMMのような横で分業制を敷くこともあります。
TPMもその一環で、PMから派生し生まれます。

ファンクショナルベース（縦割り）と職能ベース（横割り）

TPMに必要なスキル

TPMになるにはどんなスキルを持つ必要があるでしょうか。プログラミング能力も必要なのでしょうか？実際に私も、元々はソフトウェアエンジニアとしてずっと働き、TPMにジョブチェンジしました。その経験から、TPMになるに必要なスキルについて考えてみます。

TPMに必要なスキルは以下の通りです。

  • プロジェクトマネジメントスキル

  • コミュニケーション能力

  • 技術的な理解力（not プログラミングスキル）

  • 問題解決能力とクリティカルシンキング

  • ステークホルダーマネジメント

TPMは、技術的にプロダクトの推進をするからこそ、その軸となるプロジェクトを進めるにあたってのマネジメントスキルは必要です。一般にはプロジェクトマネジメントとも呼ばれますが、より現場に近くどれだけボールを拾えるか、要求を満たすものを作れているのか、安全にユーザーにプロダクトを使ってもらえるのか、など細かく気にする点は多いです。

そのためには、各ステークホルダーのマネジメント・コミュニケーションも不可欠です。TPMにとってのステークホルダーは、組織により様々です。開発チームはもちろん、デザイナー、PMM、CS、などなどたくさん存在します。TPMだからといってステークホルダーが少ないなんてことはないです。

また、何よりも論理的に物事を捉え、疑い、整理する能力が最も重要だと考えています。要求は本当に正しいのか、企画を仮説検証できるような設計ができているのか、提示されたHowは本当に要求を満たせているのか、もっとシンプルで早くユーザーに届ける価値はないのか、常に疑い続け責任を持って決断するスキル・考え方は、とても大切です。

最後に、プログラミングスキルが必要かについて、これは自分が元々ソフトウェアエンジニアをやっていたからということもありあくまで一意見ですが、プログラミングスキルはなくて良いが、全く技術がわからないならTPMは難しいと思います。技術的な観点からのプロダクトマネジメントを求められているのにも関わらず、その観点がわからない、メタ的な意見しか言えないというのはあまり意味がなく、技術に踏み込んでそれを抽象化し伝える能力、それこそがTPMの価値であると考えています。

まとめ

今回は、TPMという職種と必要なスキルについて説明しました。
かっこよくつらつら書きましたが、本質的にはプロダクトマネジメントは泥臭く毎日続けるしかない仕事です。ただ、PM、そしてTPMという職種は専門性を突き詰められる職種でもあり、そんなTPMの活躍により世の中が良いプロダクトで溢れるかえったらハッピーです。

ここまで読んでくれてありがとうございました！

ありがとうございます！