システム開発の流れを7ステップで解説｜発注者が各工程でやるべきこと

システム開発の流れを把握せずに外注すると、予算超過・手戻り・納期遅延という三重苦に陥ります。経済産業省の調査では、ITプロジェクトの約3割が当初予算を20%以上超過しており、その多くが「発注者側の準備不足」を原因としています。

企画から運用保守まで7つの工程を理解し、各フェーズで発注者が何をすべきかを事前に把握することで、プロジェクト成功率は大幅に向上します。本記事では次の3点を解説します。

• システム開発の7つの工程と各フェーズの役割
• 各工程で発注者が準備・確認すべき具体的アクション
• 発注者がよく陥る失敗パターンと回避策

システム開発の流れ：7ステップ全体像

システム開発プロセスは、大きく以下の7工程で進みます。

ステップ	工程名	発注者の主な関与度
1	企画・準備	高（目的・予算・体制を決定）
2	要件定義	高（仕様を決める最重要工程）
3	システム設計	中（基本設計のレビュー）
4	実装（開発）	低（定期的な進捗確認）
5	テスト	高（受入テストで最終確認）
6	リリース	中（本番公開の意思決定）
7	運用・保守	継続（安定稼働と改善）

ウォーターフォール型では上から順に進み、アジャイル型では2〜5のサイクルを短いスプリントで繰り返します。発注者の視点では、 どちらの手法でも1・2・5・7が特に重要 です。

ステップ1：企画・準備（目的と体制を固める）

システム開発の流れで最初に行うのが「なぜ作るのか」を明確にする企画フェーズです。

このフェーズで決めるべき4つの要素：

• 目的の数値化 ：「問い合わせ対応工数を月30時間削減」のように定量目標を設定する
• ターゲットユーザー ：誰が使うシステムか（社内向け／顧客向けなど）
• 予算の上限と内訳 ：開発費・インフラ費・運用費の概算を確保する
• 社内の推進体制 ：開発会社との窓口となるPMを社内に置く

また、このタイミングで 契約形態 を検討します。

• 請負契約 ：成果物の完成に対して対価を支払う。要件が固まっている場合に向く
• 準委任契約 ：業務遂行に対して対価を支払う。要件が変わる前提のアジャイル開発や初期MVP開発に向く

システム開発を外注する前の要件定義の前工程について、こちらで詳しく解説しています。

ステップ2：要件定義（システムの仕様を決める最重要工程）

要件定義はシステム開発プロセス全体で最も重要な工程です。ここで仕様が曖昧なまま進むと、後工程での手戻りが発生し、コストが雪だるま式に膨らみます。

要件定義書に盛り込む必須項目：

• 業務要件 ：システム導入後の業務フロー、ユーザーの役割と権限
• 機能要件 ：画面一覧、データ入力・検索・外部連携の仕様
• 非機能要件 ：セキュリティレベル、同時アクセス数の想定、稼働時間（SLA）

発注者側がすべき最重要アクションは「 要望の漏れをなくすこと 」です。開発会社は「言われたものを作る」立場のため、発注者が言わなかった機能は原則として対象外になります。

要件定義書の具体的なサンプルと書き方はこちらの要件定義書フォーマット解説が参考になります。

ステップ3：システム設計（画面と裏側の仕組みを設計する）

要件定義で決まった内容をもとに、具体的な設計図を作る工程です。設計は2段階に分かれます。

• 基本設計（外部設計） ：ユーザーから見える部分を設計。画面レイアウト・画面遷移・操作方法を定義します。発注者はワイヤーフレームやモックアップを確認し、「使い勝手に問題がないか」をレビューします
• 詳細設計（内部設計） ：エンジニアがコードを書くためのシステム内部の設計。データベース構造や処理ロジックを決定します

発注者が主体的に関わるのは 基本設計のレビュー です。この段階で「イメージと違う」と気づけば、実装前に修正できます。実装後の変更は基本設計変更の5〜10倍のコストがかかります。

各フェーズで納品される設計書の種類については、システム開発の成果物一覧で確認できます。

ステップ4：実装（プログラミングと開発）

設計書に基づき、エンジニアが実際にプログラムを書くフェーズです。このフェーズは開発会社が主体となります。

発注者が押さえるべき2つのポイント：

1. 定期的な進捗確認 ：週次や隔週でミーティングを設定し、「認識のズレ」がないかチェックする
2. MVP思考でスコープを管理する ：新規事業の初期開発では MVP（Minimum Viable Product） として最小限の機能から作り始め、初期費用と期間を抑えることが主流です

MVPによるスモールスタートは「全機能を一気に作って失敗する」リスクを下げる有効な手法です。コア機能に絞ることで開発費を抑え、ユーザーからのフィードバックを得てから機能を拡張できます。

ステップ5：テスト（品質を確認する）

開発したシステムが仕様通りに動くか確認するフェーズです。テストは複数段階で行われます。

テスト工程の種類と発注者の関与：

テスト種別	目的	発注者の関与
単体テスト	各モジュールが正しく動作するか	なし（開発側が実施）
結合テスト	複数モジュール間のデータ連携が正常か	なし（開発側が実施）
システムテスト	全機能を本番環境に近い状態で検証	低（結果の確認）
受入テスト（UAT）	業務に使えるか最終確認	高（発注者が主体）

発注者にとって最も重要なのが「 受入テスト（UAT: User Acceptance Testing） 」です。実際の業務シナリオに沿って操作し、「要件定義で合意した内容が実現されているか」を確認します。

見落としがあるとリリース後に重大な不具合が発生するリスクがあります。テストケースは開発会社に丸投げせず、発注者側でも業務フローに基づいたシナリオを用意してください。

ステップ6：リリース（本番稼働を開始する）

テストが完了し問題がないことが確認できたら、システムを本番環境に公開（デプロイ）します。

リリース前に発注者が確認すべき4点：

• データ移行計画 ：既存システムからのデータ移行が正確に完了しているか
• ユーザーへの告知と教育 ：社内外のユーザーへの使い方説明・マニュアル配布
• ロールバック手順の合意 ：リリース直後に不具合が発覚した場合の旧バージョンへの切り戻し手順
• 監視体制の確立 ：リリース直後は特に問題が起きやすいため、監視・対応窓口を明確にしておく

段階的なリリース手法（カナリアリリース・ブルーグリーンデプロイなど）を採用すると、万が一の影響範囲を限定できます。

ステップ7：運用・保守（安定稼働と継続改善）

システムはリリースして終わりではありません。安定稼働を維持し、ビジネスの変化に合わせてアップデートし続ける「運用・保守」が不可欠です。

運用と保守の役割の違い：

• 運用 ：サーバー監視、データバックアップ、ユーザー対応など日々の正常稼働を維持する業務
• 保守 ：OS・ライブラリのアップデート対応、バグ修正、セキュリティ対策など改善・維持のための業務

リリース前に SLA（Service Level Agreement：サービス品質保証） を定め、障害発生時の対応フローと責任範囲を明確にしておくことが重要です。「誰が何時間以内に対応するか」を契約に盛り込まないと、トラブル時に責任の押し付け合いになります。

保守運用フェーズの具体的なポイントはシステムの保守運用ガイドで詳しく解説しています。

開発手法の違い：ウォーターフォール vs アジャイル

システム開発の進め方には大きく2種類あり、プロジェクトの性質に応じて選ぶことが重要です。

観点	ウォーターフォール	アジャイル
進め方	7工程を順番に一方向へ進む	要件〜テストを短いサイクルで繰り返す
向いている案件	要件が明確・大規模・予算固定	要件が変わる・スピード重視・新規事業
費用の見通し	立てやすい	立てにくい（変動あり）
仕様変更	対応コストが高い	柔軟に対応できる
発注者の関与	序盤に集中	全工程にわたり継続的に必要

新規事業のプロトタイプやMVP開発では、アジャイルで小さく作って検証するアプローチが増えています。一方、社内基幹システムの刷新など要件が明確なケースではウォーターフォールの方が予算管理しやすい傾向があります。

発注者がよく陥る失敗パターンと対策

システム開発の外注経験が少ない発注者が陥りやすい失敗は共通しています。

失敗1：要件定義で「おまかせ」にする

開発会社に丸投げすると、「仕様書には書いてないので対応外です」という状況が発生します。対策は、要件定義フェーズで発注者側の担当者が必ず同席し、業務フローを自分たちで言語化することです。

失敗2：基本設計のレビューを形式的に済ませる

「よくわからないのでOKにした」という承認がその後の手戻りを生みます。ワイヤーフレームやモックアップは、実際の業務フローに照らし合わせて「この画面で本当に業務が回るか」を確認してください。

失敗3：受入テストを開発会社任せにする

テストケースを開発会社が作成し、発注者が確認するだけでは業務上の抜け漏れが見つかりません。発注者側でも「実際の業務シナリオ」に基づいたテストケースを用意してください。

失敗4：運用保守の契約を後回しにする

リリース後に「このバグは誰が直すのか」「費用はいくらか」で揉めるケースが多発しています。リリース前に保守契約の範囲・費用・SLAを明文化しておくことが必須です。

よくある外注トラブルの具体的な事例はシステム開発の外注トラブル事例集でまとめています。

よくある質問

システム開発の流れ全体でどのくらいの期間がかかりますか？

規模によって大きく異なります。中規模のWebシステム（画面数20〜30程度）で6〜12ヶ月が目安です。MVP開発であれば2〜4ヶ月でリリースするケースもあります。要件定義と設計で全体の30〜40%の時間をかけることが、後工程の手戻りを減らすポイントです。

発注者はどの工程に一番時間を使うべきですか？

要件定義と受入テストの2工程です。要件定義で仕様を正確に伝えることと、受入テストで業務シナリオに沿った確認を行うことが、プロジェクト成功の鍵です。設計や実装フェーズは開発会社主体で進みますが、週次の進捗確認は欠かさず行ってください。

アジャイル開発とウォーターフォールはどちらを選べばよいですか？

要件が明確に決まっていて変更が少ないなら ウォーターフォール 、市場ニーズを試しながら作りたい新規事業や、仕様が変わる可能性が高い場合は アジャイル が向いています。どちらの場合も、発注者側に継続的に関与できるPM担当者を置くことが重要です。

開発会社への発注前に何を準備すればよいですか？

「何のために・誰が・どう使うシステムか」をA4一枚でまとめた要求概要（RFP：提案依頼書）を用意することを推奨します。目的・想定機能・予算上限・希望納期・社内体制を明示すると、開発会社から精度の高い提案・見積もりを得られます。

まとめ

システム開発の流れを7ステップで整理すると、発注者が特に重要な工程は以下の3つです。

• 要件定義 ：業務要件・機能要件・非機能要件を漏れなく言語化し、仕様変更のリスクを最小化する
• 基本設計レビュー ：ワイヤーフレームを業務フローに照らして確認し、実装前に修正する
• 受入テスト（UAT） ：業務シナリオに基づいた自社テストケースで最終品質を担保する

システム開発プロセスの全体像を理解した上で、各フェーズで適切に関与することが、プロジェクト成功の最短経路です。まずは要件定義の前に自社の業務フローを整理し、開発会社に「伝わる言葉」で要求をまとめることから始めてみてください。