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

2020年3月26日公開

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

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

スクラムガイドによれば(*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®のマネジメント層に異動担務させることも大いに想定されます。

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

参考文献

   

執筆

  • 坂田 晶紀(さかた あきのり)

    株式会社富士通ソフトウェアテクノロジーズ Agile⁺開発センター
    ソフトウェア開発者、中小企業診断士(Registered Management Consultant)

    メインフレームOS、主にシステム資源最適化プログラムの開発に従事。
    その後、WEBアプリケーション開発業務に携わり、2002年からアジャイル開発を実践。
    アジャイルソフトウェア開発の品質管理、開発管理、組織マネジメントを中心に、約1,000の職場をコンサルティング。

   

ページの先頭へ


後編Top
後編 アジャイル開発チームの適性規模 1
後編 アジャイル開発チームの適性規模 2
後編 アジャイル開発チームの適性規模 3
後編 アジャイル開発チームの適性規模 4
後編 アジャイル開発チームの適性規模 5
後編 アジャイル開発チームの適性規模 6
後編 コストに対するアプローチ 1
後編 コストに対するアプローチ 2