日本でシステム開発を行う場合、多くの場合は「ウォーターフォールモデル」と呼ばれるプロセスに従って開発を進めます。
ウォーターフォールモデルを知ることで、各々の工程を何のために行うのかを考えることができるようになります。
システム開発作業に参画する際は、ウォーターフォールモデルについて知っていることが望ましいです。
ウォーターフォールモデルでは、実際にプログラムを作るまでは「要件定義（基本計画）」→「外部設計（基本設計）」→「内部設計・プログラム設計（詳細設計）」→「プログラミング（製造）」といった工程を踏みます。
ユーザの要求からスタートし、段階的に詳細化しシステム化の方針を決めるといった形で、トップダウンで開発を行います。
プログラムを作り終えてからは、「単体テスト(UT)」→「結合テスト(IT)」→「システムテスト(総合テスト、ST)」→「運用テスト(UAT)」といった工程を踏みます。
バグ頻発でテスト進行が妨げられることを防ぐために、細かい箇所からテストを行い徐々に統合するという形で、ボトムアップで開発を行います。
開発工程とテスト工程は、以下のように連関しています。
プログラミングの内容は単体テスト、内部設計・プログラム設計の内容は結合テスト、外部設計の内容はシステムテスト、要件定義の内容は運用テストで検証します。
これをＶ字モデルと呼びます。
誤りを修正する場合、後の工程になるほど手戻り工数が増え、修正コストが増大します。
最悪なのは、リリース後に誤りが発見され、修正の必要が生じた場合です。
そのため、手戻りは原則として行わず、各々の工程を順番にこなしていくことが理想です。
（水が流れるように順番に工程をこなすことから、「ウォーター（水が）フォール（流れ落ちる）」と呼ばれるようになりました）
手戻りを防ぐためには、レビューを強化する等し、ある工程で埋め込んだ誤りはその工程の中でできる限り解消することが重要になります。
仮に後の工程で誤りが発見された場合は、その誤りについてなるべく早い段階で例外的に前工程に戻り、その誤りの修正に関わる要件・設計・実装を見直すことが重要になります。
大規模かつミッションクリティカルなシステム開発では特にこの原則を守ることが重要となります。
以下は東証のシステム更改の例で、前工程への手戻りを正式にプロセスに組み込むことで手戻り工数を削減する「フィードバック型Ｖ字モデル」が採用されました。
http://ac.nikkeibp.co.jp/cn/xdev10/pdf/10907-xdev-A-1.pdf
また、実現性が疑わしい箇所について開発開始前にプロトタイプを作成し、実現性をあらかじめ検証するという手法も使われます。
プロトタイプを作ることで、開発開始時に実現性の問題が出て手戻りが発生することを防ぐことができます。
（このような事前検証は「POC」と呼ばれることもあります）
ざっくりまとめると、先が見える場合は１つ１つの作業を確実にこなす、先が見えない場合は先回りして視界を良好にする、という姿勢がプロジェクトを円滑に進める上で重要になります。
いかがでしたでしょうか。
私も１～２年目だった頃は、手戻りのリスクを考えずに猪突猛進に作業を進めて、結局手戻りして先輩に迷惑をかけたことがあります。
若手なら先輩に迷惑をかける程度で済みますが、リーダーや管理者の立場で同じことをすればプロジェクト全体の進捗に影響してしまいます。
ウォーターフォールモデルはシステム開発のプロセスとしては基本的なものですが、基本だからこそないがしろにしてはいけないと思っています。
単純に各工程の名前と作業内容を覚えるだけでなく、その背景にある理念も含めて理解する必要があると思っています。
それではまた次回！