はじめに

こんにちは。カケハシで生成AIプロダクトの Product Lead/PdM をしている高梨です。

つい最近、我々のチームにAI技術に特化した　AI Tech PdM がJOINしてくれました！！

迎え入れた経緯や詳細な理由をここで細かく語ることはできないのですが、端的に言えば、急速に進化する生成AIを複数機能としてプロダクトに組み込むにあたり、プロダクトを持続可能な形で開発するためには、実現技術とAIの精度に責任を持つ人材が必要不可欠と考えたためです。

この記事は、我々のチームにおける（我々が開発しているAIプロダクト開発における）PdM と Tech PdM の役割の違いと責任分解について、チームに伝達した私なりの意見をブログ記事にまとめなおしたものとなります。

Tech PdM（テクニカルプロダクトマネージャー）とは？

まずは一般的な定義として、PdM と Tech Pdm の定義の違いを確認しておきます。

PdM は、プロダクトが市場に届ける価値に責任を持つ役割です。顧客の課題を深く理解し、その課題を解決するプロダクトの「What（何を作るか）」と「Why（なぜ作るか）」を定義します。市場動向の把握、ユーザーリサーチ、ビジネス要件の整理、ステークホルダーとの合意形成、そしてプロダクトロードマップの策定などが主な責務となります。

一言でまとめると、PdM は「このプロダクトは誰のどんな課題を解決するのか？そしてそれはビジネスとして成立するのか？」に答え続ける存在です。

一方で Tech PdM は、プロダクトの技術戦略・技術的意思決定に責任を持つ役割です。PdM が「何を・なぜ作るか」に責任を持つのに対し、Tech PdM は「どのような技術で・どのようなアーキテクチャで実現するか」、つまり「How（どう作るか）」の中でも特に技術選定やシステム設計といった上流の技術的意思決定を担います。

極論を言えば、「最新の市場動向と最新のテクノロジー動向、どちらに向き合うか？」と問われた時、PdM は市場動向に、Tech PdM はテクノロジー動向に向き合う人材です。

AI Tech PdM が必要な２つの理由

Tech PdM の一般的な定義を踏まえた上で、次に「なぜ "AI" Tech PdM が必要なのか？」を整理しておきます。

AIプロダクトと従来のソフトウェアプロダクトの違い

まず、AIプロダクトと従来のソフトウェアプロダクトの違いを整理します。

AIの非決定性により、"良い品質" を担保する絶対条件が存在しない。良い品質はユースケースや機能単位で定義され得る
従来のソフトウェアエンジニアリングにおけるシステム最適化とは別にAI部分だけを切り出した最適化が存在する
通常のシステムメトリクスのモニタリングに加え、AI特有の品質メトリクスの継続的なモニタリングが不可欠（MLOps, LLMOps）
生成AI領域は技術の進化スピードが非常に速く、数ヶ月単位でベストプラクティスが陳腐化し得る。それゆえに定常的に技術プラクティスを切り替える開発サイクルにならざるを得ない
モデルプロバイダーを利用することも多く自社でコントロールし得ない要素が相対的に大きい

カケハシのAIプロダクトや開発チーム特性

次にカケハシのプロダクト固有の特性を整理します。

医療というミッションクリティカルな領域であり、AIの不確実性がサービス品質のリスクに直結しやすい。単純な精度追求ではなく、医療安全性と利便性のトレードオフを最適化した "良い塩梅" の品質が求められる
医療の現場業務に深く浸透するAIであり、応答速度や複数モダリティへの対応が重要
Musubiという医療の基幹系システム上で動くAIであり、基幹系システムへの影響を最小限にするために Complicated Subsystem & Microfrontend として切り出されている
医療領域では要配慮個人情報という個人情報の中でも更に一段シビリティの高い情報を扱うため、AI活用においてもシステム・運用・ルールの各面で一貫した個人情報保護が求められ、AIガバナンスの重要性が非常に高い

AIプロダクト固有の技術的複雑性に加え、医療領域ならではの品質要求やガバナンスの厳しさを踏まえると、通常のPdMや従来のソフトウェアエンジニアリングの延長線上では対応しきれない領域が確実に存在します。この領域に対して専門的に向き合い、技術的な意思決定を担う人材として、AI Tech PdM が必要と考えました。

AIプロダクト開発チームで定めたAI Tech PdM の役割とPL/PdMとの責任分解

大前提として、カケハシでは、どんな形であれプロダクトを市場に届ける際の最終責任は PL/PdM が担います。プロダクトや機能を市場に出すということは「市場と顧客」に直接届くことになるからです。そのため、 AI Tech PdM が判断したからといってそのままPL/PdMとの合意なしに実装されて市場に出ることはありません。

しかし、プロダクトを開発する過程においては必ず、「この課題に対して技術的にはどうするんだっけ？」という "課題解決の技術的なHow" を検討するシチュエーションが発生します。

こういったシチュエーションにおいては、その "技術的なHow" をどうするのかを意思決定する人間が必要であり、特にAIの技術領域においてその判断責任をAI Tech PdM が担います。（「特にAIの技術領域」と記載した理由は後述）

AIプロダクト開発チームでは、以下の５つをAI Tech PdM の責任範囲と定義しました。

AI Tech PdM の５つの責任範囲

1. AIプロダクトにおける精度・レイテンシ・コストのトレードオフの最適化

AIプロダクトの開発中、そしてサービスの運用保守において、様々な課題が発生します。その中でも特に大きなウェイトを占めるのが、精度・レイテンシ・コストのトレードオフです。

この課題に対するアプローチは多岐にわたります。UI/UXの改善によってユーザー体験側から吸収する方法もあれば、モデルグレードの見直し、Agentic Workflow の改修、プロンプトエンジニアリングやコンテキストエンジニアリングといった技術的な手段もあります。

AI Tech PdM は、この中でもモデルグレードの選定や Agentic Workflow の設計、プロンプト/コンテキストエンジニアリングといった技術的視点での課題解決案の立案・実行に責任を持ちます。

最終的には、AI Tech PdM による技術判断と、PdM による市場・顧客視点の判断（UI/UXの方針、市場動向、事業性など）をミックスし、実行施策を総合的に意思決定します。

2. LLM Ops による継続的なメトリクスの把握と改善施策の立案

AIプロダクトの価値を継続的に高めていくためには、適切なメトリクスを定義し、計測し、改善サイクルを回し続ける必要があります。

この領域における責任分界は以下のように整理しています。

まず、プロダクトのNorth Star Metric（NSM）はPdMが決めます。プロダクトが市場に届ける価値の最上位指標であり、これはPdMの責任範囲です。

そこに繋がる関連KPI（サインポスト指標）やガードレール指標については、PdM・AI Tech PdM・エンジニアが三者で一緒に考えます。プロダクトの価値指標と技術的な計測可能性の両面から検討する必要があるためです。

そして、それらの指標を実現するための具体的なLLM Ops 基盤や Observability の設計、各指標の導出ロジック、サインポスト指標やガードレール指標の実装優先順位、各指標の感度の見極めについては、AI Tech PdM が責任を持って判断します。

3. 複数モダリティを扱うAIプロダクト開発における技術と知見の第一人者

少なくとも現時点でも、我々のプロダクトでは音声・テキストという複数のモダリティをAIで扱っています。将来的にはここに動画や画像といったモダリティも加わってくることが見込まれます。

こうなると、単にLLMに対する知見があるだけでは不十分です。音声認識や画像処理といったモダリティごとの専門知識が求められます。さらに、技術的な実装方式に関する知見だけでなく、ユーザーがプロダクトを活用してサクセスするための支援的な側面、たとえば「この精度であればユーザーにどう提示すべきか」「音声を扱う上でユーザーをサポートするためにどのようなオンボーディングマテリアルが必要か」といった観点まで含めた知見が必要になります。

AI Tech PdM は、テキストに限らない様々なモダリティをAIで処理するための専門知識を身につけ、その知見をもってPdMやPMM、ユーザーサクセスやカスタマーサクセスが顧客に価値をデリバリーするために必要な専門的アドバイスを提供することに責任を持ちます。

4. プロダクトと事業の継続性のためのAI技術のR&Dおよび製品実装計画の立案

日本のSaaS企業の多くが、自社サービスの生成AI機能を OpenAI、Google、Anthropic といった国外のAIベンダーに依存しており、カケハシも例外ではありません。

生成AIの利用料はSaaSの変動費としてダイレクトに利益に影響するため、国外AIベンダーへの依存リスクは従来のクラウド基盤以上に大きいと言えます。加えて、我々のような医療プロダクトを開発している企業にとっては、データ主権や個人情報保護、経済安全保障の観点でも長期的には無視できない問題です。

AI Tech PdM は、この国外ベンダー依存を解消するためのR&Dにどこまで踏み込んで取り組むか、R&Dの先にある製品実装のスコープをどこまで広げるか、そしてそれによって事業継続性に対するリスクをどの程度低減できるかの見立てについて責任を持ちます。

5. 技術的な視点でのプロダクトロードマップに組み込むべき開発アイテムのプランニング

上記1〜4の責任を果たしていく中で、プロダクトロードマップに新たに加えるべき開発アイテムが必然的に発生します。技術的負債の解消はその代表例です。

日常的なリファクタリングの範囲では吸収しきれない、より大きな技術的課題、たとえばアーキテクチャの見直しや内部品質向上のための活動を洗い出し、PdMと議論の上でロードマップに組み込むことに責任を持ちます。

インフラ/アプリケーションアーキテクチャ、処理方式に対する責任は？

なお、インフラやアプリケーションアーキテクチャ、処理方式といった一般的ソフトウェアエンジニアリングに関する意思決定は、今回 AI Tech PdM の責任範囲には含めていません。

この領域は従来からチーム内の上級エンジニアが担ってくれており、ソフトウェアエンジニアリングの観点では必ずしもAIに特化した知見が必要とは言えないためです。また、会社として推奨する技術スタックやアーキテクチャは一定程度決まっており、そこに対する理解や社内での経験も重要な要素となります。

もちろん、AI Tech PdM や PdM も議論には参加しますが、この部分の最終的な意思決定に対して責任は負いません。

【余談】Tech PdM の組織論的解釈

AI Tech PdM に限った話ではないですが、Tech PdM の組織論的な解釈についても触れておきます。

Tech PdM はプロダクトチームに所属する人材なのか？エンジニアリングチームに所属する人材なのか？です。

過度に組織の縦割りを促進するつもりはありませんが、やはり会社の中で従業員のロイヤルティを高めるためには適切な組織構造やキャリアラダーへの組み込みが重要と考えます。

この問いに対する私の意見は、「Tech PdM はエンジニアリングチーム所属の人材に担うべき役割」です。一番の理由は、冒頭にも記載した通り、PdM は第一に「市場と顧客」に向き合い、Tech PdM は「技術」に向き合うからです。

一般的にPdMはプロダクトマネジメントトライアングルに代表されるように総合格闘技的能力が求められる職種で、様々な視点でプロダクト開発、ひいては事業に向き合わなければなりません。しかし、その中で「一番何を重視にするのか？」と問われれば、やはり「市場と顧客」だと思います。

極端な言い方をすれば、市場と顧客に一番に向き合わない人材はプロダクト人材とはせずに、テクノロジー人材＝エンジニアリングチームと捉えるべきでしょう。

また、人材流動性やキャリアマネジメントという観点でもエンジニアリングチーム所属の方が何かと都合が良いと考えます。

そもそも Tech PdM は「プロダクト人材の一類型」というよりは、上級エンジニアやテックリード、エンジニアリングマネージャーなどがその時の事業ニーズに応じて担う"役割" と捉える方がしっくりきます。実際の組織運営においてそこまで明確に線を引く必要はなく、あえて「Tech PdM」という専任ポジションを用意することに固執する必要もありません。

ただし、ほとんどの企業において、事業の成長とともに技術的負債や事業環境の変化に起因する技術的な成長ブロッカーが生じるはずです。代表的な例を挙げると、

事業成長を優先したことによる技術的負債（コスト増大、品質低下、開発スピードの鈍化）
レガシーシステムの刷新・リアーキテクチャ
M&A した企業との顧客ID統合や技術基盤の標準化
複数プロダクトに散在したデータの統合による横断的データ利活用

こういった問題は技術に起因するため、その解決策もその技術に精通した人間が意思決定を下す必要があります。そしてこれらの問題は、顧客獲得がひと段落して収益化に向けて筋肉質な組織にするフェーズや、事業を多角化するフェーズにおいて急激に重要度が増してきます。つまり、技術の本質的複雑性の高いプロジェクトが増えてくる企業の成長後期になるほど Tech PdM という"役割"の重要度は相対的に高まると考えます。

このように考えると、Tech PdM をプロダクトチームの専任ポジションとして固定するよりも、エンジニアリングチーム内の上級人材が事業フェーズや課題に応じて柔軟にこの役割を担う方が、組織としての人材流動性が保たれ、キャリアマネジメントの観点でも合理的です。

おわりに

この記事では、我々のチームにおける PdM と Tech PdM の役割と責任分解について紹介させていただきました。

正直なところ、こうした責任分解はまだ発展途上であり、実際に運用していく中で見直しや調整が必要になると思います。ただ、AI Tech PdM がチームに加わったことで、PdM である私自身がより「市場と顧客」により集中できるようになったのは間違いありません。技術的な意思決定を信頼して任せられるパートナーがいるというのは、AIプロダクト開発において本当に心強いことです。

また、生成AIの進化は留まるところを知らず、それ故にプロダクト開発においても日々難しい舵取りを迫られます。しかし、だからこそ刺激のあるエキサイティングなプロダクト開発を経験できていますし、様々な専門領域に造詣の深い人材と一緒に仕事をすることで私自身もどんどん新しい知識を吸収し成長を実感できています。

カケハシでは、こうした新しい変化を受け入れて、楽しみながらチャレンジしてくださる PdM や Tech PdM、エンジニア、エンジニアリングマネージャー、もちろんそれ以外の職種も多岐にわたり募集しています。もしご興味がある方は、ぜひカジュアルにお話しさせていただけると嬉しいです。

カケハシのプロダクトマネージャーの採用についてはこちらをご参照ください