多数の開発チームを管理できる「アジャイルリリーストレイン」の価値とは：ARTの原則、チーム内での役割などを解説

複数の開発チームがコードに取り組むと、統合とデプロイメントが複雑になる。こうした複雑さを摩擦なく取り除くのにはアジャイルリリーストレイン（ART）が役立つツールになる可能性がある。本稿ではこのARTについて解説する。

[Amy Reichert，TechTarget]

　品質の高いプロダクトを期日通りにリリースするのを支援する目的で、アジャイルリリーストレイン（ART）を取り入れているソフトウェアチームがある。ARTを取り入れるのは追加の手順になるため、取り組む価値があるかどうかは必ずしも明確ではない。

　ARTは、Scaled Agile Framework（SAFe）内で包括的なプロセスを担当する1つのチームで、複数の開発チームにまたがって行われる作業を円滑に進めることを目的とする。ARTは、統合されるコードや依存関係のあるコードを各チームが変更および破損するのを防ぐ目的で設計されている。ARTを正しく取り入れれば、全てのコードを1つの機能するプロダクトとして提供できるようになる。

　実質的には、ARTとは多数の開発チームを管理する一つの手法だ。開発に参加するチームの数が増えるほど、1つのチームがコードベースに対して行った変更が欠陥や不整合を生み出す可能性が高くなる。生み出された欠陥はプロダクトのデプロイメント時には解決されなければならない。それを怠れば、膨大な量の技術負債が蓄積される。

　ARTが機能すれば、コラボレーションとプロセスの透明性に基づく統制のとれた開発アプローチがもたらされる。ARTを取り込むことにより、デプロイメント全体を通じてプロジェクトを順調に進め、ビジネス目標に歩調を合わせることができるようになる。

　本稿では、ARTの原則、チーム内での役割、ARTチームが他のチームメンバーや開発プロセスに与える影響について確認する。

ARTとは

　ARTチームのメンバーは、複数の開発チームが行う作業を計画、レビュー、監視して、継続性と一貫性を確保し、事業目標の実現と顧客へのデプロイメントがスケジュール通りに、高い品質で確実に行われるようにする。

　ARTチームは、次のような役割に分かれているのが一般的だ。

• スクラムマスター：SAFeの原則を支え、プロジェクトを軌道に乗せるために、開発プロジェクトをトレーニング、指導、監視する
• プロダクトオーナー：プロダクトが事業に及ぼす成果とその結果としてのカスタマーエクスペリエンス（CX）に責任を持つ
• プロダクトマネジャー：プロダクトビジョンと事業計画を担当し、プロダクト機能と欠陥の特定に優先順位を付け、自社のプロダクトビジョンに沿ってプロジェクトを進める
• リリーストレインエンジニア（RTE）：プロセスに関与するさまざまな開発チーム間の調整、作業の阻害要因の除去、既存のリスクや依存関係の管理に重点を置いてタスクの実行を監視する
• システムアーキテクト：プロダクトアーキテクチャ実装の監視、レビュー、評価、統制を管理する

　RTEは、権限を持つ権威のある指導役としてアジャイルチームに関与する。アジャイルチームを軌道に乗せ、統合し、定期的かつ迅速なペースで高品質の作業を生み出せるようにするためにRTEが存在する。RTEはアジャイルチームの一員ではあっても、管理職やチームリーダーのレベルで活動する。

　ARTチームは、アジャイルチームにまつわる共通の問題点に対処する。それは、顧客へのデプロイメント時点までにコードが完全に統合されないという問題点だ。各アジャイルチームはイテレーションを行うが、コードベース全体にはイテレーションを行わない。ARTチームは、完全に機能する状態で全てのプロダクト機能がリリースされるよう、アジャイルチーム開発の同期を取る。

ARTの主要原則

　ARTの主な目的は、複数の開発チーム同士が効果的なコラボレーションを確実に行えるように構造を整え、ガイダンスを用意し、チーム間を調整することにある。そのため、ARTには次の要素が組み込まれる。

• スケジュールを確定する：プログラムの実装スケジュールごとに、プロジェクトの成果物を決める
• 2週間サイクル：ARTチームはアジャイルスプリントやイテレーションではなく、2週間単位のサイクルで作業する
• 速度を定義する：チーム速度の実績データを用いて作業を計画する
• 開発のペースの同期を取る：スケジュールの延期は行うが、顧客へのリリースはプロジェクトの完了によって決める
• リリースは常時でもオンデマンドでも可能にする：顧客のニーズが高ければ、機能リリースをデプロイ可能にするが、そのためには、コードの継続的な統合とテストが必要になる
• プログラムインクリメント（PI）計画：チームミーティングによって、次回PIの戦略的目標を決定する
• プロジェクト完了後にイノベーションと計画（IP）を実践する：次回PIに向けたIPミーティングでは、インフラの作業や必要なトレーニングを取り上げる
• 検証と調整のミーティング：このミーティングは毎回のPI後に開催し、プロジェクトの進捗（しんちょく）状況を評価し、改善の余地のある領域を特定する

　SAFeメソッドにおけるARTの原則は、チームのコラボレーションと連携を実現し、それを維持することを目的としている。各個人が同じ目標に向かって作業を続けることと、目標を実現することは別のことだ。

　RTEの仕事が差別化要因になる。RTEの役割は、プロジェクトの目標に向けてチーム全体の足並みをそろえ、プロジェクトの各タスクを見守り、チームのコラボレーションを促すことにある。RTEがチームとタスクをスケジュール通りに的確に足並みをそろえて維持できるかどうかは、効果的で絶え間のないコミュニケーションにかかっている。PIの開始からコードのデプロイメントまで、ミーティングのスケジュールを立て、チームの連携を評価し、必要に応じて立て直しの機会を設ける。

そもそもARTは必要か

　ARTチームと普通のアジャイルチームは何が違うのだろう。チームメンバーの役割や数が違うのか、それとも、単にミーティングの回数が増え、役割名が変わり、プロジェクトの状態を評価するための正式なタッチポイントの数が増えるだけで、同じものなのだろうか。

　統合の問題が発生しなければ、さらにはあるチームが共有コードを変更することでコードの欠損や欠陥が発生しなければ、アジャイル開発を行うIT部門にARTは必要ない。スクラムマスターがRTEのような役割を追加で担えば、IT部門内のアジャイルチームの数とは関係なく、チームの作業を整理し、プロダクトデリバリーに悪影響を及ぼさないよう、必要な管理監督を行うことができる。

　RTEという役割は、チームを整理し、コードを定期的に統合し続ける担当者を用意するところに価値がある。継続的テストや計測的デプロイメントは、アジャイルチームやDevOpsチームのプロセスに含めることができる。ARTを追加するメリットは、RTEという役割が追加されることしかない。効果の高いRTEを用意することは、リリース日を守れるかどうか、デプロイメント中の統合の欠陥を解決できるかどうか、技術的負債の拡大を経験するかどうかに違いを生む可能性がある。

　ARTはSAFe開発手法の中で価値を持つ。RTEという役割は、あらゆる種類のアジャイル開発手法全てに価値をもたらす。ART全てに取り組むか、単に効果的なRTEを追加するだけでよいかは、ビジネスプロダクトとCXに左右される。デプロイメント中に統合の欠陥が必ず問題になる場合、アプリケーションリリースの品質が一貫して低い場合は、RTEという役割を追加することで、リリースの品質が向上し、技術負債が続く状況を軽減して、CXが向上する可能性がある。