システム開発の流れ｜工程ごとの作業と発注者の役割
「開発会社に依頼したら、あとは完成を待てばいいのだろうか」「打ち合わせで何を聞かれ、何を決めればいいのかわからない」。初めてシステム開発を発注する担当者の多くが、開発の流れの中で自分が何をすべきかをつかめずに不安を抱えています。実際には、システム開発は発注者が参加しなければ進まない場面が数多くあります。
この記事では、システム開発の流れを「企画」から「運用・保守」までの7段階に分け、各段階で開発会社が行う作業と、発注者が担う役割・判断事項を対応させて解説します。発注者の負荷がかかる時期や、社内でそろえておくべき体制もまとめています。
- システム開発は企画→要件定義→設計→開発→テスト→リリース→運用・保守の流れで進みます。
- 発注者の負荷が特に高いのは要件定義と受入テストの2つの時期です。
- 発注者の役割は「業務を説明する」「判断・承認する」「確認する」「社内に展開する」の4つに整理できます。
- 各段階の終わりで何を承認するかを決めておくと、手戻りや認識のずれを防げます。
目次
システム開発の流れとは？全体像と発注者の関わり方
システム開発の流れとは、システム化の目的を決めてから、要件を定義し、設計・開発・テストを経て稼働させ、その後の運用・保守に至るまでの一連の手順のことです。多くの受託開発では、前の工程を完了させてから次に進む「ウォーターフォール型」で進められます。
この流れの中で、開発会社は設計やプログラミングなど技術的な作業を担い、発注者は業務の知識を提供し、節目ごとに内容を判断・承認します。どちらかが欠けると、使われないシステムや手戻りが発生します。つまり、システム開発の流れは「開発会社の作業工程」であると同時に「発注者の意思決定の流れ」でもあります。
システム開発の流れと発注者の負荷（イメージ）
各段階の作業と発注者の役割
ここからは7つの段階ごとに、開発会社の作業と発注者の役割を整理します。各工程の定義や成果物の一覧は、別記事の工程一覧で詳しく解説しています。
1. 企画：目的と範囲を決める
システム化の目的、対象業務、予算、稼働時期を決める段階です。主役は発注者で、開発会社への相談や見積もり依頼もここに含まれます。発注者の役割は「なぜ作るのか」を言語化し、社内の合意を取ることです。目的があいまいなまま次に進むと、要件が膨らみ続ける原因になります。
2. 要件定義：何を作るかを合意する
業務のヒアリングをもとに、システムに必要な機能や性能を決める段階です。開発会社が質問し整理しますが、答えを持っているのは発注者です。現場の業務の流れ、例外処理、帳票などを説明し、要件の優先度を判断します。最後に要件定義書を承認することが、発注者にとって最も重要な判断になります。
3. 設計：画面や帳票の姿を確認する
要件をもとに、画面・帳票・データ構造・処理の仕組みを具体化する段階です。技術的な内部設計は開発会社が担いますが、画面レイアウトや入力項目、帳票の形式など利用者から見える部分は発注者が確認します。「この画面でこの業務ができるか」という視点で確認しましょう。
4. 開発：進捗を確認し、移行準備を進める
設計に基づいてプログラムを作る段階で、発注者の負荷は比較的少なくなります。ただし定例会で進捗や課題を確認し、仕様の問い合わせにはすぐ回答することが大切です。この時期に、旧システムやExcelからの移行データの整理、受入テストの準備を並行して進めると後が楽になります。
5. テスト：実際の業務で使えるか確かめる
開発会社による単体テスト・結合テスト・総合テストの後、発注者が受入テストを行います。受入テストでは、実際の業務の流れや過去のデータを使い、要件どおりに動くか、業務で使えるかを確認します。ここで見落とした不具合は稼働後に発覚するため、現場担当者を巻き込んで十分な時間を確保しましょう。
関連記事受入テスト（UAT）の進め方と検収のチェックポイント
6. リリース：社内に展開し、稼働を判定する
本番環境への移行、データ移行、利用者への操作研修を経て、システムを稼働させる段階です。発注者は稼働してよいかを最終判断し、現場への周知や問い合わせ窓口の設置を行います。旧システムとの並行運用期間を設けるかどうかもここで決めます。
7. 運用・保守：使いながら改善する
稼働後は、日々の運用と、障害対応・修正・機能改善などの保守が続きます。発注者は利用状況や改善要望を集め、保守会社と優先順位を相談します。保守費用は年間で開発費の10〜15％程度が一つの目安です。
発注者の役割早見表
| 段階 | 開発会社の主な作業 | 発注者の主な役割 | 発注者が承認するもの |
|---|---|---|---|
| 企画 | 相談対応・概算見積もり | 目的・予算・時期の決定 | 発注先・契約 |
| 要件定義 | ヒアリング・要件整理 | 業務説明・優先度判断 | 要件定義書 |
| 設計 | 画面・データ・処理の設計 | 画面・帳票の確認 | 基本設計書 |
| 開発 | プログラミング・単体テスト | 進捗確認・移行データ準備 | （変更がある場合のみ） |
| テスト | 結合・総合テスト | 受入テストの実施 | 検収 |
| リリース | 本番移行・研修支援 | 社内展開・稼働判定 | 稼働可否 |
| 運用・保守 | 障害対応・改修 | 要望の集約・優先度判断 | 改修内容・保守契約 |
発注者側でそろえておきたい体制
小規模な企業では1人が複数の役割を兼ねることもありますが、「誰が決めるのか」だけは必ず明確にしておきましょう。判断者が不在のまま進むと、後から決定が覆り手戻りの原因になります。
関連記事システム開発を外注する流れ｜相談から納品まで8ステップ
発注者が各段階で準備しておくもの
各段階の作業をスムーズに進めるには、発注者側で事前に用意しておくと効果的な資料や情報があります。開発会社から依頼される前に準備しておくと、打ち合わせの回数と期間を減らせます。
| 段階 | 準備しておくもの |
|---|---|
| 企画 | システム化の目的、予算の上限感、稼働希望時期、社内の決裁ルート |
| 要件定義 | 業務フローのメモ、使っているExcelや帳票、業務ルールの一覧 |
| 設計 | 画面や帳票の要望、現在の帳票のサンプル、利用端末の情報 |
| 開発 | 移行対象データの整理、マスタ（得意先・商品など）のクリーニング |
| テスト | 業務シナリオ、テスト用の実データ、参加する現場担当者の予定 |
| リリース | 操作研修の日程、社内への周知文、問い合わせ窓口 |
特に移行データの整理は見落とされやすい作業です。旧システムやExcelのデータに重複や表記ゆれがあると、移行作業が長引いて稼働日に影響します。開発期間中の比較的手が空く時期に進めておきましょう。
よくある質問
- 発注者は開発中に何もしなくてよいのですか？
- 開発中は負荷が下がりますが、定例会での進捗確認や仕様の問い合わせへの回答は必要です。この時期に移行データの整理や受入テストの準備を進めておくと、後の工程がスムーズになります。
- IT担当者がいなくてもシステム開発を進められますか？
- 進められます。必要なのは技術知識よりも業務の知識と判断できる体制です。業務をよく知る担当者と決裁者を決め、専門的な部分は開発会社に説明を求めながら進めましょう。
- アジャイル開発でも流れは同じですか？
- 要件定義から運用までの要素は同じですが、アジャイル開発では短い期間で設計・開発・テストを繰り返します。発注者は各周期の終わりに成果物を確認し、次に作る機能の優先度を判断する役割を継続的に担います。
まとめ
システム開発は企画から運用・保守までの7段階で進み、各段階で発注者には業務説明・判断・確認・社内展開という役割があります。特に要件定義と受入テストの時期は発注者の負荷が高いため、体制と時間を事前に確保しておくことが成功の近道です。
この記事に関連するサービス
受託システム開発
業務システム・Webシステム・基幹システムを、要件が固まる前のご相談から設計・開発・運用保守まで一貫して開発します。プロトタイプで早い段階から画面を確認でき、開発資産の活用で品質を… サービスの詳細を見る
