システム開発の流れ・工程を発注者向けに解説｜要件定義から納品まで【初めての外注】
システム開発を初めて外注するとき、「何を準備すればよいか」「途中で何を確認すべきか」が分からないのは自然なことです。
発注者が最初から技術仕様を決める必要はありません。ただし、業務上の目的と判断すべきタイミングを知らないまま丸投げすると、完成後に「想像していた使い方と違う」という問題が起きやすくなります。
この記事では、初めてシステム開発を依頼する中小企業の担当者向けに、工程ごとに発注者が行うことを解説します。
システム開発の工程・流れ【早見表】
| 工程 | 主な内容 | 発注者が確認すること |
|---|---|---|
| 企画・課題整理 | 目的、対象業務、予算を整理 | 何を改善したいか |
| 要件定義 | 機能、利用者、データ、範囲を決定 | 必須機能と優先順位 |
| 設計 | 画面、操作、システム構成を設計 | 実際の業務で使えるか |
| 開発 | プログラムを実装 | 途中成果と変更点 |
| テスト | 機能・連携・安全性を確認 | 業務上の例外が含まれるか |
| 受入・納品 | 発注者が最終確認 | 合意した要件を満たすか |
| リリース・保守 | 本番運用、改善、障害対応 | 問い合わせ先と保守範囲 |
1. 企画・課題整理
最初に決めるのは「どんなシステムを作るか」ではなく、「どの業務の何を改善するか」です。
たとえば「顧客管理システムが欲しい」だけでは、必要な機能を判断できません。「顧客情報が複数のExcelに分散し、担当者しか最新状況を分からない」と整理できれば、一元管理、検索、権限、履歴といった候補が見えてきます。
必須現状の困りごと、利用者、期限、予算上限を共有します。おすすめ実際に使っているExcel、紙の帳票、メール文面も見せると、見積もりの精度が上がります。
2. 要件定義｜発注者が準備すること
要件定義では、システムが満たすべき条件を開発会社と合意します。主に次を決めます。
- 対象にする業務と対象外にする業務
- 利用者、管理者、承認者などの権限
- 必要な画面と機能
- 登録・検索・出力するデータ
- 外部サービスや既存システムとの連携
- 性能、セキュリティ、バックアップ
- 納期、予算、検収条件
発注者の役割は、技術的な実現方法を指定することではありません。「この入力は誰が、いつ行うか」「間違えた場合は誰が直すか」など、業務の事実と優先順位を伝えることです。
3. 設計｜画面と操作を確認する
設計工程では、要件を画面やデータの構造へ落とし込みます。発注者が主に確認するのは画面設計です。
項目名が現場の言葉と合っているか、スマートフォンで使う場面が考慮されているか、一覧から次の作業へ迷わず進めるかを確認します。完成後の修正より、この段階での修正のほうが負担を抑えやすくなります。
4. 開発｜途中で動くものを確認する
開発会社が設計に基づいて実装します。発注者側は何もせず待つのではなく、定期的なレビューへ参加します。
画面ごと、機能ごとに途中成果を確認できると、認識違いを早期に発見できます。追加要望が出た場合は、その場で口頭依頼せず、費用・納期・ほかの機能への影響を確認して変更として記録しましょう。
5. テスト｜開発会社と発注者の確認は別
開発会社は、入力、計算、権限、外部連携などが設計どおり動くかをテストします。その後、発注者が行うのが受入テストです。
受入テストでは、現場担当者が普段の業務に近いデータを使います。月末処理、差し戻し、キャンセル、同姓同名、入力漏れなど、日常で起きる例外も確認してください。
6. 納品・リリース
受入条件を満たしたら、本番環境へリリースします。データ移行、利用者登録、操作説明、旧運用からの切り替え日も計画に含めます。
納品時には、管理者アカウント、操作資料、ソースコードやデータの扱い、障害時の連絡先を確認します。「納品」の定義が公開日なのか、検収完了日なのかも契約前に揃えておくと安心です。
7. 保守運用・改善
システムは公開して終わりではありません。不具合対応、OSや外部サービスの変更、バックアップ、利用者からの改善要望に対応します。
保守契約では、対応時間、月額内に含まれる作業、追加開発の見積もり方法を確認してください。利用状況を見て機能を追加する前提なら、初回開発を必要最小限に絞れます。
ウォーターフォールとアジャイルの違い
| 比較 | ウォーターフォール | アジャイル |
|---|---|---|
| 進め方 | 工程を順番に完了 | 短い開発単位を反復 |
| 向く案件 | 要件・納期が明確 | 触りながら改善したい |
| 変更 | 後半ほど影響が大きい | 優先順位を調整しやすい |
| 発注者の参加 | 節目ごとの確認 | 頻繁な確認が必要 |
名称だけで選ぶのではなく、誰がどの頻度で判断するか、追加変更をどう見積もるかを開発会社と確認することが大切です。
システム開発でよくある失敗
- 必須機能と将来機能を分けず、予算と期間が膨らむ
- 経営者だけで決め、実際の利用者が完成後に初めて触る
- データ移行や操作教育を開発範囲に含めていない
- 安さだけで比較し、見積もりに含まれる工程を確認しない
開発期間の目安
小規模な管理ツールは2〜3か月、中規模の業務システムは3〜6か月程度が一つの目安です。外部連携、複雑な権限、大量のデータ移行、関係部署の多さで期間は延びます。
費用の内訳と規模別の目安はシステム開発の費用相場、依頼先を比較するポイントはシステム開発会社の選び方で詳しく解説しています。既存システムの作り替えはシステムリプレイスの進め方をご覧ください。システム・アプリ開発では、要件整理から保守までご相談いただけます。
まとめ
システム開発は、企画、要件定義、設計、開発、テスト、納品、保守の順で進みます。発注者が技術仕様を作る必要はありませんが、業務の目的、優先順位、受入条件を判断する役割は欠かせません。
現在のExcelや帳票を出発点に、必須機能から小さく始めると、認識違いと過剰開発を抑えやすくなります。
よくある質問
Q. システム開発はどのような流れで進みますか？
A. 一般に、企画・課題整理、要件定義、設計、開発、テスト、受入テスト、リリース、保守運用の順で進みます。小規模開発やアジャイル開発では、設計からテストまでを短い単位で繰り返します。
Q. 要件定義で発注者が準備するものは何ですか？
A. 現在使っているExcelや帳票、業務の流れ、利用者と権限、困っている場面、希望時期、予算の上限を準備すると話が早くなります。機能一覧を完成させておく必要はありません。
Q. システム開発にはどのくらいの期間がかかりますか？
A. 小規模な業務ツールは2〜3か月、中規模の業務システムは3〜6か月程度が一つの目安です。機能数、外部連携、データ移行、関係者数によって変わります。
Q. ウォーターフォールとアジャイルはどちらを選ぶべきですか？
A. 要件が明確で変更が少ないならウォーターフォール、実際に触りながら優先順位を調整したいならアジャイルが向きます。開発名ではなく、確認頻度、変更の扱い、予算管理の方法を確認してください。
Q. 発注者による受入テストは必要ですか？
A. 必要です。開発会社のテストで不具合がなくても、実際の業務手順や例外ケースに合うとは限りません。現場担当者が実データに近い条件で確認しましょう。