非ウォータフォール型「アジャイル」の必要性

従来のウォーターフォール型のソフトウェア開発では、品質の高いソフトウェアを生産性高く開発するために、開発作業をいくつかの工程に分け、各工程での成果をドキュメントにまとめて明確にしてから次の工程へ進むという流れで進めていた。しかしながら、大抵の顧客は、最初から自分の欲しいソフトウェアをはっきりと説明できないことが多く、出来上がったソフトウェアを見てから、自分の欲しいものではなかったと気づく。また、近年のビジネスは変化が非常に早く、要求が刻々と変化していく場面でそそれを固定するのは困難である。その影響から、結果的に無駄な作業が発生し、追加の作業によって納期が遅れることが多い。そのため、従来のウォーターフォール型とは異なる、新たなソフトウェア開発モデルが必要とされてきている。そのような「非ウォーターフォール型」のソフトウェア開発モデルの代表として、アジャイル型開発が注目されている。

アジャイル型開発とは

アジャイル型開発イメージ図

アジャイル型開発とは、ウォーターフォール型開発の「成果物の品質を確保し、前工程への後戻り（手戻り）を最小限にする」手法とは異なり、仕様や設計の変更が当然あるという前提に立ち、最初から厳密な仕様は決めず、大まかな仕様だけで細かい開発を開始し、機能レベルでの小単位で設計→実装→テスト実行を繰り返し、徐々に開発を進めていく手法である。例えば、基本的な動作をするソフトウェアを元に、開発チーム内あるいは顧客とチームで密接に議論を交わし、変更する箇所や追加する機能を決め、もう一度各工程を反復する。この小単位でのサイクルを短く何度も繰り返すことにより徐々にソフトウェアの完成度を高めていくのがアジャイル開発の手法の１つと言える。

アジャイル型開発のメリット

アジャイル型開発が従来型のウォーターフォール型開発と比較してどのようなメリットがあるのか以下に挙げる。

１.開発のスケジュールの変更に対応しやすい

ウォーターフォール型開発では、詳細に計画してスケジュール通りに進めることを重視している。一方、アジャイル開発では、状況の変化に応じて、柔軟に仕様や設計の変更に対応していく。また、アジャイル開発ではウォーターフォール型開発のように一気に詳細な計画を立てずに、必要な分だけ、徐々に計画をしていく。長期的な計画は変更されることが常なので役に立たないためである。

２.仕様変更に対応しやすい

ウォーターフォール型開発では、設計、仕様について主に上流SEが決める。設計、仕様が確定した後、PGが仕様書通りにコーディングする流れである。各工程ごとに作業が進んでいくため、現時点でまだ必要のないものも作る。一方、アジャイル型開発では、設計作業の一部を開発チーム内で徐々に進めていく。第1フェーズはここまで作る、第2フェーズはここまで作るといったように作業を進めるため、必要な部分に絞って作業を行うことができる。現時点で必要なものだけを作ることができるために、無駄の発生を最小限に抑えられることに加え、繰り返しの中で新しい機能を追加しながら設計を行うことが可能となるた。そのため、仕様変更による再設計の無駄を避けることができる。

３.早期に顧客要求とのズレに対応できる

顧客とのすり合わせについて、ウォーターフォール型開発では、プロジェクトの最終局面まで顧客が動くソフトウェアを見ることがないことから、不具合が後工程になるほど手戻り工数が大きくなるという欠点があるが、アジャイル開発では、早急に動くソフトウェアを開発し、定期的に顧客からのフィードバックを得て改善を行っていくことにより、早期に要求とのズレを修正し、大幅な手戻りを防ぐことができ手戻り工数を最小限に抑えることができる。そのため、手戻りに発生するコストの削減、仕様変更や追加にも柔軟に対応が可能である。

アジャイル開発のデメリット

上記ではウォーターフォール型開発と比較した場合のアジャイル型開発の利点を挙げてきたが、逆にアジャイル型開発にはどのようなデメリットがあるのか以下に挙げる。

１.全体のスケジュールや進捗が把握しづらく、マネジメントのコントロールが難しい

従来のウォーターフォール型開発の場合は、全体の設計を済ませてから実装していくため、スケジュールや進捗を把握しやすい上に、SIの標準的な開発手法であり、慣れているクライアントが多いことから開発方針に馴染みやすい人が多いというメリットがある。しかしアジャイル型開発の場合は、機能レベルでの小単位で設計→実装→テスト実行を繰り返すため、全体のスケジュールや進捗が把握しづらく、マネジメントのコントロールが難しい。また、大規模システムのような管理志向の強いマネージャやプロジェクトでは敬遠される傾向にある。これは企業経営的な安全の面から、ビジネス価値が創出できないことよりも、計画が不明確な契約であるというリスクに対して敏感に反応する傾向にあるためであると考えられる。

２.期間内に機能が出来上がらないリスクがある

短い周期で設計→実装→テストを繰り返すアジャイル型開発では、期間内になかなか機能が出来上がらない事態に直面しやすい。

アジャイル型開発では、短い周期で設計→実装→テスト実行を繰り返すことにより最終的に、ソフトウエアの機能をリリースする。しかしながら、最初に予定した機能が終了時になっても完成しない場合も少なくない。その結果、取りこぼし分の機能が積み上がり、結果的にソフトウェアにリリースの目途が立たなくなることがある。これらの原因として考えられることは、要求事項などの前提条件が明確に決まらない状態で開発を始めてしまうこと。短い周期で設計→実装→テストを行うため、内在するリスクや問題点を発見・改善に結び付けることが難しい等が挙げられる。

３.機能単位で開発を進めることでデグレードのリスクが発生する

アジャイル型開発では、機能ごとに設計→実装→テスト実行を繰り返して進めていくことから、各機能でリファクタリング、仕様変更、不具合修正等を行った結果、デグレードが発生することが多い。これは、ある機能で仕様変更、修正等を行ったことにより、別の機能で問題の無かった部分にデグレードが発生する等が挙げられる。手を加えたことによる影響を確認するために、回帰テスト(コンピュータプログラムに手を加えたことによる影響を確認するテスト操作)を行い、デグレードを防ぐ必要がある。

アジャイル開発の現状

開発対象システムの複雑化、短納期など、開発環境の変化に対応するために変更に強く、品質や効率の高い開発を目指して考え出されたアジャイル型開発であるが、日本でのアジャイル型開発手法の普及率は海外と比べると非常に低いのが現状である。理由は主に以下のようなものが挙げられる。

１.ソフトウェア開発に外注を多用しているため

外注を多用する日本のソフトウェア開発では、アジャイル開発を導入しにくいことが原因のひとつと言われる。日本ではソフトウェア開発を行う際にその都度契約を交わす必要があるので、ソフトウェアの仕様変更に対応しにくく、アジャイル型開発に適していない。

２.IT人材の流動性が低いため

人材の流動性とは人材がいろいろな企業を渡り歩いている度合いのことで、日本では技術情報やアジャイル型開発の経験がある人材の流動性が低いため一社に留まる傾向にある。技術情報や経験も流通しにくい状態でありアジャイル型開発が浸透していかない。

アジャイル型開発はどういった開発プロジェクトに向いているか

ここまでアジャイル開発の特徴や問題点を挙げてきたが、どんなタイプの開発プロジェクトがアジャイル型開発に向いているのだろうか。

１.要件定義の段階で仕様の全体が見えないプロジェクト

要件定義の段階で仕様を完全に確定せずに設計フェーズに移行する、またそのほかに残りの仕様が確定していない要件は、プロジェクトの状況を見ながら仕様を固めていくので、短納期での納品やレビューを繰り返す際にアジャイル型開発が適用できる。

２.顧客のビジネス状況によって開発優先度に変更が発生するプロジェクト

アジャイル型開発では第１フェーズはここまで作る、第２フェーズはここまで作るといったように開発を進めており、部分的な納品を繰り返していることから、その境目で優先度を柔軟に変更することができる。そのため、完成した部分から顧客へ届けられるので、顧客もビジネスの状況によって優先度を変更して開発を行うことができる。

３.客側の情報システム担当者が参画しているプロジェクト

プロダクトマネージャーにあたる役割をクライアントが担当している場合、可視化が難しかったシステム開発の現状が可視化しやすいことに加え、メンバーに対しても要件の伝達が容易であるため、より迅速で柔軟な開発ができるようになる。

まとめ

現在の日本ソフトウェア開発では、契約時に対象の成果物とそれに掛かるコストを決めてしまうため、開発途中での仕様追加、変更に対応し辛いことから、アジャイル型開発に合った契約内容にする必要がある。仕様追加、変更について開発途中で発生した場合はコストの増減に大きく影響するため、契約の見直しについて顧客・経営層の理解が必須となる。また、すべてのソフトウェア開発にアジャイル型開発手法を適用できるというわけではない。ビジネスや市場、その他の開発の文脈によって、ウォーターフォール型開発が適している場面もあれば、アジャイル型開発が適している場面もある。そのため、現場に合わせて開発手法を選択、改善を行う必要がある。