エンタープライズ・アジャイルってなんだろう？ 3つの視点と2つのフレームワーク

その中で、視点2の「規模感」と「アジャイル」との関係については、ある程度の答えが出ているように思います。いわゆる「スクラム・オブ・スクラムズ（Scrum of Scrums）」に代表される、自主独立したチームの階層的な構造です。

たとえば、オープンソースのEclipseのサイトでは、開発プロセスが公開されています。
［参考］Eclipse Development Process 2014

図1: Eclipseの開発体制（クリックで拡大）

図1は、上記のサイトからプロジェクト構造を表す図を引用したものです。個々のプロジェクトは自分達でリソースを所有し、コミッタを抱えることで決定権限も持って、他から独立して運営されます。ご存じのようにEclipseはプラグインの集合体ですから、個々のプラグイン・プロジェクトの成果物が集まって、プラットフォームとしてのエディション（最近ですと、「LunaのStandardエディション」とか）ができあがります。Eclipse自体が様々な商用製品のベースになっていることからわかるように、それ自身が大規模なアジャイル開発の成功例であることは、みなさんも同意いただけると思います。

では、こんな成功例があるのに、なぜいまさら「エンタープライズ」とわざわざ宣言する必要があるのでしょうか？　「エンタープライズ」という言葉で意図したい問題意識は何でしょうか？　代表的な2つのフレームワークの特徴を通して見ていきます。

2つのフレームワーク

最近、エンタープライズ・アジャイル向けのフレームワークとして取り上げられているものが2つあります。一つはDean Leffingwell氏の提唱する「スケールド・アジャイル・フレームワーク（Scaled Agile Framework：SAFe）」、もう一つはScott Ambler氏の提唱する「ディシプリンド・アジャイル・デリバリー（Disciplined Agile Delivery：DAD）フレームワーク」です。

どちらのフレームワークも開発の企画段階からデリバリー（かつその繰り返し）まで考慮しており、共通点も多いのですが、双方を比較するとそのスコープ（というか視点）には大きな違いがあります（表1）。

表1: 2つのフレームワークの比較

アジャイル開発では、「ビジネス上の重要性によって開発するストーリーの優先順位をつける」という作業を計画時に行います。では肝心の「ビジネス上の重要性」は、誰がどうやって決めるのでしょうか？　この疑問を突き詰めていくと、ビジネスニーズを明確にする役割の人達の決定と、実現手段であるサービスの開発者が作成するものが、方向性を同じくしている必要性に気づきます。SAFeは、PMBOKの「プロジェクトープログラムーポートフォリオ」を模した体系化によって、ビジネス目標が、実装対象のストーリーに具体化されるまでをモデル化しています。もちろんそれに付随して、各プレイヤーがどう振る舞うかも記述されます（図2）。

それに対して、DADは「一つのプロジェクトの完了」にフォーカスしたフレームワークです（図3）。プロジェクトの開始（企画）時点からデリバリーまでの間には、多様な利害関係者と同意を取り付ける意志決定のポイントが複数あります。しかし、プロジェクトの置かれた環境（関係者のスキルや知識の差、使う道具の違い、リスク、サービスの性格等々）によって判断の基準はケースバイケースにならざるを得ません。最近DADの本家のサイトでは、“Decision Framework”という表現を使っていますが、その心は意志決定のポイントがなにか、どのような点を考慮すべきか、各選択肢のメリット・デメリットは何かを提示することで、プロジェクトに関わる利害関係者との合意形成を助けることにあります。

図2: Scaled Agile Frameworkのライフサイクルチャート（クリックで拡大）

（出典：オージス総研）

図3: DADのライフサイクルチャート（クリックで拡大）

あえて紐付けるなら、DADは前述の視点1、SAFeは視点3と見ることができます。各々のフレームワークのスコープは違いますが、共通している問題意識として、次のものを挙げることができるでしょう。