大規模アジャイル開発の可能性（後編）アジャイル開発は大規模に耐えられるのか？

大規模開発に向いていると思われているウォーターフォール開発も、実は大規模化するにつれてリスクが高まることを前編で述べました。ここでは、アジャイル開発は「大規模化に耐えうるエンタープライズアジャイル」として成立するのか？について考察します。

アジャイル開発チームの適性規模

スクラムガイドによれば（＊1）開発チームの適正規模は、9名以下つまり1桁だと記載されています。

10名を軽く超えていても上手くやっているアジャイル開発チームはよく見かけます。
（上手くいっているチームほど10名を軽く超えている印象を受けます）

果たして、10名程度の人数で、個々のメンバへの調整がチーム活動を阻害するほどののコストになるでしょうか？

前編で、ノードとリンクの関係を下図のように示しました。

アジャイル開発の場合はどうでしょう？

アジャイル開発チームの場合、多くは

• 常時結合（継続的統合：Continuous Integration）を実施
• コードの共同所有

を実施しているようです。
であれば、下図の右側のようなコミュニケーションパスとなるのではないでしょうか？

共同所有され、しかも常時結合された動くソフトウェアそのものを媒体にしたコミュニケーションであれば、コミュニケーションパスは人数の2乗に比例したりしないのではないでしょうか。

また、ペアプログラミングを実施しているのであれば、コミュニケーションパスは下図のようになるでしょう。

ペアプログラミングとは（大げさに言えば）脳を共有してプログラミングすることです。
上図のように、コミュニケーションパスはソロプログラミングに較べて半減します。

さらに、ペアのローテーションを頻繁に実施するとなればどうでしょうか。

個々のメンバへの調整がチーム活動を阻害する人数は、決して1桁超えた程度ではなさそうです。
アジャイル開発であれば、コミュニケーションのありようは下図の左から右へと変化し、結果的にコミュニケーションパスはかなり減少しそうです。

つまり、アジャイル開発はスケールしやすいといえそうです。

ではなぜ、メンバ数1桁が神話のように信じられているのでしょう。
ひょっとすると、下図のように誤解されているのではないでしょうか？

複数のアジャイルチームで構成される大規模アジャイル開発

1つのアジャイル開発チームがスケールされるとはいえ、さすがに100名を超えるメンバの場合は直感的にも運営が困難になりそうです。

そこで、大規模開発に対応するためのアジャイルフレームワークがいくつか提唱されています。
LeSS、Nexus™、Scrum@Scale™、SAFe®などといった大規模アジャイルフレームワークがそれです。

単一チームでは成しえない、より大きな規模の開発に向き合うためのフレームワークです。

• LeSS

  LeSS（Large-Scale Scrum）は、著書「初めてのアジャイル開発」などで知られるクレーグ・ラーマンらによって提唱された大規模アジャイルフレームワークです。
  規模によって2種類のLessが用意されており、いずれも複数のスクラムチームによって構成されます。
  小規模は"Less（basic Less）"、大規模は"LeSS Huge"と呼ばれます。
  Less Hugeは、8チーム以上（1,000～2,000名程度まで）の規模であるとされています。

• Scrum@Scale™

  Scrum@Scale™はスクラムの提唱者の1人であるジェフ・サザーランド氏によって提唱された、複数スクラムチームを一貫して機能させるための大規模アジャイルフレームワークです。
  Scrum@Scale®ガイド によれば、「（複数の）スクラムチームだけから構成されるために、理解は容易である」とされています。

• Nexus™

  Nexus™はスクラムの提唱者の1人であるケン・シュウェーバー氏によって提唱された、3～9のスクラムチームとNexus統合チームによって構成される大規模アジャイルフレームワークです。

• SAFe®

  SAFe®は、ディーン・レフィンゲル氏によって提唱された大規模アジャイルフレームワークです。
  スクラムチームを開発組織の構成単位としており、PPM（Program Portfolio Management）が特徴的です。

• スポティファイモデル

  スポティファイとは、スポティファイ・テクノロジー社によって提供されている音楽配信サービスであり、その開発モデルがスポティファイモデルと呼ばれることがあります。
  開発プロセスのみならず、クロスファンクション、技術経営、組織学習など組織構造を含めた大規模アジャイルモデルです。

大規模アジャイルが解決すべき課題

大規模アジャイル開発が目指すものは、単一チームのアジャイル開発と同様であり、テクノロジーコラムの「アジャイル開発とは（前編）」でご紹介した以下の特長

これらを実現することです。
これらの特長は、テクノロジーコラムの「アジャイル開発とは（後編）」の最後に述べたように規模の経済からスピードの経済への変革、すなわち、変化を受入れるためのリードタイム短縮を目指すことによって得られるものです。

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

多くの大規模アジャイルフレームワークの目指すものを端的に言ってしまえば、

つまり、大規模アジャイル開発においても、「唯一のコードベース」を保ちつつ、いかにリードタイムを短縮できるかということに尽きるのではないでしょうか。

個々のアジャイル開発チームによって十分に短縮されたリードタイムを、大規模アジャイルでも短いまま維持するための「常時結合（継続的統合）の戦略」が大規模アジャイル開発の意義だと考えられます。

コストに対するアプローチ

最初に全てが計画されているウォーターフォール開発では、品質の確保とともにコストダウンによる利益の確保が重要な課題です。価格が決定されているため、利益確保の方法がコストダウンに依らなければならないためです。
さて、大規模アジャイル開発はどのようにコストに対してアプローチするのでしょうか？

アジャイル開発は、XP（eXtreme Programming：エクストリームプログラミング）のプラクティスである計画ゲームに代表されるように、

を目指しています。
であれば、大規模アジャイル開発も、ウォーターフォール開発のようにコストに対するアプローチも必要ではないでしょうか。
しかし、アジャイル開発はウォーターフォール開発のようなコストダウン戦略を単純に取り込むことはできません。最初に全てが計画されている訳ではないからです。

コストを統制すると同時に、アジャイル開発の特長である自律によるスピードも維持する。
そんな戦略が必要そうです。

これは何かに似ています…

DXなエンタープライズアジャイルとJIT

門田安弘氏の著作「トヨタプロダクションシステム―その理論と体系」によれば、
JIT（Just In Time）は、かんばん方式とMRP（Materials Requirements Planning：資材所要量計画）の調和によって成立されているようです。
要約して下図に示します。

変動対応生産と総生産量の担保のために、プルシステムであるかんばん方式と原材料量や工員数を決定するMRPが併存し、生産平準化を実現します。

大規模アジャイル開発、いわゆるエンタープライズアジャイルも類似性が認められるのではないでしょうか？

変動対応開発と機能提供の担保のために、プルシステムであるチケット駆動開発と予算や開発者数を決定するPPM（Program Portfolio Management）が併存し、開発平準化を実現する。
これらによって、

これらの調和を図れそうです。
PPMに対応した大規模に対応したアジャイルフレームワークとしては、先に述べたSAFe®があります。
一見、他のフレームワークよりも分がありそうです。

しかし、PPMに対応しているからといって安直にSAFe®を採用するにはリスクもありそうです。マネジメントのオーバーヘッドが、必要以上に大きくなることがあり得るからです。
ウォーターフォール開発では、設計／実装／テストに関わることのないメンバー（非開発要員）が多くいます。大規模なウォーターフォール開発になれ親しんだSIerが非開発要員を、SAFe®のマネジメント層に異動担務させることも大いに想定されます。

雇用対策的なこの異動担務が、大規模アジャイル開発を官僚的な組織にさせてしまえば、自律性は失われ開発者はただの歯車のようになり、重鈍な塊になるリスクがあることを忘れてはならないのではないでしょうか？

続いて番外編では、大規模アジャイル開発の可能性についてコミュニケーションの視点で説明します。

参考文献

• ＊1 Ken Schwaber, Jeff Sutherland. “The Scrum Guide”. Scrum Guides. 2017.
  https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf, (参照 2020-03-17).
• Scrum at Scale, LLC."Scrum@Scale™".
  https://www.scrumatscale.com/. (2020-01-10参照)
• The LeSS Company B.V. "LeSS（Large-Scale Scrum）".
  https://less.works/. (2020-01-10参照)
• Scrum.org™. The Nexus™ Guide.
  https://www.scrum.org/resources/nexus-guide. (2020-01-10参照)
• SAFe® Scaled Agile
  https://www.scaledagileframework.com/ (2020-02-25参照)
• Ken Schwaber and Jeff Sutherland. The Scrum Guide™,
  https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf(2020-02-25参照)
• Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む .
  https://leantrenches.wordpress.com/2013/10/16/scaling-agile-at-spotify-ja/(2020-03-02参照)
• 門田安弘. “トヨタプロダクションシステム―その理論と体系”. ダイヤモンド社, 2006/02, ISBN 978-4478460085.