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

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

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

藤井智弘[著]

2012/03/21 14:00

ポスト

（やっと）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入門」を入手していただき、ご覧いただければと思います。