第2回　ディシプリンド・アジャイル・デリバリーというお作法

“アジャイル”の次へ：IBMの開発プロセス戦略の今（2）

2012/03/21 14:00

　前回は、「RUPはどこに消えたのか？」という（少々あざとい^^;）タイトルのもと、RUPをめぐるここ数年の動きを概観してきました。「あれ？アジャイルがないじゃん？」と思った方もいらっしゃることでしょう。なにせ連載タイトルにはアジャイルってありますからね……ということで、今回はアジャイルのお話です。

はじめに

　ここ数年、IBM Rationalチームは、グローバルで"Agility@Scale（"アジリティー・アット・スケール"と読みます）"というメッセージの下、アジャイル・ソリューションをアピールしてきました。その動きの中で昨年から、ディシプリンド・アジャイル・デリバリー（以降、DAD）という名のアジャイル・プロセスを構築しました。DADについては、「DAD入門」というホワイトペーパーを配布していますが（※配布終了しました）、この稿では日本でのアジャイル事情も加味して、DADの位置づけとその意味をご紹介したいと思います。

そもそも大規模に適用するとはどういうことか？
――アジャイル・スケーリング・ファクターという考え方

　「アジャイルと大規模」をテーマにした論考、セミナー、パネルディスカッションが一時期よくみられました（ちなみに、うちもやりましたが(・_;)）。これらをみてみると、論者の立ち位置には以下の3つのパターンがあるように思います。

立ち位置1：大企業に少人数のアジャイルチームをたくさん増やす
→これを「大規模に展開する」と呼ぶ流派
立ち位置2：大規模（＝大人数）プロジェクトに小規模チームで培われたプラクティスが適用できるか
→大人数で実施できるか？あるいは大人数で実施するためにどうするか？を論じる流派
立ち位置3：大規模（＝大人数）プロジェクトを、少人数のアジャイルチームの集合体として編成して運営できるか？
→多くのチームをどうまとめるか？多くの利害関係者とどうコラボレーションするか？を論じる流派

　これらが整理されずに、会話が微妙にかみ合っていないパネルディスカッションを見たことも少なくありません。

　さて、これら3パターンに共通するのは、いずれも「作る技術としてのアジャイル・プラクティス」と「規模」との関係性に注目している点です。これに対して、IBMでは「プロジェクトとして成立させるためのファクター」に着目します。それらのファクターを具体的に表したモノが、図1です（これらをアジャイル・スケーリング・ファクターと呼んでいます）。いくつか例を挙げてみましょう。

図1 アジャイル・スケーリング・ファクター

大人数で開発する際には、オフショアに代表される地理的に分散した体制が一般的になっている。国によって労働条件に対する法的規定、文化的慣習が異なり、プロジェクトとして成立するにはこれらの違いを考慮した体制構築が必要となる。
構築対象となるシステムが、業界団体あるいは監督官庁によって定められた規定・法令の制約を受けることがある。これらを遵守するため、プロジェクトでの情報管理のあり方が影響を受ける場合がある（俗に言うコンプライアンス・ケース）。

等々。

　あえて開発技術以外の項目を選んでみましたが、これらは開発の効率化やその手段としてのアジャイル・プラクティス云々とは別次元の話です。しかし、開発プロジェクトをプロジェクトとして成立させるためには必須の条件です。もちろん、あらゆるケースで図1で提示されているスケーリング・ファクターすべてが関係してくるわけではありません。しかし、なにを考慮すべきか否かを見極めることは必要です。

　これまで少人数のアジャイル開発に慣れている開発者も、いきなり上で挙げたようなファクターを考慮してプロジェクトを編成する立場になったら、戸惑うのではないでしょうか？「それは、アジャイルチームの仕事ではなく、プロジェクトマネージャの仕事でしょ？」という声が聞こえてきそうです。もしそういう声が多いようなら、それは「アジャイル・プラクティスと規模」の話だけでは、大規模アジャイルをプロジェクトとして運営することができないということなのでしょう。