この記事は プロダクトマネージャー Advent Calendar 202512日目の記事です。
プロダクトマネジメントに向き合っている方が、日々の意思決定を整理する際のヒントになれば幸いです。
Sansan株式会社Sansan事業部VPoPの川瀬です。
最近は、AIエージェントやMCPサーバーに向き合う日々を過ごしています。国内外の流れが凄まじいですね。「未来」が日々更新されていて、楽しいです。
一方で、機能廃止やパフォーマンス改善、四半期ごとのチームの注力領域の見直し、既存プロダクトの再編成といった土台整備にも力を入れて取り組んでいます。
これらは何かの事象に対する場当たり的な反応として取り組んでいるわけではなく、「今やるべき」と判断した結果ですが、改めて言語化してみました。
それが、システム x エンジン x インパクトという三層構造と、その循環です。
プロダクト価値は、単に機能開発を積み上げるだけでは最大化できません。
ここでは、プロダクトマネジメントとして向き合っている全体像を整理してお伝えします。
システム
「価値が生まれる仕組みそのもの」をつくる層
[システム]
├─ 戦略（ターゲット・課題・ポジショニング）
├─ 実行基盤（組織構造・意思決定・プロセス）
└─ 経済モデル（収益モデル・コスト構造・LTV）
システムは、価値が正しく、かつ継続的に生まれるための土台です。ここが揺らいでいると、どれだけ施策を積み重ねても価値は安定的に伸びません。システムは、プロダクトマネジメントの本丸の一つだと思っています。内部的な仕組みだけではなく、とくに戦略システムはプロダクトマネージャーが日々ユーザーに価値を届けるために向き合っている領域そのものです。
戦略
AIや自動化の進展により、顧客が抱える課題も、それに対して期待する「理想の体験」も急速に変化しています。
- どの顧客の
- どの課題に対し
- どのような体験を届けるプロダクトとして存在するのか
この問いに向き合うことが、戦略の中心です。既存プロダクトと新規ソリューションの役割を定義しなおし、ユーザーがプロダクトをまたいでも「連続した価値体験」を得られるように、データ構造やユーザー体験を設計することも含まれます。
実行基盤
機能廃止やプロダクト再編成、負債返済の仕組み化、クロスファンクショナルな意思決定プロセスの改善、四半期ごとのチーム編成など、すべては 「良いユーザー体験を、速く・安定して届ける構造」 をつくるためのものです。
開発が遅いのではなく「遅くせざるを得ない構造になっている」ケースは多く存在します。
- 機能が増えすぎてユーザー体験が複雑化
- チームの境界で体験が途切れる
- プロダクト負債によりパフォーマンスが低下
- 意思決定が遅く改善が滞る
これらはすべて「体験を悪化させる内部要因」です。
実行基盤は、それらを取り除き、価値が流れる状態を作るための仕組みです。
経済モデル
顧客が価値を感じるポイントと投資意欲は、体験と密接に紐づいています。
- 「効率化される体験」にどれほどの価値を感じるのか
- 「自動化」に対してどの規模で予算が動くのか
- 「高頻度で触れる体験」と価格の関係はどうなるのか
直近では、生成AIモデル利用やFDEのような価値提供において、コストをこれまで以上に意識する必要があります。だからこそ、自ら商談に入り、体験価値とユニットエコノミクスをCEOや事業責任者らと議論しながら、経済モデルを更新しています。これらのシステムが整っているほど、次に紹介するエンジンの効果が最大化されます。
エンジン
「価値がどれだけの速度と力強さで流れるか」を決める層
[エンジン]
├─ スピード（開発・提供・パフォーマンス）
└─ タイミング（市場・技術・ユーザー潮流）
システムが「価値が生まれる土台」だとすれば、エンジンは「その価値がどれだけ速く流れるか」を決めています。
自分は日々の意思決定の多くを、このエンジンにも紐づけて考えています。
スピード
スピードは「開発が速いかどうか」だけではありません。
自分はスピードを「開発・提供・パフォーマンス」の3つに分けて扱っています。
1. 開発スピード
仮説→実装→学習のスピードです。
プロダクトが重いと、このサイクルが必ず遅くなります。
そのため、機能廃止や構造の軽量化を継続的に行っています。
2. 提供スピード
ユーザーが価値を受け取るまでの距離を最短にすることです。
オンボーディング、設定、権限、連携など、提供の摩擦は価値の毀損につながります。
3. パフォーマンス
ユーザーが体感する速度そのものです。ミクロな観点では「提供スピード」とも言えるかもしれません。後述のインパクトにもつながります。
タイミング
タイミングとは「今だから最大価値が出るテーマ」に集中する力です。市場の成熟、技術の進化、顧客行動の変化が重なる瞬間があります。MCPサーバーは顕著で、まさにその“波の重なり”が訪れています。同じ施策でも、タイミングが違えば価値は何倍にも変わります。タイミングは、価値最大化において非常に強いレバーです。
インパクト
“成果”であり、次の改善を生む“入力”になる層
[インパクト]
├─ 質（課題解決度）
├─ 量（ユーザー数 × 利用頻度）
├─ 期間（継続利用）
└─ 売上（収益・更新）
インパクトは成果そのものであり、プロダクトマネジメントの最重要要素の一つです。
インパクト自体は、いろいろな観点やフレームがあるのでここでは深掘りしませんが、自分はシンプルに「どれだけ深く課題を解決できたか（質）」「どれだけの数と頻度で使われているか（量）」「どれだけ長く使い続けてもらえているか（期間）」「どれだけの金額が動いているか（売上）」の4つで捉えています。詳細な指標設計や見方については、また別途まとめようと思います。
さらに、自分はインパクトを「次のシステムとエンジンを更新するための重要な入力」として扱っています。
- 事前にインパクトの予測を置き
- 実績との差分を分析し
- システム（戦略・実行基盤・経済モデル）や エンジン（スピード・タイミング）に還元する
インパクトはゴールではなく、循環を回すスタート地点でもあります。
システム → エンジン → インパクト → システム
この三層は因果関係の連鎖を表しています。システム（構造）がエンジン（能力）を
規定し、エンジンがインパクト（成果）を生み出す――上流の質が下流の最大値を
決めるため、価値最大化には三層すべてへの同時的な投資が必要です。
[システム]
├─ 戦略（ターゲット・課題・ポジショニング）
├─ 実行基盤（組織構造・意思決定・プロセス）
└─ 経済モデル（収益モデル・コスト構造・LTV）
↓ システムが強いほど エンジン が効く
[エンジン]
├─ スピード（開発・提供・パフォーマンス）
└─ タイミング（市場・技術・ユーザー潮流）
↓ エンジン が インパクト を押し上げる
[インパクト]
├─ 質（課題解決度）
├─ 量（ユーザー数 × 利用頻度）
├─ 期間（継続利用）
└─ 売上（収益・更新）
↓ インパクト の予測・結果がシステムとエンジンを進化させる
どう活用しているか
上記の考え方は、例えば以下のように活用しています。
プロダクトの状態診断
1. インパクトが出ない → システムorエンジンに根本原因
2. エンジンが回らない → システムの課題を疑う
3. システムもエンジンも良好なのに成果が出ない → インパクト指標の再設定
投資優先度の判断
- システムへの投資 = レバレッジ最大、効果は遅効性
- エンジンへの投資 = 即効性あり、ただしシステムが前提
- 両方が脆弱 → システムから着手
おわりに
自分はプロダクトマネジメントにおいて「単発の施策」ではなく「構造と循環」こそが価値を最大化すると考えています。
- システムが価値が生まれる仕組みをつくり
- エンジンがその価値を加速し
- インパクトが成果を示し、同時に次の改善を生む
この循環を回し続けることが、プロダクトの価値を次のステージへ押し上げるための最も重要なアプローチだと考えています。
まだまだやり切れていない部分も多々ありますが、このようなことを考えながら取り組んでいます。ふわっとした頭の中の言語化の良い機会になりました。
今回は考え方中心で具体事例などはあまり含めなかったのですが、また別途書こうと思います。
そして、システム、エンジン、インパクトを生み出す・動かすエネルギーは「人」ですね。それもまた別途書こうと思います。
もしもっと知りたいポイントなどがあれば、XでポストやDMしていただけると嬉しいです。イベント参加やディスカッションの機会もお待ちしています！
ありがとうございました！
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひ 【Sansan】カジュアル面談申し込みフォーム をご検討ください。
