これを簡単に認める人はほとんどいないが、アジャイル開発に関する最大の誤解の1つは、これによって要件やコードを文書化する必要がなくなり、文書化ではなく開発作業に時間を使えるようになる、というものだ。アジャイルの文書化要件がウォーターフォールモデルと異なるのは確かだ。だが、アジャイルモデルで作成されたのか従来のモデルで作成されたのかにかかわらず、十分に文書化されていないコードは十分に文書化されていないコードでしかない。そして結局は、いずれのコードのサポートにも同じくらい高いコストがかかる。
アナリストが「アジャイル開発を取り入れようよ」と言うとき
真意：誰も決断を下そうとしていないではないか。プロジェクトのスコープも定まらず、変わり続けている。
何度も見直さなければならない要件やスコープほど、最初のエネルギーをプロジェクトから奪うものはない。そして、スコープがなかなか定まらないプロジェクトに効果的という点で、アジャイルは理にかなった選択肢だ。しかしアジャイルであっても、3～30日以内に完成させるべきものが定まっていないプロジェクトに役立てるのはほとんど不可能だ。長期的なスコープの管理は確かに難しいが、明日の朝にやるべきことについてすら意見が一致していないのなら、アジャイルを導入しても効果はないだろう。
顧客が「アジャイル開発を取り入れようよ」と言うとき
真意：大金を払っているのだから、具体的な成果を見せてくれ。
大規模プロジェクトに対する不満の1つは、プロジェクトがかなり先の段階に進むまで、具体的な結果がほとんど出ないことだ。十分な知識のない顧客にとってアジャイルは、「より短時間で真の成果を得られる」ことを意味する場合が多い。そしてアジャイルを求める声には、プロトタイプ、初期段階での開発テストへの参加、より頻度の高いコミュニケーションなどによって応えられる場合がある。
まとめ
スピードと柔軟性、華々しさを暗示する名前を持つものを拒絶するのは、容易なことではない。その方法論の背後にある詳細がほとんど理解されていないときは特にそうだ。そしてすべての関係者にとって、アジャイルモデルを首尾よく運用していくためには協力が重要だ。誰かがアジャイルをやかましく要求するのを耳にしたら、その要求の根本原因を探り出す努力をしよう。
「アジャイル開発を取り入れようよ」という意見の裏には、午後にデモを見せたり、ステータスをアップデートしたりするだけで簡単に解消されるような要求が隠れていることもある。「われわれにはアジャイルが必要だ」という意見は、プロジェクトに根本的な問題があることを示す初期の危険信号の場合もある。アジャイルを検討するように求める声を無視することと、アジャイルを性急に導入することは、同じほど危険だ。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。
