Next'25 速報 - GitLabが語る「ソフトウェアロジスティクス」
はじめに
現在ラスベガスで開催されている Google Cloud の旗艦イベント「Google Cloud NEXT'25(以下、Next'25)」に現地参加中の
Google Cloud NEXT'25 で発表された 最新情報 を現地からお届けしています。
この記事は、Google Cloud Next '25 で発表されたセッション「Software Logistics: The Future of Software Delivery」の参加レポートです。
TL;DR
- ソフトウェアロジスティクス: ソフトウェアロジスティクスとは、ソフトウェアのパッケージが完成した後、その製品を実際に運用環境へと届けるプロセス全体を指します。
- 開発パラダイムシフト: ソフトウェア開発は課題解決中心に進化し、生産性と統制を両立するプラットフォームが重要。
- サプライチェーンの定義: ソフトウェアサプライチェーンは開発(生産性)とデリバリー(効率性)から成り、両者の最適化を目指す。
- プラットフォーム戦略: プラットフォーム構築は状況に応じ、API・UI・AI等を備えデータ駆動での改善が不可欠。
セッション概要
セッションタイトル
Software Logistics: The Future of Software Delivery
登壇者
- Lee Faus (GitLab)
セッション内容
ソフトウェア開発は得意でも、それを本番環境へ確実に届けるプロセス、すなわち「デリバリー」の複雑さに悩む組織は少なくありません。
このセッションでは、ソフトウェアロジスティクスに焦点を当て、クラウドネイティブアプリケーション向けのデリバリーパイプライン構築法が紹介されました。
セクション1: ソフトウェアサプライチェーンの再定義:「ファクトリー」と「ロジスティクス」
セッションでは、ソフトウェアサプライチェーンの理解を深めるために、2 つの異なるフェーズが提示されました。
-
ソフトウェアファクトリー (Software Factory):
- 範囲: 開発ライフサイクルの前半部分。具体的には、課題 (Issue) の発生から、コードが書かれ、テストされ、最終的にリリース可能な「パッケージ」が作成されるまで。
- 測定基準: リードタイム、サイクルタイムなど、個々の開発タスクの完了速度に関連する生産性 (Productivity)。
-
ソフトウェアロジスティクス (Software Logistics):
- 範囲: 作成されたパッケージを、テスト環境、ステージング環境、そして最終的に本番環境へと、効率的かつ安全にデリバリーするプロセス全体。
- 測定基準: デプロイ頻度、変更失敗率、平均修復時間 (MTTR) など、デリバリープロセス全体の効率性 (Efficiency)。
多くの組織がこれら 2 つを混同している、あるいは「ソフトウェアファクトリー」側に偏重している傾向があると指摘されました。
真に効率的なソフトウェアデリバリーを実現するには、「ソフトウェアロジスティクス」にも同等の注意を払い、最適化していく必要があります。
これら 2 つを合わせたものが、真の「ソフトウェアサプライチェーン」であると定義されました。
セクション2: モダンなプラットフォームエンジニアリングの要件
従来のプラットフォームは、ソースコード管理、CI/CD、課題管理といった個別の「機能」を提供することに主眼が置かれていました。
しかし、これらのツールを単純に組み合わせるだけでは、真の効率化は達成できません。
課題:
-
ツールの分断と Webhooks の限界: 多くのツールは独立しており、連携のために Webhooks が多用されます。
しかし、Webhooks は「ファイア・アンド・フォーゲット」方式であり、トランザクションが保証されません。
例えば、Webhook の送信失敗や、受け取り側のシステムダウンにより、ビルドやセキュリティスキャンが実行されないリスクがあります。
また、エラーが発生しても成功ステータスが返却され、問題が見過ごされる可能性も指摘されました。
モダンなプラットフォームに求められること:
- ビジネス課題解決へのフォーカス: ツール機能の提供だけでなく、「ソフトウェアをより速く、安全に、繰り返しデリバリーするにはどうすればよいか?」というビジネス課題の解決を目指す必要があります。
- ガードレールとゴールデンパスウェイ: 開発者に自律性を与えつつも、品質とセキュリティを担保するための「ガードレール」(例:必須のセキュリティスキャン、承認プロセス)と、推奨される開発・デリバリープロセスである「ゴールデンパスウェイ」(例:標準化されたCI/CDテンプレート、推奨ライブラリ)を提供することが重要です。
- 統合されたワークフローと自動化: 分断されたツール群を連携させるだけでなく、より統合されたワークフローエンジンと自動化が必要です。これにより、プロセス全体の信頼性と可視性が向上します。
- AI 強化チーム: AI の活用は、個人のコーディング支援 (Copilot など) に留まらず、チーム全体のコラボレーション(課題の自動関連付け、リファクタリング提案など)や、デリバリープロセスの最適化(自動修復計画など)にまで拡張されるべきです。
- データ駆動型の改善: プラットフォームの利用状況やデリバリープロセスに関するデータを収集・分析し、継続的な改善を行う文化と仕組みが不可欠です。
GitLab では、これらの要件に応えるため、以下の 4 つの柱に注力していると紹介されました。
- 開発者生産性の向上 (Improve developer productivity)
- 高性能チームの構築 (Build high-performing teams)
- ソフトウェアサプライチェーンの保護 (Secure the software supply chain): SBOM (Software Bill of Materials) の生成と管理など。
- クラウドネイティブアーキテクチャへの移行加速 (Accelerate cloud-native transitions): 単なるコンテナ化ではなく、PaaS (Platform as a Service) としてのクラウド活用。
セクション3: プラットフォーム構築の考慮事項
モダンな開発プラットフォームを導入・構築する際には、いくつかの重要な考慮点があります。
構築 (Build) vs 購入 (Buy) vs ハイブリッド:
- 画一的な答えはなく、「状況による (It depends)」と Lee Faus 氏が述べました。
- 考慮すべき要素: 予算、社内チームのスキルセットと持続性(担当者の離職リスク)、規制要件、必要な機能の複雑さ(多様なデプロイ先、プログレッシブデリバリーなど)。
- プラットフォームエンジニアには、単なるツール操作だけでなく、コーディング能力(Python, Java など)や API 連携、自動化スクリプト作成などのスキルが求められる傾向が強まっています。
プラットフォームアーキテクチャの構成要素:
モダンなプラットフォームが備えるべき主要コンポーネントとして、以下が挙げられました。
Phase1
Phase2の前段階として、以下のような構成要素も挙げられていました。
- API レイヤー: 外部ツールやカスタムスクリプトとの連携を可能にし、自動化や拡張性の基盤となる。
- Web UI とダッシュボード: 直感的な操作を提供し、プロジェクト横断での状況(ビルド、デプロイ、セキュリティスキャン結果など)を可視化する。
- ホストされた IDE 環境: 環境構築の手間を削減し、開発者がすぐにコーディングを開始できる開発環境(例: Cloud Workstations のようなコンテナ内 VS Code 環境)。
- AI ゲートウェイ: 様々な AI モデル(オンプレミス、クラウド、API サービス)を選択・利用可能にし、プロンプト管理やアクセス制御を行うインターフェース。
- 中央集権化されたワークフローエンジン: ツール間の連携を管理し、CI/CDパイプラインなどの自動化されたプロセスを実行するコアコンポーネント。
- ストリーミングプラットフォーム: 外部ツール(監視、セキュリティスキャンなど)からのデータをリアルタイムで取り込み、分析やダッシュボード表示に活用する基盤。
まとめ
本セッションは、「ソフトウェアロジスティクス」という概念を通じて、現代のソフトウェアデリバリーが直面する課題と、それを克服するためのプラットフォームエンジニアリングのあり方を提示しました。
以下のポイントが特に印象に残りました。
- ソフトウェアサプライチェーンの構成要素: ソフトウェアサプライチェーンは、課題からパッケージ作成までを担う「ソフトウェアファクトリー」と、パッケージを本番環境へ届ける「ソフトウェアロジスティクス」の 2 つで構成される。
- プラットフォームの役割の変化: モダンなプラットフォームは、単なる機能提供だけでなく、ビジネス課題(開発速度向上、セキュリティ組み込み、反復可能なデリバリー)の解決に貢献すべきである。
- プラットフォームエンジニアリングの進化: Webhooks のような従来のツール連携の課題を克服し、統合されたワークフロー、自動化、そしてデータに基づいた改善が求められる。
- AI の活用範囲の拡大: AI は個人の開発生産性(IDE でのコーディング支援など)だけでなく、チーム全体のコラボレーションやデリバリープロセスを強化するためにも活用されるべきである。
- 長期的な視点の重要性: 開発プラットフォームは長期的な投資であり、構築 (Build) vs 購入 (Buy) vs ハイブリッドのアプローチを慎重に検討する必要がある。
最後までお読みいただき、ありがとうございました。
Discussion