エンタープライズアジャイル
- 2019.02.18
- アジャイル
本記事ではエンタープライズアジャイルについてお話しします。日本でも複数のチームでアジャイル開発をすること、その方法論について注目が集まっています。スクラムに関するカンファレンスにおいても関係する事例のセッションは注目されていました。本記事でもエンタープライズアジャイルについてお話をしていきます。
スクラム(またはアジャイル開発)をスケールさせる
大規模なアジャイル開発に興味のある方はおそらくすでにある程度はスクラムについて知識があることかと思います。スクラムはご存知のようにチームの開発に焦点があたっており大規模なプロジェクトでどういった方法でアジャイルに開発を進めていくか、については記述されていません。スクラムガイドには開発チームについて以下の通り記載があります。
開発チームに最適な人数は、小回りが利く程度に少なく、1 つのスプリントで重要な作業が成し遂げられる程度に多い人数である。開発チームのメンバーが 3 人未満の場合は、相互作用が少なく、生産性の向上につながらない。また、開発チームの規模が小さいと、スキル不足が原因でリリース判断可能なインクリメントを届けられない可能性もある。メンバーが 9 人を超えた場合は、調整の機会が多くなってしまう。また、チームの規模が大きいと経験的プロセスが複雑になり、有益ではなくなる。スプリントバックログの作業に携わらないのであれば、プロダクトオーナーとスクラムマスターはこの人数に含まない。
出典：スクラムガイド
スクラムガイドそのものは1つの開発チーム(3〜9人)を対象にしたフレームワークとして設計されているとわかります。その意味で前述したようにこれ以上の人数になった場合の対処については述べられていません。
一方でやはり案件の規模が大きくなるとアジャイルに大人数で開発を進める必要がでてきます。そのため特に欧米諸国を中心に大規模アジャイル開発の手法が研究されていたようです。論文などをみると2000年代前半からすでに盛んにそういった手法が研究されていたようです。
Since 2001 agile software development approaches are being adopted across a wide range of organizations and are now being applied at scale. There are eight factors to consider – team size, geographical distribution, entrenched culture, system complexity, legacy systems, regulatory compliance, organizational distribution, governance and enterprise focus – when scaling agile.
(訳)2001年からアジャイルソフトウェア開発のアプローチは幅広い組織に適用されてきた、そして今では大規模に適用されるようになっている。アジャイルをスケールさせる時、チームの大きさ、地理的な分散、文化の構築、システムの複雑さ、レガシーシステム、企業のコンプライアンス、組織の分布、ガバナンス、企業が重きをおいていること、の8つの考えるべき要素がある。
記載されているように大規模にアジャイルな開発をしようとするとチームだけでなくより大きな視点で考える必要があり組織全体のことなどが課題になってきます。
日本においてはまだまだ大規模なアジャイル開発プロジェクトの事例は少ないと思います。一方で国外では大規模アジャイルに関する書籍も多く出版されています。LeSSに関する書籍は日本語に翻訳されており、他にもSAFeについての書籍も出版がされています。
 |
|
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 新品価格 |
日本では最近富士通がSAFeを推進するScaled Agile, Inc.とパートナーシップ契約をしたことが知られています。
富士通、米Scaled Agile, Inc.とパートナーシップ契約を締結し、 エンタープライズ領域における大規模アジャイルを推進
まだ事例が少ないと思いますがSAFeは比較的規模の小さな組織でのアジャイルから大きな組織でのアジャイルまでカバーしており海外では事例が最も多い企業向けのアジャイルのフレームワークです。以下グラフでは企業で複数チームでアジャイル開発を行う時のフレームワーク選定を示しています。グラフで示すようにSAFeが最も選択されているフレームワークとなっています。
スクラムをベースにスケールさせる(Large Scale Scrumの場合)
本記事では具体的なフレームワークとしてLarge Scale Scrum(LeSS)をとりあげます。（LeSSは日本においても比較的事例が報告されているため選定しています。）
LeSS(レス)は大規模なアジャイル開発をするためのフレームワークの一つになります。スクラムがベースになっておりスクラムに慣れ親しんだ方にとっては理解が容易でしょう。まとまった情報をしっかり把握したい方には今ですと先ほどもご紹介した書籍を一読するのがおすすめです。LeSSはless worksのサイトでも詳しくまとまっていますので今すぐ知りたい方はそちらを確認いただくのもおすすめです。
LeSSにはさらに大規模なプロジェクトでも適用できるLeSS Hugeというフレームワークもあります。
出典：LeSS Huge
僕自身が経験があるのはこのLeSS Hugeです。LeSSとLeSS Hugeは根っこにある思想は同じです。しかしLeSS HugeはLeSSをベースにエリアという機能ごとに分割した新たな階層を設けることでさらにスケールできるよう設計されています。上記図を見ていただくとイメージがつくでしょう。LeSS Hugeについても書籍内にしっかり記載がありますので興味がある方はぜひ。
|
|
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 新品価格 |
本記事は以上になります。LeSS、LeSS Huge共に規模が大きくなると組織全体を巻き込む必要がありますし、場合によっては地理的に離れたチーム同士てプロジェクトを進めることもあるでしょう。1つのチームでスクラム等をしている時よりももちろんハードルは多いですが大人数でアジャイルに開発を進めるためのフレームワークとしては特に海外で実績も数多くありますし信頼できるフレームワークもあります。国内での事例はまだまだ少ないですが日本語の書籍もでてきましたので参考にしつつ進めるのがいいでしょう。
なおスクラムについては下記記事で詳細についてまとめていますので参考になれば幸いです。