開発モデル

後戻りしないからこそ、承認が要る

後戻りしない前提なので、次に進む前に確実に固める必要があります。そのための仕組みが、ドキュメント化と承認です。

⑤ 位置づけ

長年多くのシステム開発プロジェクトに採用されてきた基本的なモデルです。

前節で学んだ6工程は、まさにこのモデルの工程です。他のモデルも、このモデルとの対比で説明されることが多くあります。

⑥ メリット

ウォータフォールモデルには、以下のようなメリットがあります。

⑦ なぜ管理しやすいのか

「いま全体の何%が終わったか」が言える——これが管理しやすさの中身です。

⑧ 大規模開発に向く理由

第10章で学ぶプロジェクト進捗管理の手法は、このモデルを前提にしたものが多くあります。

⑨ デメリット

ウォータフォールモデルには、以下のようなデメリットがあります。

⑩ 2つのデメリットの構造

どちらも「後戻りしない」という前提から生じています。

⑪ 前節の手戻り費用とつなげる

前節で見たとおり、工程が進むほど手戻りの費用は大きくなります。

ウォータフォールモデルでは、上流の欠陥がテスト工程まで発見されません。つまり、もっとも費用のかかる段階で見つかることになります。

これが最大の弱点であり、後続のモデルが解こうとした問題です。

⑫ どんな場合に向くか

「何を作るかが最初から分かっている」ことが前提——この条件を満たせるかどうかが、選択の分かれ目です。

建築では当たり前のこの進め方が、システム開発でも長く使われてきました。

ただし、建築とシステムには違いがある

2つ目と3つ目が、システム開発特有の事情です。だからこそ、後戻りを許す他のモデルが生まれました。

大規模プロジェクトでウォータフォールが選ばれる理由

100人が関わるプロジェクトを想定します。

4つ目が実務上重要

外部に発注する場合、「どこまでできたら、いくら支払うか」を決める必要があります。工程が明確に区切られていれば、契約も区切りやすくなります。

アジャイル開発では、この区切りが難しくなります。第10章で学ぶ見積りの問題とも関わる論点です。

中小企業でのウォータフォール

「何を作るか分かっているか」を最初に問う

診断士としての助言

「いきなり全部作ろうとしない」——これが、中小企業への助言として実務的です。

確認してみましょう

> 次の記述の正誤を判定せよ。

> a　ウォータフォールモデルでは、各工程での成果をドキュメントにまとめ、ユーザ企業の承認を得てから次の工程へ進む。

> b　ウォータフォールモデルは、工程の後戻りがあるため、スケジュール管理が困難である。

> c　ウォータフォールモデルでは、上流工程で欠陥があってもプロジェクトの終盤まで発見できないことがある。

解答　a：○　b：×　c：○

• b：×……工程の後戻りがないため、スケジュール策定やそれに基づく管理が比較的行いやすいというのがメリットです。

④ このモデルが解こうとした問題

このような試行錯誤を繰り返すことで、ユーザの満足するシステムを開発することができます。

ウォータフォールモデルのデメリットと対比すると、狙いが明確になります。

⑤ なぜ「動くもの」が必要なのか

「こういうものだと思っていた」という認識のずれは、動くものを見るまで表面化しません。

人は、見たことのないものを正確に想像できない——プロトタイプモデルは、この人間の限界を前提にした進め方です。

⑥ デメリット

なお、比較的小規模なシステムの開発に限定されるなどのデメリットがあります。

⑦ なぜ小規模に限られるのか

⑧ ウォータフォールモデルとの比較

⑨ 第8章とのつながり

第8章で学んだノーコード・ローコードは、プロトタイプを素早く作る手段として有効です。

試作品を作る費用が下がれば、プロトタイプモデルを採用しやすくなります。近年、この進め方が広がっている背景には、こうした道具の発達があります。

⑩ 実務での使われ方

プロトタイプモデル単独で使われることは、現在では多くありません。ただし、プロトタイピングという技法は、さまざまな場面で使われます。

「動くものを早く見せる」という考え方そのものが、その後の開発モデルに引き継がれた——こう捉えると、このモデルの位置づけが分かります。

③ 進め方

④ イメージ

各サブシステムが、設計から評価までの一巡を回る——この繰り返しが、らせん（spiral）のように見えることが名前の由来です。

⑤ リスク管理という特徴

各開発サイクルの開始時にはリスク分析の評価を行うなどリスク管理を行う点に特徴があります。

なぜリスク分析なのか

サブシステムごとに区切って進めるため、次にどのサブシステムを開発するかを選べます。

「危ないところから手をつける」——これがリスク管理の考え方です。

⑥ プロトタイピングの適用

また、スパイラルモデルは、プロトタイピングを適用することが多くなっています。

各サイクルで、前のテーマで学んだプロトタイピングの技法が使われます。

⑦ メリットとデメリット

ウォータフォールモデルと同様に設計から評価への方向性を一連のサイクルとして開発するため、工程全体の見通しをある程度立てることができますが、ウォータフォールモデルと比べるとプロジェクトの管理はしにくくなります。

⑧ 3つのモデルを並べる

⑨ スパイラルモデルの位置づけ

プロトタイプモデルの良さを、大きな規模でも使えるようにした——これがスパイラルモデルの立ち位置です。

⑩ 試験での問われ方

令和4年度の本試験では、次の記述が出されました。

> スパイラルモデルは、システムを複数のサブシステムに分け、基本となるサブシステムをまずウォータフォールモデルの方法で開発してユーザに試用してもらい、その結果を反映させて次のサブシステムを開発することを繰り返していくモデルである。

解答：○

「複数のサブシステムに分ける」「ウォータフォールモデルの方法で開発」「繰り返す」——3つの語がそろっているかを確認します。

⑪ 第8章のローコードで見た設例

第8章で、次の設例を見ました。

> ローコード開発では、システムの全体像をモデル化し、優先度を付けた機能単位で計画、設計、構築を反復的に行う。

> 解答：×（アジャイル開発またはスパイラルモデルに関連する内容）

「優先度を付けた機能単位で反復的に行う」——これがスパイラルモデルやアジャイル開発の特徴です。ローコードは記述量の話であって、進め方の話ではありませんでした。

少しずつ積み増していく——この性格が名前になっています。

③ 利点

この手法により、システム全体が完成する前から部分的に利用が可能となり、ユーザからのフィードバックをもとに素早く改良を加えることができます。

④ スパイラルモデルとの違い

スパイラルモデルは、要件定義からテストまでを一連のサイクルとして繰り返すのに対し、インクリメンタルモデルでは最初にシステム全体の要件定義を定めた後に、各インクリメントで設計からテストまでを段階的に進めます。

要件定義を最初にまとめてやるか、各回でやるか——これが決定的な違いです。

⑤ アジャイル開発との違い

また、アジャイル開発は短いサイクルで開発を進め、各サイクルで要件や設計が変わる可能性がありますが、インクリメント開発では全体の要件や設計が最初に決まっていることが多くなっています。

⑥ 4つを「要件をいつ決めるか」で並べる

上から下へ行くほど、変化を受け入れる度合いが高くなります。

⑦ インクリメンタル開発が向く場面

⑧ 「部分的に利用が可能」ということの価値

投資の観点から見ても意味があります。1年かけて作るシステムでも、3か月目から一部が使えれば、9か月分の効果が前倒しになります。

⑨ 4つのモデルをまとめる

⑩ 選ぶ基準

「どれが優れているか」ではなく「どの条件に合うか」——モデルの選択は、この判断です。