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

新しい技術が市場で広く受け入れられるまでには、何段階かのステップを踏むと言われています。初期のブームからいったん熱が冷め、その後に現実的な選択肢として再評価を受けて軌道にのる、というようなステップです。個人的には、アジャイル開発は「再評価から広く適用」の入り口にいるように感じます。

その流れで最近出てきたのが「エンタープライズ・アジャイル」という考え方です。しかしこれまでのアジャイルとなにが違うのかが、いまひとつ理解しづらいようです。というよりも、ご説明に伺うと「そもそもアジャイルって」と基本的な質問がいまだに多かったりするのが現実です（もっとも、だからこそ「広まってきたな」と実感できるわけですが）。

さまざまな解説本や物語仕立ての本が出ているのに、なぜいつまでもこうした基本的な質問がなくならないのか？　もしかしたら、この手の本は、良くも悪くも日本での現実からちょっと離れた環境を前提としてないか？

「もっとベタベタな日本でのプロジェクトを意識した、リアリティのある説明ができないかな」

ということでスタートしたのが、この連載です。Web記事ですからプロジェクトをそのまま運営することができないので、あくまでも“ごっこ”に過ぎませんが、それを通して「エンタープライズ・アジャイルってなんだろう」というイメージを、少しでも具体的に持っていただければと思っています。

さて、“ごっこ”遊びにもそれなりのルールがないと、カオスになってしまいます。始める前に、基本的なルールを見ておきましょう。

「エンタープライズ」という言葉がつくと……

「エンタープライズ」という言葉を付けて「デカい」とか「大規模」という大雑把なイメージを付加してしまい、わかりづらくしてしまうのは、IT業界（というかITベンダーかな？）の悪い癖です。いまだに「アジャイル＝小規模向け」という根強いイメージが残る中で、「エンタープライズ」と「アジャイル」との関係性については、いくつかの視点があります。代表的なところで次のような視点が挙げられます。

視点1：大企業で、小規模なアジャイルを導入する

「日本の大企業は保守的」というイメージ（コンセンサス？）の下で、新しいやり方（アジャイル）にどんな意味があるか、どのように導入するかという論点。アジャイル自体の特性は変えずに、導入価値や方法に注目します。

視点2：大規模プロジェクトをアジャイルで運営する

小規模向けといわれていたアジャイルを、大規模な（つまり参加人数が多くなる）案件にどう適用するかという論点。アジャイルそれ自体のやり方の変化に注目しています。

視点3：組織や企業そのものをアジャイルに運営する

組織や企業の運営そのものをアジャイル（＝俊敏）に運営するという論点。開発プロジェクトだけでなく、それをつかさどる組織運営までも視野に入れて、どう変えるかに注目します。ある意味アジャイルの発展形かつ最終形でしょう。

一時期、あちこちのイベントで「企業へのアジャイル導入」みたいなパネルディスカッションが見られましたが、上記3つの視点がごちゃごちゃになって、会話が噛み合ってないのが散見されました。

※もちろん、中には「『アジャイル開発は変化に強い』＋『変化に対応するビジネス力が重要』→だから『エンタープライズ・アジャイル』」みたいな、「ただ文字列連結しただけの安易なメッセージ」もあったりしますが。

その中で、視点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と見ることができます。各々のフレームワークのスコープは違いますが、共通している問題意識として、次のものを挙げることができるでしょう。

多様な利害関係者

スクラムに代表される従来のアジャイルの世界観にくらべて、利害関係者が複雑かつ多様化します。より上位のビジネス決定者、アジャイル自体への理解が足りない関係者、組織や会社のITインフラの標準や共通アーキテクチャを管理するエンジニア、関連する既存システムを担当する開発者等々、関わるプレイヤーの顔ぶれは一気に拡がっていきます。

利害は一つではない

利害関係者が多様化することによって、各々の利害がぶつかる状況も多くなってきます。「なぜそのサービスが必要になるのか？」ということを、利害の対立する関係者に対しても説明できる能力（Accountability）と、そのビジョンを共有する手段やプロセスが必要になります。

すっごく日本的な表現に置き換えてしまうと、「しがらみをどうコントロールするか？（もちろんポジティブな方向に、です）」がエンタープライズ・アジャイルの要諦の一つと言っても過言ではないでしょう。

さて、この連載で何をするか

最後にこの連載の目的を明確にしておきましょう。
冒頭述べたように、エンタープライズだなんだと言いながらも、いまだに「そもそも」レベルの質問も多いのが現状です。そこで、読者対象を次のような皆さんに設定します。

• 製品開発よりも、社内システムや外向けのサービスを開発する組織。いわゆるシステムインテグレータが活躍するような領域のシステムの開発
• 従来のアジャイルについて、机上の学習、開発者主体のパイロットプロジェクト実施、あるいはそれに毛の生えた程度の経験
• 開発者に限定せず、関わる利害関係者（ユーザ部門等）も想定

フレームワークとしては、DADをベースに進めていきます。これは、SAFe vs DADでどちらが優れているか？　という構図ではありません。単に筆者自身の専門領域がDAD側だからに過ぎません（つまり深い意味はありません）。

ただし、極々私的な見解として、DADのほうが取り組みやすいと考えている点はここで述べておきます。「なぜ取り組みやすいのか？」は、連載の中でおいおい触れていきましょう。

“ごっこ”の遊具としては、私の勤務するHP社の“HP Agile Manager”を使います（以降、AGMと称します）。ただ、本連載はツールの詳細を説明することよりも考え方が主体となっています。

次回以降は、次のように進めていこうと思います。
第2回　遊具の準備と最初の一歩
第3回　計画する
第4回　作りながら、己を知る
第5回　何事も節目が大事
第6回　おさらい

次回は、遊具の準備と、計画の第1歩に踏み出します。“ごっこ”ですから、気楽におつきあいください。