V字モデルと各工程の概要

これまでの記事ではIT業界の仕事以外にも応用できる汎用的なソフトスキルを解説した。
しかし、IT業界でソフトスキルを活用するには、IT業界特有のプロセスを理解する必要がある。

IT業界で最も一般的に用いられているプロセスは、ウォーターフォールと呼ばれるプロセスモデルである。
今回の記事では、ウォーターフォールについて、そのプロセスの概要を端的に表したV字モデルを用いながら簡単に説明する。

(1)V字モデルを用いたウォーターフォールの概要の説明

ウォーターフォールは、一つ一つの工程を順番通りに着実にこなすことに特徴があるプロセスモデルである。

ウォーターフォールでは、実際にプログラムを作るまでに、以下の順番で工程を踏む。
曖昧な要件から、具体的な設計まで、順番に落とし込んでいくイメージである。

• 要件定義（「RD」とも呼ばれる）

• 基本設計（「BD」や「外部設計」とも呼ばれる）

• 詳細設計（「DD」や「内部設計」、細かいものは「プログラム設計」とも呼ばれる）

上記の工程を踏むことで何を作るのかが明確になるので、次に「製造」と呼ばれる工程でプログラムを作成する。
（「コーディング」や「プログラミング」とも呼ばれる）
そのプログラムに対しては、レビューが行われることが一般的である。

その後、以下の工程を踏むことで、品質を担保する。
細かい所の品質を担保した後、全体を通して要件通りであるかどうかを確認するイメージである。

• 単体テスト（「UT」や「ユニットテスト」や「単体試験」とも呼ばれる）

• 結合テスト（「IT」や「結合試験」とも呼ばれる）

• システムテスト（「ST」や「総合テスト」や「総合試験」とも呼ばれる）

先に挙げた工程と結びつけると、「単体テスト」は「詳細設計」の内容、「結合テスト」は「基本設計」の内容、「システムテスト」は「要件定義」の内容を検証するイメージである。

ここまでの内容を図に表すと以下のようになる。
工程の対応関係がV字に見えることから、以下のような図は「V字モデル」と呼ばれている。

図1-1：ウォーターフォールのV字モデル

ウォーターフォールの利点は、一つ一つの工程の品質が良く手戻りがない場合に計画を立てやすくなることにある。
ITのシステム開発では、「発注者が要件を明確に伝えられていない」「技術的な問題で全体として不整合が出る」等の理由で手戻り（作り直し）が発生することが多く、このことが計画の立てにくさに繋がっているが、一つ一つの工程で品質を作りこむことで、このような問題を回避できる。

ウォーターフォールの利点は「一つ一つの工程で品質を作りこめば、実際にシステムを作る中で不測の事態が発生しなくなり、手戻りを回避できる」ということを前提にしているが、この前提はシステム開発に携わる人々に全知全能が備わっているかのようなものであるため、非現実的とも言える前提をおいていることがウォーターフォールへの主な批判材料となっている。
とはいえ、技術的に予見可能性が高いシステムの開発ではこの前提に近い状況になること、日本のシステム開発では今でもウォーターフォールが主流であること、ウォーターフォールの問題点を理解することが他のプロセスモデルの理解に繋がることを考えると、ウォーターフォールについて理解することは現在においても有効であると言えるだろう。

また、ウォーターフォールの問題点については、実際のプロセス運用では以下の方針で対策が取られることも多く、合わせて覚えておくと良いだろう。

• 工程の先取り
  「要件が不明確」「未検証の技術の利用」といった、手戻りに繋がる可能性が高い機能に関しては、その機能のみ先に試作することで、不明確・未検証の部分を解消し、後工程で手戻りが発生する可能性を軽減する。

• 工程の後戻り
  前工程が原因となる不良が多発した機能については、その機能に対して前工程のやり直しを行い前工程の品質を固めることで、現工程や後工程で不良が頻発する事態を回避する。

(2)各工程の概要の説明

ウォーターフォールで定義されている各工程について、概要を説明すると以下の通りである。

• 要件定義
  発注者の要件を明確にまとめることで、開発者が開発するべきシステム（ゴール）を定義する工程。
  発注者の要望をヒアリングし、それを明確化・細分化し、ドキュメントにまとめ上げ、発注者と開発者の間で合意を取る作業が必要となる。
  

• 基本設計
  要件定義に基づき、システムの外装的な設計を行う工程。
  適用する技術、機器の構成、機能の分割とフローの作成、データの構造の定義、画面や帳票のレイアウト定義、といった作業を行う。
  

• 詳細設計
  基本設計に基づき、システムの内部的な設計を行う工程。
  一つ一つの設定やプログラムで何を行うのかを明確に記述し、製造可能な状態とする。
  

• 製造
  プログラムの実装を行う工程。
  詳細設計で作成した設計書に基づいて実装を行う。
  

• コードレビュー
  プログラムのソースコードに対して、第三者が机上で確認を行うことで品質の担保を行う工程。
  製造に対応している。
  

• 単体テスト
  単独のプログラムを対象とした試験。
  詳細設計に対応している。
  あるプログラムから別のプログラムを呼び出すことがあるが、どちらかのプログラムが未完成の場合は「スタブ」や「ドライバ」といった仮のプログラムが使用される（現場によっては「モック」とも呼ばれる）。
  「スタブ」は呼び出し先のプログラムに相当する仮のプログラムであり、「ドライバ」は呼び出し元のプログラムに相当する仮のプログラムである。
  

• 結合テスト
  あるプログラムから別のプログラムへの呼び出しの箇所の担保を取ることに着目した試験。
  基本設計に対応している。
  

• システムテスト
  プログラム等の改修を行ったシステムについて、システム全体の挙動を確認する試験。
  要件定義に対応している。
  他システムとの連携についても、この段階で行うことが多い。