アジャイル開発に対する「誤解」を解く
国内でアジャイル開発の案件があまり増えない理由のひとつに、「アジャイル開発への誤解」があります。次に、その例を見てみます。
誤解その1「アジャイル開発って、ドキュメントを作らないんでしょ? それは後々不安だなぁ…」
工程ごとにドキュメントを作成、レビューするウォーターフォール型開発に対し、アジャイル開発は「動くプログラム」がその代わりになる、と前回でも解説しました。「アジャイル宣言」には4つの価値の1つとして「包括的なドキュメントよりも動くソフトウェアを」と記されています。アジャイル開発を特徴づける重要なコンセプトであることは間違いありません。
しかし、だからといって「アジャイル開発ではドキュメントを書かない」というのは大きな誤解です。アジャイル開発でも当然ながらドキュメントを書く作業は発生します。強いて言うならば「アジャイル開発ではムダなドキュメントをできるだけ書かない」のほうが、より正確でしょう。
ウォーターフォール型開発では、工程によって担当者が変わるため、コミュニケーション手段としてドキュメントが必要です。しかし、アジャイル開発では、ある機能は短期間に1人で「設計」「実装」「テスト」の作業を行うため、ドキュメントを作る必要性はありません。つまり、工程間での引き継ぎが不要なため、自分の考えを整理するために必要ならばドキュメントを作成しますが、そうでない場合はドキュメントを作る必要性はないのです。ただし、運用や保守は担当者が異なるため、そのために必要なドキュメントを作ります。
また、ウォーターフォール型開発では、ドキュメントを使って第三者によるレビューを行うことで設計の品質を確保します。一方、アジャイル開発では、ペアプログラミングやテストコードに仕様を書くことで、設計の品質を確保しています。もちろん、顧客からの要求があれば、必要なドキュメント以外も作成しますが、開発効率は低くなります。実際には必要に応じてドキュメントを作るにもかかわらず、なぜか「アジャイル開発=ドキュメントを作らない」というイメージが根強く浸透しているようです。
誤解その2「アジャイル開発って、手戻りを認めるんだよね? 際限なく仕様変更があると、成果物(ゴール)のイメージを共有できないよ」
本稿で何度か触れてきたとおり、ウォーターフォール型開発では基本的に「手戻り」を避けることが原則です。対してアジャイル開発は、「手戻りを容認する手法」として認識されています。
このことから、「顧客からの仕様変更要求に際限なく応えるのがアジャイル開発」と誤解している人々も多いようです。そのため、「仕様変更に柔軟に対応できるというからアジャイル開発を採用したのに、手戻りを重ねるたびに、どんなソフトウェアが出来上がるのか見当もつかなくなってきた」「変更続きが重なりプロジェクトがいつ完了するのかがまったく見えてこない」といったケースも実際に起こっています。
手戻りが頻繁に発生すると、当然、期間も余計にかかるため、当初予定していた時期にシステムを稼働できなくなるリスクが高まります。また、顧客からの変更要求を折り込んだ一括請負契約の場合、むやみな仕様変更で開発期間が延び、契約金額内でプロジェクトを完了できないことも起こり得ます。
アジャイル開発では、変更に伴ってプログラムの複雑さが著しく増大しないよう、顧客と開発者とが協議し、技術的管理を行い、開発過程をうまくコントロールする必要があります。