最近、急速に利用されつつあるアジャイル開発
アジャイルと言えば、1996年に登場した「XP」（Extreme Programming）と、さらに遡って1993年に提唱された「スクラム」（Scrum）という開発手法が有名です。2001年にこれらの開発手法を総称して「アジャイルソフトウェア開発宣言」（【コラム】「XPかスクラムか」を参照）という言葉と定義が誕生しました。
XPやアジャイルが現われた頃は、コンピュータ誌などでも頻繁に取り上げられ、その柔軟で楽しそうな開発手法が脚光を浴びていました。しかし、その割には実際の開発現場で使われる場面は少なく、根強い支持者を持ちながら普及度は今ひとつという状況でした。
しかし、この2、3年で米国を中心にアジャイル開発の採用が広まり、日本でも改めてアジャイル開発が見直されています。今年の1月に米国の調査会社フォレスター・リサーチが発表したレポートによると、米国においてアジャイル開発を利用している企業の割合は、2005年が14％だったのに対し2009年の第三四半期（3Q）には45％と全体のほぼ半分近くに急上昇しています（図2）。
このデータは米国の調査であり、またアンケートに“やっている”と答えたと言ってもその会社で行なっているプロジェクトの一握りかもしれません。しかし、MIJSに加盟するベンダの多くもアジャイル開発を取り入れており、ソフトウェア開発の現場においてアジャイルが着実に定着しつつあることを伺わせます。
キリスト教や仏教など宗教にもいろいろな宗派があるように、アジャイルにも下記のような流派がたくさんあります。
- XP
- スクラム
- 動的システム開発手法（DSDM：Dynamic Systems Development Method）
- クリスタル
- 機能駆動型開発（FDD：Feature Driven Development）
- アジャイルユニファイドプロセス（AUP：Agile Unified Process）
- リーンソフトウェア開発
この中で人気を2分しているのがXPとスクラムです。「XPよりスクラムのほうが現実的だ」「いやXPのほうが具体的だ」などと言い合う人もいますが、これはまるでキリスト教のカソリックかプロテスタントかを論じているようなものです。キリスト教に聖書があるようにアジャイルにも「アジャイルソフトウェア開発宣言」というバイブルがあり、その理念に沿っているこの2つは相反するようなものではありません。
XPが開発主体に内容を定義しているのに対し、スクラムはマネジメント主体で方法論を論じています。自社で採用する際は、どちらか一方というよりも両方の利点を組み合わせるのが良いでしょう（逆に言えば自社に向いていないところは遠慮なくカットする）。
ただし、XPでは「イテレーション」と呼ぶ反復期間をスクラムでは「スプリント」と呼ぶなど、同じ対象なのに異なった名前が付けられています。そのため、用語に関してはどちらを使うかを決める必要があります。
なお、XPやスクラムのプラクティス（定義内容）の対比については、次回で詳しく説明します。
アジャイルソフトウェア開発宣言
2001年に17名の署名入りで発行されたアジャイルソフトウェア開発のマニフェストでは、アジャイルが重んじる価値とアジャイル開発を行なううえでの原則が宣言されています。アジャイルの手法はいろいろと発表されていますが、基本的にこの価値と原則に則ったものとされています。
価値
- プロセスやツールよりも、人間同士の相互作用
- 包括的なドキュメントよりも、動作するソフトウェア
- 契約上の交渉よりも、顧客との協調
- 計画に従うことよりも、変化に対応すること
原則
- 最も重要なことは早く、そして継続的に価値のあるソフトウェアをリリースして顧客を満足させることである
- 開発の終盤においても要求の変更を受け入れる。アジャイルプロセスは顧客の競争力を優位にするための道具である
- 数週間から数ヶ月の短めの期間で頻繁に実用的なソフトウェアをリリースする
- プロジェクトの間中、毎日顧客と開発者は一緒に作業する
- 意欲のある人を中心にプロジェクトを構築する。環境と必要なサポートを与え、彼らが仕事を成し遂げると信じる
- 開発チーム内で情報伝達を行なう最も効果的で有効な方法は、フェイス・トゥ・フェイスの会話である
- 動くソフトウェアが一番の進捗把握である
- アジャイルプロセスは継続的な開発を促進する。スポンサーや開発者、ユーザーは一定のペースを保てるようになる
- 優れた技術と良い設計に絶えず目を配ることで機敏性を発揮する
- シンプルさ、つまり仕事を多くしないことがポイントである
- 統制が取れたチームが、最善のアーキテクチャ、要求、デザインを生み出す
- 定期的にチームにもっと効果的な方法を反映することで、それに応じて微調整や修正がなされるようになる
ウォーターフォールとのハイブリッド
初期の頃のアジャイル信奉者の多くは、「アジャイルは素晴らしくクールだ。ウォーターフォールはもう古くてダサイ」という論調を展開し、ウォーターフォールのフェーズの一部をアジャイルにするのではなく、最初から最後までアジャイルでやるべきだと主張していました。
筆者は違う意見でした。規模の比較的大きな開発の場合、プロジェクトの最初（要件定義や基本設計）と最後（結合テストや総合テスト）ではアジャイル開発はやりにくいため、詳細設計（一部基本設計も含む）とプログラミングフェーズの部分だけをアジャイル開発にすべきと考えて実践していました。
上記したフォレスター・リサーチによるレポートのエグゼクティブサマリにも、「blending agile and non-Agile techniques and practices to create a hybrid methodology that fits larger organizations」と書かれていて、比較的大きな開発チームにはアジャイルとノンアジャイル（ウォーターフォール）を混在した方式が取られていると記載されています。対象となるシステムや規模にもよりますが、このように実践的なハイブリッドが取り入れられてきたことが普及要因の1つになっているのでしょう。
