全体像：統合型デリバリーオペレーティングモデルが実際に機能する仕組み
素早くデプロイできるチームがある。内部ツールを構築するプラットフォームチームがある。テストを自動実行するパイプラインがある。どこかのドキュメントにガバナンスポリシーが書いてある。それでもなお、リリースは混沌としている。
足りないのは、別のツールや別のプロセスではない。足りないのは、これらすべてのピースをつなぐ連携だ。ビジネス目標、チーム構造、プラットフォーム機能、デプロイ戦略、ガバナンスポリシーがそれぞれ孤立して動いていると、個々のピースは良く見えても、システム全体としては成果を出せない。
ここで統合型デリバリーオペレーティングモデルが登場する。これは壁に飾る図ではない。デリバリーシステムのすべての部分が、他の何かに役立つために存在し、すべての部分が全体を改善するためにフィードバックを返す、そういう仕組みを作る方法だ。
「なぜ」から始める：トップにビジネスアウトカム
すべてのデリバリーシステムは、何かを達成するために存在する。その「何か」がビジネスアウトカムだ。新機能の市場投入までの時間短縮、重要なサービスの信頼性向上、あるいはユーザー増加に耐えられるスケーラビリティの確保などだ。
ここから始めなければ、他のすべては方向性のない活動になる。高速なパイプラインも、間違ったものを届けていれば無意味だ。洗練されたデプロイ戦略も、チームが誰も必要としない機能に取り組んでいれば無駄になる。
ビジネスアウトカムはモデルの最上位に位置する。「なぜこれをやっているのか？」という問いに答えるものだ。
バリューストリーム：アイデアからユーザーへの経路
達成したいことが決まったら、アイデアからユーザーが使えるものになるまで、実際にどのように作業が流れるかをマッピングする。これがバリューストリームだ。ディスカバリー、設計、開発、テスト、デプロイ、監視、すべてのステップが含まれる。
バリューストリームはチーム構造とは異なる。多くの組織はこの2つを混同している。「プラットフォーム」チームと「アプリケーション」チームがあるから、バリューストリームは単なるチーム間の引き継ぎだと思い込んでいる。実際には、バリューストリームは、どこで作業が詰まり、どこで待ち時間が発生し、どこで品質問題が発生するかを明らかにする。
チームトポロジー：誰が何をするか
バリューストリームが明確になれば、誰が何を構築し、誰が何を維持するかを決められる。これがチームトポロジーだ。エンドツーエンドのサービスを所有するチームもいれば、他のチームが使うプラットフォームを構築するチームもいる。他のチームのスピード向上に注力するチームもある。
トポロジーはバリューストリームに従うべきであり、その逆ではない。もしチームが技術レイヤー（フロントエンドチーム、バックエンドチーム、データベースチーム）で編成されているのに、バリューストリームが高速なエンドツーエンドデリバリーを要求しているなら、すべての引き継ぎで摩擦が生じる。
プラットフォームエンジニアリング：ツール集ではなく基盤
プラットフォームエンジニアリングはバリューストリームと並行して存在する。チームがビルド、テスト、デプロイに使う技術基盤を提供する。しかしプラットフォームとは、承認されたツールのリストではない。チームが毎回インフラを再構築することなく利用できる機能のレイヤーだ。
優れたプラットフォームは、アプリケーションチームの認知負荷を軽減する。彼らはKubernetesクラスター、データベースプロビジョニング、CI/CDパイプラインのメンテナンスについて考える必要がない。自分たちのプロダクトに集中できる。プラットフォームチームは、その体験をよりスムーズにする方法を考える。
パイプライン：コードから本番への経路
プラットフォームの上で、CI/CDパイプラインがコードコミットから本番への変更を運ぶ。各パイプラインには、リスクとデリバリー対象の性質に基づいて選択されたデプロイ戦略がある。
シンプルなWebアプリケーションならローリングアップデートを使うかもしれない。データベースマイグレーションならブルーグリーンデプロイが必要かもしれない。重要な決済サービスなら、自動ロールバック付きのカナリアリリースが必要かもしれない。パイプラインは画一的ではない。デリバリー対象に合わせて適応する。
ガバナンスと検証：ルールは埋め込まれ、付属しない
ガバナンスはしばしば別のレイヤーとして扱われる。誰かがポリシーを書き、別の誰かがコンプライアンスをチェックし、全員がスピードを落とされたと感じる。統合モデルでは、ガバナンスはパイプラインに埋め込まれている。すべての変更は、次のステージに進む前に検証ゲートを通過する。
これらのゲートは、セキュリティスキャン、コンプライアンスチェック、パフォーマンステスト、または高リスク変更に対する手動承認などだ。ゲートに失敗した場合、変更はそこで停止する。すべてのゲートを通過した場合、選択されたデプロイ戦略を使って変更は本番に進む。
重要な違いは、ガバナンスがドキュメントではないことだ。デリバリーの一部として自動的に実行されるメカニズムである。チームはポリシーを確認することを覚えておく必要がない。システムが強制する。
改善ループ：循環を閉じる
変更が本番に到達した後も、モデルは止まらない。すべてのリリースからデータが収集される。デリバリーにかかった時間、最も頻繁に失敗したゲート、デプロイ戦略が期待通りに機能したか、ビジネスアウトカムが達成されたか。
このデータはモデルのすべての部分にフィードバックされる。プラットフォームに新しい機能が必要かもしれない。低リスクの変更にはガバナンスポリシーが厳しすぎるかもしれない。チームトポロジーが不要な引き継ぎを生んでいるかもしれない。改善ループは、モデルが経験から学習することを保証する。
各要素のつながり方
このモデルが統合されているのは、すべてのコンポーネントが存在するからではなく、各コンポーネントが明示的に他のコンポーネントとつながっているからだ。
以下のフローチャートは、これらのつながりをひとつの図にまとめたものだ。
- ビジネスアウトカムが、どのバリューストリームを優先するかを決定する。
- バリューストリームがチームトポロジーを決定する。
- チームトポロジーが、どのプラットフォーム機能が必要かを決定する。
- プラットフォーム機能が、どのようなパイプラインを構築できるかを決定する。
- パイプラインが、どのデプロイ戦略が利用可能かを決定する。
- ガバナンスと検証が、すべてのステップで安全性を確保する。
- 改善ループが、すべてをビジネスアウトカムにフィードバックする。
デリバリーが遅い場合、問題を追跡できる。パイプラインの問題か？プラットフォームの問題か？ガバナンスが厳しすぎるのか？それともバリューストリームが非効率なのか？本番で問題が増えた場合、検証ゲートが十分か、デプロイ戦略を変更すべきかを確認できる。
チームのための実践的チェックリスト
デリバリーシステムのギャップを評価するために、以下を確認してほしい。
- すべてのチームメンバーが、自分の作業がどのビジネスアウトカムを支援しているかを説明できるか？
- バリューストリームはマッピングされており、どこで作業が詰まるかを把握しているか？
- チームトポロジーはバリューストリームに従っているか、それとも技術レイヤーに従っているか？
- プラットフォームは認知負荷を軽減しているか、それとも複雑さを増しているか？
- ガバナンスポリシーはパイプラインに埋め込まれているか、それとも手動のチェックリストか？
- すべてのリリースからデータを収集し、改善に活用しているか？
モデルは生きて変化する
統合型デリバリーオペレーティングモデルは、一度書いて終わりのドキュメントではない。組織が学習するにつれて進化する。デリバリーサイクルごとに、モデルを調整するための情報がもたらされる。リスクプロファイルが変化すれば、チームはデプロイ戦略を変更できる。新しいニーズが生まれれば、プラットフォームは機能を追加できる。セキュリティギャップが検出されれば、ガバナンスを更新できる。
全員が同じ全体像を見ていると、意思決定が容易になる。アプリケーションチームは、特定のガバナンスルールに従わなければならない理由を理解する。プラットフォームチームは、次に何を構築すべきかを知っている。経営陣は、プラットフォームとパイプラインへの投資が期待通りのビジネスアウトカムを生み出しているかどうかを確認できる。
全員が同じ方向に動く。強制されているからではない。モデルのすべての部分が、他のすべての部分を支えているからだ。