システム開発手法
ウォーターフォールモデル
概要
プロジェクトによって工程の定義に差はあるが、開発プロジェクトを時系列に、「要求定義」「外部設計（概要設計）」「内部設計（詳細設計）」「開発（プログラミング）」「テスト」「運用」などの作業工程（局面、フェーズ）にトップダウンで分割する開発手法。原則として前工程が完了しないと次工程に進まない（設計中にプログラミングを開始するなどの並行作業は行わない）事で、前工程の成果物の品質を確保し、前工程への後戻り（手戻り）を最小限にする。ウォーターフォール・モデルの利点は、工程の進捗管理がしやすいことである。
歴史
1968年、NATO後援の国際会議にて、ソフトウェア開発を職人芸的な作成方法から工業製品としての作成方法に変える方法として、製品製造過程のように開発をいくつかの工程に分け、各工程の終了を意味する文書を作成することで進捗を管理し、早いうちから品質の作りこみをしようとするウォーターフォール・モデルの原形が提唱された。
「ウォーターフォール・モデル」という用語は、文字通り「滝」を意味し、W. W.ロイスによって1970年に発表された論文「Managing the Development of Large Software Systems」の内容が元になったとされる。この論文において、「大規模ソフトウェア開発には、製品製造過程のようにいくつかの工程に分けたトップダウンアプローチが必要」と述べている。しかし論文には「ウォーターフォール・モデル」という記述は無く、また、前工程への後戻り（見直し）も提唱されており、元の論文の内容とは異なっている。
問題点
ウォーターフォール・モデルの問題点は、『前工程に間違いがない』ことを前提または期待していることである。古くから（現代においても）、要求を事前に詳細に定義することは困難であると言われている。要求をユーザーに徹底的に確認したにも関わらず、下流工程になって見え始めたシステムを見たユーザーから修正要望が出ることがある。この要望に応えるには、前工程に戻って進捗度を戻さざるをえなくなる。
前工程への後戻りはスケジュールの遅延の原因であると評価されるため、前工程の完了要件（要件定義局面であれば、要件定義書などの成果物の完成）を徹底して品質を高め、後戻りの発生率を可能な限り低下させるとともに、後戻りが発生する場合は変更管理によって公式に決定し、後戻りや横展開を確実にフォローすることが求められる。
プロトタイプモデル
概要
プロトタイプモデルとは、設計の早い段階から機能を制限したり簡易化したりした試作機（プロトタイプ）を作成し、トータルの開発工数を減らすための開発手法のことである。クライアント企業にとっては初期の段階から本番に近い画面イメージを確認することができるのが最大のメリットである。
歴史
1980年代前半まで主流だった開発手法が、高いところから水を流すように、工程を上流から下流へ最後まで一気に開発をすすめるウォーターフォール・モデルだった。ところがこの手法の問題点は、システム開発の終盤になって初めて発注者側で、システムがイメージ通りだったかどうかを確認できるという点である。
発注者側の要望と違うイメージの製品になってしまった場合には、それを修正するために前の工程へ後戻りしなければならず、いわゆるやり直し作業にかかる時間が増えて生産性が低くなるという欠点がある。また、最悪の場合には前工程に戻っても対処することができずに、最初からやり直しというケースもあり、この場合の損失は極めて大きくなる。
ウォーターフォール型開発のこうした問題点が明確になるにつれて、その問題点を解決するためにできたのがプロトタイプ開発モデルである。開発の早い段階で試作品（プロトタイプ）を作成し、その試作品をエンドユーザーが確認することで、ウォーターフォール型にあった「こんなはずじゃなかった」という悲劇を回避することを目的としている。
問題点
プロトタイプ・モデルでは、試作品とは言え、エンドユーザーに確認、評価してもらえるだけの機能を作りこむ必要がある。システムの機能や特性にもよりますが、完成品の全機能を試作品として開発しないと意味がない、というシステムも中にはあるだろう。その場合は、ほぼ完成品という試作品を作る必要があるので、開発コストが膨らむのは目に見えている。
逆に、エンドユーザーが確認、評価できないような、中途半端な試作品を作ったとする。その場合には、試作品に対する十分なフィードバック（エンドユーザーの確認、評価）を得ることができず、「要件漏れを防ぐ」「仕様精度の向上」といった本来の目的を達成することができない。この場合、試作品を作ったこと自体が無意味になってしまう。
スパイラルモデル
概要
スパイラルモデルとは、ユーザーからのフィードバックや要望に対して具体的に対応しながら、精査や改善を施し、徐々に完成させていく、プロセスモデルの手法のことである。作業工程を分割し、分割した工程を順序だてて実施するウォーターフォールモデルの一つ一つの段階を、エンドユーザーとの認識のズレを補正するプロトタイプの作成などを含め、成長モデル的に進めることで、らせん状（スパイラル）に昇華するような開発工程をたどる。
トップダウン設計は、段階的に詳細にしていく設計技法である。最初にシステム全体を定式化し、その時点では個々の詳細には立ち入らない。その後、システムの個々の部分の設計を段階的に詳細化していく。最終段階では、実装に移せるまで詳細化する。内部構造に立ち入らずに設計を行っている段階では、各部分をブラックボックスとして扱う。
ボトムアップ設計では、最初にシステムを構成する個々の部品を細部まで設計する。そして部品群を組み合わせてより大きな部分を作っていき、最終的にシステム全体が構成される。
問題点
フィードバック毎に様々な問題が浮上した場合、何度も何度もシステムを開発しなければならなくなり、開発に時間がかかる。また、初期の想定よりシステムの仕様が肥大化し、コストがかかってしまう可能性がある。また、顧客にとっては一度金銭的な契約が締結されたら何度でも無料で修正できる手法だと考え、依頼する用件をまとめない傾向にある。
アジャイル開発
概要
アジャイル（Agile）とは、直訳すると「素早い」「機敏な」「頭の回転が速い」という意味である。アジャイル開発は、システムやソフトウェア開発におけるプロジェクト開発手法のひとつで、大きな単位でシステムを区切ることなく、小単位で実装とテストを繰り返して開発を進めていく。従来の開発手法に比べて開発期間が短縮されるため、アジャイル（素早い）と呼ばれている。
歴史
近年のアジャイルソフトウェア開発の定義は、1990年代半ばに、「重量ソフトウェア開発手法」への反対運動の一部から発展して形成されてきた。 重量開発手法の特徴は、ウォーターフォール開発モデルを適用した場合に多くみられる、厳格な規律と統制、管理不足などである。 ウォーターフォールモデルのこのような適用に端を発する重量開発手法は、官僚的で、もたもたしていて (slow) 、衰退的 (demeaning) で、そのためソフトウェア技術者が効果的に作業を進めるという観点と矛盾していた。
2001年に、当時軽量のソフトウェア開発を提唱していた17名の技術者やプログラマーが米国ユタ州に集まり、開発手法の重要な部分について統合することを議論した。それをまとめたものが「アジャイルソフトウェア開発宣言」である。アジャイルソフトウェア開発宣言は、ソフトウェア開発とそれに基づく12の原則を定義しており、2017年現在もアジャイル開発の公式文書として広く知られている。
アジャイル開発の流れ
アジャイル開発では、ソフトウェアの計画段階で厳密な仕様を決めずに、だいたいの仕様と要求だけを決める。これは「開発途中に仕様や設計の変更があることは当たり前」という前提があるからである。おおまかな計画のみでは、その後の実装フェーズで問題が起こりそうだが、仕様が決まっていないと途中で変更があっても臨機応変に対応できるため、顧客のニーズに最大限応えることが可能である。
だいたいの仕様と要求を決めたら、イテレーション（iteration）と呼ばれるサイクルを繰り返して開発を進める。イテレーションとは「反復」という意味で、小さな単位に分けられた開発を「計画」→「設計」→「実装」→「テスト」と行いながら、機能のリリースを繰り返す。イテレーションは1週間～2週間ごとが一般的で、イテレーションごとに毎回機能をリリースする。「イテレーション1」「イテレーション2」「イテレーション3」…と繰り返しながら、細かく開発を進めていく。
アジャイル開発は、開発の途中で仕様の変更や追加が予想されるプロジェクトに向いている手法である。例えば、モバイル分野などの日進月歩で技術や仕組みが進化している産業では、開発の途中で仕様の変更や追加が容易に予想できる。アジャイル開発では、リリース計画段階で厳密な仕様を決定しないため、途中変更の多いプロジェクトと相性が良い。
一方、数十年手作業で実行していた工程をシステム化する、20年稼働していたシステムをリプレースするといった場合は、すでに作るべき機能が明確に決まっている。そのため、このようなシステムの場合にはアジャイル開発よりも、ウォーターフォール開発が向いているといえる。
参考:ウォーターフォール・モデル - Wikipedia
