エンタープライズ・アジャイルのキモとなるスケーリング
アジャイルにおける「スケーリング」
エンタープライズという言葉がつくと、「大企業」=「大規模」というイメージを条件反射的に持たれる方が多いと思います。それはあながち間違いではありませんが、DAD自身は自らを大規模開発向けのフレームワークとしては位置付けていません。DAD以前のアジャイル開発論は、アジャイルマニフェストを核にしてどう開発するか? に論点がありました。しかし、実際にプロジェクトを適用することを考えると、純粋な開発としてのあるべき論と同時に考慮すべき事柄が多くあります。それらのことを加味した上で開発の進め方を決め、それに基づいて開発を進めていかねばなりません。「スケーリング(Scaling)」という言葉を聞くと、ついつい「スケールアップ」=「規模拡大」のような単純なイメージを持ってしまいがちですが、DADの文脈では、ただ規模が大きい・小さいだけではなく、それに伴って生じる各種の考慮事項を加味して調整することを、その意味に含んでいます。
図4は、Disciplined Agileコンソーシアムが提供している“Introduction to Disciplined Agile Delivery”という資料の中にある図で、考慮事項の実例が挙げられています。
大規模チーム編成
チームの規模(人数)が増えてくると、コミュニケーションのあり方やビルドプロセスのチューニング等、多くの技術的考慮事項が生じます。
地理的に分散したチーム
オフショアや海外拠点との共同開発では、情報の共有やプロジェクトの可視化、担当領域の分担等の考慮が必要です。
コンプライアンス
業界によっては(アジャイルか否かにかかわらず)、何らかの業界団体・規制団体の指示に基づくアウトプットや監査情報の管理が求められます。このような外部の規制だけではなく、全社標準のITフレームワークに準ずるようなことも、内部的なコンプライアンス/ガバナンスの観点で検討しなければなりません。
ドメインの複雑さ
対象のビジネスドメインに開発チームや利害関係者の経験が十分でない場合には、ビジネスドメインのエキスパートの支援が必要になります。
技術的な複雑さ
技術的に高度で複雑なものを取り扱う必要がある場合は、その技術領域のエキスパートの支援が必要です。
複数組織
複数の組織によって業務や開発が運営される場合は、法的な契約事項等も含めた調整事項が発生します。
DADでは、これらの考慮事項のことを「スケーリングファクター」と呼んでいます。これまでXPだScrumだと言っていた純粋なアジャイル開発の文脈とはかなり様子が違い、ギャップがあるのがわかるかと思います。
構築にフォーカスした小規模運営に慣れているチームにとって、拡大した利害関係者とともにこれらの考慮事項にどう対処すればいいか、どのタイミングで何を合意しながら進めていけばいいのかというのは、なかなか想像がつかないと思います。そのため、拡大する利害関係者と合意形成しながら進める基盤として、DADは両者の中間に位置づけられます。
つまり、「小規模のScrumベースのアジャイルチーム」→「多様な利害関係者との合意形成を意識した、適度なガバナンスを伴う小規模アジャイルチーム」→「スケーリングファクターを加味した中大規模アジャイルチーム」という発展の経緯を想定しているのです。
「DADは意思決定のフレームワーク」ということを、これまでにも何度か説明してきましたが、意思決定のためにはインプットが必要であり、それを元にチームが置かれた状況(コンテキスト)を踏まえて、適切な決定を下さなければなりません。チームや利害関係者の知識レベルや成熟度、ビジネス環境によって、同じインプットでも下される決定は異なってきます。一口に適切な決定とは言っても、複数の選択肢の中からメリットとデメリットを比較して、適切な手段を選択するには、それなりの経験が必要です。
DADの特徴(人によっては、これこそ一番意味があると思われるかもしれませんが)は、チームのコンテキストに応じてどのような決定がありうるかを提示していることです。これが意思決定のフレームワークのもうひとつの側面です。
図5は、DAD本から引用した例です。この例では、方向付けのビジョン策定のアプローチについて考えられる方法のメリット、デメリットと考慮事項が提示されています。DAD本には、このような意思決定のパターンが100パターン以上提示されており、利用者が検討する際のスピードを加速します。これこそDADが「コンサルタントのネタ帳」と呼ばれる理由でもあります。
(ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイドより引用)
最近海外の本家DADサイトでは、最上位の“Agility at Scale”をメインテーマに据えたサイトが立ち上がっており、スケーリングに関する情報提供が今まで以上に出てくることが期待されます。
最後のまとめ
エンタープライズ・アジャイルとは、シンプルな開発技術論としてのアジャイルから、実際の環境条件を加味した、より実践を意識したアジャイルの発展系だと思います。
- スケーリングファクター
- 反アジャイル派の存在も意識した多様な利害関係者
- より上位の経営層から開発チームへと連なる、ビジネス→システムの実現のアプローチ
- アジリティを実現した開発現場のスピード感を、逆にビジネスサイドの意思決定のスピード化につなげるフィードバック
これらをひっくるめた総合的なイニシアティブこそが、エンタープライズ・アジャイルと言えるのではないでしょうか?
当初の予定から若干(?)ぶれながらも、なんとか6回の連載を終えました。書けば書くほど、まだ書き足りないこと、言葉足らずのところがあるように反省しつつ、この分野への注目が高まっているのを感じているので、今後もいろんな形で情報を提供していければと思っています。
お付き合いいただき、ありがとうございました。
【参考文献】
Scott W. Ambler, Mark Lines 『ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド』 翔泳社(発行年:2013)
HPの開発・テスト・検証ツール [PR] |
---|
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- アジャイル開発における「ニーズの変化」への対応方法
- アジャイル開発の明暗を分ける時間軸の捉え方の違いとは
- アジャイル開発の「構築フェーズ」で留意すべきポイント
- エンタープライズ・アジャイルってなんだろう? 3つの視点と2つのフレームワーク
- ディシプリンド・アジャイル・デリバリーの基本モデル「方向付けフェーズ」を理解する
- アジャイル開発とは?プロジェクト推進からチームビルディング、見積もりのコツまでを完全解説
- 少人数によるアジャイル開発の事例
- アジャイル・ブームの再来
- モバイルアプリの継続的テストフレームワーク、配信後のユーザー体験を測定―Think IT Mobile Developer Seminar 2015レポート
- Agile×Ruby×Cloudが示す価値