第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で提示されているスケーリング・ファクターすべてが関係してくるわけではありません。しかし、なにを考慮すべきか否かを見極めることは必要です。

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

次ページ：アジャイル・スケーリング・モデルとDAD

アジャイル・スケーリング・モデルとDAD

　前述のスケーリング・ファクターに対してどう対処すべきかは、これまで広く知られているアジャイルのプラクティスでは十分なガイドにはなっていないのが現実です。小規模なチームでのアジャイル開発に慣れている技術者にとって、スケーリング・ファクターが意味を持つような規模のプロジェクトへ移行するのは大きなジャンプが必要です。そこで、IBMでは、規模の発展に合わせてアジャイル・チームの振る舞いが変わることを表現するために、アジャイル・スケーリング・モデル（ASM）というものを併せて提唱しています（図2）。

図2 アジャイル・スケーリング・モデル（ASM）

　このモデルの中では、従来の少人数でのアジャイル開発スタイルをコア・アジャイル・デベロップメントと呼んでいます。ここで使われるプラクティスは、現在広く知られているアジャイルのプラクティス群そのものです。それに対して、前述のスケーリング・ファクターを考慮しなければならない規模の開発スタイルのことを、Agility@Scaleと呼んでいます。

　従来のアジャイル・プラクティスは「モノを作る」に焦点をあてています。しかし、スケーリング・ファクターを考慮するような規模になった時点で、意思決定に絡む利害関係者の多さ、技術の複雑さ（裏を返せば、技術的なリスク）が増してきます。これらにうまく対処するためには、1回のスプリント期間中のチームの振る舞いだけではなく、プロジェクトの開始から終了まで考慮した時間軸の中での意思決定ポイントやプロジェクトの運営を明確にした枠組みを用意し、利害関係者も含めた全体で合意しておく必要があります。DADは、この枠組みそのものであり、アジャイル・スケーリング・モデル上は、コアと＠Scaleの中間に位置付けられています。

　注意が必要なのは、DADは「大規模向けに限定されたアジャイルプロセスではない」ということです。その本質は、プロジェクトの運営という観点で見た枠組みなので、少人数のチームや案件であっても、利害関係者が多い場合には、十分有効なものです。これまで日本国内でアジャイルを試行されたお客様の話をお伺いする機会が何度かありましたが、総じて「ユーザー部門の関わり方」に課題が多いように思います。またスプリント内でのバックログの管理に「場当たり的」という不安を持たれる方も多いようです。「プロジェクトの時間軸に沿った運用の枠組み」は、これらの不安にかなり答えることができると思います。

次ページ：（やっと）DADの定義

（やっと）DADの定義

　図3がDADの定義としてあちこちで紹介しているモノです。アジャイルな開発であるという基本軸はそのままに、いくつか特徴づけるキーワードがありますので列挙してみましょう。

図3 ディシプリンド・アジャイル・デリバリーの定義

リスクと価値を秤にかけながら…

　従来のアジャイル開発のスタイルでは、バックログに管理されているストーリーから、ユーザーにとって価値の高いモノから優先して開発していく、いわゆる価値駆動（Value-Driven）のアプローチが取られます。これに対して、DADでは、さらにリスクを加味します。ログの中のストーリーを優先順位付けする際に、ユーザーにとっての価値と（主に技術的な）リスクとを天秤にかけるのです。単一の独立したシステムを作るならいざ知らず、基幹系システムの構築では、既存システムとの連携やSOA共通基盤上での動作保証など、さまざまなリスクや制約が存在します。プロジェクトの早期では主に技術リスクの解決に焦点をあて、その後機能性の充実に焦点を移していくことを推奨しています（これは、「リスクと価値によるライフサイクル」と呼ばれています）。

適切なガバナンス・フレームワーク…

　ガバナンスという言葉を出しただけで反発を受けそうです。日本語では、統治とか統制という訳語が充てられることが多いので、トップダウンで強制執行という反アジャイルのイメージを持つ人が多いのでしょう。しかし、IBM Rationalでは、ガバナンスという言葉のニュアンスを少し違う風に使っています。皆さんのイメージされるトップダウンで強制執行、箸の上げ下ろしまで事細かに規定するという姿のことは、コマンド＆コントロール（Command & Control）と表現しています。それに対して、目的やゴールを共有し、そこに至る過程では各自の裁量を認めながら、全体として達成する運営スタイルのことをガバナンス（Governance）と呼んでいます。

　適切なガバナンス・フレームワークとして、DADではプロジェクト運営上の節目を明確にするために、フェーズとマイルストーンという概念を導入しています…と、ここまで聞いて、「なるほど」と思った方もいらっしゃるでしょう。この2つの概念は、前回ご紹介したRUPを特徴付けるモノでもあるからです。図4は、DADでのプロジェクトライフサイクルを表現したモノです。

図4 DADのライフサイクル

　DADでの運営スタイルはスクラムに準じています（用語等は若干調整していますが）。図の上方にある円は、繰り返し実行されるスプリントを表現しています。それに加えて、時間軸にそってプロジェクト期間を次の3つのフェーズに分けています（図中では、円の下の帯で表現）。

方向付け（Inception）フェーズ
…プロジェクトのスコープ、システムの存在理由を利害関係者と同意するフェーズ
構築（Construction）フェーズ
…実装するフェーズ。従来のスクラムの運営に準じる。XP等のプラクティスも実践する
移行（Transition）フェーズ
…本番稼働に向けての環境移行・教育等のフェーズ

図5 フェーズ（構築）とプラクティスのマッピング

　これらのフェーズの終わりには、マイルストーンが設定されています。このようにプロジェクト全体を見据えて、何時何をすべきかの枠組みが提示されることで、プロジェクト全体が正しい方向を向いて進んでいるかを検証しながら進めていくことができるのです。

　また、DADではあまたあるアジャイル・プラクティスを、さまざまな形で分類しています。

フェーズごとによく利用されるプラクティスをマッピング（図5は構築フェーズの例）
作業の分野（「要求定義」「テスト」等）による分類

　アジャイルに着手しようとするプロジェクトにとって、プラクティスがたくさんあることはありがたいことである反面、どのタイミングで何を実施すべきか迷いことも多いと聞きます。適度に分類することでプロジェクトへのアジャイル適用の敷居を下げようとしているのです。

適度なセレモニー…

　筆者は（恥ずかしながら）英語が得意ではないので、セレモニーという言葉が持つニュアンスを正確に理解できていると思いません。でも、レビューという作業に比べると、（若干形式張ってはいますが^^;）若干柔らかく、○○様ご一行様による節目って感じがしませんか？

　DADが前提とする世界観では、利害関係者が頻繁に開発チームの作業場所を訪れて状況を共有する…なんてことは難しいと想定していますし、たぶん難しいでしょう。前述のフェーズと合わせて、利害関係者一同で方向性を共有し（必要があれば）軌道修正するタイミングとしてフェーズを設け、中間報告としてのマイルストーンを設定し、それを確認するイベント（これがセレモニー）を設けることで、開発チームやプロダクトオーナーの独善にプロジェクトが陥らないよう運営していくのです。

「アジャイル」の次へ

　あまたある開発手法を、「プロジェクトへ適用するために」整理統合したことがRUPの価値である……前回お伝えしたRUPの意味は、今回のDADでも同じであることに気がつかれた方も多くいらっしゃるでしょう。中大規模向けのプロセスとして一定のご評価をいただいたRUPのエッセンスをアジャイル開発のスケールアップのために組みいれるというのは、IBM Rationalチームに取ってみれば、半ば当然のことです。

　若干の偏見も自覚しつつですが、日本でのこれまでのアジャイルの訴求は、「開発者が楽になる」といった類の話が多く、3Kやら10Kやらと揶揄されるソフトウェア開発現場の救いであるかのように、アピールされてきました。一面それは真実だと思いますが、その訴求が1人歩きして管理者層へ「当てにならない」という印象を与えてきたように思います。

　連載タイトルにアジャイルの次へと入れたのは、誤解と偏見に満ちてしまった今のアジャイルを再評価して、「プロジェクトとしてきちんと運営できるアジャイルへ転換するタイミングが来たのだ」……そんな我々の想いの表れなのです。

　ぜひ「Disciplined Agile Delivery入門」を入手していただき、ご覧いただければと思います。