0. はじめに
ウォーターフォール型のシステム開発について調べると、一般的には次のような工程が紹介されます。
要件定義 → 外部設計 → 内部設計 → 実装 → テスト → リリース
ただし、実際のシステム開発は、要件定義から突然始まるわけではありません。また、設計書やプログラムを作るだけでシステムが利用できるようになるわけでもありません。
この記事では、ウォーターフォール型開発について、実際の現場で何を行い、何に注意するのかという視点から説明します。
1.システム開発は要件定義より前から始まっている
ウォーターフォール型開発は、要件定義が突然始まる訳ではありません。
実際は要件定義に入る前には、営業活動があります。
一例として、要件定義の手前には次のような流れがあります。
- 業務の構想・業務設計
- システム化範囲の検討
- PoCによる技術検証
- ITベンダーや製品の選定
2.ウォーターフォールとV字モデル
ウォーターフォール型開発では、設計工程とテスト工程が対応しています。
この対応関係を表したものがV字モデルです。
要件定義 受入テスト(UAT)・並行稼働
\ /
外部設計 外部結合テスト・内部結合テスト
\ /
内部設計 単体テスト
\ /
実装
対応する工程や名称はプロジェクトによって異なりますが、考え方は共通しています。
- 各工程では直前の成果物をもとに作業する
- 前工程の成果物を承認してから次工程へ進む
- 設計工程で決めた内容を、V時モデルで対応するテスト工程で正しく実現できているかを確認する
3. 各工程の目的と実務上のポイント
3-1.要件定義
要件定義は、何をシステム化するのか、システムで何を実現するのかを明確にする工程です。
WHATに焦点を絞って整理します。
主な検討内容の例
- 現在の業務フロー
- システム導入後の業務フロー
- システム化する業務の範囲
- 性能や可用性などの非機能要件
- 他システムとの関係
BOMシステムの場合
BOMシステムでは、その会社特有のBOMの考え方や業務ルールを整理する必要があります。
例えば、次のような内容です。
- BOMにどのようなバリエーションがあるか
- 製品/部品/工程の特徴
- 設計BOMと製造BOMの違い
- 品番変更や構成変更の登録方法(差分を登録 or 変更後の構成を登録)
3-2.外部設計
外部設計は、会社やプロジェクトによって、次のような名称で呼ばれることがあります。
- 外部設計
- 基本設計
- 論理設計
共通する考え方は、要件定義で決めた内容を、顧客が確認できる仕様に具体化することです。
画面単位/機能単位で何を実現するかのWHATを合意するのが目的なので、顧客に伝わる概念で設計書を記載することが重要です。
BOMシステムの場合
設計BOM/製造BOMという概念に対しての処理は記載しますが、具体的なテーブル名は記載しません。
設計書の読者を意識し、業務担当者に伝わる表現を使う必要があります。
3-3.内部設計
内部設計は、次のような名称で呼ばれることがあります。
- 内部設計
- 詳細設計
- 物理設計
内部設計の目的は、外部設計で決めた仕様を、開発者が実装できるレベルまで具体化することです。
どのように実装するかのHOWを設計するフェーズです。
理想としては、実装者が設計者へ質問しなくても、設計書をもとに同じ品質で実装できる状態を目指します。
注意点:物理名へ置き換えるだけでは内部設計とは限らない
現場によっては、外部設計書に記載された論理名を物理名へ変更したり、論理名で書かれたSQLを物理名へ書き換えたりする作業が、内部設計と呼ばれることがあります。
しかし、それだけではどのように実装するかを設計した事にはならないので、本来の内部設計として十分とは限りません。
案件ごとに設計書の粒度は異なりますが、その違いを理解したうえで「本来何を設計するための工程なのか」を考えることが大切です。
3-4.単体テスト設計――仕様をどのように確認するかを決める
実装に入る前後で、単体テスト仕様書を作成します。
単体テスト仕様書は、設計書で定めた仕様が正しく実現されているかを、どのような入力と期待結果で確認するかを定義する資料です。
ブラックボックステスト
画面や機能仕様を確認するテストでは、主にブラックボックステストの考え方を用います。
ブラックボックステストでは、プログラムの内部構造ではなく、画面やDBなどの外部から見える仕様をもとにテストします。
3-5.実装
実装工程では、内部設計をもとにプログラムを作成します。
実装工程の目的は、単に各担当者が動くプログラムを書くことではありません。
プロジェクトに参加する複数の開発者が、一定のルールに従って、同じ水準の品質でプログラムを作ることです。
チームで統一すべきルール例
- 命名規則
- コーディング規約
- クラスやメソッドの分割方針
- 共通部品の使用方法
- エラー処理
- 例外処理
- SQLの書き方
3-6.単体テスト
単体テストでは、画面、バッチなどの機能単位で、単体テスト設計書どおりに動作するかを確認します。
テスト実施では、単に「動きました」「問題ありませんでした」と報告するだけでは不十分です。
テストを実施していないレビュー担当者や顧客が見たときに、期待結果どおりであることを客観的に判断できる証跡を残します。
例えば、次のような証跡です。
- 画面の実行前後のスクリーンショット
- データベースの更新前後の値
- メールの宛先、件名、本文
- ログ
3-7.内部結合テスト――機能を業務の流れとしてつなげる
内部結合テストでは、複数の機能をつなぎ、業務の流れとして正しく処理できるかを確認します。
単体テストとの違いとして、
単体テストでは、その機能を確認するために、データベースへ直接データを登録することがある一方で、
内部結合テストでは、画面や外部IFなどの実際の運用に近い経路でデータを作成します。
また、内部結合テストでは、業務シナリオを作成して確認します。
例えば、次のような流れです。
- 製品情報を登録する
- 設計BOMを登録する
- 設計BOMから製造BOMを作成する
- 必要なデータを他システムへ連携する
可能な限り、顧客から提供されたマスタデータや、本番に近いデータを使用して確認するのが理想です。
3-8.外部結合テスト
外部結合テストでは、自分たちが開発したシステムだけでなく、他のシステムと連携した状態でテストします。
例えば、周辺には次のようなシステムが存在することがあります。
- SAPなどの基幹システム
- 既存の販売管理システム
- 倉庫管理システム(WMS)
外部結合テストでは、システム単体ではなく、システム同士をつないだ全体のつながりが問題ないかを確認します。
3-9.受入テスト――お客様が業務で使えるかを判断する
受入テストは、UAT(User Acceptance Test)とも呼ばれます。
それまでのテストは、主に開発ベンダー側が実施します。
受入テストでは、顧客が主体となり、実際の業務で使用できるシステムになっているかを確認します。
受入テストで起こりがちな問題
受入テストで、
- 現場が求めていたものと違う
- その部署には説明されていない
- 実際の業務では使えない
- 必要な機能が不足している
といった問題が初めて発覚すると、大きな手戻りになります。
これを防ぐため、要件定義や外部設計では、特定の担当者だけでなく、関係する部署や現場担当者とも認識を合わせることが重要です。
3-10.本番稼働リハーサル・並行稼働
受入テストが完了した後、カットオーバー(本稼働)の前に、本番環境に近い状態で実際の業務を一通り実施することが多いです。
目的は、プログラムの動作だけでなく、業務、運用、データ、担当者の動きまで含めて確認することです。
システムの利用頻度によって方法は変わる
販売管理システムのように、毎日大量の受注を処理するシステムでは、1日分の業務をまとめて新システムでテスト実施する日を設けることがあります。
一方で、BOMシステムやEDIシステムのように、毎日入力が発生するわけではないシステムでは、2週間や1か月などの一定期間で並行稼働を行います。
旧システムと新システムの両方へ同じ入力をして、新旧システムの結果を比較します。
3-11.カットオーバー(本稼働)
カットオーバーとは、旧システムから新システムへ正式に切り替え、本番稼働を開始することです。
カットオーバーでは、例えば次の作業を行います。
- 旧システムの利用停止
- 本番データ移行
- 外部システム連携の切り替え
- 問題発生時の切り戻し判断
4. 開発と並行して進む活動
4-1.マスタ移行
データ移行やマスタ移行は、ウォーターフォールモデルには登場しないですが、
実際にはシステム開発に大きく影響する作業です。
理解度テスト
ウォーターフォール型システム開発プロセスの理解度テストを別ページに作成したので、試してみてください!
新人向け:ウォーターフォール型システム開発プロセスの理解度テスト
参考資料
令和05年【春期】【秋期】 応用情報技術者 合格教本 情報処理技術者試験
エンジニアが学ぶ生産管理システムの「知識」と「技術」
ウォーターフォールとは?~各工程について解説~
