編集部からのお知らせ
新着:記事選集「エッジコンピューティング」
PDF Report at ZDNet:「ドローン活用」

アジャイル開発はなぜ難しい?--アジャイル開発を実案件に生かすための基礎知識(2) - (page 2)

柏木雅之、山下博之 (IPA SEC エンタプライズ系プロジェクト)

2011-06-01 12:00

アジャイル開発に対する「誤解」を解く

 国内でアジャイル開発の案件があまり増えない理由のひとつに、「アジャイル開発への誤解」があります。次に、その例を見てみます。

誤解その1「アジャイル開発って、ドキュメントを作らないんでしょ? それは後々不安だなぁ…」

 工程ごとにドキュメントを作成、レビューするウォーターフォール型開発に対し、アジャイル開発は「動くプログラム」がその代わりになる、と前回でも解説しました。「アジャイル宣言」には4つの価値の1つとして「包括的なドキュメントよりも動くソフトウェアを」と記されています。アジャイル開発を特徴づける重要なコンセプトであることは間違いありません。

 しかし、だからといって「アジャイル開発ではドキュメントを書かない」というのは大きな誤解です。アジャイル開発でも当然ながらドキュメントを書く作業は発生します。強いて言うならば「アジャイル開発ではムダなドキュメントをできるだけ書かない」のほうが、より正確でしょう。

 ウォーターフォール型開発では、工程によって担当者が変わるため、コミュニケーション手段としてドキュメントが必要です。しかし、アジャイル開発では、ある機能は短期間に1人で「設計」「実装」「テスト」の作業を行うため、ドキュメントを作る必要性はありません。つまり、工程間での引き継ぎが不要なため、自分の考えを整理するために必要ならばドキュメントを作成しますが、そうでない場合はドキュメントを作る必要性はないのです。ただし、運用や保守は担当者が異なるため、そのために必要なドキュメントを作ります。

 また、ウォーターフォール型開発では、ドキュメントを使って第三者によるレビューを行うことで設計の品質を確保します。一方、アジャイル開発では、ペアプログラミングやテストコードに仕様を書くことで、設計の品質を確保しています。もちろん、顧客からの要求があれば、必要なドキュメント以外も作成しますが、開発効率は低くなります。実際には必要に応じてドキュメントを作るにもかかわらず、なぜか「アジャイル開発=ドキュメントを作らない」というイメージが根強く浸透しているようです。

誤解その2「アジャイル開発って、手戻りを認めるんだよね? 際限なく仕様変更があると、成果物(ゴール)のイメージを共有できないよ」

 本稿で何度か触れてきたとおり、ウォーターフォール型開発では基本的に「手戻り」を避けることが原則です。対してアジャイル開発は、「手戻りを容認する手法」として認識されています。

 このことから、「顧客からの仕様変更要求に際限なく応えるのがアジャイル開発」と誤解している人々も多いようです。そのため、「仕様変更に柔軟に対応できるというからアジャイル開発を採用したのに、手戻りを重ねるたびに、どんなソフトウェアが出来上がるのか見当もつかなくなってきた」「変更続きが重なりプロジェクトがいつ完了するのかがまったく見えてこない」といったケースも実際に起こっています。

 手戻りが頻繁に発生すると、当然、期間も余計にかかるため、当初予定していた時期にシステムを稼働できなくなるリスクが高まります。また、顧客からの変更要求を折り込んだ一括請負契約の場合、むやみな仕様変更で開発期間が延び、契約金額内でプロジェクトを完了できないことも起こり得ます。

 アジャイル開発では、変更に伴ってプログラムの複雑さが著しく増大しないよう、顧客と開発者とが協議し、技術的管理を行い、開発過程をうまくコントロールする必要があります。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

特集

CIO

モバイル

セキュリティ

スペシャル

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNet Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]