はじめに

「なぜ小さくリリースして検証しないのか」

プラットフォーム開発の意思決定をしているとき、この問いに向き合うことがある。プロダクト開発では「小さくリリースしてユーザーの反応を確認する」仮説検証サイクルが有効な手法とされている。しかしプラットフォーム開発にこの手法をそのまま適用しようとすると、判断のズレを招くことがある。

この記事では、プロダクト開発とプラットフォーム開発の違いを「判断基準・設計思想・投資観点」の3つの観点から整理する。

定義：プロダクト開発とプラットフォーム開発とは

プロダクト開発とは

プロダクト開発とは、エンドユーザーに直接価値を届ける開発である。チームトポロジーの文脈ではストリームアラインドチームが担う。

なお、プラットフォーム開発も広義にはプロダクト開発の一形態である。ここでは両者の性質の違いを明確にするため、便宜上「プロダクト開発」をエンドユーザーへの直接価値提供に絞って定義している。

• 価値の受け手：エンドユーザー
• 価値の検証方法：「ユーザーが使ったか」「ユーザーの行動が変わったか」
• 有効なアプローチ：小さくリリースして反応を確認し、仮説検証を繰り返す
• 価値の実現タイミング：リリースのたびに段階的に実現される

仮説検証サイクル（Build-Measure-Learn）が有効なのは、ユーザーの反応という「フィードバック」が早期に得られるからである。不確実性を小さな単位で解消しながら進むことで、投資リスクを抑えられる。

プラットフォーム開発とは

プラットフォーム開発とは、他のシステムやチームが「乗ること」で価値が実現される基盤を作る開発である。チームトポロジーの文脈ではプラットフォームグルーピングと呼ばれるチームが担う。

これらの違いは、プラットフォーム開発に固有の判断基準・設計思想・投資観点を形成する。以降、それぞれを詳しく見ていく。

判断基準の違い

プロダクト開発で仮説検証サイクルが有効な理由は、「ユーザーが本当に使うか」がリリースしてみないと分からないからである。プラットフォーム開発では、この前提が異なる。

• 受け手の違い：プラットフォームの判断基準（SLOを満たすか・他のシステムが安全に採用できるか、など）は、仕様のヒアリング・設計レビュー・負荷試験などで設計・実装段階で確度高く検証できる。リリースして反応を見る必要性が低くなる
• N数の違い：プロダクト開発は対象ユーザーのN数が大きくヒアリングのN数を上げにくいため、小さくリリースして反応を見ることが王道になる。プラットフォーム開発は対象が内部の限られたチームであり、比較的N数を網羅しやすいため設計段階でフィードバックを埋めやすくなる。課題の解決確度が設計時点で読みやすく、プロダクト開発ほど細かく切り出してリリースして検証する必要性は高くない

ただし、検証が不要なわけではない。一定の機能群単位での段階的な検証や、実際に利用されて初めて得られるフィードバックは存在する。

これらの判断基準の違いから、プロダクト開発で有効な「小さくリリースして仮説検証する」アプローチはプラットフォーム開発には適用しにくくなる。

設計思想の違い

• 設計の方向性：個別ユースケースへの深い最適化より、広く安定したインターフェースを維持することが優先される（個別最適より全体最適）
• 問題解決の抽象度：プラットフォームがエンドユーザーの具体的な要求を直接受け取って解決しようとすると、全プロダクトチームの要求がプラットフォームチームへ集中し「プラットフォーム対応待ち」が発生する。均等化・直列化になり、全体のスループットがプラットフォームの対応能力で頭打ちになる。課題を汎用化・抽象化して他チームが自律的に解決できる仕組みを提供することで、チーム間の依存を最小化する

投資観点の違い

• 発現タイミング：価値は利用チームが採用するたびに段階的に実現する。機能や改善が届いても、利用チームが採用してはじめて成果として計上される
• レバレッジの方向性：プロダクト開発はエンドユーザーへの機能的な価値でレバレッジを効かせるが、プラットフォーム開発は基盤を利用するシステムや開発者の開発生産性・開発者体験でレバレッジを効かせる。改善による恩恵と問題は、全チームに波及する

おわりに

プロダクト開発とプラットフォーム開発の区別は、単なる分類の問題ではない。判断基準・設計思想・投資観点のすべてが変わる。

プラットフォーム開発をプロダクト開発の基準で評価すると、「なぜ小さく検証しないのか」「なぜ個別要求に対応しないのか」という問いに答えにくくなる。逆に、プラットフォーム開発の性質を起点にすれば、設計判断や投資判断に一貫した根拠を持てる。