システム開発を発注する前に、まず押さえておきたいのが「全体の流れ」です。
「どの工程に時間がかかるのか」「自分たちは何をすればいいのか」「何が決まったらリリースなのか」——これらを理解しないまま進めると、要件のズレ・予算超過・納期遅延といった、よくある失敗を必ず踏みます。
本記事では、年間100社以上のシステム開発を支援する株式会社LUCRISの知見をもとに、システム開発の全工程を9つに分けて、各工程の目的・期間・成果物・発注側がやるべきことまで網羅的に解説します。費用相場についてはこちらの記事と合わせて読むと、発注前の準備が完璧になります。
システム開発の全体像【9工程マップ】
システム開発は、大きく分けて「企画」「設計」「実装」「テスト」「導入」「運用」の6フェーズ・9工程で構成されます。それぞれ目的と成果物が異なり、前工程の品質が後工程に直接影響します。
全9工程の俯瞰
| # | 工程名 | 目的 | 主な成果物 | 費用比率 |
|---|---|---|---|---|
| ① | 要件定義 | 「何を作るか」を決める | 要件定義書、機能一覧 | 10〜15% |
| ② | 基本設計（外部設計） | システムの「外側」を設計 | 画面遷移図、ER図、API設計書 | 10〜12% |
| ③ | 詳細設計（内部設計） | プログラムの「内側」を設計 | クラス設計書、モジュール仕様書 | 8〜12% |
| ④ | プログラミング | 実際にコードを書く | ソースコード | 25〜35% |
| ⑤ | 単体テスト | 各機能が単独で動くか確認 | 単体テスト仕様書・結果報告書 | 5〜8% |
| ⑥ | 結合テスト | 機能同士の連携を確認 | 結合テスト仕様書・結果報告書 | 5〜8% |
| ⑦ | システムテスト | 本番想定で総合的に確認 | システムテスト報告書 | 5〜7% |
| ⑧ | 受け入れテスト・リリース | 発注者が最終確認 → 公開 | UAT報告書、納品物一式 | 3〜5% |
| ⑨ | 運用保守・改善 | 稼働後の運用・改善 | 監視レポート、改善提案書 | 月額10〜20% |
※ 費用比率は中小規模プロジェクトの一般的な目安。⑨は初期費用とは別、月額換算。
期間の目安
「工程＝時間配分」を理解することが発注成功の第一歩
多くの発注者が「プログラミング＝開発の中心」と考えがちですが、実際の工数配分はプログラミングが30%程度。残り70%は設計・テスト・運用準備です。この比率を理解せず「コードを書く時間が長いから安くしてくれ」と交渉すると、見積もりは下がっても品質が落ちます。
工程① 要件定義｜「何を作るか」を決める
すべての工程の中でもっとも重要なのが要件定義です。ここでの定義の精度が、プロジェクト全体の成否を9割決めます。
要件定義で決めること
- 業務要件：誰が、いつ、何のために使うシステムか
- 機能要件：システムが「できなければならないこと」の一覧
- 非機能要件：性能、可用性、セキュリティなど「ならなければならない状態」
- 優先順位：必須機能（Must）と望ましい機能（Want）の切り分け
- 制約条件：予算、納期、技術選定の制限
期間と費用
中規模プロジェクトの場合、要件定義に1〜2ヶ月かかるのが一般的です。費用は開発費全体の10〜15%。500万円のプロジェクトなら50〜75万円が目安となります。
発注側がやるべきこと
- 業務フローを「現状（As-Is）」と「あるべき姿（To-Be）」で整理
- 主要ユーザーへのヒアリング機会を提供
- 「絶対に必要な機能」と「あったら便利な機能」を明確に分ける
- 過去のシステム利用ログ・帳票サンプル・業務マニュアルを共有
要件定義を「短く・安く」は最も危険な選択
「要件定義は短い方が安く済む」と考えて2週間で済ませると、ほぼ100%後工程で手戻りが発生します。要件定義に2週間で済ませた結果、開発フェーズで100時間以上の追加修正が発生し、結局トータルで割高になる——これは最も多い失敗パターンです。
工程② 基本設計｜システムの「外側」を設計
要件定義をもとに、システムの「外から見える形」を設計する工程です。「外部設計」とも呼ばれます。
基本設計で決めること
- 画面構成・画面遷移（UI/UX設計）
- データベース構造（ER図）
- 外部システム連携の仕様（API設計）
- 帳票・出力フォーマット
- セキュリティ・認証方式
- 運用に必要な管理画面
成果物
画面遷移図、画面定義書、ER図、API仕様書、機能一覧表、システム構成図など。非エンジニアが見ても理解できるレベルで詳細化されます。
発注側のチェックポイント
この工程の終わりに必ず設計書をレビューします。「この画面で本当に業務が回るか」「現場担当者が操作できるか」を、実際の業務担当者に確認してもらうことが重要です。
プロトタイプ作成を依頼するのも有効
基本設計の段階で簡易プロトタイプ（モックアップ）を作成してもらえば、完成イメージのズレを早期発見できます。Figma等での画面プロトでもOK。追加費用が発生する場合もありますが、後工程の手戻りを防ぐ投資としては安いものです。
工程③ 詳細設計｜プログラムの「内側」を設計
基本設計を実装可能なレベルまで落とし込む工程です。「内部設計」とも呼ばれ、プログラマーが実装する際の設計図となります。
詳細設計で決めること
- クラス・モジュール構造
- 関数・メソッドの仕様（入力/出力/処理ロジック）
- データベースの物理設計（テーブル、インデックス）
- 例外処理・エラーハンドリングのルール
- ログ出力の仕様
- テストケース設計
発注側の関わり
この工程は技術色が強いため、発注側が直接レビューすることは少ないです。ただし、「業務影響のある仕様変更」は確認の機会を設けてもらうべきです。設計レビュー会への参加権を確保しておくと安心です。
工程④ プログラミング｜設計書をコードに翻訳する
もっとも工数の大きい工程ですが、設計書が完璧なら「翻訳作業」に近い性質を持ちます。逆に設計が不十分だとプログラマーが解釈に迷い、実装スピードが落ちます。
進捗管理のポイント
- 週次の進捗レポートを必須にする
- 実装済み機能のデモを月1回以上見る機会を確保
- 機能ごとの完了基準（DoD: Definition of Done）を事前合意
- 仕様変更があった場合の影響範囲を即座に確認できる体制
AI活用で工数が30〜50%削減
2025年以降、Claude CodeやGitHub Copilotを始めとする生成AIの活用で、コーディング工数が大幅に削減されています。AI活用前提の開発会社を選べば、従来比で2〜3割安く・速く実装できます。
工程⑤ 単体テスト｜機能ごとの動作確認
プログラマーが実装した機能ひとつずつを、独立して動作確認するテストです。「ユニットテスト」とも呼ばれます。
確認内容
- 仕様書通りの入力で正しい出力が得られるか
- 異常な入力に対して適切なエラー処理がされるか
- 境界値（最大値・最小値・空値など）で正しく動作するか
単体テストはテストコードとして実装されることが多く、自動化されているケースが一般的です。テストコードの保守性は、システムの長期運用コストに直結します。
工程⑥ 結合テスト｜機能同士の連携を確認
個別の機能を組み合わせて、業務シナリオに沿った動作確認を行うテストです。
確認内容
- 機能Aから機能Bへのデータ受け渡しが正しいか
- 外部システム連携（決済、CRM、基幹システム等）が正常か
- 業務フロー全体が想定通りに進むか
- 同時アクセスでも整合性が保たれるか
結合テストの軽視が最大の品質リスク
単体テストは丁寧でも、結合テストを軽視するとリリース後に「機能Aと機能Bを連携すると想定外の挙動」というバグが頻発します。結合テスト工数を削るのは絶対NGと覚えておきましょう。
工程⑦ システムテスト｜本番想定の総合確認
本番環境と同等の構成で、システム全体の動作を検証するテストです。「総合テスト」とも呼ばれます。
確認項目
- 機能テスト：全機能が業務シナリオで正しく動くか
- 性能テスト：想定ユーザー数・データ量で応答速度が許容範囲か
- 負荷テスト：ピーク時のアクセスで耐えられるか
- セキュリティテスト：脆弱性スキャン、不正アクセス対策の確認
- 障害テスト：サーバー停止時の挙動、データ復旧の確認
工程⑧ 受け入れテスト・リリース
発注者側が「依頼通りに作られているか」を確認する最終テスト（UAT: User Acceptance Test）と、本番環境への公開作業です。
受け入れテストの進め方
- 業務シナリオに沿ったテストケースを発注側で作成（または開発会社から提供）
- 実際に業務担当者が操作して動作確認
- 不具合・改善要望をリストアップ
- 致命的な不具合はリリース前に必ず修正、軽微な要望は次フェーズで対応
リリース作業
- 本番環境への構築・データ移行
- ドメイン・SSL証明書設定
- 監視・バックアップ体制の構築
- 関係者への展開（マニュアル配布、説明会開催）
「段階的リリース」で本番事故を最小化
大規模システムでは、いきなり全社導入せず、一部部署や少数ユーザーで試験運用 → 段階的に拡大するのが定石です。万が一不具合があっても影響範囲を限定でき、運用ノウハウも段階的に蓄積できます。
工程⑨ 運用保守・改善｜稼働後こそが本番
システムは「作って終わり」ではありません。リリース後の運用・改善が、長期的なROIを決定します。
運用保守に含まれるもの
| 分類 | 内容 | 頻度 |
|---|---|---|
| 監視・障害対応 | サーバー・アプリの稼働監視、障害発生時の対応 | 24時間 or 営業時間 |
| セキュリティ対応 | 脆弱性パッチ適用、SSL更新、不正アクセス監視 | 随時 / 月次 |
| 軽微改修 | 小さなバグ修正、軽微な要望対応 | 月次 |
| 機能追加 | 新規機能の開発（別契約となるケース多い） | 四半期 / 年次 |
| 運用報告 | 稼働状況、利用統計、改善提案のレポート | 月次 |
運用保守費の相場
初期開発費の10〜20%/年が一般的です。500万円のシステムなら年間50〜100万円、月額にして約4〜8万円。サーバー費用は別途かかります。
開発手法による流れの違い
ここまで解説した9工程は、もっとも一般的な「ウォーターフォール型」の流れです。実際には、システムの性質や要件の確定度合いによって、別の開発手法も選択されます。
ウォーターフォール
各工程を順番に進める。要件が明確で変更が少ないプロジェクトに最適。基幹系・大規模・規制業界向き。
アジャイル / スクラム
2〜4週間の短いサイクルを繰り返す。要件が変動しやすい / 早期リリースが必要なプロジェクト向き。
プロトタイピング
早期に試作品を作って検証 → 本開発。UI重視のシステムや、要件が固まっていない案件向き。
スパイラル
ウォーターフォールとアジャイルの中間。リスクの高い大規模プロジェクトで、段階的に詳細化していく。
選び方の目安
| 条件 | 推奨手法 |
|---|---|
| 要件が完全に固まっている / 規制業界（金融・医療） | ウォーターフォール |
| 要件が変動しやすい / Webサービス・新規事業 | アジャイル |
| UIの完成度が重要 / ユーザー検証が必要 | プロトタイピング |
| 大規模 / 段階的にリスクを潰したい | スパイラル |
発注側がフェーズ毎にやるべきこと
「お任せ」では成功しません。発注側もフェーズに応じた役割を果たすことが、プロジェクト成功の鍵です。
フェーズ別アクションリスト
| フェーズ | 発注側がやること |
|---|---|
| 要件定義 | 業務フロー整理、関係者ヒアリング、優先順位決定、過去資料共有 |
| 基本設計 | 画面遷移レビュー、業務担当者によるユーザビリティ確認 |
| 詳細設計 | 業務影響のある仕様変更だけ確認、設計レビュー会への参加 |
| プログラミング | 週次進捗レポート確認、月1回のデモへの参加 |
| テスト | テストケース作成への協力、不具合報告のレビュー |
| 受け入れテスト | 業務シナリオで実機テスト、本番リリース可否の最終判断 |
| 運用保守 | 月次運用報告のレビュー、改善要望のとりまとめ |
「丸投げ」は失敗の最短ルート
「専門家に任せたから大丈夫」と要件定義から手を引くと、現場の業務に合わないシステムが出来上がります。発注者の業務知識は誰にも代替できない資産です。週次の打ち合わせ参加と月次のデモ確認は、最低限の関わりとして死守してください。
プロジェクトを成功させる7つのポイント
1,000件以上の開発プロジェクト支援から見えた、成功するプロジェクトの共通点を7つにまとめました。
- 要件定義に予算の15%を確保する（短く済ませず、しっかり時間を使う）
- 「絶対必要」と「あったら便利」を明確に切り分ける（MVP発想）
- 現場担当者を要件定義から巻き込む（管理者だけで決めない）
- 週次の進捗レポート＋月次のデモを契約に明記する
- テスト工程の予算を死守する（25〜30%は確保）
- 段階的リリースを計画する（一斉導入は事故のもと）
- 運用保守契約をリリース前に締結する（稼働後の対応窓口を確保）
AI活用で開発フローはこう変わる【2026年最新】
2025〜2026年は、生成AI活用が開発フローを大きく変える転換期です。各工程でAIがどう活用されているかを整理します。
工程別AI活用
| 工程 | AI活用内容 | 削減効果 |
|---|---|---|
| 要件定義 | 業務ヒアリング議事録の自動整理、要件抜け漏れチェック | 20〜30% |
| 基本設計 | 類似事例の参照、ER図・画面遷移図のたたき台生成 | 20〜30% |
| 詳細設計 | 関数仕様の自動補完、設計書のドキュメント化 | 30〜40% |
| プログラミング | Claude Code等によるコード自動生成、リファクタリング | 40〜60% |
| 単体テスト | テストコードの自動生成、エッジケース提案 | 40〜50% |
| 結合テスト | テストシナリオの網羅性チェック | 20〜30% |
| 運用保守 | ログ自動分析、障害一次対応、改善提案の自動化 | 30〜50% |
プロジェクト全体での削減効果
各工程での削減効果を統合すると、プロジェクト全体で2〜3割の工数削減が現実的なラインです。これにより、従来1,000万円かかっていたシステムが700〜800万円で実現可能になっています。
AI活用ができる開発会社の見極め方
見積もり依頼時に「AIをどう活用していますか？」と質問してみましょう。具体的なツール名（Claude Code、GitHub Copilot、Cursor等）と工程別の活用方法を即答できる会社は、確実に工数を削減できます。曖昧な答えしかない会社は、従来手法のままなのでコスト面で劣ります。
用語集
- 要件定義
- 「何を作るか」を決める初期工程。業務要件・機能要件・非機能要件を整理する。
- 基本設計（外部設計）
- 画面、帳票、データ構造、外部システム連携などシステムの「外側」を設計する工程。
- 詳細設計（内部設計）
- プログラム内部の処理ロジック、クラス構造、関数仕様などを設計する工程。
- 単体テスト（ユニットテスト）
- 個々の機能・モジュールを単独で動作確認するテスト。
- 結合テスト
- 個別に作られた機能同士を組み合わせて、連携が正しく動くかを確認するテスト。
- システムテスト（総合テスト）
- 本番環境と同等の構成で、システム全体の動作・性能・セキュリティを検証するテスト。
- 受け入れテスト（UAT）
- User Acceptance Test。発注者側が「依頼通りに作られているか」を確認する最終テスト。
- ウォーターフォール開発
- 各工程を順番に進める開発手法。要件が明確なプロジェクトに最適。
- アジャイル開発
- 2〜4週間の短いサイクルを繰り返しながら開発を進める手法。要件変動に強い。
- MVP（Minimum Viable Product）
- 必要最小限の機能で構築した初期版。早期にユーザー検証することで、無駄な機能開発を防ぐ。
- DoD（Definition of Done）
- 「完了の定義」。各タスクが何をもって完了とみなされるかを事前に合意した基準。
よくある質問（FAQ）
システム開発の流れの中で、もっとも重要な工程はどれですか？
要件定義です。ここで決めた内容がプロジェクト全体の方向性を決めるため、後工程で大きな変更が発生すると工数が雪だるま式に膨らみます。要件定義に開発予算の15%程度をしっかり確保することを推奨します。
ウォーターフォールとアジャイル、どちらを選ぶべきですか？
要件が明確で変更が少ない場合（基幹系・規制業界）はウォーターフォール、要件が変動しやすい場合（Webサービス・新規事業）はアジャイルが向いています。判断に迷う場合、要件定義はウォーターフォール的に固め、実装はアジャイル的に進めるハイブリッド型も有効です。
発注側として、最低限どこまで関わる必要がありますか？
最低でも以下4つは死守してください：(1) 要件定義への積極参加、(2) 基本設計のレビュー、(3) 月1回のデモ確認、(4) 受け入れテストの実施。これらを怠ると、現場業務と合わないシステムが出来上がるリスクが高まります。
納期が遅れる主な原因は何ですか？
もっとも多いのは「要件変更」です。開発開始後の仕様変更は、影響範囲が大きく工数を大幅に増やします。次に多いのは「レビュー遅延」。発注側のフィードバックが遅れると、開発が止まります。週次の定例会で進捗とレビューの締切を厳守することが重要です。
テストはどのくらい時間をかけるべきですか？
開発全体の25〜30%程度を確保するのが目安です。「単体テスト 5〜8% / 結合テスト 5〜8% / システムテスト 5〜7% / 受け入れテスト 3〜5%」が一般的な配分です。テスト工数を削るとリリース後の障害対応コストが2〜3倍に膨らむため、絶対に削減すべきではありません。
運用保守は何が含まれていますか？
主に「サーバー・アプリの稼働監視」「セキュリティパッチ適用」「軽微なバグ修正」「月次運用報告」が含まれます。新機能追加や大幅改修は別契約となるケースが多いため、契約前に範囲を必ず確認してください。費用は初期開発費の年10〜20%が目安です。
受け入れテスト（UAT）は誰がやるべきですか？
実際の業務担当者が行うべきです。管理者やプロジェクトマネージャーだけで判断すると、現場の業務フローと合わない仕様が見逃されます。複数の担当者を巻き込み、業務シナリオに沿った操作テストを実施しましょう。
段階的リリースとは具体的にどう進めるのですか？
典型的なパターン：(1) 開発チーム内で動作確認、(2) 一部の協力的な部署で2〜4週間試験運用、(3) フィードバックを反映、(4) 関連部署に拡大、(5) 全社展開。各段階で問題があれば前段階に戻れる体制を作っておくことが、本番事故を防ぎます。
AI活用前提の開発を依頼すると、何が変わりますか？
主に「コーディング工数」「テストコード作成」「ドキュメント化」の3工程で大幅な時間短縮が見込めます。プロジェクト全体では2〜3割の工数削減が現実的なラインです。LUCRISでは全プロジェクトでAI活用を前提としており、従来比で見積もり額が3〜4割低い水準を実現しています。
開発会社を選ぶ際、何を確認すればよいですか？
(1) 類似業界の開発実績、(2) 「No」と言ってくれる提案力、(3) 見積もりの内訳の詳細さ、(4) 運用フェーズの体制、(5) 担当PMの顔が見えるか、(6) AI活用の具体性。詳しくはシステム開発の費用相場の記事でも解説しています。
まとめ
システム開発の流れを9工程で詳しく解説しました。最後に重要ポイントを5つにまとめます。
- システム開発は「企画→設計→実装→テスト→導入→運用」の6フェーズ・9工程
- もっとも重要なのは要件定義（予算の15%は確保）
- テスト工程は全体の25〜30%。削るとリリース後の障害コストが膨らむ
- 発注側も「要件定義への参加」「月次デモ確認」「受け入れテスト」は死守する
- 2026年現在、AI活用前提なら工数を2〜3割削減可能
システム開発の流れを理解しておくだけで、発注精度・プロジェクト成功率は大きく向上します。費用面についてはシステム開発の費用相場の記事を、開発会社の選び方については個別にご相談ください。
システム開発の無料相談・お見積り
株式会社LUCRISでは、AI活用前提の開発体制で
従来比3〜5割のコスト削減を実現しています。
要件定義からのご相談も歓迎です。
