はじめに

いわゆる上流工程に携わらせていただく機会があり、
その際自分なりの言葉でウォーターフォールやアジャイル等についてまとめたいと思い記します。

間違い等あればご指摘お願いいたします。

はじめに
そもそも開発モデルとは何か?
- なぜ「開発プロセス」が必要なのか？
開発モデルの種類
アジャイル開発
参考文献
更新

そもそも開発モデルとは何か?

開発モデルとは、システムを開発するための方式として標準化されている、開発の手順や手法のことである。

この「開発の手順・手法」とある部分が所謂開発プロセスになる。
開発プロセスとは、

1.要件定義
2.基本設計
3.詳細設計
4.プログラミング
5.単体テスト
6.結合テスト
7.システムテスト
8.運用テスト
9.運用保守

(若干の言葉の違いなどはある）という一連の流れのこと。

開発モデルとは、こういった開発プロセスをより効率的に実践し、品質の良いシステムを作り上げる目的がある。

なぜ「開発プロセス」が必要なのか？

Googleで「開発プロセス」とググってみると。
f:id:Mikiyakupo:20200813215403p:plain トップに表示されるコチラのサイトによると、

開発プロセスとはシステムを作り上げるために必要な工程のこと*1

品質の良いシステムを作り上げる上で、上記の開発プロセスは欠かせないもの。

ではシステムを作り上げる上で、「何故、要件定義や設計といった工程が必要なのか」。
と掘り下げてみると、

おそらく。。。

顧客や内部のチーム間での混乱を抑制するためなのだろう。
外部（顧客）から見ると、出来上がったものが望んでいるものでなければいけない。
また内部（開発者）から見た際に、これまでどのように計画され開発されてきたのか？といった情報がしっかりと把握されていなければいけない。

そういったソフトウェア開発において発生しうるリスクに対応しながら効率を求めた結果、開発プロセスが発展したのだろうと感じた。

そして、開発モデルもまた時代の変化に対応するため、開発プロセスをより効率的に回すように変化をしてきたと言える。

開発モデルの種類

開発モデルは先も挙げたように、開発プロセスをより効率的に実践していくため様々なモデルが作られた。

ウォーターフォールモデル

数ある開発モデルの中で、最も古くからあり、知名度のある開発モデルです。
ウォーターフォール（滝）という名の通り、先の開発プロセスを要件定義から順番に上から下に流れるように、開発を進めていく。

各工程で仕上げた成果を明確に文書として成果物として残すことで進捗を管理*2

どのようなものを作ったのか。をしっかりと明確にし勧めていき、原則前工程に戻ることはしません。

メリット

経験者が豊富である
ウォーターフォール型で開発してきたエンジニアは多くいます。
ノウハウがあることで対応がしやすいと言えます。
計画が立てやすい
先も挙げたように各工程で成果を仕上げて次に移るため、工程が区切りやすい。
そのため、流れが把握しやすく、今後どのように進んでいくのか想定しやすいのは大きなメリットかもしれないです。
また、工程ごとに成果物の請求を行えるため、資金繰りを行いやすいそう。
進捗管理がしやすい
先の計画が立てやすくなるだけでなく、開発要員の作業進捗が管理しやすいなども挙げられます。

デメリット

途中で仕様変更ができない（しづらい）
基本的にウォーターフォールでは前工程に戻らない。
そのためシステム開発の最終段階になってから、上流では想定されていなかった要望が判明することもある。
成果物作成による作業時間の増加
成果物として何かしらのドキュメント（要件定義書や基本設計書等）が無ければ、次の工程に進むことができない。
開発の規模に比例しドキュメント作成量が増え、プロジェクト期間が大幅に長くなる可能性がある。

どんなプロジェクトに向いているのか

ウォーターフォールモデルが採用されるのは、大規模開発の時が多い。
大規模開発では、多くの開発者が携わるため工程が明確に区切られ、全体を俯瞰しやすいウォーターフォールモデルが適用しやすい。

また、大規模開発となると作業工程が長期に渡る。
全ての工程が終わった段階で、費用の請求が膨大となり、もしイメージと違った場合のリスクが大きい可能性がある。
だが、各工程で請求を分けることが可能になる。

プロトタイプモデル（プロトタイピング）

プロトタイプ開発の目的は、端的に言うと「プロジェクトのリスクと費用の低減」にあります。*3

顧客に対して、試作品（プロトタイプ）を提示しながら開発をすすめる開発モデル。
プロトタイプモデルの大まかな流れは以下の通り。
（※上矢印がどうしても小さくなってしまった…）

1.要件定義
↓
2.プロトタイプ設計
↓ ↑（上矢印）
3.プロトタイプ評価
↓
4.設計
↓
5.製造
↓
6.テスト
↓
7.運用保守

プロトタイプを採用する目的は「リスクとコストの低減」が主である。
システム開発の経験が無い発注者と操作イメージや全体像を合わせてから実際に作成を始めるため、途中での仕様変更を軽減しやすい。

メリット

早期のイメージ共有によるリスク・コスト低減
先も挙げたように、早期でイメージの共有が行われるためその分手戻りが発生しづらい。
また開発に対する投資のリスクが減る。
開発者・発注者の対立の回避を高める
技術者同士どうしても自分の経験則などを参考にしてしまうことから、対立が発生しやすい。
事前にプロトタイプというベンチマークが設定されていることで、それぞれの意見や方法を比較反映させることができる。

デメリット

開発コストが高い
プロトタイプではあるが、ユーザー（発注者）に利用・評価してもらうため、ある程度の機能を作りこむ必要がある。
大規模開発には向いていない プロトタイプを作らなければならないので、当然のことながら大規模開発では非常に難しい。
仕様の確認に時間を取られ、結果として開発の効率が下がってしまう。
泥沼化し開発会社側の負担が大きくなる
プロトタイプをレビューごとに一回一回作り直すと、時間がかかり、調整などで開発会社側の負担が大きくなる。
また、発注者側によっては要求が重なり結果的にプロジェクトが泥沼化することがある。

どんなプロジェクトに向いているのか

大規模開発には向いていない。
中小規模開発あたりがプロトタイプモデルの出番といえる。

先輩が言うには、
パッケージ製品（Salesforceとか）の導入などによく採用されるそう。
あるシステムに予め出来上がっているモノを入れることでどうなるのか？という検証が手早くできるため、プロトタイプが採用しやすいそう。

スパイラルモデル（繰り返し型開発モデルの一つ）

要件定義→設計→実装→テストを繰り返し、リリースまで行くモデル。
前項のプロトタイプモデルに非常に似ているが少し違う。

スパイラルモデルでは、ソフトウェアをサブシステムで分割し、徐々にシステムを完成させていく。
このサブシステムごとにレビューを繰り返し（プロトタイプ）、システムを完成させる。

メリット

計画変更がしやすい
スパイラルモデルはサブシステムという小さな単位での開発を進めていく。
長期的計画を前提としていたウォーターフォールモデルでは、難しいスケジュール調整でした。
小さな単位かつ、しっかりとした成果物のイメージを完成させない所から、その分スケジュール調整がしやすいというわけだそう。
手戻りが発生しづらい
サブシステムごとにレビューを重ねていくため、早期に顧客との認識の相違に気づくことができ、改良することができる。

デメリット

ユーザー主導になりやすい
ユーザーに仕様変更の余地を与えるため、プロトタイプ同様にプロジェクトが泥沼化するリスクが有る。
コストの肥大化 全体像をサブシステムごとに分けるとは言っても、改良していくうちに、要求が重なり、結果初期想定よりコストが肥大化する恐れがある。

どんなプロジェクトに向いているのか

プロトタイプモデル同様に、中小規模の開発に向いていると言える。

ソフトウェア開発のプロセスモデルの一つであるスパイラルモデルに関する記述として，適切なものはどれか。
ア：基本的に後戻りが許されないので，要求仕様の変更に対応するには大きな工数を要する。
イ：システムの部分単位に要求定義・設計・プログラミング・テストを繰り返しながら開発するので，未経験分野のシステム開発に有効である。
ウ：全体の作業を幾つかのフェーズに分けて管理するので，最初から要求仕様が明白な場合に，最も効率的な方法である。
エ：要求仕様の変更のたびに機能分割と段階的な機能追加を繰り返すので，大規模システム開発に有効である。
平成16年春期問50 スパイラルモデルに関する記述｜応用情報技術者試験.com

この応用情報技術者の問題の答えは「イ」であるように、サブシステムごとに要件定義を重ねていくため、システム構成をきっちり決める大規模開発には向いていないと言えそうだ。

インクリメンタルモデル（繰り返し型開発モデルの一つ）

インクリメンタルモデルはスパイラルモデルと似ていて繰り返し型開発モデルの一つ。
同じようにシステム全体をサブシステムごとに分割する。

違う点は、
スパイラルモデルでは要件定義〜テストを繰り返し行っていくが、
インクリメンタルモデルでは設計〜テストを繰り返し行っていく。
要件定義は一回のみである。

最初に、システム全体の要件定義を行う。
その後サブシステムごとに分割し、コア部分となる部分のみを完成させる。
後はインクリメントで、サブシステムを徐々に繰り返し開発リリースして完成に近づけていく。

メリット

並行開発が可能
スパイラルモデルとは違い、一度要件定義を行ってしまえば後はサブシステムごとに開発を行ってしまえばいいので、
コア部分ができれば効率的な開発が見込める。
早期リリースが可能
早くサービス展開したいユーザーにとって、コア部分だけでもリリースできるというメリットがある。
後は段階的に展開していきたい場合にインクリメンタルモデルが採用できる。

デメリット

共通部分の開発を行ってしまう可能性がある
サブシステムを並行開発すると、共通部分までともに開発してしまう可能性があるため二重開発となり、保守性に影響が出てしまう可能性がある。
工程管理が複雑になる
ウォーターフォールモデルの並行開発版がインクリメンタルモデルみたいだが、
ウォーターフォールに比べて工程管理が複数重なるため複雑になる。

どんなプロジェクトに向いているのか

基本的にスパイラルモデルと似た中小規模と言えるかもしれない。

要件がしっかりと定義できているプロジェクト
ウォーターフォールの並行開発版のようなモノだと思われるので、「何をシステム化するのか」「どこをどう開発するのか？」という定義ができていないと採用しづらいかもしれない。
二重開発を避けるためにも、各開発をしっかり定義する必要がある。
段階的リリースを望むプロジェクト
インクリメントと名がついているだけあって、段階的にシステムを展開していきたいプロジェクトには採用しやすい開発モデルかもしれない。