システム開発の流れを完全解説｜発注から納品までの全工程

「システム開発を外注したいけど、どんな流れで進むのかわからない」「発注する側は何をすればいいの？」という不安を抱えていませんか？

システム開発は、発注してから納品されるまでに複数の工程があり、発注者側にも重要な役割があります。流れを事前に把握しておくことで、スムーズなプロジェクト進行と満足のいくシステム導入につながります。

この記事では、システム開発の発注から納品・運用開始までの全工程を、発注者の視点からわかりやすく解説します。

システム開発の全体像｜7つの工程

システム開発は、大きく分けて以下の7つの工程で進みます。

工程	主な作業	発注者の関与度	期間目安
①企画・相談	課題整理、目的の明確化	★★★★★	1〜2週間
②要件定義	必要な機能・仕様の決定	★★★★★	2〜4週間
③設計	画面設計、データベース設計	★★★☆☆	2〜4週間
④開発（実装）	プログラミング	★★☆☆☆	1〜3ヶ月
⑤テスト	動作確認、バグ修正	★★★☆☆	2〜4週間
⑥納品・リリース	本番環境への反映	★★★★☆	1〜2週間
⑦運用・保守	改善、不具合対応	★★★☆☆	継続

それぞれの工程で何が行われるのか、発注者として何をすべきかを詳しく見ていきましょう。

工程① 企画・相談（プロジェクト開始前）

この工程でやること

• 現在の業務課題を洗い出す
• システム化する目的・ゴールを明確にする
• 予算感とスケジュールの目安を決める
• 開発会社に相談・見積もりを依頼する

発注者がすべきこと

最も重要なのは「なぜシステムが必要なのか」を言語化することです。「業務を効率化したい」だけでなく、「月末の請求書作成に毎回3日かかっている。これを1日に短縮したい」のように、具体的な課題と理想の状態を整理しましょう。

この段階でRFP（提案依頼書）を作成しておくと、開発会社とのコミュニケーションがスムーズになります。

FUNBREWの場合

初回のご相談では、まず業務の現状をヒアリングし、「本当にシステム開発が必要か」から一緒に考えます。既存のSaaSツールで解決できるケースもあるため、最適な方法をご提案しています。

工程② 要件定義（最も重要な工程）

この工程でやること

• システムに必要な機能を一覧化する
• 業務フロー（誰が・いつ・何をするか）を整理する
• 画面の数やデータの種類を洗い出す
• 非機能要件（セキュリティ、性能、対応デバイスなど）を決める

発注者がすべきこと

要件定義はシステム開発の成否を左右する最重要工程です。ここでの認識のズレは、後の工程すべてに影響します。

開発会社との打ち合わせでは、以下の点を意識しましょう。

• 実際にシステムを使う現場のスタッフの意見を集めておく
• 「あったらいいな」と「絶対に必要」を明確に分ける
• 例外的なケース（イレギュラー対応）も伝える

詳しい進め方は要件定義のやり方ガイドをご覧ください。

工程③ 設計

この工程でやること

設計は「基本設計（外部設計）」と「詳細設計（内部設計）」の2段階に分かれます。

設計の種類	内容	発注者の確認ポイント
基本設計	画面レイアウト、画面遷移、データベース構造	使いやすさ、業務フローとの整合性
詳細設計	プログラムの処理ロジック、API仕様	基本的にお任せでOK

発注者がすべきこと

基本設計の段階で画面イメージを必ず確認しましょう。ワイヤーフレーム（画面の骨組み）やプロトタイプを見せてもらい、実際の業務で使えるかどうかをチェックします。

「もう少しボタンを大きくしてほしい」「この項目は不要」といったフィードバックは、この段階で出すのが最もコストが低いです。開発が始まってからの変更は、費用と時間が大幅に増えます。

工程④ 開発（実装）

この工程でやること

• 設計書に基づいてプログラムを書く
• データベースを構築する
• 各機能の単体テストを行う

発注者がすべきこと

開発中は基本的に開発会社に任せる形になりますが、定期的な進捗確認は重要です。

• 週次または隔週で進捗報告を受ける
• 途中で仕様変更が必要になった場合は早めに相談する
• テスト用のデータや情報を求められたら速やかに提供する

開発手法によって進め方が異なります。ウォーターフォール型では工程を順番に進め、アジャイル型では短いサイクルで機能を少しずつ作っていきます。詳しくはウォーターフォールとアジャイルの違いをご参照ください。

工程⑤ テスト

この工程でやること

テストは複数の段階で行われます。

テストの種類	目的	実施者
単体テスト	各機能が正しく動くか確認	開発会社
結合テスト	機能同士の連携が正しいか確認	開発会社
システムテスト	本番と同じ環境での総合テスト	開発会社
受入テスト（UAT）	発注者の要件を満たしているか確認	発注者

発注者がすべきこと

受入テスト（UAT）は発注者の最も重要な作業です。実際の業務シナリオに沿ってシステムを操作し、以下の観点で確認しましょう。

• 要件定義で決めた機能がすべて揃っているか
• 実際の業務データを入れて正しく処理されるか
• 使い勝手は問題ないか（ボタンの位置、入力項目の順番など）
• エラー時に適切なメッセージが表示されるか
• レスポンス（処理速度）は許容範囲か

不具合や改善要望は「いつ・どの画面で・何をしたら・どうなったか」を具体的に記録して伝えましょう。

工程⑥ 納品・リリース

この工程でやること

• 本番環境へのデプロイ（システムの設置）
• データ移行（旧システムからのデータ引っ越し）
• 操作マニュアルの作成・研修
• 検収（最終確認と承認）

発注者がすべきこと

リリース前に以下を確認しましょう。

• データ移行の計画 — 旧システムのデータはどう移すか。移行後にデータが欠損していないか
• 操作研修の計画 — 現場のスタッフがスムーズに使い始められるよう、研修日程を決める
• 切り替え方法 — 旧システムと新システムを一定期間並行稼働させるか、一気に切り替えるか
• 緊急時の対応体制 — リリース直後に不具合が起きた場合の連絡先と対応フロー

工程⑦ 運用・保守

この工程でやること

• システムの監視（エラーや障害の検知）
• セキュリティアップデート
• 小規模な改修・機能追加
• 利用状況の分析と改善提案

発注者がすべきこと

システムは納品して終わりではなく、運用してからが本番です。保守契約を結び、継続的な改善体制を作りましょう。

システム保守の費用相場と契約のポイントも事前に確認しておくと安心です。

開発期間と費用の目安

システムの規模によって、全体の期間と費用は大きく変わります。

規模	例	期間目安	費用目安
小規模	社内ツール、簡易な管理画面	1〜3ヶ月	50万〜200万円
中規模	業務システム、顧客管理システム	3〜6ヶ月	200万〜800万円
大規模	ECサイト、基幹システム	6ヶ月〜1年	800万〜3000万円以上

費用の詳しい内訳についてはシステム開発の費用相場をご覧ください。

スムーズに進めるための5つのポイント

1. 目的とゴールを明確にする

「何のためにシステムを作るのか」が曖昧なまま進めると、途中で方向性がブレて、手戻りが発生します。企画段階で、経営層と現場の双方が納得するゴールを設定しましょう。

2. 社内の意思決定者を決めておく

仕様の確認やフィードバックに時間がかかると、開発全体が遅れます。「この件はこの人が決める」という意思決定のルートを事前に決めておきましょう。

3. 仕様変更のルールを決める

開発中に「やっぱりこの機能も追加したい」という要望はよく出ます。仕様変更のルール（追加費用の算出方法、承認フローなど）を契約時に取り決めておきましょう。

4. コミュニケーションの頻度を決める

「週1回の定例ミーティング」「チャットツールでの日常的な連絡」など、連絡手段と頻度をプロジェクト開始時に合意しておきましょう。

5. テスト期間を十分に確保する

スケジュールが押したときに削られがちなのがテスト期間です。受入テストの時間を十分に確保し、実際の業務シナリオでしっかり検証しましょう。

FUNBREWの開発スタイル

FUNBREWでは、企画段階でプロトタイプを作り、画面イメージを見ながら要件を詰めていくスタイルを採用しています。「実際に動くもの」を早い段階で確認できるため、「思っていたのと違う」という手戻りを最小限に抑えられます。

まとめ

システム開発は「企画→要件定義→設計→開発→テスト→納品→運用」の7つの工程で進みます。

• 企画・要件定義で発注者の関与が最も重要。ここに時間をかける
• 設計段階で画面イメージを必ず確認。変更は早いほど安い
• 受入テストは実際の業務シナリオで実施する
• 運用・保守まで含めた計画を立てる
• コミュニケーションの頻度と意思決定のルートを事前に決める

「システム開発を検討しているけど、まず何から始めればいい？」と思ったら、お問い合わせからお気軽にご相談ください。業務の課題整理からお手伝いします。