DAD入門

多くの組織が、アジャイルの旅路を、スクラムの適用から始める。なぜなら、スクラムがアジャイルソフトウェアチームを導く良い戦略を提示しているからだ。しかし、スクラムは利害関係者に洗練されたソリューションを届けるために必要とされるものの一部でしかない。スクラムが意図的に無視しているプロセス上のギャップを埋めるために、チームは他の手法を探すのが常だ。他の手法を探し当てると、そこには考慮すべきことがかぶっていたり、用語の衝突があり、プラクティショナーだけでなく外部の利害関係者をも混乱させていることがある。さらに悪いことには、人々はどこにアドバイスを求めたら良いかわからないし、自分達で検討しなければならない課題がなにかすらわかっていない。

これらの難題に対処するため、ディシプリンド・アジャイル・デリバリー(DAD)プロセスディシジョンフレームワークは、アジャイルのソリューションデリバリーにより密着したアプローチを提供する。正確を期すため、ここに定義を掲げよう: ”ディシプリンド・アジャイル・デリバリー(DAD)プロセスディシジョンフレームワーク ”は、ITソリューションデリバリーのための、ピープルファースト、学習指向のハイブリットアジャイルアプローチである。その特徴は、リスクと価値のライフサイクル(risk-value delivery lifecycle)、ゴール駆動(goal-driven)、エンタープライズ対応(enterprise aware)であり、スケーラブルであることだ”。

DADフレームワークには、明らかに特徴的な面がいくつかある。DADは、スクラムを拡張するハイブリッドアプローチを採用している。ベースとなるのは、アジャイルモデリング(AM)、エクストリーム・プログラミング(XP)、ユニファイドプロセス(UP)、カンバン、リーンソフトウェア開発、アウトサイドイン開発(OID)その他いくつかの手法から採られた、実証された戦略達だ。DADは、プロプライエタリーではなく、自由に使えるフレームワークである。構築にフォーカスしたスクラムのライフサイクルを拡張し、プロジェクトの立ち上げからエンドユーザにソリューションをデリバリーするまでの完全に、エンドトゥエンドのライフサイクルを扱う。また、このライフサイクルのリーン版や継続的デリバリー版もサポートする:他のアジャイル手法とは異なり、DADは単一のライフサイクルをあらかじめ詳細に記述してはいない。なぜなら、ひとつのプロセスサイズですべてに合わせるのは無理だと思っているからだ。DADは、エクストリーム・プログラミング(XP)から採用したテクニカルなプラクティスに関するアドバイスを提示するのと同様に、スクラムやXPからは漏れてしまったモデリングや文書化、そしてガバナンスの戦略についてもアドバイスを提供している。しかし、スクラムのような他の手法に見られるような事前に詳細に記述するアプローチの代わりに、DADフレームワークは、ゴール駆動アプローチを採用している。これにより、DADは、コンテキストに合わせたアドバイスを提供する。採りうる選択肢とそのトレードオフが提示されることで、読者は自身の直面する状況に効果的に対処出来るよう、DADをテーラーリングすることができるようになる。何が機能し、何が機能しないのか、さらに重要なことに、それがなぜかを記述することで、DADは読者が有効な戦略を選択し適用するチャンスを増やす助けとなる。

 

ピープルファースト:DADでの役割

DADフレームワークは、以下のような強固な役割セットを提案している。個々の役割をざっと見ていこう:

3-roles

よくいただく質問が、“主な役割”と”補助的役割”との違いは何か?である。主な役割とは、すべてのDADプロジェクトで、状況にかかわらず現れるであろう役割のことだ。それに対して、補助的役割は、特の状況に合わせてスケールさせる際に必要とされる役割であり、一時的な場合もしばしば見られる。もう一つのよくある質問は、なぜこんなにたくさんの役割があるのか?だ。例えば、スクラムは3つの役割(スクラムマスター、プロダクトオーナー、チームメンバー)を提示している 。それなのに、なぜDADは10個も必要なのか?主な課題は、スコープに関するものだ。スクラムは、その大部分が、構築フェーズにおけるリーダーシップと変更管理の側面にフォーカスしており、それが役割に反映されている。一方DADは、明らかにデリバリーライフサイクル全体とソリューションデリバリーのすべての側面にフォーカスしており、スクラムが取り扱っていない技術的な側面も含んでいる。だから、スコープが拡がるのを受けて役割がもっと必要になるのだ。例えば、DADは、アジャイルアーキテクチャの課題を扱っているが、それに応じてアーキテクチャオーナーという役割を提示している。スクラムは、アーキテクチャを扱わないので、そのような役割がない。

 

ハイブリッドフレームワーク

ディシプリンドアジャイルデリバリー(DAD)はハイブリッドフレームワークであり、他の手法やソフトウェアプロセスフレームワークからなる強固な基盤の上に構築されている。DADフレームワークは、これら既存のソースからプラクティスや戦略を採用し、いつ、どのようにこれらを一緒に適用するかのアドバイスを提供している。ある意味、スクラム、エクストリーム・プログラミング(XP)、カンバン、アジャイルモデリング(AM)はプロセスのブロックを提供しており、DADはこれらを効果的にひとつにまとめるモルタルである。

 HybridFramework

アジャイルそしてリーンソフトウェア開発の最も大きなアドバンテージのひとつは、あなたが利用出来る価値あるプラクティスやテクニック、そして戦略が豊富にあることだ。それはまた、DAフレームワークのような何かがなければ、何を選択し、それらをどう一緒に使えば良いのか知ることが難しく、大変なチャレンジになってしまうということでもある。

 

完全なアジャイルデリバリーライフサイクル

DADはデリバリーにフォーカスしているが、システムライフサイクルの他の側面がデリバリーライフサイクルにどのような影響を及ぼすかも扱っている。 完全なシステム/プロダクトライフサイクルは、プロダクトへの初期のアイディアから始まり、デリバリー活動を通して、運用とサポートまで続き、このデリバリーライフサイクルが繰り返すことも珍しく無い。次の図は、DADライフサイクルのハイレベルなビューだ。3つのフェーズからなるライフサイクルであり、この期間を通して使用可能なソリューションをインクリメンタルにビルドしていく。

high level Overview
もちろん、ハイレベルの概要以上のものが存在する。DADは、事前に詳細を記述しておらず、出来るだけ現実を反映しようと努力してきたので、実際にはデリバリーライフサイクルの複数のバージョンをサポートする。ライフサイクルには、以下に挙げる4つのバージョンがある:

  1. アジャイル/基本バージョン。RUPから実績のあるアイディアを採りこんで、スクラムの構築ライフサイクルを拡張したもの;
  2. アドバンスド/リーンライフサイクル;
  3. リーン継続的デリバリーライフサイクル;
  4. 探索的”リーンスタートアップ”ライフサイクル;
 3 - DAD Lifecycle agile scrum

 

3 - DAD Lifecycle Advanced

 

 3 - DAD Lifecycle Continuous Delivery3 - DAD Lifecycle Exploratory

DADチームは、状況に最適なライフサイクルを選択し、適切にテーラーリングする。詳細は、「完全なアジャイルデリバリーライフサイクル」を参照いただきたい。

 

ゴール駆動

DADゴール駆動アプローチは、事前に詳細を記述することを避け、それによって他のアジャイル手法よりに柔軟で簡単にスケールすることを可能にしている。例えば、スクラムは、価値駆動のプロダクトバックログアプローチで要求を管理しているような場合に、DADは代わりに構築フェーズの間に利害関係者のニーズの変化に対応する、というゴールを提示している。その次に、そのゴールの周辺に考慮すべき課題がいくつかあることと、次に採用するか否か検討すべきテクニック/プラクティスをいくつか提示する。さらに進んで、各テクニックの有利な点と不利な点を説明し、どのような状況にそれらが最もフィットするかを説明する。そう、スクラムのプロダクトバックログアプローチは、利害関係者のニーズの変化を扱う方法のひとつだが、たったひとつの方法でもなければ、殆どの状況で最上の選択肢でもない。

DAD本では、ゴールの表現としてビジュアルではなく表を使い、課題に関係するテクニックの利点と不利な点を記述している。2012年の後半からこのアプローチを拡張し、ゴールをビジュアルに表現する手法を開発した。筆者達はこれをゴール図と呼んでいる(表記法についての詳細な議論は、 Disciplined Agilists Take a Goal-Driven Approach を参照されたい)。

いくつかサンプルをウォークスルーしていこう。次の図は、「初期のスコープを探索する」のゴール図で、このゴールはプロジェクトの始め、方向付けフェーズ(DADは、構築ライフサイクルだけで無く、完全なライフサイクルを推進していることを思いだそう。)で扱われる。アジャイル手法の中には、初期のユーザーストーリをいくつかプロダクトバックログを作るよう簡単にアドバイスしているものがあるが、ゴール図は、読者が自身のアプローチをもっと洗練させたいと望む点をはっきりさせる。もし選択肢があるなら、どの詳細度で記述すべきだろうか?(数枚のカードと、ホワイトボード上の2~3枚のスケッチを使った簡易な仕様記述は、検討すべきオプションのひとつだ)。どんなタイプの視点を検討すべきか?(ユーザーストーリーは使い方をモデル化するひとつのアプローチだ。だが、他の視点、他飛べデータやUIは検討しなくてもいいのだろうか?)。デフォルトで使われる、いやより正確には、まず最初に使う提案されるテクニックは、太字の斜体で示されている。使用法、基本的なドメインの概念(ハイレベルの概念図)、非機能要求等々、を捉え表現するにはいくつかのやり方があるが、それを筆者達がどのように表現しているか注意されたい。モデリングのやり方にも複数の戦略があり、読者は検討する必要があるかもしれない。読者は、自身の作業を管理するアプローチの検討を始めるべきだ。DADにおいて筆者達があきらかにしたのは、アジャイルチームが新しい要求を実装する以上のことをやっているということであり、それがスクラムの単純なプロダクトバックログ戦略ではなく、一歩進めてワークアイテムスタックをデフォルトとして推奨している理由だ。ゴール図があきらかにしているのは、初期のスコープを探索するときには、非機能要求 -信頼性、可用性、セキュリティ要求(その他諸々) -も捉えるべきだということだ。

explorerinitialscope

アジャイルソリューションデリバリーのゴール駆動アプローチを採用することの利点をいくつか挙げておこう。第1に、ゴール駆動アプローチは、プロセスでの意思決定を明確にすることで、プロセスのテーラーリングをサポートする。第2に、読者が直面しているスケーリングファクターの現実を反映する戦略をテーラーリングすることを通して、より効果的にスケーリングできるよう読者をガイドする。第3に、プロセス上の選択肢を明確にしそれによって読者が直面している状況に適切な戦略を特定することを容易にしている。第4に、アジャイル手法のあてずっぽうな拡張を排し、利害関係者に価値を提供するための実際の仕事にフォーカスすることを可能にする。第5に、読者の選択がもたらすリスクを明確にし、それによって、プロジェクト成功率を高めることが出来るようになる。第6に、これは利点ではないが、アジャイルの成熟度モデルの参考になる。

 

エンタープライズ対応

エンタープライズ対応(Enterprise awareness)は、ディシプリンドアジャイルデリバリー(DAD)フレームワークのキーとなる側面のひとつだ。これまでの実践の場を通してわかったのは、DADチームは、他のチームと同じように、組織内の全社的なエコシステムの中で働くということだ。そこには、今現在稼働している既存のシステムがあり、最低限読者のソリューションがそれらへ影響を及ぼすべきでない。望むらくは、読者のソリューションが、本番稼働している既存の機能やデータを活用することだ。時には、他のチームが並行して作業し、相互にお互いのいいところを取りいれあうことを望むかもしれない。組織は、チームが貢献すべきビジネスやテクニカルなビジョンに向けて突き進んでいるかもしれない。ガバナンス戦略は、読者のチームがしていることをさらに拡張するようなものであることが望ましい。

エンタープライズ対応は、自律の重要な側面である。なぜなら、読者はプロフェッショナルとして、自分に興味あることではなく、組織にとって正しいことを為すために努力すべきだからだ。孤立したチームによる開発では、組織内に成功裏に導入されテストされ構成されきめ細かくチューニングされたものがすでにあっても、既存の何かをゼロから作ったり、異なる開発ツールを使ったり、異なるデータソースを使うという選択をするかもしれない。ディシプリンドアジャイルのプロフェッショナルは…

  • エンタープライズアーキテクトやポートフォリオ管理者といった、全社レベルのプロフェッショナルと密に協力して働く
  • 全社標準のガイドラインを採用し準ずる。
  • 組織内のアセットを活用する。アセットには既存のシステムやデータソースが含まれる。
  • 組織のエコシステムを、アセットをリファクタリングすることで、拡張する
  • DevOps 文化を適用する
  • 学習したことを他のチームと共有する。
  • 適切なガバナンス戦略を採用する(ここに挙げたような)。オープンで正直なモニタリングが含まれる

エンタープライズ対応が重要な理由を挙げていこう。第1に、既存のアセットを活用することで、全体的なデリバリー時間とコストを削減することが出来る。言い換えると、DADチームは車輪の再発明に時間を費やすことがなく、利害関係者にとって真に価値のあるものを生産することにもっと多くの時間を割くことが出来る。第2に、全社レベルのプロフェッショナルと密に協業することによって、DADチームは容易に正しい方向に向かって進んでいくことが出来る。第3に、デリバリーチームが、担当する”ソリューション部分”だけにとどまらず、組織全体を最適化する助けとなる機会を増やす。リーンソフトウェア開発のムーブメントが示したのは、市場へ投入する期間が短くなることでチームの有効性が高まるということだ。

 

DADはアジャイルをスケールする基礎を提供する

次に挙げる図は、筆者がIBM Rational時代に開発組織をリードした際に用いた基本的な戦略の概要だ。この考え方の基はそれまでの観察から導き出されたものであるが、多くの組織はアジャイルメソッド、特にスクラムをどのようにスケールさせるかで苦労している。筆者達が感じているのは、まず最初の一歩はエンドトゥエンドでソリューションの開発をどのように成功させるかを特定するのが良いということだ。主流となっているアジャイル手法は多くの有用な戦略を提供してきたことはあきらかだが、しかし、それらをひとつに結び付けるという点で、コンサルタントウェア(“私を雇ってください。そうすればどうすればいいか教えますよ”)以上のものではない。ここにDADが登場するわけだが、それでも読者が自身の置かれたコンテキストを反映してアプローチをテーラリングする最初に一歩に過ぎない。

agilitatscale

DADフレームワークは、アジャイルをスケールさせるより良い基盤をいくつかの方法で提供する。第1に、リスクと価値のライフサイクルを奨励し、よりリスクの高い作業を開発の早い段階で行うことで、部分的に、あるいはすべてのリスクを排除する。これによってプロジェクトを成功させるチャンスを増やすのだ。これを”失敗を先に(failing fast)”の一面として引用する者もいるが、筆者達は早期に成功を収めるという言葉を使いたい。第2に、DADは効果的なガバナンスにより強化された自己組織化を奨励している。これは、アジャイルプロジェクトチームがもっと大きな組織のエコシステムのスコープや成約の中で作業しているという事実の観察に基づくものだ。結果として、DADはアジャイルチームをガイドする効果的なガバナンス戦略を適用することを推奨している。第3に、DADは、ただ動くソフトウェアを作るというだけに留まらず、使用可能なソリューションをデリバリーすることを奨励している。ソフトウェアを構築することに加えて、DADチームはサポート用文書の作成やソフトウェアが実行されるマシンのアップグレードやその再配備、システムが使われることによって産まれる潜在的なビジネスプロセスの変更をも手がける。場合によっては、システムを使う人々の組織構造にすら変化をもたらすかもしれない。第4に、以前に記したように、DADはチーム内に留まらることなくくエンタープライズ対応を奨励している。第5に、DADはコンテキストを意識し、ゴール駆動である。あらかじめ手順を詳細に記述してはいない。ひとつのサイズのプロセスはすべてに当てはまるわけではない。効力のあるチームは、彼らが置かれた状況を反映するために戦略をテーラーリングするものだ。

アジャイルをスケールさせるとは何を意味するのか、確認していこう。”スケーリング”と言う言葉を耳にすると、多くの人が(何らかの形で地理的に分散しているかもしれない) 大規模チームを思い浮かべる。これは実際にあきらかに実際に起きていることだし、この類いの状況にアジャイルを適用することに成功している人々もいる(アジャイルのスケーリングに関して筆者達が集めた最新の情報を参照いただきたい。もちろん以前のものも) 。しかし、それ以外にもスケーリングが必要な場合があるのだ。組織は、なんらかのコンプライアンスが必要な状況 - 課せられた法的規制や自らが選択した(CMMIやISOのような) 標準に準ずるような状況にもアジャイルを適用している。彼らは、様々な課題やソリューションの複雑さ、そして時には複数の組織がかかわるような場合(例えばアウトソーシング)にもアジャイルを適用している。次の図は、可能性のあるスケーリングファクターをまとめたものだが、読者はアジャイル戦略をテーラーリングする際にこれらを検討する必要があるのだ。

Context Factors

この章のまとめ

ディシプリンド・アジャイル・デリバリー(DAD)プロセスディシジョンフレームワークは、チームが自身が置かれた固有の状況に対処するためにアジャイルの戦略をスケールさせるのに有効な、実用本位のアプローチを提供する。DADは、エンタープライズアジャイルチームが直面する課題をとりあつかうという立場を明確にしており、それは多くのアジャイル手法がどちらかというと避けてきたものだ。このフレームワークは、アジャイルチームを無駄なく成功裏に立ち上げるにはどうするか、アーキテクチャに関する作業をアジャイルのライフサイクルにどうやって適合させるか、有効な文書化の戦略、エンタープライズ環境での品質の課題にどう対応するか、利害関係者の尽きることのない関心事に対処するためにアジャイルの分析テクニックをどう使うか、その他諸々を取り扱っている。

オリジナル:Introduction to DAD

http://www.disciplinedagiledelivery.com/introduction-to-dad/

 (翻訳:藤井智弘)

Pocket