みなさん、業務システム開発に関わったことはありますか？
この業務システム開発ですが、日本は海外に比べて特殊な構造になっていると感じます。
業務システムは企業の根幹を担う部分であり、AIの社会実装を考える場合、この現状を理解することは非常に重要だと言えるでしょう。
日本のIT業界は一般的に「ウォーターフォール開発」という手法で開発しています。
実はこの手法、多くの問題を抱えています。
下記のような絵をみたことはありますか？
一度でも業務システム開発に関わったことがある方は、非常に共感できるイラストではないでしょうか？
「日本のIT業界の特殊な構造」と「ウォーターフォール開発」は上記イラストのような問題が起こりやすい構造だと感じます。「能力や教育が足りない」「仕事の仕方に問題がある」と言う方々もいらっしゃいますが、「人間は完璧な生き物でない」という前提に立っていない気がします。つまり、仕組や構造の問題ですね。
業務システム開発にAIを導入するにあたり、この構造を変えず、要件定義と基本設計という「上流工程」と呼ばれるもののみ人が行い、詳細設計や実装、テストなどの「下流工程」はAIが行う…みたいな夢を持っているITベンター様は多いのではないでしょうか？
私の考えでは、業務システム開発において、このようなAIの使い方は…多分うまくいかないだろう…効果が出たとしても限定的だろう…と考えています。
その理由についてはここでは語りつくせないので次回以降にいたします。
とはいえ、「ウォーターフォール開発」が長年運用され、頭のいい多くの人たちが何度も考えて整理し、今のような具体的な開発手法になっています。
そう考えると、学ぶことも多いと思います。
「故きを温ねて新しきを知る」という言葉があります。
まずは、「日本のIT業界の特殊な構造」と「ウォーターフォール開発」のうち「ウォーターフォール開発」のお話をいたします。
ほぼ自分の頭の整理のために書いていますので、非常に長く退屈な話になるかと思います。読み疲れたら「なんか面倒そう」という感想だけ持ち帰り、その時点で閉じてしまっても全然問題ありません。
もし、間違いや異なる意見がありましたら、ご意見、ご指摘下さい！
注意！！アジャイルについて話し出すと議論が変な方向に行き、非常に荒れそうなので、ここでは厳禁で！
💻 ウォーターフォール開発とは？ 🖥
日本のIT業界の特殊な構造を考えるにあたり、まずひとつのキーワードがあります。業務システム開発の現場でよく耳にする言葉で、「ウォーターフォール開発」というものがあります。これは開発工程を 上流から下流へ順番に進めていく開発手法で、原則として前の工程に戻らない前提で管理します。つまり、「最初に全部決めてから、順番に作る方法」ということです。日本の多くの業務システム開発は、この枠組みを前提に語られることが多いといえます。
そのウォーターフォール開発ですが、、1970年にアメリカの技術者ウィンストン・ウォーカー・ロイスがソフトウェア開発の進め方を整理した論文が原点とされています。
当時の開発環境はメインフレーム中心で、修正ややり直しのコストが高く、一度進めた工程を戻すことが容易ではありませんでした。そのため、まず必要な仕様を定め、それをもとに設計を固め、設計に従って実装し、最後に全体を検証するというように、段階的に進める考え方が合理的とされました。
この進め方は、当時すでに一般的だった大規模な物理プロジェクトの管理手法と発想が近いものでした。機械工学や土木・建設の分野では、設計が固まらないまま施工に入ることは大きなリスクになります。
変更には多大なコストがかかるため、上流で十分に検討し、順序立てて進めることが安全でした。ソフトウェア開発も当時は同様に「やり直しが高コストなプロジェクト」と捉えられており、そのため段階的に固めて進めるモデルが自然な選択となったのです。
💻 ウォーターフォール開発の流れ🖥
ウォーターフォール開発では、プロジェクト全体をいくつかの工程（フェーズ）に分け、それぞれを順番に進めていきます。前の工程の成果をもとに次の工程へ進むという、段階的な進め方が特徴です。
一般的には、次のようなフェーズで構成されます。
【要件定義】
どのような目的で、どのようなシステムを作るのかを整理する段階です。
現場へのヒアリングを行い、必要な機能や業務フロー、制約条件などを文書化します。この段階では「何を作るのか」を明確にすることが目的です。
【基本設計 / 外部設計】
要件定義で整理した内容を、システムとしてどのような形で実現するかを具体化する段階です。利用者の操作方法や業務の流れ、データの扱い方などを整理し、「システムとしてどう振る舞うか」を定義します。
【詳細設計 / 内部設計】
基本設計で定めた振る舞いを、実際に構築できるレベルまで分解する段階です。処理の手順やデータ構造、モジュールの分割方法などを明確にし、実装者が迷わず作業できる状態に落とし込みます。
【製造 / 実装】
詳細設計に基づいて実際にプログラムを作成します。設計書どおりに構築することが基本原則になります。
【単体テスト】
作成したプログラム単位で動作確認を行います。想定どおりの入力に対して正しい結果が出るか、エラー処理が機能するかなどを検証します。
【結合テスト】
複数のプログラムを組み合わせ、データの受け渡しや処理の流れが正しく動くかを確認します。インターフェース不整合や連携ミスを洗い出します。
【システムテスト】
システム全体として、要件定義で定めた内容を満たしているかを検証します。
業務シナリオに沿った総合的な確認を行います。
【受入テスト / UAT】
発注者や利用部門が実際の業務観点で最終確認を行います。
「業務として問題なく使えるか」を判断する工程です。
ここを通過すると正式に受け入れ（検収）となるケースが多いです。
【本番導入・運用】
実際の業務環境で稼働を開始し、運用・保守を行います。
障害対応や改善対応もこのフェーズに含まれます。
💻 要件定義 で行う事と成果物🖥
ここでは、要件定義で実施する検討項目と、その成果物の全体像を整理します。項目は(1)〜(12)までのテーマごとに、【やること】と【成果物】の２つの構成とし、何を決め、何を残すのかを明確にします。
(1) 体制・意思決定の整理 （誰が決めるかを確定）
【やること】
関係者（業務部門・情シス・監査/法務・連携先など）を特定し、役割と意思決定ルートを決める。合意の形式（サイン/稟議/議事録承認）も決める。
【成果物】
・関係者一覧（連絡先・役割・関心事・影響度）
・体制図／会議体一覧（定例、ステコミなど）
・役割分担表（RACI等でも可：誰が責任者かを明示）
※ステコミ：ステアリングコミッティの略。組織内で大きな影響力を持つメンバーで構成される委員会など
※RACI（レイシー）：プロジェクトや何らかの工程をチームあるいは人々に役割分担させる際に使用される図の一種
(2) 目的・前提・制約の確定 （プロジェクトの土台を固める）
【やること】
目的、成功条件、前提条件、制約（期限・予算・利用環境・法規等）を言語化してズレを潰す。
【成果物】
・目的・背景・課題の整理（1〜2枚でも可）
・前提条件／制約条件一覧
・用語集（業務用語・システム用語）
(3) スコープ確定 （やる／やらないを明文化）
【やること】
対象範囲（業務・組織・機能・データ・期間）と、対象外を決める。段階導入（Phase分け）と優先順位も置く。
【成果物】
・スコープ定義（対象／対象外、境界、優先順位）
・フェーズ分割案（Phase1/2…）
(4) 現状業務（As-Is）の可視化 （暗黙知の掘り起こし）
【やること】
現場の手順、例外処理、手作業、締め・ピーク、帳票、責任と権限などを洗い出す。
【成果物】
・As-Is業務フロー（業務手順・入出力・担当・判断点）
・業務ルール一覧（例外含む）
・現状課題／不具合／暫定運用の棚卸し
(5) あるべき業務（To-Be）の定義（業務として何を変えるか）
【やること】
改善後の業務の流れ・責任分担・運用方法を定義する（“システムの前に業務”）
【成果物】
・To-Be業務フロー
・運用シナリオ（業務としてどう回すか）
(6) 機能要件の定義 （何ができれば業務が回るか）
【やること】
業務を実現するために必要な機能を、漏れない粒度で定義する（シナリオ→機能分解）
【成果物】
・業務シナリオ／ユースケース
・機能一覧（機能分解）＋優先順位
・画面・帳票・通知・バッチの「要求一覧」（必要性と範囲まで。詳細は設計へ）
※ユースケース：顧客や利用者が、ある業務やサービスをどのような目的で、どんな流れで使うのかを整理した“利用シナリオ”のこと。
(7) データ要件の定義（データの“正”を決める）
【やること】
主要データ、マスタ／トランザクション、ID体系、履歴の考え方、データの正（どこがマスタか）を決める。
※マスタ（データ）：業務運用の基盤となる“恒常的な基礎データ”を指す。顧客・商品・社員など、各種取引や処理の前提となる情報を保持し、頻繁には更新されない。
※トランザクション（データ）：日々の業務活動によって発生する“取引・処理の記録”を指す。受注、売上、在庫移動など、業務の動きを時系列で蓄積していく。トランザクション管理という別の意味の言葉もあるので注意！
【成果物】
・データ要件（主要エンティティ、ID体系、保持・履歴方針、データの正）
・データ項目の要求レベル定義（必須／任意、意味、粒度）
※エンティティ：業務上「管理すべき対象」をひとまとまりの情報として扱うための概念。顧客、商品、注文など、業務プロセスの中で独立して存在し、識別でき、属性を持つ“データの単位”を指す。
(8) 外部連携要件の定義 （責任分担まで握る）
【やること】
連携先・方式・頻度・データ粒度・失敗時の扱い（再送／手動／検知）・責任境界を決める。
【成果物】
・外部連携一覧（連携先、方式、頻度、データ粒度）
・連携失敗時運用（検知・再処理・責任分界）
(9) 非機能要件の定義 （品質・技術・移行・運用）
【やること】
下記成果物を“非機能要件”として整理し、目標値（または暫定値）と具体事項、未確定なら「決め方（PoC/設計で確定）」まで合意する。
【成果物】
・品質要件（性能・可用性・信頼性など）
・セキュリティ要件（認証認可・監査ログ等）
・技術要件（環境・標準・制約）
・移行要件（移行対象・切替方針）
・運用要件（監視・障害対応・権限運用）
上記の指標・目標値（確定 or 暫定）／未確定項目の確定手順（PoCで測定等）
(10) 受入条件 （検収の骨格）
【やること】
「何ができたらOKか」を、業務シナリオと観点で定義する
【成果物】
受入条件（受入観点、重要シナリオ、重要帳票、重要連携、合否基準）
(11) 変更管理ルール （“要件定義にないもの”の扱い）
【やること】
仕様変更の受付、判断者、影響評価（費用・納期）、合意方法、再見積りのタイミングを決める。
【成果物】
・変更管理手順（ワークフロー）
・変更要求票（フォーマット）
(12) 各種合意の証跡
【やること】
決定事項・未決事項・宿題・担当・期限を確実に記録として残し、確認・承認を取る。
【成果物】
・議事録（決定／未決／ToDo／担当／期限）
・決定事項一覧
・課題・未決事項一覧
要件定義に書かれていることが「業務で使う全ての機能」という前提になりがちで、そこでお金も見積もられますので、当たり前すぎて書き忘れていた…があると大きな問題に発展する可能性があります。
要件定義の問題は下流に全て凝縮されますので、要件定義だけする会社はぶん殴りたいです…（失礼！）
💻 基本設計 / 外部設計で行う事と成果物🖥
会社によって差異がありますが、ここでは一般的な 内部設計＝実装可能な粒度まで落とす工程として扱います。工程名の呼称が組織で異なる点はIPAでも指摘されています。
(1) 要件定義との整合確認
【やること】
要件定義書を読み直し、設計に落とす前提のブレ／未決事項／矛盾を潰す
【成果物】
• 要件確認結果
• 未決事項／確認事項一覧（質問・回答ログ）
• 要件トレーサビリティ
（要件→基本設計項目の対応表：簡易でも可）
(2) 利用者・運用者・権限の具体化
【やること】
ユーザー種別（業務担当、承認者、管理者、運用者など）と、画面・操作・データへのアクセス範囲を決める。
【成果物】
• ロール定義（業務システム運用時の役割一覧）
• 権限制御方針（ロール別に出来る／出来ないこと）
• 画面・機能と権限の対応表
(3) 利用シナリオを機能仕様として整理
【やること】
要件定義で整理された業務フロー／ユースケースを前提として、システムで必要な機能要件を整理し、利用者視点でどんな機能が必要かを明確にする。
【成果物】
• 主要ユースケースに対応した機能リスト
• 各機能の入出力・前提条件・例外仕様
• 画面遷移図／画面フロー
(4) 画面仕様（UI）を確定（入力・表示・操作・エラーの仕様化）
【やること】
画面ごとに、入力項目・表示項目・操作（ボタン）・バリデーション・エラーメッセージ・一覧/検索条件などを決める。
【成果物】
• 画面一覧
• 画面仕様書（項目、入力制約、イベント、表示ルール、例外）
• 画面モック／ワイヤーフレーム（必要に応じて）
(5) 帳票・出力（PDF/CSV/集計）を確定
【やること】
帳票・データ出力について、必要な種類、レイアウト要件、集計粒度、出力条件、締め基準、出力タイミングを決める。
【成果物】
• 帳票一覧
• 帳票仕様書（項目、並び、集計、条件）
• CSV/データ出力仕様（項目定義、フォーマット）
(6) データモデル設計（ER モデル）
【やること】
主要データ（マスタ／トランザクション）を整理し、画面・帳票・外部連携で支障なく扱える形に定義。エンティティや主キー、関連関係、履歴の考え方を明確にし、各項目の意味や必須性などを定め、論理データベース設計を確定。
【成果物】
• データ項目定義（データ辞書）
• 論理データモデル（論理ER、主キー・外部キー定義を含む）
• CRUDマトリクス（画面／機能 × データ）
※ER モデル：業務で扱うデータとその関係を図で表した設計図。データの構造とつながりを表す。
※CRUD：Create（作成）・Read（参照）・Update（更新）・Delete（削除）の頭文字を取ったもので、データに対する基本操作を指す。どの機能がどのデータにどの操作を行うかを整理し、漏れや重複を確認するために用いる。
(7) 外部インターフェース（外部IF）設計
【やること】
他システムとの連携方式・データ項目・連携タイミングを定義し、エラー時の再送方法や検知方法、責任分界まで明確にする。
【成果物】
• 外部IF一覧（連携先、方式、頻度の一覧）
• 外部IF仕様書（リクエスト/レスポンス/エラー仕様、ファイル形式、データ項目、コード体系）
• 外部IF運用定義書（失敗時の扱い、再処理手順、監視方法、責任分界）
(8) 非機能要件のうち、外部仕様に影響する事項の反映
【やること】
要件定義で定めた非機能要件のうち、画面・帳票・外部IFなど基本設計の仕様に影響する事項を具体化し、設計内容へ反映する。
【成果物】
• 要件定義時の非機能要件の変更・反映（履歴管理）
• 権限・表示制御仕様
• 操作ログ／監査ログ仕様
• 性能制約前提（一覧件数上限、検索条件制限など）
(9) レビューと承認
【やること】
顧客レビュー（利用部門・情シス・監査等）を回し、指摘を反映し、承認を取る。以降の変更は変更管理に載せる。
【成果物】
• 外部設計レビュー議事録（決定/保留/宿題/担当/期限）
• 指摘一覧と改版履歴
• 承認記録（サイン、稟議、承認メール等）
• ベースライン版 外部設計書
対外的な信頼性向上や取引・入札で有利になるISO取得を目指す場合、計画・成果物・レビュー記録を明確に残す必要があります。そのためには、今までの考察で分かるように、工程と文書が段階的に整理されるウォーターフォール開発は対応しやすいとうメリットがあります。
何も考えずにスケジュール引くと抜けがちな、「システム共通フレームワーク」は、私の考えでは、ここのフェーズで設計・開発します。詳細設計は共通フレームワークが出来てないと正しく書けないからです。
共通フレームワークは「実装段階で共通的なものが見え」、全体構造を変えながら進めますので、普通は詳細設計は書きません。納品物として求められた場合は、出来上がったらソースから詳細設計を書いたりもします。
これを全く別のチームや別プロジェクト、特別な工程として開発するのが理想ですが、それでも、理解しているメンバーがそれを使う側の案件に深く関わらないと、コミュニケーションのギャップが生まれて険悪になりがちです。
💻 詳細設計 / 内部設計で行う事と成果物🖥
実装可能な粒度まで落とす工程です。システムエンジニアが詳細設計を行い、プログラマー（コーダー）が実装という計画が立てられがちです。
(1) 内部構造設計（分割・責務・依存）
【やること】
基本設計で定義した機能を、実装しやすい単位に分割し、責務と依存ルールを決める。
【成果物】
• モジュール構成図（サブシステム／機能群／モジュールの区分）
• レイヤ構成（例：画面／業務／データアクセス 等の責務）
• 共通部品一覧（共通化対象、利用条件）
• 依存関係ルール（依存の向き、禁止事項）
(2) 処理方式設計（トランザクション・排他・再実行）
【やること】
処理の成立条件（トランザクション境界、排他、再実行）を決め、整合性事故を防ぐ。
【成果物】
• トランザクション方針（開始／終了、境界）
• 排他方針（同時更新時の扱い、ロック粒度、競合時動作）
• 再実行方針（失敗時のやり直し単位、リトライ可否）
• 非同期化の方針（必要箇所のみ：キュー／バッチ化 等）
※トランザクション（管理）：一連の処理を「全部成功」か「全部取り消し」にする仕組み。途中失敗なら最初から無かったことにする。
※ロック：更新中のデータに一時的に鍵をかけ、他の人が同時に変更できないようにする仕組み。
(3) 処理設計（画面・帳票・バッチ）
【やること】
これを一般的に詳細設計書と呼ぶことが多い。
処理単位で、手順・分岐・例外・エラーを実装できる粒度に落とす。
画面処理設計（オンライン）、帳票設計、バッチ処理設計、IF処理設計など。
【成果物】
・処理概要（目的／前提／起動条件／終了条件）
・画面別：取得条件／検索条件／ソート／ページング仕様
・表示ルール（表示/非表示、計算項目、編集可否）
・権限反映（ロール別にできること／できないこと）
・処理手順 / 処理フロー図（番号付きの処理ステップなど）
・チェック仕様（入力チェック／業務ルールチェック／整合性チェック）
・メッセージ・エラー一覧（エラーコード、表示文言、復帰方法）
・参照・更新データ一覧（参照テーブル／更新テーブル／更新条件）
・項目移送定義（入出力定義 / 項目対応表）
・帳票生成仕様（ヘッダ、フッタ、並び順、集計方法、抽出条件）
・出力フォーマット定義（CSV項目、並び、コード）
・大量処理時の方式（分割、非同期、処理時間の前提）
(4) DB設計（テーブル・項目・制約・索引）
【やること】
基本設計のデータ構造を前提に、DBとして「そのまま作れる」状態に確定する。
【成果物】
・ER図
・テーブル定義書（カラム、型、桁、NULL可否、デフォルト）
・制約定義（主キー、ユニーク、参照整合、チェック）
・インデックス設計（対象、根拠、想定クエリ）
・履歴設計（履歴粒度、訂正方式、監査データの保持）
・件数・伸び方の前提（性能の前提として最低限）
(5) 外部IF詳細設計（項目定義＋失敗時運用）
【やること】
IFを項目レベルまで確定し、エラー時の扱いを手順化する。方式・サイクル・項目定義・エラー時取り扱い（再送、手動介入、責任分界）まで含めて書く。
【成果物】
・IF概要（連携先、送受信方向、方式、タイミング、文字コード等）
・IF項目定義（項目ID、項目名、型、桁、フォーマット、関連テーブル）
・エラー時の取り扱い（検知、再送、手動介入、責任分界）
・重複排除／リトライ方針（必要なら）
(6) バッチ・ジョブ詳細設計（締め処理含む）
【やること】
締め・集計・夜間処理を、再実行・途中再開・排他・復旧まで含めて設計する。個別のプログラムというより、日次、月次などの大きな処理の全体を決めるイメージ。
【成果物】
・ジョブ構成図（依存関係）
・ジョブスケジュール一覧
・実行条件一覧
・再実行/途中再開戦略
・締めサイクル設計（いつ締めるか）
・障害復旧設計（誰がどう戻すか）
(7) 運用・監視設計
【やること】
サイクルで回す運用の形（監視・障害一次対応）を設計する。
ログについては「共通ログ設計ガイド」を定義しておき、個別設計書に毎回同じ内容を記述しないようにする。
【成果物】
・（共通）ログ設計ガイド（必須フィールド、レベル運用、フォーマット、禁止事項 など）
・（共通）監視設計（メトリクス、アラート条件、ダッシュボード）
・（個別）監査ログ要件（証跡が必要な操作だけ：誰が何をいつ）
・（個別）セキュリティイベント（認証失敗・権限エラー等）に限った出力要件
・障害切り分け手順（一次対応観点）
(8) 品質（非機能）の実装方針
【やること】
要件定義の品質要求を、実装・運用に落ちる形で具体化する。
【成果物】
・性能対策方針（索引、キャッシュ、非同期化など）
・バックアップ／リストア方針（復旧手順、復旧単位）
・セキュリティ実装方針（認可、暗号化、秘密情報管理）
・脆弱性対応方針（更新、検知、緊急対応）
(9) 実装ルール（規約・レビュー・手順）
【やること】
実装品質を揃えて、実装者によるバラツキを防ぐためのルールを決める。
詳細設計〜実装に移る直前に確定することで、コーディングの品質・レビュー基準・作業フローを全員で共有する。
【成果物】
• コーディング規約（命名、例外、禁止事項）
•単体テストのレビュー観点（チェックリスト）
• ソース管理、ブランチ運用ルール
• プログラム完成後のリリース手順
(10) レビュー・確定（ベースライン化）
【やること】
レビューで成果物を潰し込み、版管理して確定する（以降の変更は変更管理へ）
ベースラインとは、公式に承認された設計書などの成果物の集合を指し、以後の開発や変更はこの基準値を基に管理される。
レビューは設計成果物を他者の目で検証し合意を形成する手段であり、重大な抜けや矛盾を表面化させるには有効である一方、すべてを完璧に確認することは現実的には不可能であり、実際に実装やテストによって未発見の不整合が後工程で発見されることはよくある。
【成果物】
• レビュー議事録
• 指摘一覧・改版履歴
• 確定版 詳細設計書一式
ドキュメントはデバッグできないので詳細設計は間違いがあって当然のものですが、新人がその認識なしで実装しようとすると大混乱します。私としては…こんな間違いやすいものをチマチマと書いてるぐらいなら、必要な事のみ決めて、さっさと実装した方が早いと感じます。
そして、次工程以降で詳細設計書の修正が必ずと言っていいほど入り、詳細設計書とプログラムソースは最終的に一致しないことが多いです。一番正しいのは「プログラムソース」となり、詳細設計書は信用のできない紙切れになりやすいです。
💻 【製造 / 実装・単体テスト】で行う事と成果物🖥
ウォーターフォール開発は、工程を 明確に分けて順番に完了させていく手法として定義されるため、製造（実装）が一段落したあとに単体テストという独立したフェーズとして扱われるのが普通になります。見積も分けて数字を出す事が多いです。
しかしながら、実作業として、この工程を分けるメリットはほとんどなく、逆にデメリットしかないため、ここでは一緒に扱う事とします。単体テストが完了していないプログラムは、製造に戻され何度も行き来する為、分けなくてもウォーターフォール的には全く問題ありません。
【やること】
・製造（実装）
詳細設計書（内部設計）と基本設計（外部設計）で決めた仕様を元に、対象機能（画面／帳票／バッチ／外部IFなど）をプログラムとして製造。製造では、正常系だけでなく、入力不正や業務エラー、システム例外などの例外・エラー時の振る舞いも仕様に沿って組み込む。あわせて、ログ出力やエラー通知などが共通仕様で決まっている場合は、それに準拠した形で埋め込む。
製造は「ビルドが通り、起動して最低限の動作確認ができる状態」で完了となる。
・コードレビュー
実装が一通り形になったら、実装者以外（リーダー／有識者など）の視点でレビューし、仕様逸脱・設計不整合・可読性・保守性・危険な実装（例：例外処理の欠落、境界値の抜け、権限チェック漏れ等）を洗い出す。
日本のウォーターフォールでは、工程ごとの成果物を「意思疎通の基盤」としてレビュー・承認を通し、品質と引き継ぎ耐性を上げる運用が多い。これをしないケースは結構多い。
・単体テスト
単体テストでは、作成したプログラム（モジュール／プログラム単位）が仕様どおり動くかを確認する。テストは、観点を整理してケース化し、実行して結果を残す。（正常系だけでなく、異常系・境界値・権限制御・例外系の確認もする）不具合が見つかった場合は、修正→再テストでクローズし、結果と証跡を残せる形に整える。製造と合わせて同じ人が担当することが多いので、モラルがない開発者だと「この機能は正しく動作した」と書かれていても、動かないことは多々ある。
・引き渡し準備（結合テストに渡せる状態に整える）
最後に、結合テスト工程へ「困らず渡せる」状態にまとめる。具体的には、何を渡すのが正（ソース／設定／資材／ビルド物の版）かが特定でき、結合テストで必要な起動手順・設定手順・既知の制約や注意点（暫定対応や残件を含む）が整理されていることが重要。
最近はソース管理ツールがあるので、ツール内で全て管理すると楽。
【成果物】
・ソースコード一式（アプリケーション、バッチ、スクリプト等）
・設定ファイル／環境定義（接続先、外部IF設定、ジョブ定義など）
・ビルド成果物（ビルド済みモジュール、パッケージ等：運用次第）
・開発・ビルド手順書（ローカル構築、ビルド、起動、依存物の手順）
・単体テスト仕様書（単体試験項目書）（観点・ケース・入力・期待結果）
・単体テスト結果（エビデンス／結果報告）（実施結果、ログ、スクショ、実行記録など）
・不具合票／修正記録（発生→原因→修正→再テスト→クローズ）
・レビュー記録（レビュー議事録、指摘一覧、対応状況）
・結合テストへの申し送り事項（既知課題、制約、注意点）
非常に多くのことが書いてありますが、全部必要かというと、そうではありません。工程や成果物を増やせば増やすほど品質が高くなるかというと…実はそうでもないのです。技術と経験、そしてモラルの高いプログラマーが製造を行っているかどうか？のほうが圧倒的に品質に対する影響が大きいです。
💻 【結合テスト】で行う事と成果物🖥
結合テストでは複数の機能を連携して動かします。いままでの工程が正しかったのかの答え合わせの始まりです。
【やること】
単体テストを終えた複数のプログラム（モジュール／サービス／画面＋API／バッチ＋DB 等）を結合し、データの受け渡し・インターフェース整合・処理順序（呼び出し順）・例外時の連携が設計どおり動くかを確認。特に、項目の型・桁・必須、コード体系、タイミング（同期／非同期）、トランザクション境界、エラー時の復帰（再送・リトライ・ロールバック）で破綻しやすいので、ここで不整合を潰す。
【成果物】
・結合テスト計画書（範囲、観点、体制、環境、スケジュール）
・結合テスト仕様書／結合テスト項目表（シナリオ、手順、入力データ、期待結果）
・結合テスト環境・設定手順書（結合用の接続先、設定値、起動手順）
・結合テストデータ（投入・初期化手順を含む）
・不具合票（原因・影響・対応・再テスト結果）
・結合テスト結果報告書（消化状況、未完了、残件、次工程への申し送り）
「スキルが高く少ない人数」で開発しない限りは最初はまともに動きません。製造や詳細設計に問題があったのならいいのですが、場合によっては要件定義に漏れや矛盾があったりすると目も当てられません。「なぜ、こんなことが分からなかったんだ！」って事が、普通に発生します。
💻 【システムテスト】で行う事と成果物🖥
結合テストは「都合の良いデータ」でテストしますが、システムテストは「実運用に近いデータ」で行われます。
【やること】
システム全体として、要件定義で定めた機能要件と非機能要件（性能・信頼性・セキュリティ等）を満たしているかを確認。業務の利用パターン（業務シナリオ、画面遷移、操作手順）で端から端まで流し、外部システムとのインターフェースや利用環境条件も含めて「システムとして成立しているか」を検証する。
【成果物】
・システムテスト計画書（目的、範囲、非機能の扱い、体制、移行条件）
・システムテスト仕様書／項目表（業務シナリオ、異常系、非機能観点のケース）
・性能試験・セキュリティ試験などの結果（必要な場合）
・不具合票（重要度・優先度・収束状況）
・システムテスト結果報告書（品質評価、残課題、リリース可否の判断材料）
「俺は上流工程」とか言ってプログラミング出来ない人は「システムの負荷」とか理解できない人が多いので…ヤバい匂いを感じられる技術者がいて早期に対策していないと、こんな最後の方で「処理が遅くて使い物にならん！」なんて根本的な問題が結構な確率で発生します。そんな時でもスーパーな技術者がサーカスみたいなことをして何とかしますけど…そんな彼らは、いつか対応できない日が来ることを恐れて夢にまでうなされていると思います。
💻 【受入テスト / UAT】で行う事と成果物🖥
ここでようやくお客さんがシステムを触り始めます。要件定義や基本設計の確認で無口だったお客さんたちが、急に饒舌になる工程でもあります。
【やること】
発注者／利用部門が“業務の当事者”として、実運用に近い観点で最終確認を行う。ポイントは「仕様どおり」よりも、業務として回るか（運用手順・例外時・現新比較・連動システム含む）／検収できる品質になる。外注の場合はここが納品物の検収（受け入れ・承認）に直結することが多い。
「仕様どおり」に作ったのに「業務として回らない」ことは非常に多くあり、ITベンダーはここで「最終的な落とし所」を決めるという泥沼的な交渉をすることになります。この状態で必要となるのは、「見積を高く見せてバッファを持たせる技術」で獲得出来ている余剰工数か、お客に追加のお金を出させる交渉術か、ただ働きしてくれる技術者になります。上流の人からすると、1番最後の選択が精神的に1番気持ちが楽な選択になります。
【成果物】
・受入テスト計画書（実施体制、観点、優先順位、判定基準）
・受入テスト項目表（業務シナリオ、現新比較、連携確認など）
・受入テスト結果報告書（合否、指摘、要改善、対応方針）
・受入判定（検収）記録（承認メール、稟議、サイン等）
・UATで出た要望・課題一覧（“追加要望”として扱うかの整理を含む）
実際に業務を回しているキーマン的な人は多忙です。初めてシステムに触れ、実際の業務で使おうとすると、高い確率で「これは使えない」「業務に合っていない」という状態になります。このとき、管理職や営業が「社内」と「お客さん」の…どちらの立場を優先するかによってプロジェクトの行方が大きく変わります。特に「わが社はお客さまファースト！お客様の意見や要望を追加料金なしで全て受け入れる！」とか言い出すと、仕様変更・追加要求が雪だるま式に増え、修正の負担も膨大になり、死の行進が始まり、地獄のような状態へと進むことになります。
ここでの仕様変更は、今までのテストが「無駄働き」と化し、忙しさからドキュメントの修正もテストも追いつかず、品質がひたすら落ちていくことにもつながります。
余談ですが、ここで炎上している場合、プロジェクトリーダーが逃亡したり入院したりすると、今まで厳しかったお客様が、危機を感じて急に優しくなったりするので、意外とプロジェクトが上手くいくなんていう不思議なことも起きたりします。
💻 【本番導入・運用】で行う事と成果物🖥
長い苦難の道を超えて、いよいよ本番導入です。
【やること】
本番導入では、リリース（切替）に向けて移行計画・移行リハーサル・切り戻し（ロールバック）まで含めた段取りを整え、決めた手順で本番反映まで行う。運用では、監視・バックアップ・障害対応・問い合わせ対応・変更管理を回し、安定稼働と継続改善を行うことになる。
検収（正しく動いたからお金を払う）が行われるまでは、案件の見積金額範囲内で赤字になっても作業をしなくてはならならず、検収がもらえたら…ITベンダーが原因のトラブルが発生がなければ…毎月の保守費用で、何もしなくても、システムが使われる限りは、お金が入ってくるようになる。
【成果物】
・移行計画書（移行方式、作業ステップ、体制、切戻し方針）
・移行作業手順書（本番移行の具体手順）
・移行リハーサル結果（問題点、是正、所要時間）
・本番リリース手順書／リリース判定記録（Go/No-Go）
・業務運用手順書（現場の運用オペレーション）
・システム運用手順書（監視、バックアップ、定期作業、復旧）
・監視・障害対応設計（監視項目、通知、エスカレーション、復旧手順）
・障害／問い合わせ管理台帳（インシデント記録、原因、再発防止）
・改善・変更管理資料（軽微改修の受付、影響確認、リリース履歴）
本番導入を終えたら「やれやれひと段落」なんて…甘いものではありません。
余程のことがない限り、トラブルが発生します！！
自分のせいでもないのに「大変申し訳ございません」という謝罪文章を書き、単純な能力不足の人為的な単純ミスであっても、今後発生しないための施策とかも考えないといけません。
それでも、早期にトラブル対応できるのなら幸せな方で、プログラムに致命的な問題が発生したりして、それらが日々データを壊したり…などがあると、眠れない自転車操業が始まります。復旧出来ないデータが出来た時は、お客さんに「全て再度手入力してください」みたいな無茶なお願いもしなくてはなりません。
本番導入立ち合いは本当に嫌…
💻 終わりに🖥
これが日本における「ウォーターフォール開発」の全容です。
最後の方は怖い感じになりましたが、現実はもっと怖いです。
さて、次回は「日本のIT業界の特殊な構造」のお話が出来ればと思います！