初めてシステム開発を発注した担当者から「工程の説明は受けたのに、自分が何をすべきかよくわからなかった」という声をよく聞きます。
開発会社はプロとしてシステムを作ってくれますが、「何を作るか」を決める段階から「それが正しく動いているか」を確認する段階まで、各工程で発注者が果たすべき役割があります。そこを曖昧にしたまま進めると、完成したシステムが「想定と違う」「使いにくい」「テスト中に大量の不具合が出る」といったトラブルに発展しやすくなります。
発注者がすべてエンジニアである必要はありません。ただ、「この工程で自分が何をすべきか」を知っているだけで、プロジェクトの成功確率は大きく変わります。
本記事では、システム開発の代表的な工程を「発注者として各フェーズで何をすべきか」という観点で解説します。失敗パターンと対策も工程ごとに紹介しますので、初めてシステム開発に関わる方にも参考にしていただける内容です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
システム開発の工程とは？全体像と必要な理由
工程とは「開発を段階に分けて進める仕組み」
システム開発の「工程」とは、システムを完成させるまでの作業を段階（フェーズ）に分けて進める仕組みのことです。「要件定義→設計→開発→テスト→リリース→保守」というように、各段階を順番に完了させながら全体を進めていきます。
工程を分ける理由はシンプルで、「前の段階が曖昧なまま次に進むと、後から大きな手戻りが発生するから」です。たとえば、「何を作るか（要件定義）」が不明確なまま設計を始めると、設計書を何度も書き直すことになります。テスト段階になって要件の誤りに気づいた場合は、開発からやり直しになることも珍しくありません。
工程ごとに「何を決め、何を確認するか」を明確にしておくことで、手戻りを最小限に抑え、品質の高いシステムをコスト通りに完成させやすくなります。
発注者が工程を理解すべき3つの理由
開発を外注する場合、「技術的な作業は開発会社に任せればいい」と考えがちです。しかし、以下の3点から、発注者も工程を理解しておく必要があります。
1. 各工程で発注者の意思決定が必要になるから
要件定義では「何を作るか」、設計レビューでは「この画面で合っているか」、テストでは「この動作で業務が回るか」など、各工程で発注者しか判断できない事項が存在します。ここを開発会社任せにすると、意図と異なるシステムが完成します。
2. 進捗確認と課題発見のタイミングを理解できるから
工程の節目（マイルストーン）を理解していると、「今何が決まっていないと後で困るか」を先読みできます。問題を早期発見できれば、コスト・スケジュールへの影響を最小限に抑えられます。
3. 開発会社とのコミュニケーションが円滑になるから
「要件定義書とは何か」「テスト仕様書のレビューとは何をすることか」を理解しているだけで、開発会社からの説明の理解度が格段に上がります。認識のズレを早期に解消できれば、関係性も良くなります。
ウォーターフォールとアジャイルの工程比較
システム開発には複数の進め方（手法）があります。その中で、現在最も多く採用されているのが「ウォーターフォール型」と「アジャイル型」の2種類です。どちらを選ぶかによって、発注者の関わり方も変わります。
ウォーターフォールの工程（計画通りに順番に進む）
ウォーターフォール型は、工程を順番に「一方向」で進めます。前の工程が完了してから次に進む方式のため、計画が立てやすく、進捗が管理しやすいのが特徴です。
典型的な工程の流れは以下のとおりです。
要件定義 → 基本設計 → 詳細設計 → 開発・実装 → 単体テスト → 結合テスト → システムテスト → 受け入れテスト → リリース → 保守・運用
各工程での成果物（要件定義書、設計書、テスト仕様書など）を確認・承認しながら進めます。仕様変更は「変更管理」を通じて行いますが、後工程での大幅な変更はコスト増につながりやすいため、要件定義を丁寧に行うことが重要です。
向いているプロジェクト: 要件が最初から明確、仕様変更が少ない、規模が大きく開発メンバーが多い
アジャイルの工程（短いサイクルで繰り返す）
アジャイル型は、「スプリント」と呼ばれる1〜4週間の短いサイクルを繰り返しながら開発を進めます。各スプリントで機能を少しずつ完成させ、動くものを早期に確認しながら改善していく方式です。
1スプリントの基本的な流れは以下のとおりです。
計画（スプリントプランニング） → 開発 → レビュー（スプリントレビュー） → 振り返り（レトロスペクティブ） → 次のスプリントへ
発注者は「プロダクトオーナー」として、開発する機能の優先順位をスプリントごとに決める役割を担います。変更に柔軟に対応できる反面、発注者の関与頻度が高くなります。
向いているプロジェクト: 要件が変わりやすい、早期に動くものを確認したい、発注者が週次で関与できる
どちらを選ぶかの判断基準
比較項目 | ウォーターフォール | アジャイル |
|---|---|---|
仕様の確定度 | 高い（決まっている） | 低い（変わりやすい） |
発注者の関与頻度 | 工程の節目（月次程度） | 週次〜隔週 |
変更への対応 | 変更管理が必要でコスト増の可能性 | スプリント単位で柔軟に対応可 |
コスト予測 | 立てやすい | 変動しやすい |
どちらが正解かはプロジェクトの性質によります。開発会社と「自社の状況にどちらが合うか」を事前に相談することをおすすめします。
詳しくはこちらの記事もご参照ください：アジャイル開発とは？発注者として知っておくべき関わり方・契約・進め方ガイド
システム開発の主要工程とは（発注者がやること付き）
ここでは、システム開発の各工程で発注者として何をすべきかを解説します。ウォーターフォール型の工程を基準に説明しますが、アジャイル型にも共通する部分は多くあります。
要件定義
工程の内容: 「何を作るか」を明確に定義するフェーズです。システムの目的・機能・範囲・制約条件を開発会社と合意します。この工程がシステム開発全体の品質を最も大きく左右します。
発注者がやること:
- 現在の業務フローを整理し、改善したい課題を具体的に言語化する
- 関係する社内部署（現場担当者・管理職）にヒアリングし、要望を集約する
- ヒアリングには「誰が・いつ・何のために・どのようにシステムを使うか」の視点で臨む
- 開発会社との打ち合わせに現行業務のマニュアルや帳票、画面のスクリーンショットを持参する
- 要件定義書（仕様書）が完成したら、社内関係者と内容を確認・承認する
完了の目安: 要件定義書に「機能要件・非機能要件・業務フロー・制約条件」が記載され、発注者・開発会社の双方が署名（承認）している状態
基本設計（外部設計）
工程の内容: 要件定義をもとに、ユーザーが実際に触れる部分（画面・帳票・外部システムとの連携）の設計を行います。「どんな見た目・操作でシステムを使うか」をこの工程で確定させます。
発注者がやること:
- 画面設計書（ワイヤーフレーム）を受け取り、実際の業務フローと照らして確認する
- 「この操作で誰が・何のためにこの画面を使うか」を想像しながらレビューする
- 疑問や気になる点は速やかに開発会社に質問し、設計書へ反映してもらう
- 最終的な設計書に承認サインをする（後の工程での変更を防ぐため）
完了の目安: 画面設計書・機能一覧・外部連携仕様が確定し、発注者が承認した状態
詳細設計（内部設計）
工程の内容: 基本設計をもとに、エンジニアが実際にコードを書くために必要な設計を行います。データベースの構造・処理ロジックなど、発注者には専門的な内容が多いフェーズです。
発注者がやること:
- 開発会社から「こういう場合はどう処理するか」という質問（課題管理表）に迅速に回答する
- 「仕様が決まっていない部分」を指摘された場合は、遅延なく意思決定する
- 必要に応じて追加要件の可否（スコープ判断）を行う
完了の目安: 詳細設計書が完成し、主要な仕様の未決事項がなくなっている状態
開発・実装
工程の内容: エンジニアが設計書に従ってプログラムを作成するフェーズです。発注者が直接関わる機会は比較的少なくなります。
発注者がやること:
- 開発会社から定期報告（週次定例会など）で進捗を確認する
- 課題管理表（バグ・質問・懸案事項一覧）の「発注者対応事項」を確認し、迅速に回答する
- スコープ変更（追加・削除要件）が出た場合は、「変更管理ルール」に従って記録・承認する
- 途中でのデモ（プロトタイプ確認）が可能であれば積極的に参加する
完了の目安: 単体テスト（各機能の動作確認）が完了し、結合テストに入れる状態
テスト（受け入れテスト：UAT）
工程の内容: システムが要件通りに動作するかを確認するフェーズです。「単体テスト→結合テスト→システムテスト」は開発会社が主体ですが、「受け入れテスト（UAT）」は発注者が主体となって行います。
発注者がやること:
- テスト前に「テストシナリオ（業務フローに沿ったテストケース）」を作成する（開発会社と協力して作成）
- 実際の業務フローに沿ってシステムを操作し、意図通りに動くかを確認する
- 不具合・想定外の動作は「不具合管理票」に記録し、開発会社に報告する
- 重大度（業務に支障が出るか・軽微か）を判断し、リリース可否を最終的に決定する
完了の目安: 受け入れテストで重大な不具合がゼロとなり、発注者がリリース承認をした状態
リリース・移行
工程の内容: 本番環境へのシステム移行と稼働開始です。データ移行（旧システムからのデータ取り込み）が必要な場合はここで行います。
発注者がやること:
- リリース日・時間帯を業務への影響を考慮して決定する（例: 月末・繁忙期は避ける）
- データ移行が必要な場合は、移行計画・移行手順を開発会社と共同で確認する
- 社内関係者へリリース日時・操作変更点を周知する
- 切り替え後の初日に現場担当者をフォローする体制を整える
完了の目安: システムが本番環境で正常稼働し、業務が新システムで回っている状態
保守・運用
工程の内容: リリース後のシステム維持・改善フェーズです。バグ対応・機能改善・サーバー管理などが含まれます。
発注者がやること:
- 社内での問い合わせ窓口（一次対応担当者）を決め、開発会社へのエスカレーションルートを明確にする
- バグ・改善要望は「改善要望一覧」に蓄積し、優先順位をつけて定期的に開発会社と確認する
- 半年〜1年ごとに「システムが業務要件を満たし続けているか」を評価し、大規模な改修の要否を判断する
完了の目安: 設定なし（継続フェーズのため）
工程別・発注者が陥りやすい失敗パターンと対策
実際のシステム開発プロジェクトで発注者がよく陥る失敗を工程別にまとめました。
要件定義フェーズ：「ざっくり伝えたら違うものができた」
失敗の状況: 「使いやすいシステムにしてください」「今の業務の問題を解決したい」と大まかな要望しか伝えなかった結果、完成したシステムが現場で使えないものだった。
原因: 発注者と開発会社で「使いやすい」「問題を解決する」の解釈が異なっていた。
対策:
- 「誰が・いつ・何をするシステムか」を具体的に言語化する
- 現行業務の資料（マニュアル・帳票）を開発会社に共有する
- 「こういう画面は困る」「こういう動作は必須」という否定形・肯定形の両方で要件を言語化する
設計フェーズ：「設計書を確認せずに承認したら想定外の画面が完成した」
失敗の状況: 設計書の確認を「開発会社に任せた」として素通りし、開発が完了してから「この画面では使えない」と発覚した。この時点での変更はコスト・スケジュールに大きな影響が出る。
原因: 設計書のレビューを「技術的な確認作業」と捉え、発注者が関わらなかった。
対策:
- 設計書（特に画面設計）は「実際に業務で使うイメージ」で確認する
- 技術的な内容がわからなくても「画面の操作フロー」「何のためのボタンか」は発注者が確認できる
- 疑問点は「小さすぎる」と思わず都度質問する
テストフェーズ：「テストは開発会社に任せたら本番で使えない部分があった」
失敗の状況: 「テストは開発会社がやるもの」と考え、受け入れテストを省略または軽視した結果、リリース後に「この業務フローでは使えない」「この操作が直感的でない」という問題が多発した。
原因: 開発会社のテストは「設計書通りに動くか」を確認するもの。「実際の業務フローで使えるか」は発注者のみが判断できる。
対策:
- 受け入れテスト（UAT）は発注者が実施する最重要工程として位置づける
- 現場の実際の業務担当者に参加してもらい、「本当に使えるか」を確認する
- テスト期間を十分に確保し、リリース前に「合格基準を満たしているか」を明確に判断する
リリース後：「リリースしたら終わりと思っていたら運用できなかった」
失敗の状況: リリースをゴールと捉え、保守・運用の計画を立てていなかった。社内の問い合わせ対応が混乱し、開発会社への連絡が遅れてトラブルが長期化した。
原因: 「システムはリリースしたら完成」という認識。実際にはリリース直後が最も問題が起きやすい時期。
対策:
- 社内の問い合わせ窓口（一次対応者）を事前に決定する
- 開発会社との「緊急連絡フロー」を確立しておく
- リリース直後の1〜2週間は社内サポート体制を強化する
システム開発の工程をスムーズに進めるためのポイント
工程別の対策に加え、開発全体を通じて発注者が意識すべき横断的なポイントをまとめます。
定例会議の目的を工程ごとに整理する
定例会議は「進捗報告を聞く場」だけでなく、工程によって目的が変わります。
- 要件定義期: 認識合わせ・仕様確定の場
- 設計・開発期: 課題解決・変更管理の場
- テスト期: 不具合状況共有・リリース判断の場
会議の目的を事前に明確にすることで、「報告を聞いて終わる」という受け身の参加を防げます。
仕様変更は「変更管理ルール」で文書化する
開発途中に「やっぱりこの機能を追加したい」「この仕様は変えてほしい」という要望が出ることは珍しくありません。ただし、口頭のみでの変更依頼はトラブルの原因になります。
変更管理のポイント:
- 変更要望は必ず文書（変更管理票）で記録する
- 変更のコスト・スケジュール影響を確認し、承認してから反映する
- 変更履歴を蓄積し、後から「なぜこうなったか」を追えるようにする
工程の完了条件（成果物リスト）を事前に確認する
各工程の「何が完成したら次に進んでよいか」を開発会社と事前に合意しておくことが重要です。
たとえば要件定義の場合、「要件定義書が完成し、発注者・開発会社の双方が承認した状態」が完了条件です。この基準が曖昧なまま進むと、「まだ決まっていない事項があるのに次の工程に進んでしまった」という事態が起きます。
プロジェクト開始時に、各工程の成果物（ドキュメント）リストと完了条件を確認しておきましょう。
まとめ
システム開発の工程は、要件定義・設計・開発・テスト・リリース・保守と続きますが、発注者がすべての工程に技術者として関わる必要はありません。大切なのは、「各工程で何が決まるのか」「自分が何を確認・判断すべきか」を理解した上で、主体的に関与することです。
特に、以下の3つの工程での発注者の関与が、プロジェクト成功のカギを握ります。
- 要件定義: 「何を作るか」を具体的に言語化し、認識のズレを防ぐ
- 設計レビュー: 画面設計を業務観点で確認し、使いやすいシステムを担保する
- 受け入れテスト（UAT）: 実際の業務フローで使えるかを発注者自身が確認する
システム開発の全体的な流れについてはシステム開発の流れとは？メリット・デメリットから発注前に押さえるべきポイントまで解説もあわせてご覧ください。
上流工程（要件定義・設計）についての詳細はシステム開発の上流工程とは？各役割や下流との違いについて解説で掘り下げています。
「アジャイルで開発したい」という場合は、アジャイル開発とは？発注者として知っておくべき関わり方・契約・進め方ガイドもご参照ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
