ディシプリンド・アジャイル・デリバリー: エンタープライズ・アジャイル実践ガイド

著者 : Scott W.Ambler Mark Lines 熱海英樹

• 翔泳社 (2013年6月1日発売)

作品紹介・あらすじ

次世代のエンタープライズ・アジャイル・ソフトウェア開発手法である、ディシプリンド・アジャイル・デリバリー(DAD)フレームワークを紹介。

感想・レビュー・書評

[daipresentsさんの感想 · 2022年12月21日]

ウォーターフォール フィーチャリングアジャイルな重厚壮大なプロセスの印象。自分の知るエンタープライズアジャイル・スケーリングアジャイルじゃなかった

[exphenomenologueさんの感想 · 2015年2月22日]

エンタープライズアジャイルの方法論。ERPのような企業全体に及ぶエンタープライズの規模のソフトウェア開発をアジャイルで行うにはどうしたら良いか。基本的な考えとしては、開発に先立つアーキテクチャの構築に重きを置くこと、ガバナンスをしっかりすること、移行フェーズを独立して設けることなどがある。つまり、ガバナンス、アーキテクチャのプランニング、モデリングといった活動に一定レベルの厳格さを与えることが特徴(p.3)。エンタープライズ対応であるとは、単なる規模の問題だけではない。それは、企業内の非アジャイル的な組織（データ管理チーム、EAチーム、運用チームなど）との協働を行うこと、そして企業のビジネス的・技術的な方針や標準に準拠することだ(p.107f)。後者の方針・標準への準拠は、アジャイルにガバナンスという観点を持ち込む(p.372)。

この本で提示される方法論Disciplined Agile Delivery(DAD)は、構築に重きを置くアジャイルをデリバリープロセスの全体に配慮するよう拡張したもの。ソフトウェアの構築から、制約のなかでステークホルダーにビジネス価値をもたらすソリューションの提供へと拡張することを目指している(p.4, 11, 27)。アジャイル宣言で言われているのはソフトウェアであってソリューションではない。だから各イテレーションの終わりでも、DADが求めるのは単なる要求を満たしたソフトウェアの完成ではなく、使用可能なソリューションだ。この使用可能性は、非機能要件を満たし、文書化も行われ、UXにも配慮したものであり、ユーザ側もソフトウェアのプロセスに応じた組織変更や運用・サポートを考慮しなければならない(p.407f)。

この本は方法論の提示に加え、プロジェクトの個々の場面で取りうる選択肢（例えば見積もりにおける見積もり方法の選択肢）を、場面ごとに一覧化してメリット・デメリットを列挙している。その上で、本書の設定で取りうる選択肢を論じている。このリストは個々の場面に渡ってかなり詳細なもので、プロジェクトをテーラリングする際に役立ちそうだ。

方法論としてはスクラムの軽量さとRUPの包括性のいいとこ取りを目指している(p.xii)。大きなフェーズ分けとしては、方向付けフェーズ、構築フェーズ、移行フェーズの三つを設けている(p.15-17)。それぞれのフェーズの中は、調整Coordinate、協働Collaborate、完成Completeという3Cリズムからなる。プロジェクトにおけるマイルストーンは、ステークホルダー間のビジョンへの合意、アーキテクチャの実証、プロジェクトの実現可能性検討、リリースするに十分な機能性の担保、運用準備完了、ステークホルダーの満足といったものが挙げられている(p.386)。

構築フェーズはほぼスクラムのように扱われているから、DADの特徴は方向付けフェーズを設けていることになるだろう。これはスクラムでいうとスプリント0の拡張に当たる。平均では4週間程度を要するとされているフェーズ。きちんとした(disciplined)計画を構築に先立って作ることはアジャイリストには不評かもしれない(p.106)。だが、エンタープライズ規模のソリューションを構築するにあたっては、長期的な利益のためにこうしたフェーズが必要だというのがDADの主張。方向付けフェーズではプロジェクトのビジョンの構築、チームの確立、要求の把握、実現可能性の検討と予算の獲得、初期のリリース計画、そしてアーキテクチャの構想などを行う。特にアーキテクチャ構想には重きを置かれている。ここでモデリング手法や、非機能要件を考える。というのも、「他のアジャイル手法に対するDADの重要な差別化要因はプロジェクトの初期段階で必要不可欠な技術的課題を解決せずに、価値の高いワークアイテムを提供することは誤りであることを認識していること」(p.321)なのだ。

とはいえ、方向付けフェーズにあまりに時間をかけすぎ、多くの文書を作ってしまうことはもちろん問題だ。ここで規律を取れずに数週間以上を費やすようでは、悪名高きWater-Scrum-Fallになってしまう(p.410)。DADは各フェーズで必要な成果物を定義してリストアップすることはない。定義されているのは各フェーズのゴールであって、そのゴールを達成できるのならば成果物の形にはこだわらない(p.14, 115)。

チーム編成もDADの特徴の一つだろう。これは例えばスクラムのチームから拡張されている。大規模なチームの場合にはリーダーシップチームを設け、全体の調整役としてプログラムマネジャーを設ける(p.84f)。アーキテクチャに重きを置くため、チームリーダとは別にアーキテクチャオーナーを設ける(p.82)。ボトルネックになりがちなプロダクトオーナーをチーム化し、要求のバックログだけでなく欠陥や他チームのサポート・レビューを担わせる(p.64f)。また、大規模開発では開発チームが細分化するため、全体を統合した独立したテストチームの必要性を説いている(p.294-297)。

かなり大部の本なので一読して把握できるものではないけれども、多くのヒントに満ちた一冊。これにしっかり取り組むには時間がかかる。

[disktnkさんの感想 · 2015年1月30日]

アジャイルやスクラムの根底にある、自己組織化された開発チームを運用していくための規律や開発アプローチを網羅。100人を超える大規模開発や、移行作業への言及もあり、エンタープライズ方面も考慮している。"イテレーティブでインクリメンタルな(進化的)プロセス"など、すっと理解できないカタカナ語の連発だけど、基本的には輸入された開発手法なので、しょうがない。
開発はもちろん、その前の方向付けから計画立ても組織内で話し合う、そりゃアジャイルトレーナーも必要とされるわな、と思った。