アジャイルソフトウェア開発
アジャイルとは
これまで見てきた開発プロセスは、システムの規模拡大に伴い必要性が認識されたものです。すなわち、システム規模が拡大するにつれて、システム品質や開発進ちょくを制御するのが困難になってきたので、これを解決するために開発プロセスが整備されてきました。言うなれば、これらの開発プロセスは、重厚長大なシステムを開発するための重量級の開発プロセスです。
1990年代後半に入ると、この状況に変化が現れます。ハードウエアの発達やWebの普及等により、「少数の大きなシステムが存在する」世界から「多数の小さなシステムが存在する」世界にシフトしてきたのです。この変化により、開発するシステムと同様、開発プロジェクトもより小さく、軽量化してきます。そのため、それまでの重量級の開発プロセスにおける非効率な側面がクローズアップされることとなったため、「軽量級」の開発プロセスが提唱されるようになりました。
そして、2000年代に入ると、これら軽量級の開発プロセスのエッセンスを集め、「アジャイルソフトウエア開発宣言」が発表されました。それ以降、この「アジャイルソフトウエア開発宣言」に基づいた開発手法や開発プロセス、考え方を総称して「アジャイル」と呼ぶようになりました。ですので、「アジャイルソフトウエア開発」というのは、1つの開発手法や開発プロセスを指す言葉ではなく、また、厳密に定義されて使われている言葉でもありません（図1）。なお、アジャイル（agile）という言葉自体は、「俊敏な」「機敏な」という意味を持っています。
アジャイルソフトウエア開発宣言
アジャイルソフトウエア開発宣言では、4つの価値と12の原則を示しています。
4つの価値（http://www.agilemanifesto.org/）
・プロセスやツールよりも、個人と相互作用
・包括的なドキュメントよりも、動作するソフトウエア
・契約交渉よりも、顧客との協調
・計画の順守よりも、変化への対応
各項目において、前者にも価値はあるが、後者の価値をより重視する。
12の原則（http://www.agilemanifesto.org/principles.html）
・最も重要なのは、顧客満足。初期段階から継続的に、価値あるソフトウエアをリリースすること。
・終盤での要求変更も受け入れること。アジャイルプロセスは顧客の競争力を高めるためのもの。
・数週間～数か月の単位で頻繁にリリースすること。リリース間隔は短い方が良い。
・プロジェクト中、毎日、顧客と開発者が一緒に働くこと。
・やる気を重視して開発チームを構成すること。顧客も開発チームの仕事遂行を信じサポートすること。
・開発チーム内の情報伝達は、会話が一番。
・最も重要な進ちょく尺度は、動くソフトウエア。
・アジャイルプロセスは、継続的な開発を促進する。顧客や開発者は一定のペースを保てる。
・技術や設計をレベルアップさせる意識が、より俊敏（アジャイル）さを高める。
・「手作業を行わないための工夫」が重要。
・自律的なメンバーが協調して動くチームの方が、パフォーマンスが高い。
・定期的な「ふり返り」により、開発チームのパフォーマンスをより高めるようにすること。
現在、いろいろな局面で「アジャイル」という言葉が使われていますが、この言葉の根本の考え方には、この「アジャイルソフトウエア開発宣言」があると考えて良いでしょう。
アジャイルな開発プロセス
では、アジャイル開発プロセスには、どのようなものがあるのでしょうか。いくつか紹介します。細かい点ではいろいろな違いがありますが、アジャイルな開発プロセスのイメージをつかんでください（図2）。
・エクストリームプログラミング（XP：Extreme Programming）
XPは、「コミュニケーション」「シンプルさ」「フィードバック」「勇気」「敬意」といった価値、「ストーリー（この単位で要件を扱い開発を進める）」「ペアプログラミング」「テスト駆動」「継続的インテグレーション」「ふり返り」といったプラクティスで有名な開発プロセスです（価値やプラクティスは改訂を重ねる度に変わっています）。XPでは、これらのプラクティスに従って、1～4週間のサイクルで、開発を進めていきます。
名前からも分かる通り、XPは、プログラマーを主役にした開発プロセスであり、規模の小さいプロジェクトで効果を発揮すると言って良いでしょう。
・スクラム（Scrum）
名前からも分かる通り、スクラムは「チーム一丸となってゴールを目指す」ことに焦点を当てた、プロジェクト管理を主体にした開発プロセスです。スクラムでは、「バックログ」としてタスクを決定し、「スプリント」という2～4週間のサイクルを繰り返すことにより、完了タスクを増やしていきます。
スクラムでは、「計画通りに動く」というよりも「自律的に最適化を行う」ことを前提としていて、そのために毎日、スタンドアップ・ミーティングを行う、としています。このコミュニケーション手段は、アジャイル開発に限らず、広く行われるようになっています（朝会等、いろいろな名前で開催されているかと思います）。
・機能駆動開発（FDD：Feature-Driven Development）
FDDは、上で説明した開発プロセスよりも、手続きが規定されているため、大規模開発向けにも適用できる開発プロセスです。開発は「機能」を単位として、機能ごとにチームを作って進めていきます。各チームは並列で開発を進めることが可能となっているため、大規模開発にも適用できる、という訳です。機能とは、システムを使う側から見て意味がある単位であり、その観点からは、重量級の開発プロセスと近いと言えるかも知れません。
このように、アジャイルな開発プロセスと言っても、個々の開発プロセスはさまざまな特徴を持っているので、アジャイルと1つにまとめて論じる場合には注意が必要です。なお、ほかにも、Crystal、DSDM等、アジャイルな開発プロセスはいろいろと提唱されています（図2）。
カウボーイ開発
アジャイルという言葉が広まるにつれて、「カウボーイ開発」という言葉も有名になってきたので、ここで紹介します。
・カウボーイ開発（カウボーイ・コーディング）
無統制でバラバラのコーディングを寄せ集めた開発を指す。開発メンバーは、自分が正しいと思った作業を、自分が正しいと思ったやり方でこなしていく。すなわち「開発メンバーのそれぞれが、正しいと思うやり方でバラバラに開発すること」を指す。非常に俗人性が高く、明確な手法が欠如した、開発プロセスとは呼べないやり方。
アジャイル開発が批判される際には、このカウボーイ開発が引き合いに出されることが多く、「アジャイル開発は、カウボーイ開発に、それっぽい名前をつけただけではないか」と言われます。確かに、アジャイル開発でプロジェクトを進めるのは難しい面が多く、経験者がいないような場合にはカウボーイ開発に早変わりするリスクが高い、という意味では、全く的外れでもないと思います。逆に言うと、アジャイルで開発を進める際には、カウボーイ開発にならないように気をつけなければなりません。
重量級開発プロセスとの違い
アジャイルには、「ドキュメントよりも動くソフトウエア」という考え方がありますので、この点では、考え方をさらに推し進めただけで、反復型の重量級開発プロセスと似ているとも思えます。しかし、アジャイルな開発プロセスと重量級開発プロセスとの根本的な違いが、アジャイルソフトウエア開発宣言の価値に表れています。重量級プロセスが「事前に予見」「手続き中心」という考え方なのに対して、アジャイルな開発プロセスでは「計画よりも変化への対応」「プロセスよりも個人」という考え方を重視していることです。
では、アジャイルな開発プロセスでは、どのようなプロジェクトに適用できるのでしょうか。判断基準として、下記のような切り口があります。アジャイルな開発プロセスは、重量級プロセスを置き替えるものではなく、適材適所で適用していくことが重要なのです（図3）。
・種類
クリティカルなシステムでは、厳密な統制下で開発を進めることにより、計画通りの品質を保つことが最重要ですので、アジャイルな進め方は向かないと言われています。
・規模
アジャイルの特徴として「個人と相互作用」とか「変化への対応」があります。これらは、プロジェクトの規模が大きくなると、統制を保つのが難しくなっていくものです。そのため、規模拡大に対応するためには、ある程度「手続き中心」の考え方を取り込む必要があります。
・経験
アジャイルでは、開発メンバーが自律的な動きすることを期待します。つまり、ある程度のスキルを持った開発者でないと、効率よく開発を進めていくことができません。また、プロジェクト管理の側面においても、アジャイル開発の管理を行える管理者がいないと、カウボーイ開発になってしまいます。
・契約
アジャイルは「変化に対応」します。すなわち、見積もり時点の要件と完成時点の要件が違うことが少なくありません。そのため、少なくとも一括発注の場合には、契約に落とし込むのが難しく、ここがアジャイルの障壁になっていることが多いのではないでしょうか。
こぼれ話
ここでは、アジャイルに関連したよくある落とし穴として、私が携わったPJでの話を披露したいと思います。皆さまも十分注意してください。
・「アジャイルでやりましょう」
画面設計が全く進んでいない状況での、ユーザー側担当者のご提案。その開発PJでは、画面設計書を使ってドキュメントベースで設計を進めていたが、進ちょくが芳しくなかったため、やり方を変える一案として提案された。プロジェクトメンバーの中には、アジャイルの経験者はおろか、アジャイルの理解者もいなかったが、なぜか、PM判断によりアジャイルでの開発を行うこととなった。結果、アジャイルという名を借りた「無駄な作業」を1か月間行った後に、元の開発プロセスに戻ることとなった。
「アジャイル」という言葉の響きは、バズワードと同様、人の判断力をまひさせる効果があるようです。プロジェクトの進ちょくが芳しくなかったために、何か進め方を変えなければならない、といった意識を持つのは当然のことだと思いますが、プロジェクトメンバーの誰も理解していない「アジャイル」なる進め方で開発を行うことに対しては、もう少し慎重な判断が必要だったと言えます。
また、「アジャイルはダメだ」という意見もよく耳にしますが、このような「似非（えせ）アジャイル」に対する意見も多いと思われます。現在ではアジャイルという言葉が先行している感がありますが、アジャイルの中身が普及し、アジャイルの考え方や個々の開発プロセスが理解されるようになれば、アジャイルに対する評価が上がり、結果、普及が進むのではないでしょうか。
