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

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

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

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

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

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

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

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