計画の遵守よりも変化への対応を
これは、アジャイルマニフェストにおいて筆者が最も好きな文です。そして、企業が競合他社との差異化を図るために最も重要なポイントでもあります。システムやプロセスが変化に対して迅速かつ効果的に対応するように構成されていれば、その企業には成功し、一歩リードする可能性があります。
この原則は具体的には、ソフトウェアの開発中に変化を予測し受け入れることを意味します。XPでは、要件をユーザーストーリーと呼ばれる小さなサイズに分割して実現していきます。アジャイル手法の中には、要件を機能という小さな単位に分割するものもあります。要件のサイズは手法によってさまざまですが、どの手法でも、イテレーションを開始する前に顧客が要件を変更できるチャンスを設けています。
例えば、eコマースのサイトを構築しているときに、サイトの顧客が商品にブックマークを付けられるようにするという要件が挙げられたとします。翌日または1年後にサイトに戻ってきたときに、買い物かごに商品が残っているようにするためです。しかし、あるイテレーションの開始時に、顧客が新しい要件を出してきました。調査の結果、おすすめエンジンをサイトに追加した方が売り上げが増加することがわかったためです。計画ミーティング時に顧客は、このおすすめエンジンの機能を今回のイテレーションで最優先で実装してほしいと要求してきました。チームはこれを承諾し、顧客側も他の機能は後回しになること（場合によっては将来的にも実装されないこと）を納得しました。これが、変化への対応ということです。
変化への対応をプロセス自体に組み込んでおくと、顧客の要求に迅速に対応できます。そのためアジャイルチームはやっかいな変更委員会にかかわることなく、計画ミーティングで利害関係者だけを相手にできます。
理論的には、顧客が最初に要件として150個のストーリーを提示し、プロセスを進める中でそのうち100個のストーリーを破棄し、新たに200個のストーリーを追加することも可能です。アジャイルのプロセスは透明であり、それぞれのストーリーのコストは明白です。顧客は計画ミーティングに参加しているので、チームがどこまで作業を終えていて、どのストーリーがまだ実現されていないのかを把握できます。顧客が方向を転換したいときは転換できますが、その場合、まだ手付かずの古いストーリーは後回しになります。
前にも述べたように、イテレーションに組み込まれなかったストーリーは、その後二度と実装されない可能性もあります。計画ミーティングと毎日のスタンドアップミーティングによって、顧客／利害関係者は各機能のコストを把握するようになります。プロセスに慣れてくるにつれ、重要性の低い機能は予算の関係で実装しないという話になるかもしれません。このプロセスにより、チームは企業にとって最も価値のある機能に集中できます。
アジャイルはカオスではない
本稿ではアジャイルの原則を実践するためのプラクティスを紹介してきましたが、これにより、アジャイルがカオスではないことが理解していただけたのではないかと思います。アジャイルは、agileという単語の本来の意味が示すとおり非常に機敏で対応力に優れています。プロセスを通して変化に迅速に対応できますし、どんな顧客に対しても優れた価値を提供できます。
アジャイル手法の成熟に伴い、リーンの価値や手法をプロセスにもっと取り入れようとする動きがあります。リーンの概念は、本質的な部分でアジャイルに完璧に適合しており、チームがソフトウェア／ITのビジネス的側面を重視するための一助になります。結局のところ、最も重要なのは顧客であり、チームのメンバーです。アジャイルはこれらを尊重する手法と言えます。
参考文献
- 『Agile Principles, Patterns and Practices in C#』Robert C. Martin、Micah Martin著、Prentice Hall PTR、2006年7月
- 『Agile Estimating and Planning』Mike Cohn著、Prentice Hall PTR、2005年11月
- A Kanban System for Sustaining Engineering：agilemanagement Blog
- 『Lean Software Development: An Agile Toolkit』Mary Poppendieck、Tom Poppendieck著、Addison-Wesley Professional、2003年5月
