プラットフォーム開発をプロジェクトからプロダクトへ転換する——その本質と現場への含意
KubeCon & CloudNativeCon Europe での発表が示した「プロジェクト型からプロダクト型へのプラットフォーム移行」は、多くの開発組織が直面しているが言語化できていない問題を丁寧に切り取っている。
出典: Shifting Platform Development from Projects to Products
要点 (事実のみ)
- Eugenia Bergman と Hagen Tonnies が KubeCon & CloudNativeCon Europe で発表。プラットフォームが単一チームの利用規模を超えたことを契機に、プロジェクト型からプロダクト型思考へ移行した経緯を共有した。
- 旧来のプロジェクト型では「バックログが積み上がり続ける」「チームがプラットフォームを迂回して使う」「何が実際に使われているかわからない」という問題が顕在化した。
- 転換の方向性は「フィーチャー提供 → ユーザー課題解決」「固定スコープ → 仮説駆動ロードマップ」「アウトプット指標 → 採用率・使用性シグナル」の3軸。
- 技術的には Kubernetes / GitOps を基盤とし、Helm・GitLab・内部 IDP モデルから、API 駆動の自己サービス型マルチテナントアーキテクチャへ段階的に進化。
- 参照文献として『Project to Product』と『The Phoenix Project』が社内の認識変容に影響したと Tonnies は述べた。
徐 聖博の見解
この発表が示す問題は、プラットフォーム規模が「単一サービス」から「複数の内部チームへの提供基盤」に変わった瞬間に本質が変化するという点だ。私が受託開発と社内AIエージェント基盤を並走させる中でも、同じ断層を感じている。
プロジェクト思考の問題は、「完了」を成功と定義してしまうことにある。スコープを守り、期日までに届けた——それ自体は悪くないが、使われない機能が蓄積され、使い勝手の改善に優先度が割り当てられにくくなる。Bergman の言う「継続的に届けているが、プラットフォーム全体の使いやすさは改善されていない」という状態は、受託案件でフェーズ区切りの開発をしているチームなら誰でも経験があるはずだ。
一方で、「プロダクト化すれば解決する」というほど単純でもない。プロダクト思考が機能するのは、ロードマップを継続的に判断できるオーナーがいて、ユーザーのフィードバックを収集・反映するループが回る体制が前提となる。これは単なる思想の変換ではなく、組織構造と意思決定権の再設計を伴う。Tonnies が「Scrum への長年の懐疑」から入ったという文脈は興味深い。スプリントの完了率ではなく、ユーザーの実際の採用率を見ることで、エンジニアリング作業と顧客価値の間のずれを直視できるようになる。
実装・運用の観点から補足すると、API駆動のセルフサービス化は設計コストが高い。内部利用者向けに「コントラクト（安定したインターフェース）」を定義し、プラットフォーム層と消費者層の責任を明確に分離する——これはSaaSの設計原則をほぼそのまま社内に適用することを意味する。中小規模の組織では、この投資が見合うかどうかを判断する段階から始める必要がある。自社の AI エージェント基盤でも、まず「誰が使うか」「どこまでセルフサービスにするか」の境界を設定することが最初の実務的問いになった。
(編集レンズ: 実装・運用視点 / 発注側・開発実務への含意)
