こんにちは、タイシです。
今回は開発プロセスモデル・開発手法について発信していきます。
特に有名な「ウォーターフォール」「プロトタイプ」「スパイラル」「アジャイル」の４つについて説明します。
ウォーターフォールモデル
最もオーソドックスな方法です。
ウォーターフォール（＝滝）という言葉のように、1方向に流れるがごとく、「計画→設計→プログラミング→テスト」の順を追って開発を進めることが特徴です。
逆戻りは基本的にしないので、ミスが無いように確認しながら進めないと、後々の影響が大きくなります。
全て計画を立ててから順々に進めていくため、現在の進捗状況や品質のコントロールなど、非常にプロジェクトの管理がしやすいメリットがあります。そのため、大規模の開発プロジェクトなどで良く使われています。
プロトタイプモデル
ウォーターフォールのように順を追って開発を進めるのではなく、テスト機（プロトタイプ）をまずは作ります。それを改善しながら開発していく方法です。
テスト機が素早くできるので、顧客と自分たちで確認しながら進めることができます。
特に、顧客が欲しいシステムを具体的にイメージできていない場合、後々に「思っていたのと違う」と仕様変更が発生する、などの認識のズレや曖昧な箇所を無くせるメリットがあります。
テスト機を作るので、大規模な開発だとコストと時間がかかりすぎるので向いていません。小規模なシステムだと効果が高いと言われています。
ちなみにモックアップは、あくまで画面デザインを確認してもらう紙芝居のようなものであり、プロトタイプとは違います。
スパイラルモデル
スパイラル（＝螺旋）という言葉のように、ウォーターフォールの「計画→設計→プログラミング→テスト」といった一連の流れを何回も繰り返します。繰り返しながら、徐々に開発の範囲を広げていって開発を進めます。
つまり、一斉に開発するのではなく、部分的な開発を繰り返しながら、１繰り返しが終わるごとに開発を振り返り、開発上の問題点を改善していく考え方です。
そのため、今まで経験したことのない（ノウハウがない）開発に、特に効果的です。
また、部分的に開発していくので、いきなり多くの開発者を抱えなくても良いというメリットがあります。
アジャイル開発
アジャイル（agile＝機敏な、早い）という言葉のように、機敏にソフトウェアを開発していくことを目指したものです。元はRADと呼ばれる開発手法をベースに考えられた思想です。具体的な開発手法という訳ではなく、次の基本指針を掲げた開発方針のようなものです。
- プロセス・ツールよりも、個人の対話を重視
- 包括的なドキュメントよりも、動くソフトウェアを重視
- 契約交渉よりも、顧客との協調を重視
- 計画に従うことよりも、変化への対応を重視
これに基づいて、イテレーションと呼ばれる一定の期間内での「計画→設計→プログラミング→テスト」を繰り返しながら開発を進める開発手法がいくつも提唱されています。
上記のスパイラルモデルやプロトタイプモデルの延長線上にあります。
アジャイル開発では、計画段階で大まかな仕様を決めるぐらいで、開発途中の仕様や設計の変更は許容します。
大まかな仕様を決めて、イテレーションのサイクルを繰り返して開発を進めます。
イテレーションは1週間程度～長くても半月程度が一般的です。イテレーションごとにリリースして開発を進めます。
開発途中で仕様変更が予想されるプロジェクトに効果的です。逆に、仕様が決まっていて、それをシステム化するだけのプロジェクトは、ウォーターフォールの方が効果的です。
アジャイル開発で特に有名な開発手法は「XP」「スクラム」です。
もっとアジャイル開発手法について詳しく→準備中
開発プロセスモデルや手法は、実際の開発現場では異なる場合が多いです。
独自のやり方や文化があるので、注意が必要です。工程や設計書の呼び方も異なってきます。
あくまで、「モデル・方法論」として、細かいことにはこだわらず、自分の作業と関連付けて上手く開発を進めていくのが重要です。
コメント