アジャイルをスケールする方法：エンタープライズチームのための実践ガイド

理想としては

アジャイル変革を始めるまさにその時点から。

理論上は

プロジェクトの複雑さと範囲が、複数のリソースによる作業を必要とするほど大きくなった時点で。

現実的には

組織が次のような状態を日常的に抱えている、あらゆる段階で。

• コラボレーションの不足
• ビジネス上のボトルネック
• 収益の停滞または減少
• デリバリーサイクルの長期化
• 複雑なプロセス
• 組織内の摩擦
• サイロ化した業務
• 官僚的な障壁
• チーム間で分断されるシステム

これらはいずれも、アジャイルの実践がスケーリングを必要としていることを示す兆候です。

この段階では、組織がアジャイルのスケーリングにどれだけ適しているかを確かめる評価が必要です。デザイン、IT、セキュリティといった専門機能やステークホルダーの支援が不足していないかを評価するために経営層の後押しを得て、スケーリングを妨げている全社的な要因を特定しましょう。

• ボトムアップ
• トップダウン

ボトムアップのアプローチでは、チームレベルからスケーリングを始め、組織内の他のチームやマネジメント層へと広げていきます。
これは互いの作業が独立しているチームには最適です。ただしチーム同士が依存し合っている場合は、戦略を見直す必要があります。

トップダウンのアプローチでは、まず上位のマネジメント層がアジャイルへの移行を受け入れ、それがチームレベルへと浸透していきます。
この場合、スケーリングへの移行を導いてくれるコンサルタントやアジャイルコーチを迎えることで、より確実に進められます。

どちらのアプローチでも、移行後の構造はおおむね次のようになります。小規模で多分野にわたる複数のチームが、複雑な課題を細かく分解しながら取り組みます。各チームは、素早いMVPと緊密なフィードバックループを使って、分解した各要素の解決策を生み出します。そのうえで協働し、それらの解決策を一貫したひとつの全体へと統合します。このコラボレーションの要諦は、計画そのものではなく変化への対応こそが中心であると徹底することです。プロセスの成否を測る明確な指標は、アウトプット（コード行数や新製品の数など）からアウトカム（成長、収益、顧客体験など）へと焦点が移ったかどうかです。

• ビジネス戦略は何ですか？
• 計画されているプロジェクトはいくつありますか？
• それらに取り組むチームはいくつありますか？
• 1つのプロジェクトの複雑さはどの程度ですか？
• 現在のチームは、これらのプロジェクトに取り組むだけの体制とスキルを備えていますか？
• うまくいっていることは何ですか？改善すべきことは何ですか？
• 現在の職場文化は変化を後押ししますか？
• スケーリングのKPIは何になりますか？
• チームはアジャイルをどの程度理解していますか？
• チームはアジャイルな環境で成果を出せますか？
• 移行の成功はどのような状態ですか？
• 移行に影響し得るリスクや依存関係を洗い出していますか？

Scaled Agile Framework (SAFe)

Scaled Agile Framework (SAFe) は、最短かつ持続可能な期間で最高品質の製品を生み出すという組織目標を、企業が達成できるようにします。ScrumをEnterprise Levelへとスケールさせるアプローチであり、数千人規模の企業であっても、ビジネスのニーズに応じて自由にスケールできます。

従来のScrumのロールに加えて、SAFeにはRelease Train EngineerやSolution Engineerといった新しいロールが定義されています。さらに、PI Planning、Program Incrementの実行、Agile Release Train、Solution Trainなどのセレモニーやプロセスも追加されています。

SAFeはサーバントリーダーシップとリーンアジャイルリーダーシップの考え方を取り入れ、組織構造を導入するだけにとどまらず、新しいマインドセットを根づかせます。SAFeにおけるロールの全体像は、Kendisブログで詳しく見る。

Disciplined Agile (DA)

Disciplined Agile Delivery (DAD)は、高品質な製品をより速く生み出すという企業のニーズに合わせて、状況に応じたガイダンスを示す、扱いやすく柔軟なフレームワークです。Scrum、Kanban、XP、Agile Modelling、Unified Processなど、世界で実績のあるリーンアジャイル手法を組み合わせたハイブリッドモデルです。

DAは、開発部門と組織の他部門とのあいだの壁を取り払い、すべてをひとつの取り組みにまとめることで、プロジェクトの立ち上げからエンドユーザーへの提供までを一貫して扱います。Scrumチームと組織の他部門、そして双方の作業を調整・整合させ、すべてを透明な状態に保ちます。

Large Scale Scrum (LeSS)

Large Scale Scrum（略してLeSS）は、アジャイルソフトウェア開発を代表するフレームワークのひとつです。複数チーム向けのScrumフレームワークで、12人規模から数百人、数千人規模まで、ひとつの共有プロダクトに共同で取り組むアジャイルチームに適用できます。

LeSSを使えば、大規模な製品も小規模な製品も作れます。ルール、プロセス、ロール、成果物の強制が少ない、シンプルで最小限のフレームワークです。ロールはプロダクトオーナー、スクラムマスター、チームという従来のScrumのものだけです。

LeSSは非常に顧客中心です。チームが顧客と直接やり取りする一方で、プロダクトオーナーはロードマップ、優先順位、プロダクトの長期ビジョンの策定に集中します。LeSSにおけるロールの全体像は、Kendisブログで詳しく見る。

Tribe

Spotifyが広めたTribeモデルは、スケーリングアジャイルのフレームワークに大きな変化をもたらしました。人気の音楽サービスであるSpotifyは2008年にローンチされ、いまでは複数のタイムゾーンにまたがるチームへと成長しました。その成功は、深く根づいたアジャイルの手法と、独自の色を加えたスケーリングの活用によるものです。

このフレームワークで“Squads”と呼ばれるチームは、KANBAN、Scrumのスプリント、XP、あるいはこれらを組み合わせたアジャイル手法で業務を進めます。Tribeモデルにおけるロールの全体像は、Kendisブログで詳しく見る。

• 一貫したプロセスとプラクティスの実践
• ステークホルダーである経営層からの支援
• チーム横断での共通ツールの利用
• アジャイルコーチによる助言や支援
• 文脈に即したアジャイル知識の強固な土台
• 市場投入までの期間の短縮
• より柔軟で反応の速い職場環境
• 同僚同士の相互尊重
• 全体的な生産性の向上
• 意思決定の分散

フレームワークの理解不足

スケールドアジャイルの変革の多くは、実践に移される前から失敗が決まっています。理由は3つあります。

• 変革を率いる人たちは、ツールセットを導入しさえすれば組織が魔法のように変わる、と誤解しがちです。この場合、フレームワークの限界がそのままスケールドアジャイルの限界になります。
• 特定のスケーリングフレームワークを採用する前に、自社のニーズを見極めようと努める経営層はごくわずかです。その結果、実行の細部で準備不足が露呈し、チームの信頼を失うことになります。
• 準備不足のリーダーシップとは、本を1冊読んだり短期コースを受けたりしただけで、スケーリングが組織の各階層でどう進むのかを実地で知らないまま指揮を執ろうとすることでもあります。その結果、プロセスは不十分にしか実装されず、原則も誤って解釈されます。

変わろうとする意欲の欠如

慣れ親しんだ場所から一歩踏み出すのは常に難しく、大きな組織ではなおさらです。惰性の力は確かに存在します。だからこそ、組織が変化に踏み出すとき、最初に備えるべきは、新しいプロセスや不慣れな領域に伴う居心地の悪さに怯まない意欲です。

新しいマインドセットの形成

どのスケーリングモデルを採用する場合でも、大前提となるのはリーンアジャイルのマインドセットです。これは特定の一人が持てばよいものではなく、組織のDNAに組み込まれている必要があります。リーダーは、チームの優先事項を第一に置くサーバントリーダーシップの考え方を自分のものにしなければなりません。チームには、自分たちの仕事に当事者意識を持つ方法を伝え、自ら意思決定できる権限を与える必要があります。

文化の転換

従来型のマネジメントでは、チームは階層構造に従い、それぞれのサイロの中で作業することを強いられます。上位のマネジメント層が立てた計画に忠実に従うことが求められます。スケールドアジャイルでは、新しい働き方の文化を取り入れる必要があります。

そこではトップダウンの階層という発想がなくなり、サイロが解消され、チームとマネジメント層のあいだの透明性とコラボレーションが高まります。権限はもはや一極集中しません。

この文化の定着には時間がかかり、決して楽な道のりではありませんが、その価値は十分にあります。当事者意識を全員で分かち合う文化へと意識を変えるには、多くの努力と、スケーリングという目的への強いコミットメントが必要です。

適切でないツール

サイロの中で作り上げることは、アジャイルにとって致命的です。組織では部門ごとに異なるツールが使われがちで、それが分断を生みます。

組織の技術スタックを揃えることは、スケーリングにおける最大級の課題のひとつです。全員がアクセスできるトラッキングツールが必要です。情報が透明に流れ、可視性とコラボレーションを促すものでなければなりません。そのツールでは、戦略的な計画、依存関係、リスクを作成できる必要があります。Kendisはまさにそうしたスケーリングのソリューションであり、PI Planningや依存関係管理からSolution-Levelの調整まで、あらゆるビジネスプロセスを可視化することで、パートナーのプランニングとトラッキングのニーズすべてに応えます。

リモートチーム

パンデミック後の世界では、リモートでのスケーリングはもはや目新しいものではありません。ただし、固有の課題があります。

複数の拠点
分散したチーム
異文化間のコミュニケーション
サードパーティ製テクノロジーへの依存の高まり

これらは、スケーリングで直面する課題のほんの一例です。課題と同じように、スケーリングをめぐるいくつかの誤解も存在します。こうした課題も誤解も、乗り越えられないものではありません。ただし、組織に十分な備えがなければ、対処は容易ではないでしょう。

（これらの課題をチームと共有したいですか？このテーマを扱ったブログ記事をご活用ください。）