システム開発は、要件定義や設計、テストといった工程の積み重ねで進んでいきます。
現場で起きるトラブルの多くは、エンジニアの技術力不足よりも 「工程の進め方が曖昧」 なために発生します。
この記事では、一般的なシステム開発工程（ウォーターフォール型開発）の全体像を俯瞰しつつ、炎上を避けるための要点として 工程定義 を分かりやすく整理します。
次回以降は、各工程を一つずつ掘り下げ、成果物のサンプルも合わせて紹介する予定です。
システム開発における工程定義とは？
工程定義とは、ひと言で言うと：
「特定のプロジェクトにおいて、どの工程で、何をどの粒度まで整理し、何を成果物として、誰がレビューして承認するか」を事前に決めること
です。
工程定義で特に重要なのは、次の4点です。
- 作業範囲：どこからどこまでやるのか（移行・運用設計をどこに含めるか等）
- 成果物：各工程で何を出すのか（成果物の粒度も含む）
- レビューと合意：誰が何を確認し、どのタイミングで承認するのか
- 完了条件：次工程へ進んでよい条件
工程定義をきっちり決めるだけで、システムの品質・見積り・スケジュール（いわゆるQCD）の精度が一段上がります。逆に言うと、工程定義が曖昧なまま走り出すと、後工程で炎上する原因になります。
工程定義はいつ決める？｜通常は「プロジェクト計画」で詳細化する
工程定義は「開発の各工程で何を出すか」を決める活動であり、通常は プロジェクト計画のタイミングで“プロジェクト固有の進め方”として詳細化 します。
一般的には システム化計画で作成されたRFPに基づいてベンダーが見積り・受注し、受注後にプロジェクト計画書を作る 流れになります。
つまり、プロジェクト計画の時点では「見積りに含める/含めない」の大枠は、既にRFPと契約の前提として概ね合意済みです。
一方で、要件定義（又は基本設計）でスコープが確定した後に、それ以降の概算見積りを“詳細見積り”として再提示し、再度契約（あるいは契約条件の見直し）を行う ケースも多くあります。
このためプロジェクト計画における工程定義で重要なのは、「見積り項目の線引き」そのものよりも、「工程間の整合性・実現可能性（無理のない計画）・抜け漏れのない計画を固めること」です。
プロジェクト計画で工程定義を詳細化すると、後から問題になりやすい論点（依存関係・責任分界・進め方等）を作業着手前に共通認識として揃える事ができます。具体的には次のような観点です。
- 工程間の依存関係が成立しているか（例：疎通確認済みの暫定基盤がないと結合テストが始められない）
- テストを成立させる“前提タスク”が計画に入っているか（例：スタブ/モック、テストデータ、環境準備、外部連携先調整）
- 各工程で作る成果物と粒度が、全体の進め方と整合しているか（例：要件の粒度のまま設計に突入しない）
- レビュー／承認の担当と、次工程に進める完了条件（品質ゲート）が明確か
- 体制・スキルレベル・支援体制を踏まえて、無理のないスケジュールになっているか（計画倒れを防ぐ）
システム開発における工程の一覧（全体像）
ここからは、一般的な工程の全体像を紹介します。
プロジェクトの性質によって細部は変わりますが、ウォーターフォール開発では V字モデル で全体を捉えると理解しやすくなります。
V字モデルは、左側で 「何を作るか」を具体化（要求・要件・設計） し、底で実装し、右側で 「正しく作れているか」を段階的に確認（テスト） する考え方です。左側で決めた内容を右側の対応するテストで検証します（例：詳細設計 ↔ 単体テスト、基本設計 ↔ 結合テスト など）。
なお本記事では、図中の 要求定義 は発注側主体の「システム企画／システム化計画」に含めて整理します。
この全体像を理解しておくことで、各工程で「何を決め、何を成果物として残すか、どこで確認するのか」を工程定義に落とし込みやすくなります。
- システム企画／システム化計画（本記事では要求定義を含む）
- プロジェクト計画（厳密には開発工程ではないため上の図には表れないが、ここで工程定義の詳細化を行う）
- 要件定義
- 基本設計
- 詳細設計
- 開発・単体テスト
- 結合テスト
- 総合テスト
- UAT（ユーザー受入テスト）
以下、それぞれの工程を 「目的 → 成果物（具体名） → 完了の目安（例） →注意点/対策（例）」 の順で整理します。
システム企画／システム化計画
目的：発注側が「なぜやるか／何をやるか／何をやらないか」を決め、RFPでベンダーに同じ前提を提示できる状態にする
成果物（例）：現状課題とToBe、対象/対象外のスコープ、優先順位、KPI、制約（期限・予算・セキュリティ等）、概算予算、RFP（要求のたたき台）
完了の目安（例）：目的・範囲・優先順位・制約が社内合意され、RFPとして説明責任を持てる
注意点/対策（例）：目的/優先順位が曖昧なまま要望を積み上げ、RFPが過剰な要求になる。やらない事と優先順位（Must/Should）を必ず定義し、制約とセットで情報提示する
プロジェクト計画
目的：プロジェクトの責任者及びマネージャーが主体となり、「この進め方なら成功する」と言える計画を立てる（工程定義の具体化はここで行う）
成果物（例）：工程定義（成果物/役割/レビュー/ゲート）、システム概要図、体制（RACI）、マスタースケジュール/マイルストーン、品質計画、リスク/課題、変更管理、コミュニケーション設計
完了の目安（例）：工程間の依存（環境・データ・外部連携・スタブ/モック等）と責任分界が明確で、「誰が・いつ・何を用意するか」が合意できている
注意点/対策（例）：採用する技術への知見が乏しいメンバーのみで計画を作り、依存関係（環境・データ・外部連携・スタブ/モック等）や工数感を読み違い、破綻する。技術が分かる責任者（PL/テックリー ド）を計画段階で参加させ、前提と依存関係を洗い出して現実的なスケジュール・進め方を設計する
要件定義
目的：作るべきものを「設計できる」「受入判断できる」粒度まで具体化し、後工程のブレを減らす。基本設計とそれに係る詳細見積りの土台を作る
成果物（例）：要件定義書（業務/機能/データ/非機能）、用語集、画面/帳票/IF一覧、受入基準（合否の考え方）
完了の目安（例）：業務シナリオを精緻化して、非機能・例外・運用・権限の論点が整理されている（未決は可視化され、後工程での決め方を合意できている）
注意点/対策（例）：要求（ビジネス/ユーザーサイドの願望）と要件（約束）が混在し、議論が発散して収束しない。前提・優先度・決める範囲を明確にし、受入基準から逆算して要件を固める。非機能要件の定義を疎かにしない
基本設計
目的：全体構造と外部仕様（画面・API・連携）を決めきる。システムの根幹となるアーキテクチャーを確定する
成果物（例）：画面一覧/画面遷移図、API一覧/IF設計（Input/Output）、データモデル（概念/論理）、方式設計（認証認可・ログ・監視・バッチ・外部連携）
完了の目安（例）：画面/API/データの整合が取れ、責任分界（自システム/外部）が合意できている。システム間の連携に必要な外部仕様が定義されている
注意点/対策（例）：境界が曖昧なまま進み、後で仕様・費用・納期について調整が発生する。I/F仕様・責任分界・例外時の扱い を基本設計で決め、適切なレビュー体制で確認する
詳細設計
目的：実装担当が迷わない粒度にしつつ、例外や境界条件まで含めて品質を担保する
成果物（例）：画面/API詳細設計、DB物理設計、バリデーション/メッセージ、エラー設計、タイムアウト/リトライ、テスト観点
完了の目安（例）：入力/出力、エラー、権限、外部I/F、運用上の扱いが揃い、レビューで抜け・矛盾が潰せている
注意点/対策（例）：設計書の内容が薄すぎると実装者の解釈が割れてバグが増えるが、逆に細かく書きすぎると作成/レビューで予定通りの生産性が出せずに遅延する。どこまでを設計書の責任範囲にするかを決め、障害になりやすい例外・境界条件（エラー時、タイムアウト、リトライ、権限制約など）を優先して明文化する
開発・単体テスト
目的：設計どおりに実装し、単体レベルで壊れないことを継続的に担保する（V字モデルの対応関係で言うと、左側の「詳細設計」で決めた内容を単体テストで確認する）
成果物（例）：ソースコード、単体テスト、自動テスト/静的解析設定、レビュー記録、簡易な運用手順（必要に応じて）
完了の目安（例）：レビューと単体テストが運用として回り、主要分岐・例外ケースを含めて再発防止（リグレッションテスト）ができている
注意点/対策（例）：レビューが人任せになり品質がぶれる／テストが形式化する。レビュー観点（例外・ログ・境界条件）を固定し、仕様の意図に沿ったテストケースで押さえる
結合テスト
目的：機能間・システム間の連携が正しいことを確認し、「境界」で壊れないことを示す（V字モデルの対応関係で言うと、左側の「基本設計」で決めた内容を結合テストで確認する）
成果物（例）：結合テスト計画/仕様、結合マトリクス、スタブ/モック方針と成果物、テスト環境/データ、障害時の確認観点
完了の目安：結合対象が網羅され、タイムアウト/例外/再送など境界条件を含めて主要フローが通る
注意点/対策（例）：環境・データ未整備で遅延。開始条件（Ready条件）を明文化し、外部連携は早期に疎通確認する（代替手段としてスタブ/モックも用意する）
総合テスト
目的：業務として成立すること、非機能（性能・セキュリティ・運用性）が満たせることを確認する（V字モデルの対応関係で言うと、左側の「要件定義」で整理した要件を総合テストで確認する）
成果物（例）：総合テスト計画/シナリオ、性能試験結果、セキュリティ観点の確認結果、運用リハ（監視/障害対応）
完了の目安：致命的不具合が収束し、受入に向けた“判断材料”が揃っている
注意点/対策（例）：しわ寄せで期間が削られる。優先度（重要業務・高リスク）を先にテストし、性能/セキュリティなど後戻りが大きい項目は早めに当てる
UAT（ユーザー受入テスト）
目的：利用者が「業務で使える」と判断できる状態にし、最終合意を取る（V字モデルの対応関係で言うと、左側の「要求定義」の受入基準に対して最終確認を行う）
成果物（例）：受入基準（合否/残課題の扱い）、UATシナリオ、教育資料、運用導線、問い合わせ/支援体制
完了の目安：合否判断と移行判断ができ、残課題の扱い（次リリース/運用回避等）が合意できている
注意点/対策（例）：業務側の稼働不足で形骸化。UAT稼働を計画に織り込み、事前にデータ/手順/問い合わせ導線を準備する（確認が浅いまま“形式的に合格”にならないようにする）
まとめ：工程定義は「プロジェクトの設計図」
工程を一通り知るだけでも意味がありますが、本当に大切なのは プロジェクトの特徴（目的・制約・リスク・体制など）を反映して、最適な進め方を工程定義として具体化すること です。プロジェクトは一つとして同じものはありません。
- どの工程を、どこまでやるか（範囲／責任分界）
- 各工程で何を出すか（成果物／粒度）
- 何をもって「次に進める」と判断するか（完了条件／レビュー／合意者）
- 変更が起きたときに、どう判断して反映するか（変更管理）
この枠組みを精緻化出来ると、見積り・スケジュール・品質のブレが一気に減ります。
コンサルタントとの30分無料相談のご案内
もし「システム開発の進め方が分からない」「工程をどう定義すればよいか分からない」「実行可能な計画になっているか不安」という場合は、まずは専門家とディスカッションしてたたき台を作ってしまうのが近道です。
- 弊社コンサルタントと30分の壁打ち（無料相談）：現状の課題感や進め方を聞き、抜け漏れ・リスク・次に決めるべきことを整理します
次回以降：各工程を1つずつ掘り下げます（成果物サンプル付き）
次回以降は、今回の工程一覧の各工程を 1本ずつ深掘り していきます。
それぞれの記事では、実務でそのまま使える 成果物サンプル も用意する予定です。
（例）
- 要件定義：成果物セット／要件定義書サンプル
- 基本設計：画面一覧・API基本設計・ERのサンプル
- テスト：テスト計画書・シナリオのサンプル
…など
