ディシプリンド・アジャイル・フレームワーク

ディシプリンド・アジャイル2.0プロセスディシジョンフレームワークは、組織が自分達のITプロセスを、コンテキストに合わせた形で合理化することを助ける軽量なガイダンスを提供する。ソリューションデリバリーや運用、エンタープライズアーキテクチャ、ポートフォリオ管理、そしてそれ以外の多くの活動をどのように組み合わせて実践するかを提示する。このフレームワークは、これらのアクティビティが対処するものがなにかを説明し、それを為すために取り得るオプションと、各オプションに伴うトレードオフを説明する。

この記事では、次のトピックスを見ていこう:

なぜディシプリンド・アジャイル2.0なのか?

筆者達がソリューションデリバリーの域を超えてフレームワークを拡張したのには、以下に挙げるいくつかの理由がある:

  1. アジャイルデリバリーチームの成功を可能にするために
    ディシプリンド・アジャイル・デリバリー(DAD) 1.xのフォーカスは、ソリューションデリバリーにおける活動のすべて(分析、設計、テスト、アーキテクチャ、管理、プログラミング等々)がどのようにしてしっかりとかつ効率的に組み合わされるかを示すことで、アジャイル/リーンチームが初めから終わりまでどのように活動するかを説明することにあった。しかし、デリバリーを成功させるためには、チームはチーム外の人々(例えば、エンタープライズアーキテクト、運用のエンジニア、ガバナンスを司る人達、データ管理者、その他諸々)と共に働かなければならない。アジャイル/リーンチームがより効果的にあるためには、これら(チーム外)の人々も、アジャイル/リーンの作法で活動しなければならない。
  2. アジャイルITの首尾一貫した戦略を提供する
    もし読者がソフトウェア開発をキツい(hard)仕事だと考えているなら、IT部門のすべての活動はさらに大変だ。IT部門とは複雑適応組織 (complex adaptive organiation)なのだ。この言葉を使った意味は、ひとつのチームのアクションは他のチームに影響を及ぼし、それがどんどん伝搬していくということだ。例えば、読者のアジャイルデリバリーチームのやり方が、やり取りしている他のチームに影響を及ぼし、そのチームから影響を受けるだろう。もし読者が(おそらくDevOps戦略の一環で)運用チームと作業しているなら、各々のチームがお互いに効果的に共同作業出来るようなやり方を採用する必要がある。各チームは、他のチームから仕事のやり方を学び改善することが望ましい。この改善はさざなみように他のチームに伝わっていく。難しいのは、IT分野の各領域はひとつかそれ以上の知識体系(bodies of knowledge)を持っており(場合によっては“知識本(books of knowledge)”として出版されていたりするが)、この類いの体系は、各領域で働く人へのガイダンスを提供している。例を挙げると、管理者であればPMIBoKやPrince2、エンタープライズアーキテクトであればTOGAF やZachmanフレームワーク、ビジネスアナリストであれば、IIBA BoK、データ管理者でれば、DAMA BoK等々、といった具合だ。これらのインダストリーグループとそれに関連する知識体系は、お互いを否定しあい、アジャイル/リーンの学習曲線の異なる位置におり、時々アジャイル/リーンではない戦略を推奨したりする。ITのレベルでは、大きな混乱が起こり、機能不全に終わる可能性がある。DAフレームワークは、どのようにこれらすべてを柔軟に組み合わせて、複雑適応系において直面した現実をサポートするかを提示する。
  3. リーンエンタープライズのサポート
    リーンエンタープライズは、市場での変化を予測し、迅速に対応することを可能にする。これは、直面している状況に対応出来るように変化することを促す、組織の文化と構造によってなされる。リーンエンタープライズは主流のビジネスで学び続けるマインドセットと、イノベーションをドライブする底流に流れるリーンおよびアジャイルプロセスを必要とする。これは、アジャイル/リーンのやり方でIT部門が作業出来るということも意味している。
  4. コンテキストを考慮する
    すべての人、チーム、組織が、ひとつひとつはユニークなものだ。これが意味するところは、読者諸氏には、選択肢を提供したフレームワークが必要だということだ。それによって読者は現実に直面している状況に対処するためのアプローチをテイラリングでき、後々それを進化させることができる。SAFeやNexusのようにあらかじめ規定され(prescriptive) 1サイズですべてに適用させるフレームワークは、プロセスに関連する最初期のニーズに対しては魅力的で簡単なソリューションに思えるかもしれないが、現実は採用した組織に対して、良いことよりも害を及ぼすほうが多くなることがしばしば見られる。

なぜ名前を変えたのか?

フレームワークのスコープが、ITソリューションのデリバリーをどう効果的に進めるかから、IT活動全般をどう効果的なものにするかへと、進化している。結果として筆者達は、”ディシプリンド・アジャイル・デリバリー”という名称が、もはやフレームワークのゴールを表現していないと感じた。”ディシプリンド・アジャイル”のほうがより正確だ。

リリース戦略(※訳注:古い情報です)

 基本的な素材は2014年後半から2015年にかけてリリースを始め、最終的には、2015年8月リリースを予定している。つまりまだ終わっていない。2015年8月にDA2.0 のマテリアルを段階的にリリースしていく。

経緯・歴史

 このフレームワークは、3つのメジャーリリースをここまで重ねてきた。
  1. ディシプリンド・アジャイル・デリバリー 0.x     本フレームワークの起源は、IBM Rationalで2009年の始めから2012年6月にかけて開発された。 IBMチームは、ビジネスパートナーと密に協力してきたが、その中にMark Linesが参加し、Scott Amblerがリードしてきた。IBM Rational Method Composer(RMC)は、DADフレームワークの早期バージョン(バージョン0.5)をサポートしている。
  2. ディシプリンド・アジャイル・デリバリー 1.x     2012年6月の最初のDAD本”ディシプリンド・アジャイル・デリバリー”出版を以て、DAD1.0のリリースとしている。DADフレームワークの進化と公開は今ご覧のサイト上で2012年の8月から始まっている。DADフレームワークの知的財産は、Disciplined Agile Consortiumへ2012年10月に引き渡され、2014年6月IBMにより法的に確認された。
  3. ディシプリンド・アジャイル・デリバリー 2.0     これが現在のバージョンである。最初のリリースは2015年8月に行われた。前述したように、フォーカスはITプロセスへの柔軟でコンテキストに応じたアプローチへと進化している。

将来

今後もこのサイト上でマテリアルを開発し続けるつもりだ。アップデートの通知が必要であれば、このブログを購読してほしい。LinkedInのディシプリンド・アジャイルにフォーラムを開設しているので、進行中の議論に参加したければ、そちらにもご参加いただきたい。

 http://www.disciplinedagiledelivery.com/agility-at-scale/disciplined-agile-2/
 (翻訳 藤井智弘)
Pocket