エンタープライズ・アジャイルのフレームワークがなぜ必要か？
いわゆる「エンタープライズ・アジャイル」、大規模なアジャイル開発のフレームワークとして、LeSS（Large Scale Scrum）やSAFe（Scaled Agile Framework）が知られています。
多くのアジャイルの本に書いてある手法は、XPやスクラムあるいはカンバンでも、一つのチームで製品をつくることが前提で描かれています。
しかし、ある程度の規模になると、複数のチームに分かれて製品開発を行うのが普通です。そうした場合、アジャイルではどのようにすすめていけばいいのかという問題にぶつかります。
またアジャイルの課題として、ウォーターフォール開発ではおなじみの「要求定義」あるいは「製品設計」をどうするのかという問題がありました。
特に初期のXPで（誤解も含めて）言われてきたことですが、アジャイルは「要件定義」をしない。「製品設計書」を書かない。なぜなら顧客との頻繁なやり取りの中で、自律的、自己組織化的に製品ができあがるものである。
ウォーターフォールの「要件定義書」は、「製品開発者は（将来を含めた）顧客の要望を100％理解している」「設計時とリリース時の間に製品を取り巻く環境や状況に変化はない（もしくは変化が予測可能である）」という２つの前提があります。
しかし実際には、「自分が本当にやりたいこと」すらわからないのに、他人の（将来を含めた）要望や要求を理解することは本当に可能なのか？そして、まさに今のWithコロナ、Afterコロナの状況を見るまでもなく、近い将来のことですら予測は不可能なのではないか。
実際ウォーターフォール開発で、予算的に計画通りに進捗したプロジェクトは全体の４分の一程度であったと言われています。
そうかと言って、XPやスクラムなどアジャイルを取り入れれば全てうまくいくかと言うと、そういう単純なものではもちろんなく、プロダクトオーナー（PO）やチーフプログラマー、スクラムマスターの力量次第、場合によっては彼らに過度な負担をかけてなんとかリリースに持ち込む、という事例も少なくありません。
グライダーは自然の力で空を滑空しますが、最初は飛行機に引っ張ってもらうなどの動力を必要とします。空を飛ぶにはやはり「滑走路」は必要なわけで、ある程度の規模の製品開発、あるいは事業開発になると、顧客や関係者の要望や要求を聞き、設計に落とし込むという「上流工程」が必要となるケースが多いと思われます。
そこで「エンタープライズ・アジャイル」のフレームワークとして、LeSSやSAFeが注目されています。
ここでは両者の簡単な説明と比較を行ってみたいと思います。
LeSS（Large Scale Scrum）
スクラムのスケーリング手法としては、スクラム開発者のジェフ・サザーランドが提唱するScrum@Scaleや、Scrum of Scrumがあります。LeSSはこれらの手法をベースにラーマン・クレーグが提唱した手法です。
最大8チームまで（一チームも8人まで）対応しています。（8チームを超えるとLess Hugeという手法になります。）
基本的にチームが分かれていても、一つのバックログで対応します。そしてそれぞれのチームの代表が（Scrum of Scrumと同じく）、スプリントプランニングやレトロスペクティブ（振り返り）を行い、それと連動する形で、各チームもスクラムのイベントを行います。
新たな製品やシステムを開発する場合、それがどのくらいの規模感でどのくらいのチーム編成になるか、最初はわからないケースが多いと思われます。
そこでLeSSでは、まず少数のチームでスプリントを回しながら全体の計画をつくっていきます。
したがって、柔軟なチーム編成ができる組織づくりが必要となります。
日々行う業務は、スクラムでやっていることと殆ど変わりません。スクラムに慣れている組織なら、比較的スムーズに実行が可能であると考えられます。
LeSSフレームワーク
SAFe（Scaled Agile Framework）
ディーン・レフィングウェルによって提唱された大規模アジャイルの手法です。
下図のように４つのレイヤー（レベル）でマネジメントします。
上位のレイヤー（レベル）で、ユーザー要求や設計を行い、下位のレイヤー（レベル）で開発を行います。プログラムレベルとチームレベルの関係はScrum of Scrumに近いです。
階層を持つことや、設計（上流）と製品開発（下流）が分離しているところから、ウォーターフォール的なエッセンスもあり、「これはアジャイルではない」という声も聞かれます。
反面（特に日本の）SIerが現在の組織体制をそれほど変えずにアジャイルに取り組むフレームワークとして取り掛かりやすい一面も見逃せません。
2019年5月に発表された「Annual State Of Agile Report」によれば、大規模アジャイルへの取り組みので、SAFeの採用が30％、Scrum of Scrumの採用が16%、LeSSが３％となっています。今年の6月には富士通が、SAFeの管理会社であるSAI社とパートナーシップ契約を結びました。大企業へのSAFeの浸透が加速するかもしれません。
SAFeフレームワーク
LeSSとSAFeどちらが自分の組織に向いているのか。
LeSSは、アジャイル本来の目的である自己組織化組織、自律的なプロジェクトに向いています。またイノベーションも起きやすいでしょう。
ただし、上流工程に関する手法があまりないため、特にチームが増えると全体像が見えなくなる不安はあります。
この場合、後述のICONIXとの組み合わせは、組織やシステムのダイナミズムを失わせないで、全体像を見ることができる方法論です。
一方で、大企業のSIer等が既存の組織をできるだけ変えずがリスクをできるだけ少なくすることを考えるとSAFeが向いていると思います。
反面アジャイルの根幹であるAgility（俊敏さ、柔軟さ）が失われやすく、特に経営陣やビジネスサイドが硬直化すると、変化に対応できなかったり社会や顧客に合わないシステムが出来上がってしまう可能性はあります。デザイン思考を取り入れるなど、顧客や社会情勢の変化にうまく対応できるかどうかが成功の鍵となります。
ベンチャーや中堅企業へのアジャイル・フレームワークに適した「ICONIX for Business Design」
LeSSもSAFeもあるいはScrum of Scrumもアジャイル開発をすすめるための枠組みを定めたものです。その枠組みの中で「何をするのか」は、個々の企業や組織ごとに定めていかなければなりません。
そこで役立つフレームワークの一つにICONIXがあります。
ICONIXはローゼンバーグが提唱したUMLベースのソフトウェア・デザインのフレームワークです。
小規模なシステムから大規模なシステムまで適応が可能で、現在ではアジャイルと組み合わせ、「Agile ICONIX」とも呼ばれています。
システムの要求を可視化して、その振る舞いを明確にした上で、振る舞いをオブジェクトに割り当てる。とてもコンパクトですが、全体を把握しかつ変化に対応できる強力なプロセスです。
ICONIXプロセス
ただ、ICONIXはソフトウェアのみが対象ですし、UMLベースという若干古さを感じさせるところもあり、私たちは、このICONIXをビジネスデザイン全般に拡張させる「ICONIX for Business Design」を開発しています。
詳しくは、2021年の「日本ビジネスモデル学会」の論文誌で発表した論文を参照ください。
「ICONIX for Business Design」はデザイン思考とアジャイル開発をつなぐフレームワークとして、システム開発分野のみならずDXへの取り組みの一助になると考えています。
ICONIX for Business Design
DXの推進、自律組織やプロダクトをデザインする手法のセミナー
日本能率協会主催「DX時代に求められる「３つの思考法」入門セミナー」開催
