はじめに
本稿にわざと挑発的なタイトルを付けたのは、対立する2つの意見を持つ人たちの注意を引き寄せるためです。一方は、アジャイル手法の信奉者で、自分たちの支持するアプローチについての反論を粉砕したいと思っている人々。そしてもう一方は、アジャイル手法に反対し、自分たちの考えを正当化する理由を探している人々です。
本稿の目標は、この2つの派閥の対立を緩和することと、どちらの立場を取るべきか決めかねている人たちに何らかの判断材料を提供することです。
実際のところ、アジャイル手法に従った開発プロジェクトは失敗してきました。ウォーターフォールやRUPに従ったプロジェクトも同様です。本を表紙で判断してはならないという常套句がしばしば真実であるように（実際、私は自分の古臭い偏見のせいでロバート・ハインラインの『フライデイ（Friday）』の知的な面白さを味わうチャンスを何年も逃していました）、タイトルを見ただけでトピックの結論まで理解したようなつもりになるのは禁物です（孫子の『兵法（The Art of War）』は、むしろいかに''戦わないか''についての本なのです）。
現在のアジャイル手法の詳細を掘り下げるつもりはありません。内容が多すぎて本稿1回だけでは十分にカバーできませんし、このような詳細が、アジャイルプロジェクトがなぜ成功（または失敗）するかに直接影響を与えることもありません。
アジャイルはプロジェクトに適用できる一種のツールセットですが、それと同時に、プロジェクトについての1つの考え方でもあります。成功する考え方を形作るさまざまな側面は、アジャイルにもアジャイル以外の手法にも当てはめることができます。
プロジェクト
あるオンライン辞書でアジャイル（agile）という単語を調べてみたところ、2つある定義の両方に「機敏（quick）」という表現が出てきました。agileという単語は、運動能力と、優雅で、身のこなしの早い猫のような捕食動物を思い起こさせます。初めてアジャイル手法を採用したきっかけとして「納期が厳しかったから」という理由を挙げる人がいたとしても不思議ではありません。おそらくそのうちに、「手法を名前で選ぶ」という新しい常套句ができることでしょう！
いくつかのプロジェクトでアジャイル手法を経験したことのある人に話を聞けば、アジャイル手法ならすぐに結果が得られると教えてくれたり、それを実証する成果物を見せてくれたりするでしょう。ただ彼らが忘れている（あるいは単に言い忘れている）のは、成功するアジャイルプロジェクトは、アジャイル手法で成功するだけの利点をいくつか備えている、ということです。
あるソフトハウスの初めてのアジャイルプロジェクトが成功するためには、対象のプロジェクトが、その会社でアジャイル手法を採用するのにふさわしいプロジェクトであることが必要です。そのプロジェクトは、期間の面でもチームの大きさの面でも小規模なものでなければなりません。
プロジェクトのマネージャは、積極的にアジャイル成果物をそのまま採用するか、その評価方法を受け入れる必要があります。最も重要なのは、プロジェクトチームに、アジャイル手法に慣れたメンバーをある程度の人数揃えること、あるいは学習曲線が上向くまでの余裕を与えることです。
アジャイル手法は、すべてのレベルの関係者間の、途切れることのないオープンなコミュニケーションに依存しています。従来のウォーターフォールグループでは、ある要件の記述の意味を理解するために開発者がビジネススポンサーやクライアントに直接問い合わせることは見られません。アジャイルプロジェクトでは、そうしたことを行えるかどうかが、成功と失敗を分ける鍵になることがあります。
アジャイル手法を使用して大きいプロジェクトを成功させることもできますが、この手法に初めて取り組んでいるチームでは難しいでしょう。大きなプロジェクトは、ほとんどの場合、チームメンバーの数が多く、複数のロケーションにまたがっています。いくつかのプロジェクトを経て、小さなアジャイルチームを大きな分散型チームへと成長させることはできますが、大きなチームをゼロから組み立てようとすると失望するかもしれません。
仮にメンバー全員にアジャイルの経験があったとしても、いきなり大きなチームを成功させるのは困難です。多くの形容詞にさまざまな意味があるのと同様に、一口にアジャイルと言っても、人や状況が違えばそれぞれ異なる意味を持ってきます。経験豊富なアジャイルプロジェクトメンバーの2人がまったく相反するアプローチを取ることもあります。大きいアジャイルチームは、手当たり次第に寄せ集めるのではなく、組織的に成長させる必要があります。
おそらくアジャイルプロジェクトの実施に関するこのような注意事項が、アジャイルは大きいプロジェクトに適していないという一般的なコンセンサスの根源であると思われます。アジャイル手法を初めてチームに導入するときには、この注意を覚えておくとよいでしょう。
ここまで、アジャイルプロジェクトを成功させるために必要な構成要素について説明してきましたが、その中でさまざまな蓋然性の様相演算子を使ってきたのは、単にバラエティに富んだ表現をするためではなく、実は意図的な選択の結果だったということに注意してください。
初めてアジャイル手法に取り組むプロジェクトマネージャは、積極的に受け入れる必要があります。チームとしてアジャイルアプローチを経験するのが初めてのチームには、アジャイルの経験があるメンバーを十分に揃えるか、試行錯誤して覚える機会が与えられなければなりません。関係者間のコミュニケーションは結果に影響を与える可能性があります。
これには例外があり、たとえばビジネス要件を技術要件に変換する役割などを担う人々が、ビジネス側および開発側と良好な関係を築き、円滑なコミュニケーションを行っていて、このコミュニケーションにおいて高い能力を発揮している場合などです。
このセクションでは、最初に辞書の定義を参照しました。ほとんどの辞書には、単語の現在の意味に加えて、単語の歴史、つまり語源も記載されています。上記のリンクでは、agileの語源として「from Latin agilis, from agere to drive, act.（ラテン語agilisより、前進する、行動するという意のagereから）」とされています。
つまり、現代英語のagileという単語は、その語源から発展して、「機敏（quick）」という概念を含むようになっているのです。アジャイル手法は、組織の中で我々が望むとおりのものに進化する可能性を持っていますが、最初から希望どおりのものになる見込みは薄そうです。
