はじめに
この1年間で、アジャイル開発手法は、マイナーな存在から、ソフトウェア開発のための主流の手法とみなされるまでに進化しました。アジャイルへの動きは、1990年代終わりのエクストリームプログラミング（XP：Extreme Programming）、スクラム（SCRUM）、DSDM、ユーザー機能主導型開発（FDD：Feature Driven Development）などの出現によって始まりました。2001年2月には、アジャイル開発の主要な原則をまとめたアジャイルマニフェストが発表されました。なぜこれが、私たちにとって重要なのでしょうか？
結局のところ、アジャイルの重要性とは、ソフトウェア開発にビジネスの規律をもたらしたことです。アジャイルには、トヨタ生産方式に代表されるリーン手法に共通する部分が多くあります。リーン手法がアジャイルチームに取り入れられるケースも増えてきており、ソフトウェア開発／ITチームにさらなるビジネスの視点をもたらしています。
アジャイルを何と比較するか？
アジャイルについて議論する場合、それを何と比較しているのでしょうか？ 本稿では、アジャイルを厳格な計画主導型の開発手法と比較して考えます。これはウォーターフォール型と呼ばれることが多いですが、特に名前を付けることなく使用している企業もあるかもしれません。もし今採用しているプロセスが、プロジェクトの開始前にすべての要件を明確化することを求めていて、その要件は何があっても変更できないというものであるならば、それこそまさに、ここでアジャイルの比較対象として考えているものです。
アジャイルの高レベルの概念を把握するには、AgileManifesto.orgにあるマニフェストを読むとよいでしょう。マニフェストは、次の4つの文で始まります。
- プロセスやツールよりも人とコミュニケーションを
- 包括的なドキュメントよりも動作するソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画の遵守よりも変化への対応を
これらの文は、やや概念的なので、これを自分の環境において実践する方法を理解するために、肉付けしてみることにしましょう。
アジャイルマニフェストのこの各文に対し、アジャイル手法には具体的なプラクティスが存在します。以降では、各文を1つずつ取り上げ、その文の意図を実現するために使用されるプラクティスを示します。
プロセスやツールよりも人とコミュニケーションを
この文からは、アジャイルにはプロセスが存在しないのかという印象を受けるかもしれません。しかし実際のところ、それは大きな誤解です。アジャイルはプロセスを排除してしまうものではなく、人とコミュニケーションがプロセスやツールに勝るという意味なのです。
人とコミュニケーション、つまり各自の行動とチーム内の対話が重要であるという考え方は、多くのアジャイル手法に共通して見られる、頻繁な計画立案や毎日のスタンドアップミーティングに現れています。XP、スクラム、リーン手法では、毎日のスタンドアップミーティングが重要です。このミーティングにおいて、強い意識を持ったチームメンバー全員が、次のような質問を交わしてコミュニケーションを図ります。
- 自分は昨日何をしたか？
- 今日は何をしているか？
- 作業の妨げとなっているものは何か？
毎日のスタンドアップミーティングは、プロジェクトの進捗状況の把握に役立つものでなければなりません。つまり、スタンドアップミーティングで話し合った内容（人とコミュニケーション）によって、プロジェクト計画を変更せざるを得なくなる場合もあります。大抵の場合は、このようなミーティングで障害が見つかります。しかし早い段階で発見されれば、すぐに問題を解決できます。ある技術が期待どおりに動作していなかったり、ビジネスロジックが実は他のロジックと衝突していたりする場合は、毎日のスタンドアップミーティングでこれらの問題を取り上げ、ミーティングの後に行動計画を立てます。
