＊本コラムは、技術評論社「Software Design」2023年8月号に寄稿したコラムを掲載しています。

アジャイル開発の導入がうまくいったとして、その体制のまま開発を続けてもよいのでしょうか。プロダクトや組織規模が拡大すれば、当初の体制のままではうまくいかないことも増えてきます。本章では、そんな「変化」に耐え得るための適切なスケーリング方法を紹介します。

アジャイルのスケーリングとは

スクラムによる6名前後の単体チームでのアジャイル開発がうまくいったとしても、その方法論だけでは解決できない課題があります。

これらの単体チームでは解決できない課題に対するアプローチとして、アジャイルをスケールすることが選択肢になるでしょう。注意が必要なのは、「スケーリングの本質は単に規模を拡大することではない」ということです。規模が拡大しても単体チームのときと同様のアジリティを出せるかどうかがポイントになります。

スケーリングって人を増やすこと？

体制拡大にはチームの人数を増やせばよいでしょうか。「スクラムガイド」^注1には開発チームの適正規模は9名以下と記載されています。これは、ルールではなく経験則に基づくベストプラクティスです。10 名以上の場合は、チームを分割して適切な人数を保つほうが効率的だと言われています。チームの人数が多くなればコミュニケーションパスも増えますし透明性も低下してしまいます。また、単純に人数が多ければスクラムイベントにかかる時間も増えてしまいます。10 名以上のチームでもうまくやっているアジャイル開発チームもあるとは思います。しかし開発規模が大きくなり30人、50人と増えれば、いずれ限界は来るでしょう。スケーリングの際は1チームに適切な人数を維持しつつ、チームを増やしていくほうがよさそうです。
なお、規模が大きいプロダクトを複数チームでアジャイル開発することを、本稿では大規模アジャイルと定義します。

チームを増やすだけでよいのか？

チームを増やしてうまくいけば万歳ですが、なかなかそうもいきません。単体チームで進めていたときと比べ、意思決定ルートやチーム間の情報連携・調整事などが複雑化し、複数チームならではの課題も出てきます。
また、単体チームでうまくいったからといって、そのやり方をそのまま複数チームに適用してもうまく進まないでしょう。たとえ手練れのスクラムチームを複数用意しても、ソースコードの衝突やデグレなども起こり得ます。立ち上げ当初はどのチームもプロダクトのその先の顧客を意識していても、次第にチーム間の最適化に主眼を置くようになってしまうかもしれません。

◆　◆　◆

規模拡大に伴って生じる課題を考慮しながら、適切にスケーリングすることが重要です。また、複数のチームからなる大規模アジャイルにもさまざまなフレームワークがあります。そのようなフレームワークの中から自分たちに合いそうなものを適用してみるのもよいかもしれません。次節からは、大規模アジャイルならではの課題とそれにどう対応していけばよいか、さらに大規模アジャイルのフレームワークについても紹介します。

大規模アジャイルの課題

複数チームによる大規模な開発であっても単体チームによる開発であっても、アジャイルの本質に変わりはありません。しかし、単体チームでうまくいったことが複数チームでもうまくいくとは限らないのは、前節でも述べたとおりです。では大規模アジャイルを実践するうえでどのような課題があるでしょうか。１つの大規模なプロダクトを複数チームで並行開発する場合を例にとってみましょう。
1つのプロダクトを複数チームで開発するということは、プロダクトバックログを複数チームで分担して開発するということです。その際は、複数チームが並行して開発できるように優先順位や依存関係などを考慮する必要があります。また、各チームのアウトプットを1つのプロダクトとして結合する必要もあります。開発中はチーム間の連携も重要です。関係者が増えればコミュニケーションコストも上がります。また、チームが増えるということは、チーム間で同じモノを使ったり作ったりするムダが発生したり、チーム間で品質のムラが発生したりする可能性があります。かといって、ムダやムラをなくすためにあれもこれも同じモノを使おうとすると、チームが持つ裁量が少なくなり、全体のアジリティを下げてしまうことでしょう。

これらが大規模アジャイルの重要な成功要因であり、単体チームから大規模アジャイルへチャレンジする際の課題となりそうです（図1）。

図1：大規模アジャイルならではの課題

最適なチーム編成

1つの大きなプロダクトを複数チームで作っていく場合、各チームに対して、どんな切り口で仕事を分担すればよいでしょうか。考えられるのは次の3つがあります。

プロセス単位で分ける

プロダクトバックログは、設計やUIデザイン、コーディング、テストなどのプロセスを通じてインクリメント（成果物）としてアウトプットされます。それらのプロセスごとに担当するチームを分担します（図2）。ウォーターフォールのような従来型開発から急に大規模アジャイルにシフトさせた現場でたまに見る編成です。「スクラムガイド」には「スクラムチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキルを備えている」とあり、特定プロセスをサイロ化^注2してしまうと、チーム間での引継ぎのコストが発生します。この分担は避けるべきでしょう。

図2：各チームにプロセスを割り振る

コンポーネント単位で分ける

チームは、担当するシステム構成要素（コンポーネント）、たとえばフロントエンドであったり、各機能単位のバックエンドであったり、サブシステムのような単位で開発します。この場合、1つのユーザーストーリーに対して複数のシステム構成要素を利用するエンドツーエンドの機能は、複数のチームが協力してテストする必要があります（図3）。システム構成要素内のソースコードの衝突は抑えられますが、チームがプロダクトのゴールや目的感を見失いがちになります。

図3：各チームにコンポーネントを割り振る

ユーザーストーリー単位で分ける

チームは1つのプロダクトバックログアイテムまたはユーザーストーリー単位で開発するため、たいていは複数コンポーネントにまたがって開発を行います。この場合、1つのユーザーストーリーに対するエンドツーエンドの機能は、1つのチームが一貫してテストするので、システムが提供する機能に対する責務が明確になります（図4）。
一方で、ソースの衝突は生まれやすくなるため、設計やコーディングには苦労するでしょう。また開発者が把握できるシステムの範囲には限界がありますので、保守性の高いコードとアーキテクチャである必要があります。チームメンバー全員が一定水準の技術スキルを持ってアーキテクチャを正しく理解している状態でない場合、誰もメンテナンスできないシステムができあがりかねません。

図4：各チームにユーザーストーリーを割り振る

どの分担のしかたがよいのか？

プロセス単位は除外するとして、コンポーネント単位とユーザーストーリー単位を比較するとどちらがベターなのでしょうか。先述のとおり、コンポーネント単位では結合時に、ユーザーストーリー単位では設計やコーディング時にチーム間の競合が発生するリスクがあります。顧客に価値を届けることを第一に、かつリスクは早期にクリアにしておきたいことを考えると、ユーザーストーリー単位で分けるのが理想でしょう。
しかしながら現実問題として、多様なシステム構成要素を扱えるクロスファンクショナルなチームを作るのが困難な場合や、チームを増やしすぎてシステム全体を把握できなくなる場合などがあり、コンポーネント単位でチームを分担している現場は多いです。メンバーのスキルや利用する技術要素、全体のシステムの規模などのプロジェクトの特性から分担のしかたを決めるのがよいでしょう。

チーム間の効率的なコミュニケーション

複数のチームで開発を行うとなるとチーム間での調整が必要になるのは前述のとおりです。これはチームをコンポーネント単位で分けてもユーザーストーリー単位で分けても同じことが言えます。では、どういった調整事が出てくるでしょうか？　図5からもわかるようにチーム間で依存関係が発生します。これらの依存関係を明確にし、チーム間で調整や協力をして依存関係を緩和するようチーム間のコミュニケーションが大切です。

調整は各チームがバックログに着手するまでに終わらせる

このような調整はいつどのように行うべきでしょうか？　実際にバックログに着手する前に調整できれば依存関係を極力緩和することができそうです。
スクラムイベントで言うと、

が該当します。
バックログリファインメントは次回スプリント以降で取り組むバックログのあいまいな点を解消し、関係者全員が認識をそろえる場です。チーム間の依存関係を早期に発見するには最適な場ですし、スプリント計画において依存関係を考慮した計画を立てられるようになるでしょう。
スプリント計画はチームそれぞれで行いますが、各チームの代表者を集め調整・共有する場も設け、チーム間の依存関係や必要な調整事項について話し合います。各チームが取り組む予定のタスクや優先順位、リソースの共有などを確認し、依存関係の解決に向けた計画を立てます。また、スプリント計画において各チームのリリーススケジュールを調整するとよいでしょう。依存関係をふまえたうえでどのチームがどのバックログをいつまでに消化しリリースするかをチーム間で調整することで「チームYのAPIができあがってないからバックログに着手できない」といったことも起こりにくくなるでしょう。

図5：チーム間での調整が必要な状況

スプリント中の調整はどうするか

しかし、スプリントの最中にもチームにまたがる課題や新たな依存が出てくることもあります。そういった場合に「スクラムオブスクラム（SoS）」を開催するというのはよく聞きます。先述のリファインメントとスプリント計画は単体チームで開発する際にも実施されるスクラムイベントですが、SoSは複数チームで開発する大規模アジャイルならではのものです。
SoSではチームの代表者が定期的に集まり、プロジェクト全体の進捗や課題を共有します。いわばデイリースクラムをスケールさせたものと言えます。この中でチームのスプリントの進捗状況、重要な課題、リソースの調整などについて話し合うことで、チーム間の透明性も保たれるとともに、各チームが個別にバックログを消化しながらも、プロジェクト全体のビジョンや目標を共有できます。
また、チーム間の課題や依存を解決するバーチャルチームを作ることもあります。SoSもバーチャルチームの一種ですが、SoS はチーム間での共有を主とし解決は各チームが行います。これに対してバーチャルチームは、チーム間の課題を解決するために各チームから特定技術に関する有識者を集めて結成します（図6）。バーチャルチームに集まるメンバーは、普段は自チームで作業を行いますが、課題が発生するとバーチャルチームの作業を優先します。これによって各チームはほかのチームとの関係を気にすることなく自分たちのバックログに集中できますが、中心メンバーが兼務のため計画が立てづらくスプリントの進捗にも影響を与える可能性があります。メリットもデメリットもあるので課題の規模や状況で判断するのがよいかもしれません。

図6：バーチャルチーム

各チームは水平で対等な関係を保つ

チーム間の調整で重要となるのがチームの関係性です。チームの関係に強弱があると、強いチームが常に意思決定をするようになってしまいます。各チームが互いに連携していくためにもチームの関係をフラットに保ちましょう。
また、チーム外のステークホルダーたちとのコミュニケーションも発生します。複数チームによる大規模な開発になると関わるステークホルダーも単体チームのときと比べ多くなるでしょう。そういったステークホルダーたちの中には、しばしば「あっちのチームに比べてこっちのチームはベロシティが低いのはどういうことだ。生産性が悪いんじゃないか」などとチームを比較しようとすることがあります。ですが、ベロシティをほかのチームと比較してはいけません。ベロシティは1スプリントで完了したプロダクトバックログのストーリーポイントの合算値です。ストーリーポイントの基準値はチームによって異なりますのでベロシティを比較することは無意味だからです。ベロシティでチームを比較しようものなら、各チームはストーリーポイントをわざと多く見積もって完了したストーリーポイントの合算値を水増しし、ベロシティを高く見せるようなことをしてしまうかもしれません。ベロシティはあくまでも以降のスプリント計画での目安として利用すべきです。チーム間のコミュニケーションにプラスして、ステークホルダーたちとは数値ではなく、チームが創出する価値そのものに焦点を当てたコミュニケーションが必要です。

適度な共通化

共通化と聞くとモジュールや機能の共通化を思い浮かべると思いますが、ここではチームが共通で使ったり作ったりするものすべてが対象、と考えてください。ルール、アーキテクチャ、ツール、CI/CD パイプライン、環境、マニュアルなど、多岐にわたります。
共通化をいっさいしないと、チームの創発的な設計や実装のみに頼ることになり、プロジェクト全体の視点から見ると、タスクが重複したり、アーキテクチャの再設計が頻発したり、チーム間の結合が難航したり、品質が低下したり、最悪の場合プロジェクトが破綻してしまったりするリスクがあります。しかし行き過ぎた共通化は、先述のとおり各チームの改善の機会を奪うことになり、アジャイル開発ならではの反復による改善の余地をなくしてしまいます。そのため、何をどこまで共通化するか、バランスを考慮した検討が必要でしょう。
いくつかある対象のうち、とくにバランスを取るのが難しい次の3つについて考えてみます。

ルール

ルールは統制をとるための道具で、どのような組織にも必要なものです。アジャイル開発ではとくに完了の定義が各メンバーのインクリメント、働き方の認識を合わせる重要な役割を持っており、一定の統制がとれていない場合、成果物の品質や各メンバーの作業スピードに大きな差が生じ問題プロジェクトへ発展するリスクがあります。そのため、最低限の定義は大規模アジャイルのチーム間で共通の内容からスタートすることが多いです。しかし、完了の定義はレトロスペクティブの中で毎スプリント内容を精査し改善していくものであるため、統制をとり過ぎてしまうと各チームのタスクに最適な内容へと調整するのが難しくなってしまいます。また共通のルールが増えすぎるとルールを守るためだけの作業割合が増えたり、そもそもルールが守られなくなったりするリスクがあります。
結合のタイミングで困らない最低限のルールの統制から始め、各チームに適した内容に変更するように働きかけ、場合によっては統制をとっている箇所も変更するような柔軟な姿勢をプロジェクト全体で持つのがよいでしょう。

アーキテクチャ

一般的に、アーキテクチャの設計はプロジェクトを立ち上げるタイミングで技術ノウハウのあるアーキテクトが行います。次にチームが、設計されたアーキテクチャに従ってインフラやアプリケーションを作成していきます。追加の要件や技術的制限が判明したタイミングでアーキテクチャの再検討、一部変更が発生することもありますが、その場合も基本的にアーキテクトが担当します。開発中の変更は許容しているものの、このようなトップダウンなアプローチだけで最適なアーキテクチャにたどり着くことは可能でしょうか？
チームが自ら考えることにより最良なものが生まれるというアジャイル開発の原則に沿うのであれば、特定の人物がすべてを決めてしまうのではなく、各チームで自律的にアーキテクチャの改善を継続していくために次の4点に気をつけると良いでしょう。

CI/CDパイプライン

CI/CD パイプラインとは、プロダクトを結合したりデリバリーしたりするまでの一連のプロセスです。CI/CD パイプラインを自動化できれば、コマンド1つで各種テストの実施、脆弱性の検知、ビルドからデプロイまで行うことができます。これを共通化して各チームに利用してもらうことで、全体の作業のコストを下げながら、チーム間の品質のムラを減らす、結合時にバグが発生するリスクを下げる、といった効果が期待できます。
しかし、このような多機能で複雑なパイプラインは実行に時間がかかります。また、CI/CDパイプラインはアーキテクチャと密に関係しているため、アーキテクチャの変更に応じてすばやくパイプラインも変更する必要があります。ところがパイプラインが複雑で特定のメンバーでないとメンテナンスが困難な状況だと、パイプラインのメンテナンス作業が開発のボトルネックになってしまうこともあります。
全体の品質を高めるしくみに加え、各チームが自由にパイプラインを改善できるような余地を残すには、次の4点を考慮するとよいでしょう。

1つの多機能なパイプラインを、複数の最小限の機能のパイプラインに分けることで、パイプライン自体の変更容易性の向上や属人性の低下が図れます。しかしその結果、複数の環境を用意する必要があったり、結合がうまくいかないなどの問題が起きたりする可能性があります。パイプラインにおいてもプロジェクトごとに最適な統制のバランスがあるため、最低限から始め必要に応じて改善していくことが重要です。

共通化もアジャイルに

アジャイルでは、今回紹介した一般的に固定化されてしまうようなルール、アーキテクチャ、CI/CD パイプラインであっても、プロジェクトの途中で変更することができます。もちろん大幅な変更はそれなりの代償（コスト）を払う必要があるので、最低限の共通化から始め、小さい失敗を繰り返し改善していく余地を残すのがよいでしょう。結合の段階で膨大なコストがかからず、チームごとの柔軟な成長の妨げにならない、そのプロジェクトに最適なバランスの取れた共通化を徐々に目指していきましょう。

大規模アジャイルフレームワーク

ここまで紹介したような、大規模アジャイルならではの課題とそれらの解決方針について、体系化して実装したフレームワークがすでにいくつか存在します。それらには、大規模アジャイルのためのロール・イベント・成果物が定義されています。スクラムをスケールする観点やアプローチは違っていますが、すべて「スクラムガイド」「アジャイルソフトウェア開発宣言」を基礎としている点はどのフレームワークも同じです。また、すでにスクラムを習熟している前提で記載されている点も同じです。
本節では4つの有名な大規模アジャイルフレームワークを紹介します。

Nexus：スクラムの基礎を拡張した軽量フレームワーク

Nexus は「スクラムガイド」の著者であるKen Schwaber 氏と、同氏が設立したScrum.orgが開発したフレームワークです。公式ガイドはわずかPDF12ページにまとめられています^注3。内容もスクラムを基礎としており、スクラムの目的と意図を継承しながら、チームを越えた仕事の依存関係やコラボレーションの課題を解決できるよう、基礎となる要素を拡張したものとなっています。規模感は3～9 チームとされており、複数チームで同じ1つのプロダクトバックログに取り組みます。大規模アジャイルの中では比較的小規模なプロダクトを対象としており、これまで単体チームでアジャイル開発をしてきた組織が次のステップとして取り入れやすい手法だと思います。
大きな特徴は、「Nexus 統合チーム」がロールに追加されている点でしょう（図7）。Nexus統合チームは、スプリントごとに価値のある有用なインクリメントを提供できるようにするという重大な責務を負っています。チームはプロダクトオーナー、スクラムマスター、各チームから選ばれたメンバーから構成されます。プロダクトオーナーは、最終的なプロダクトバックログの内容について決定権を持つ1人です。スクラムチームの作業の価値を最大化することに責任を持ちます。スクラムマスターは、通常のスクラム同様、Nexusが理解されて実施されることの結果に責任を持ちます。各スクラムチームのスクラムマスターとの掛け持ちが可能です。メンバーは、各チームから輩出された問題解決ができる能力と知識を持った人たち、いわゆる「アベンジャーズ」です。各チームのスクラムメンバーとしても作業しますが、Nexus統合チームの作業が優先されます。そのため、Nexus統合チーム側の作業が全体のボトルネックになる可能性があります。「Nexus 統合チーム」のメンバーは掛け持ちになるため、一部メンバーに負荷がかからないようにしたり、チーム内でのフラットな関係を維持させるようにしたり、注意を払うべきでしょう。
Nexusでは通常のスクラムイベントから「クロスチームリファインメント」「Nexusスプリントプランニング」「Nexus デイリースクラム」「Nexus スプリントレビュー」「Nexus スプリントレトロスペクティブ」が拡張・追加されています。いずれも各スクラムチームを超えた全体での統合を促すものです。これらのイベントは全メンバーが参加する必要はありません。また成果物としても、「Nexusスプリントバックログ」「統合インクリメント」といった定義が追加されています。

図7：「Nexus統合チーム」による統合

出典："Nexus Guide", Figure 1: The Nexus Framework, https://www.scrum.org/resources/online-nexus-guide

LeSS：長年の経験をベースとしたフレームワーク

LeSS（Large-Scale Scrum）は認定スクラムトレーナーのCraig Larman 氏とBas Vodde 氏が作った大規模スクラムのフレームワークです。スクラムの原則・目的・要素を、可能な限りシンプルにかつ忠実に大規模開発へ適用するよう、長年の経験を基にルールや必要最低限のフレームワークが定義されています。Web サイト^注4や『大規模スクラム』^注5という本にまとめられています。日本語の情報も多いので、取り入れやすいフレームワークだと思います。
LeSSは情報量が多く、一見すると重厚に見えますが、フレームワーク部分はシンプルです。というのもLeSSはオプションとなる部分が多いからです。図8のように、中心が「原理原則」、それを実現する必要最低限の「ルール（＝フレームワーク）」、その周りを囲うのが「ガイド」で強いお勧めやtipsを含みます。一番外側が「実験」で特定の状況下で有用となるプラクティスという位置づけです。数々の実験を通じてだんだんとガイドやルールへ昇格していくというような構造になっています。ルールは守破離の「守」の位置づけで、ガイドと実験はオプションです。
LeSSの規模感は2～8チームです。1つのプロダクト、１つのプロダクトバックログに対し、全チームでDoneの定義をしてインクリメントを作成します。チーム構成は、プロダクトオーナーが全体で1人、スクラムマスターは3チームまで掛け持ち可能です。プロダクトオーナーの負荷が高いのでは、と思われるかもしれませんが、LeSSではプロダクトオーナーはプロダクトバックログの優先付けにフォーカスし、内容の明確化はチームメンバーと顧客・ユーザーの直接対話を促すことになっています。LeSSにおけるチームは、顧客中心の原則に従い、エンドツーエンドでの機能を提供する「フィーチャーチーム」です。コンポーネント横断型であり、実現するには最新のエンジニアリング手法やCI が不可欠であるとしています。
9チーム以上になる場合はLeSS Hugeというフレームワークが用意されています。LeSS Huge はプロダクトオーナーの次にエリアプロダクトオーナーというロールを設けます。プロダクトオーナーとエリアプロダクトオーナーはプロダクトバックログアイテムを要求エリアごとにカテゴリ分けし、エリアプロダクトオーナーはエリアプロダクトバックログを作成します。1つのエリアに対してチームは4～10程度とされています。LeSS Hugeは適用できるまでに数ヵ月～数年かかるとされています。
LeSSのイベントは、スプリント計画とレトロスペクティブが全体とチーム単位実施の2回に分けられています。コードや会話を通じた分散型で、自己組織化されたチーム間調整が重要視されています。複数チームでのスクラムにおいて一般的なSoSは推奨されていません。SoS は不必要な依存関係や作業の共有ができないチームの兆候であるとされています。
自律分散できるチームという概念には「あるべき姿が凝縮されている」とも言えますが、チームメンバーに裁量が与えられている状態が前提ですので、組織内の役職や契約上十分な権限が与えられない場合はなかなか適用が難しいところがあるかもしれません。

図8：LeSSの全体像

出典："Introduction to LeSS", LeSS complete picture(CC BY-ND), https://less.works/less/framework/introduction

Scrum@Scale：組織のフレームワーク

Scrum@Scaleは「スクラムガイド」の著者であるJeff Sutherland 氏と同氏が設立したScrum Inc.が開発した組織のフレームワークで、組織構造に焦点が置かれています^注6。Scrum@Scaleはスクラムを組織全体に拡張させ、チーム数に比例してアウトプットをリニアに増加し、変化にすばやく対応できるビジネスアジリティを持ったうえで、管理機構は最小限で済む「構造」を作ることをねらいとしています。
Scrum@Scale では、通常のスクラムと同様にプロダクトオーナー1人とスクラムマスターがそれぞれのチームにいる状態で、4～5 チームごとにSoS を編成し、複数チームの取り組みを調整します。さらにチームが増える場合は、上位組織であるスクラムオブスクラムオブスクラムを構成します。同様の方法を繰り返し、フラクタル構造のような形で大規模にスケールしていきます。
Scrum@Scale ではスクラムマスターがHowを、プロダクトオーナーがWhatを調整するとしています（図9）。SoSのスクラムマスターとして「スクラムオブスクラムマスター」が、プロダクトオーナーは「チーフプロダクトオーナー」がロールとして定義されています。フラクタル構造の最上位レイヤにはスクラムマスターの最上位である「エクゼクティブアクションチーム」とプロダクトオーナーの最上位である「エクゼクティブメタスクラム」が存在します。エクゼクティブアクションチームは組織の障害物を除去する責任を持ち、権限を持ったメンバーによって構成されます。エクゼクティブメタスクラムはチーフプロダクトオーナーがエクゼクティブや主要ステークホルダーと会合するイベントで、組織のビジョンと戦略的な優先順位を決定します。
プロダクトに関する言及はないため、プロダクト統合に関するヒントは得られないでしょう。組織レベルでアジャイルを実践していきたい場合や、スクラムをソフトウェア開発以外の分野、たとえば新規事業開発であったり、人事・経理といった企業のスタッフ部門であったりへ応用していきたい場合に有用なフレームワークと言えます。

図9：Scrum@Scaleのコンポーネント

出典：「Scrum@Scaleガイド」https://scruminc.jp/scrum-at-scale/guide/

SAFe：企業の変革までサポートする重厚なフレームワーク

SAFeはScaled Agile, Inc.が開発したフレームワークで、エンタープライズ規模のアジャイル開発を実装するために必要なロール、責任、成果物、およびアクティビティをガイドする広範な知識体系です。リーン生産方式、アジャイル、DevOpsといった幅広い知識を基にプラクティスがまとめられており、戦略、バリューストリームや予算管理といった超上流まで体系化されています。階層型にロールが定義されており、企業が組織を大きく変更することなく取り入れられます。幅広い業種の大手企業で採用実績があり、今も継続的にメンテナンスされています。各種トレーニングのほか、教材や資料も潤沢に用意されています。コンテンツはWebサイト^注7から閲覧できます。
SAFe では、50～125人からなるアジャイルリリーストレイン（ART）を形成し、ART 単位にスケールします。ART には、複数のスクラムチームと、複数チーム間の障害除去やCIの改善を促す「リリーストレインエンジニア」、システム全体のアーキテクチャを定義する「システムアーキテクト」、ARTの最終的な責任を負う「ビジネスオーナー」がいます。さらなる上位層やART内にもさまざまなロールが定義されているのですが、ここでは割愛します。
ARTはプログラムインクリメント（PI）という8～12週間のタイムボックスで開発を行います。SAFeではイベントが多数定義されていますが、中でも重要とされているのが「PIプランニング」です。PI 開始時にPI プランニングというイベントを大々的に開催します。2日間にわたる全員参加型のイベントで、ミッションやビジョンの共有を行い、各チームの開発の優先順位付けや調整をします。PI プランニングを通じてチーム間やステークホルダーとのコミュニケーションを確立し、早い意思決定を可能にします。
成果物としてArchitectural Runway、Enablerといったアーキテクチャに関する内容が明確に定義されていることも、SAFe の特徴です。Architectural Runway は将来的な機能開発を加速させる技術要素のことで、CI/CD パイプラインやクラウドサービスのようなものが該当します。Enabler はArchitectural Runway の構築・拡張や非機能に関するバックログアイテムのことで、通常のバックログアイテムと同様に管理されます。
SAFeの導入には、チームメンバーはもちろんのこと、経営層への説明も必須とされているため、ちょっと試したいという場合には不向きかもしれません。また、コンテンツの情報量が多いので、全体像がつかみにくいかもしれませんが、トレーニングに参加するとポイントを押さえて要領よく情報を得ることができます。

◆　◆　◆

各フレームワークとスクラムの関係を筆者の勝手なイメージでまとめると図10のようになります。性質・規模感がそれぞれ異なりますが、どれが優れている、劣っているということはありません。大規模アジャイルフレームワークの適用を考えている方は、自プロジェクト、組織にとって適切なものを選択しましょう。

図10：大規模アジャイルフレームワークとスクラムの関係イメージ

おわりに

これまでの大規模なプロダクト開発では、計画をしっかりと立て、設計し、実装・テストを長い時間をかけて行うウォーターフォール開発手法が一般的でした。しかし、1年後のビジネスニーズさえ予測が困難な変化の激しい現代において、長い時間をかけて作っていては世の中のニーズの変化についていけないばかりでなく、大規模であるがゆえビジネスリスクも大きくなります。
Agile Alliance ではアジャイルを「変化に対応する力で、不確実で激動の環境に対処し、最終的には成功する方法」と定義しています^注8。これは規模の大きさによるものではなく、当然大規模なプロダクトをアジャイルで開発する際にも当てはまるアジャイルの本質です。うまくアジャイルをスケールさせることができれば、ビジネスリスクを小さくとどめながら世の中の変化に追随し、価値の高いプロダクトを提供していくことができるでしょう。