フレームワーク活用ガイドひとことで言うと#
50〜125名規模の開発組織を5〜12のアジャイルチームで構成し、8〜12週間のPI（Program Increment）サイクルで全チームを同期させる大規模アジャイルの実行単位。定期発車する「列車」のように、固定リズムで価値を届け続ける。
押さえておきたい用語#
- PI（Program Increment）
- ARTの基本的な計画・実行サイクルで通常8〜12週間。PIの中に4〜5回のスプリント（イテレーション）が含まれる。
- PI Planning
- PI開始時に全チームが一堂に会し、次のPIで何を作るかを2日間で計画するイベント。ARTの心臓部とも言える。
- RTE（Release Train Engineer）
- ARTのファシリテーターであり推進役。スクラムマスターのART版にあたり、チーム間の障害除去やプロセス改善を担う。
- System Demo
- PI内のスプリント終了ごとに全チームの成果物を統合してデモするイベント。動くソフトウェアで進捗を確認する。
アジャイルリリーストレインの全体像#
こんな悩みに効く#
- 50名以上の開発組織でアジャイルを実践したいが方法がわからない
- チーム間の依存関係でスプリントが毎回ブロックされる
- 各チームがバラバラに動いて統合テストで問題が噴出する
- 大規模開発でもアジャイルの「リズム」を維持したい
基本の使い方#
具体例#
従業員80名のフィンテック企業。決済プラットフォームの大型リニューアルで、フロントエンド・バックエンド・インフラの3チーム（計23名）をARTとして組成した。
PI Planning（2日間）で次10週の計画を立て、チーム間の依存ポイント 8件 を可視化。RTEが週次のSync（同期会議）で依存の進捗を追跡した。
| PI | 計画PI目標数 | 達成数 | 達成率 |
|---|---|---|---|
| PI 1 | 12 | 8 | 67% |
| PI 2 | 14 | 11 | 79% |
| PI 3 | 13 | 12 | 92% |
PI 1では依存管理の不慣れから達成率が低かったが、Inspect & Adaptでの改善を重ね、PI 3では 92% まで向上。リリースまでの期間は従来見積もりの 14か月→11か月 に短縮された。
大手SIer。地方銀行の勘定系システム刷新プロジェクト（80名体制）にARTを適用。8チームを組成し、10週PIで回した。
最大の課題はチーム間の依存関係の多さ。PI Planning時にボード上で 42件の依存 が可視化され、うち 7件 が「解決しないとブロックされる」リスク項目として識別された。
RTEが専任で依存解消にあたり、PI中のブロック発生を 3件 に抑制。従来のウォーターフォール型管理では統合テスト段階まで気づかなかった問題を、System Demoで 毎2週間ごとに検出 できるようになった。プロジェクト全体の品質指標（本番障害件数）は前プロジェクト比で 60%改善 した。
従業員55名のEdTechスタートアップ。東京・大阪・福岡に分散する6チーム（計48名）で学習プラットフォームを開発している。全員リモートワークのためPI Planningも完全オンラインで実施。
MiroとZoomを組み合わせたリモートPI Planning（2日間）で計画し、依存関係はMiroのボード上でリアルタイムに可視化。RTEがMiro上の依存ボードを毎日更新し、Slackの#art-syncチャンネルで進捗を共有した。
導入前は「チーム間の調整はSlackの個別DMで行われ、情報が散在して誰も全体像を把握できていなかった」状態だったが、ARTの導入でPI Planning時に全員が全体像を共有するようになった。機能リリースのサイクルは 月1回→隔週 に短縮されている。
やりがちな失敗パターン#
- PI Planningを省略する ─ ARTの最大の価値はPI Planningでの全体同期にある。省略すると各チームがバラバラに動き、ARTの意味がなくなる
- RTEを兼任にする ─ チーム間の調整は想像以上に工数がかかる。専任のRTEを置かないとボトルネックになる
- チーム間の依存を可視化しない ─ 依存をボードに出さないと「誰も知らない依存」でスプリントがブロックされる。PI Planningで全件洗い出す
- System Demoを各チーム個別で行う ─ 統合デモでなければチーム間のインテグレーション問題に気づけない。必ず全チームの成果物を統合して見せる
まとめ#
アジャイルリリーストレイン（ART）は、50〜125名規模の開発組織を5〜12チームで構成し、8〜12週のPIサイクルで同期させる大規模アジャイルの実行単位。PI Planningで全チームが計画を共有し、System Demoで統合確認を行い、Inspect & Adaptで改善を回す。RTEの専任配置とチーム間の依存の可視化が成功の鍵。