アジャイル開発とそれに関連するさまざまな方法論は、適切に利用すれば素晴らしいツールだ。しかし最悪のケースでは、アジャイルは責任回避の口実になる。
「アジャイル開発を取り入れようよ」。筆者はこうした意見を聞くと恐ろしさを感じる。これはプロジェクトに深刻な構造的欠陥があることを示す初期の危険信号であることが多いからだ。そして、良かれと思ってこの破滅的な意見を述べた人物が問題の一部であることも多い。
ありとあらゆる要件が慎重に集められ、明確に定義されたプロジェクトフェーズをチーム全体で同時に進んでいくウォーターフォールモデルの方法論とは対照的に、アジャイルは短期間のスプリントを繰り返すことで目標を達成する。基本的に、1回のスプリントは、小規模な要件セットと非常に迅速な設計および構築期間、迅速なテスト期間を含む、極めて小規模なウォーターフォールプロジェクトに相当する。
厳格なアジャイル主義者なら、さまざまな相違点を挙げることができるだろう。しかしアジャイルの最も分かりやすい魅力は、迅速に結果を出せることだ。従来のウォーターフォールモデルが何カ月もかけて要件をマッピングする間に、標準的なアジャイル製品は、目で見て感じることができる初期の結果を出せるだろう。
アジャイルプラクティスをうまく実装したいのなら、事前に熟考する必要がある。そして、すべてのプロジェクトがアジャイルからの恩恵を得られるわけではない。「アジャイル開発を取り入れようよ」という意見の裏により深刻な問題が隠れているときに、それを見破る方法を紹介する。
経営者が「アジャイル開発を取り入れようよ」と言うとき
真意：ITプロジェクトにあまりにも多くの時間、コストがかかっている。その根本的な問題を必ずしも解決したいわけではない。何であれ、もっと高速かつ低コストにプロジェクトを進めてほしい。
アジャイルを理解していないからといって「背広組を非難する」のは簡単だ。しかし多くの場合、アジャイルの導入が提案されるのは、プロジェクトのペースが遅くて誰かが苦しんでいるときだ。停滞を打破する新しい方法を即座に探し始めるのではなく、停滞の原因を突き止めよう。それは意思決定の遅さかもしれないし、優柔不断な出資者かもしれないし、リソースの不足かもしれない。まず停滞の原因を排除して、それから方法の変更について考えよう。
開発者が「アジャイル開発を取り入れようよ」と言うとき
真意：この無意味な文書化と形式的な手続きにはうんざりだ。文書化よりもコーディングをしたい。
