ソフトウェアを
より早く、より安く
ローリスクに提供する為に
我々はアジャイルに
辿りつきました。
アジャイル開発とは
ステークホルダーが継続的に協力を進めて、有益な機能を、小さいインクリメントで、迅速かつ高頻度に提供するソフトウェア開発手法をまとめたものである。アジャイル型の手法には、多くの種類がある。その中でも人気が高いものとしては、スクラム、エクストリームプログラミング、リーンソフトウェア開発、フィーチャー駆動開発、カンバ ンなどが ある。『 アジャイルソフトウェア開発宣言』( Beck et al. 2001)が発表されて以来、「 アジャイル開発」ということばが人気を博している。アジャイル型の手法は、ソフトウェア開発に対するイテレーティブでインクリメンタルなアプローチに基づいており、長年の実績がある(たとえば、Boehm 1988; Gilb 1988; and Larman and Basili 2003 を 参照)。アジャイル開発アプローチは、互いに異なる特徴を持っているが、そのすべての基本において、予測的なアプローチ(「 計画駆動」とも呼ばれる)ではなく、適応的なアプローチ(「 変化駆動」とも呼ばれる)をとる( Boehm and Turner 2004; IIBA 2009)。 ウォーターフォール開発のような予測的なアプローチでは、ソフトウェアの構築に先立って、広範な計画を立てて文書化を行うことにより、プロジェクトのリスクを最小化しようとする。プロジェクトマネジャーとビジネスアナリストは、ステークホルダー全員が、何を提供しようとしているかを正確に理解してから、それを構築する。最初に要求をきちんと理解でき、プロジェクト期間中に要求が比較的安定している可能性が高い場合は、このやり方でうまくいく。これに対して、アジャイル開発のような適応的なアプローチは、プロジェクトでどうしても発生する変更に適応できるように設計されている。要求が非常に不確実または変わりやすいプロジェクトでも、うまく働く。(カール ウィーガーズ;ジョイ ビーティ. ソフトウェア要求 第3版)より出典
ウォーターフォール開発
1Q
2Q
要件定義
3Q
4Q
5Q
6Q
設計
開発
テスト
アジャイル開発
企画
設計
開発
テスト
1W
企画
設計
開発
テスト
2W
企画
設計
開発
テスト
3W
企画
設計
開発
テスト
4W
5W
企画
設計
開発
テスト
6W
企画
設計
開発
テスト
ウォーターフォール開発の限界
多くの企業で採用されているウォーターフォール開発プロセスでは、要件定義を完全に行い、長期間にわたる設計・開発の後、テストを行います。要件定義と設計の誤りを早期に発見できるメリットがありますし、要件定義が完全なものであれば予算やリソースを正確に見積もる事が出来ます。しかし、実際のソフトウェア開発では要件定義時に作成した要件に従ったプロジェクトは殆んどありません。多くのウォーターフォールアプローチによるプロジェクトでは納期が大幅に遅れ、必要な機能が実装されず発注ユーザー側の期待に応えられないか、受注側の開発ベンダーが大幅なリソースを投入し、コストオーバーに陥るケースが少なからず発生します。原因としては、長いプロジェクトの途中で市場や環境の変化や予測していない要件の発生など、変更することが多くこれに対応できない事が考えられます。
アジャイル開発のメリット
1.
市場、環境の変化に迅速に対応できる
追加の変更要求に対して優先順位付けを行い、現実的な納期とリソースを要求毎に検討します。リリース単位を小さくすることで素早くリリースする事が出来るので、環境の変化や細かな要望に素早く対応できます。
2.
本稼働直前~直後のバタバタを回避
ウォーターフォール開発プロセスでは実際に動くプログラムの確認が本番稼働直前になり障害や仕様・要件漏れの確認に急を要します。
また、本稼働直後の重大なバグや仕様漏れに対処しきれない可能性があります。
3.
開発にかかるコストが固定化
ウォーターフォールの受託開発では変更の追加見積もりが発生し、コストオーバーに陥いります。必要な機能が、予算がなくて実装されないといった恐れや悩みを感じずに、システム開発に集中できることが精神的にもコスト的にもアジャイル開発のメリットです。
日々、ベンダー企業と見積もり金額交渉を行う事もコストになります。
4.
顧客の参加によるプロジェクト成功率の向上
プロジェクトの成功は、お客様がどう関わるかで大きく変わります。ウォーターフォール開発では前半の要件定義フェーズに集中し、構築のフェーズでの参加は殆んどありませんが、アジャイル開発では常に関われるため、大幅に成功率が向上します。そして、本当にお客様のニーズに沿ったシステムの提供が実現します。
5.
リスクの分散
企画~リリースまでの開発規模が小さいので、変更箇所も少なく、リスクが分割されます。リスクは小さく分割されているほど対処しやすく、バグや不具合も見つけやすくなります。それによって、高い品質を維持できるので、信頼性の担保にもつながります。
また、変更箇所が少ないので、不具合そのものの発生を減らし、スピーディに新機能を追加することもできます。
お気軽にご相談ください。