皆さんは「アジャイル開発」と聞くとどんなイメージを思い浮かべるでしょうか。語源となっている英語の“agile”を辞書で引くと「俊敏な、迅速な」という意味が載っています。そのとおり、刻々と変化する市場の要求、顧客の要求に迅速に対応していくというのが基本的なアジャイル開発のあり方です。
本連載では3回に渡り、アジャイル開発の採用を検討している方々に対して、その基本的な事項を解説していきたいと思っています。本連載によってアジャイル開発への理解を深めていただくきっかけになれば幸いです。
「ウォーターフォール型」の限界
アジャイル開発の説明に入る前に、「ウォーターフォール型開発」について見ていきましょう。
システム開発には納期が伴います。開発サイドは決められた期間内に要求通りの機能を実現し、顧客に納品しなければなりません。そのためには開発を効率化する手順や約束ごとが必要です。
そこで開発の過程を時間軸に沿って「要求」→「設計」→「実装」→「テスト」といったような工程に分け、開発の早い段階で要求を固定化し、それぞれの工程でドキュメントや仕様書といった成果物を作成して形式化しながら進めるという、いわゆる「ウォーターフォール型開発」という開発手法が生み出されました。
滝の水が上から下へと流れ落ちるように、開発の各工程が上から下へとおりてくるのです。また、要求や設計が適切に実装されたかどうかをテスト工程で確認することになります。ウォーターフォール型開発では、各工程ですべきことがはっきりと分かれているため、進ちょくの管理がしやすく、見積もりなども行いやすいのが特徴です。従って「段階的かつ着実に品質を確認しながら進められる」というメリットがあります。
このウォーターフォール型開発は、現在でもソフトウェア開発現場において主流を占めています。しかし、近年、開発の効率化を図るために生まれたこの開発手法に対し、疑問の声が多く聞こえてくるようになりました。
滝の水は上から下に流れていくものであり、決して下から上に逆流することはありません。逆流させるためには多大なエネルギーが必要です。ウォーターフォール型開発もこれと同じで、たとえばテスト工程で不具合が発見された場合、それを要求や設計の段階に戻ってやり直すことになれば、納期の遅延や開発コストの増大などの大きな影響が生じます。
また、顧客であるユーザーは各工程をすべて通り抜けた後でなければ実際に動くシステムを目にすることができません。そのため、実際に統合テストの段階に入って顧客から「こんなモノが欲しかったわけじゃない」という仕様の不備に対する不満が噴出することもしょっちゅうです。
よく開発の現場では「プロジェクトが火を噴く」というフレーズが言われることがありますが、これは主にあいまいな仕様のまま開発を進めたために後の工程で顧客から突きつけられた予定外の仕様変更に現場が対応しきれなくなり、他のプロジェクトや外部から応援を呼ばざるを得なくなるような、文字通り「火事場」のような状況を指しています(余談ですが、このとき応援に駆けつける人々を「火消し」と呼ぶことも多いです)。
なぜこのようなことが起こるのか。それはウォーターフォール型が開発手法に「変化」という要素を十分に考慮していないことに大きな原因があります。
(本稿では、要件を完全に決めることができず、要件が変更される場合も要件の「変化」と定義します)