- システム開発の流れは全9工程。「要件定義 → 基本設計 → 詳細設計 → プログラミング → 単体テスト → 結合テスト → システムテスト → 受け入れテスト・リリース → 運用保守」の順に進みます。
- 期間の目安は小規模1〜2ヶ月、中規模3〜6ヶ月、大規模6〜12ヶ月、基幹系12〜24ヶ月（いずれもケースにより変動）。本記事に規模別の工程表（スケジュール表）サンプルを掲載しています。
- 費用比率の目安は設計約30%・プログラミング約30%・テスト約25%・要件定義約15%。プログラミングだけが開発ではありません。
- 発注側の役割が成否を分けます。「丸投げ」せず、要件定義・基本設計レビュー・受け入れテストには必ず関与を。
- AI活用を前提にした開発体制なら、工程全体で2〜3割の工数削減が現実的なライン（ケースにより変動）。
結論：システム開発の流れは「要件定義からリリース・運用まで全9工程」であり、成功の鍵は「どの工程に時間がかかるか」「発注側が何をすべきか」を最初に理解しておくことです。
「プログラミングが開発の中心」という誤解のまま発注すると、要件のズレ・予算超過・現場で使われないシステム——という典型的な失敗を踏みます。実際は工数の約7割が設計・テスト・運用準備に費やされます。
本記事では、滋賀県を拠点に中小企業のDX・システム開発支援で培った知見をもとに、全9工程の目的・期間・成果物・費用比率・発注側がやるべきことを、工程表サンプル・流れ図・規模別のスケジュール感とともに網羅的に解説します。投資判断（費用対効果・回収期間）は業務システム化のROI計算の記事と合わせて読むと、発注前の準備が完璧になります。
システム開発の全体像【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%は設計・テスト・運用準備です。この比率を理解せず「コードを書く時間が長いから安くしてくれ」と交渉すると、見積もりは下がっても品質が落ちます。値引き交渉をするなら、機能の優先順位を絞る方向（スコープ調整）が正解です。
システム開発の流れ図【全工程フローチャート】
下のカードを上から順に読むと、システム開発の全体フローが矢印のようにつながります。各工程の成果物が、次の工程の「入力」になる——この連鎖を意識してください。上流（前半）の成果物の品質が低いと、その不備は下流（後半）にそのまま流れ込み、増幅されます。
要件定義
入力：業務課題・経営の要望
成果物：要件定義書・機能一覧
→ 次工程「基本設計」へ渡す
基本設計（外部設計）
入力：要件定義書
成果物：画面遷移図・ER図・API設計
→ 次工程「詳細設計」へ渡す
詳細設計（内部設計）
入力：基本設計書
成果物：クラス設計・モジュール仕様
→ 次工程「プログラミング」へ渡す
プログラミング
入力：詳細設計書
成果物：ソースコード
→ 次工程「単体テスト」へ渡す
単体テスト
入力：ソースコード・詳細設計
成果物：単体テスト結果報告書
→ 次工程「結合テスト」へ渡す
結合テスト
入力：動作確認済みの各機能
成果物：結合テスト結果報告書
→ 次工程「システムテスト」へ渡す
システムテスト
入力：連携確認済みのシステム
成果物：システムテスト報告書
→ 次工程「受け入れテスト」へ渡す
受け入れテスト・リリース
入力：完成したシステム
成果物：UAT報告書・納品物一式
→ 本番公開 →「運用保守」へ
運用保守・改善
入力：稼働中のシステム・利用ログ
成果物：監視レポート・改善提案
→ 改善要望は「要件定義」へ戻る
注目すべきは、工程⑨の運用保守が起点（工程①）に戻る点です。システムは一度作って終わりではなく、運用で得た気づきが次の改善要件になり、ループします。この「V字（左で設計→右でテスト）の連なりが、運用で円環になる」のがシステム開発フローの本質です。
V字モデルという見方
テスト工程は、対応する設計工程を「検証する」関係にあります。単体テストは詳細設計を、結合テストは基本設計を、受け入れテストは要件定義を検証する——これがV字モデルです。つまり「設計が雑だと、対応するテストで必ず破綻する」。流れ図を左右対称のVとして眺めると、どのテストで何が問われるかが直感的に理解できます。
システム開発の工程表（スケジュール表）サンプル｜規模別の期間配分
「工程表をどう作ればいいか分からない」という声は非常に多いです。ここでは規模別に、月単位のスケジュール表サンプルを掲載します。セル内の「●」がその工程を実施する期間を表します（実際には工程は一部オーバーラップしますが、ここでは分かりやすさを優先して整理しています）。
小規模プロジェクト（目安：合計約2ヶ月／100〜300万円）
| 工程 | 1ヶ月目 | 2ヶ月目 |
|---|---|---|
| 要件定義 | ●●● | |
| 基本・詳細設計 | ●● | ● |
| プログラミング | ●● | |
| テスト各種 | ● | |
| 受け入れ・リリース | ● |
中規模プロジェクト（目安：合計約5ヶ月／400〜1,000万円）
| 工程 | 1ヶ月目 | 2ヶ月目 | 3ヶ月目 | 4ヶ月目 | 5ヶ月目 |
|---|---|---|---|---|---|
| 要件定義 | ●● | ||||
| 基本設計 | ● | ● | |||
| 詳細設計 | ● | ||||
| プログラミング | ● | ●● | ● | ||
| 単体・結合テスト | ●● | ||||
| システムテスト | ● | ● | |||
| 受け入れ・リリース | ●● |
大規模プロジェクト（目安：合計約10ヶ月／1,000〜3,000万円）
| 工程 | 1-2月 | 3-4月 | 5-6月 | 7-8月 | 9-10月 |
|---|---|---|---|---|---|
| 要件定義 | ●●●● | ||||
| 基本設計 | ●● | ●● | |||
| 詳細設計 | ●●● | ● | |||
| プログラミング | ● | ●●● | ●● | ||
| 単体・結合テスト | ●● | ● | |||
| システムテスト | ● | ● | |||
| 受け入れ・リリース | ●● |
工程表を作るときのコツ
- バッファ（予備期間）を全体の10〜15%確保する。要件変更・レビュー遅延・連休を見越しておく
- 発注側のレビュー期間をスケジュールに明記する。「設計レビュー1週間」など、開発会社任せにしない
- マイルストーン（節目）を3〜5個設定する。「要件確定」「設計完了」「内部テスト完了」「リリース判定」など、関係者が同じ地図を持つ
- 各工程の「完了条件（成果物の承認）」を決めておく。曖昧なまま次工程に進めない
工程表は「契約書の別紙」にしておく
工程表を口頭合意で済ませると、遅延の責任所在が曖昧になります。マイルストーンと成果物を明記した工程表を見積書・契約書の別紙として添付してもらいましょう。「いつ・何が・誰の承認で完了するか」が文書化されていれば、進捗の認識ズレを大幅に減らせます。
システム開発の期間の目安はどれくらい？規模・手法別の早見表
「うちのシステム、どれくらいで完成しますか？」——これは最も多い質問のひとつです。正確な期間は要件次第ですが、おおまかなスケジュール感をつかむための早見表を用意しました。
規模別・期間の目安
期間を左右する3つの変数
| 変数 | 期間が短くなる条件 | 期間が長くなる条件 |
|---|---|---|
| 要件の確定度 | 業務フローが整理済み・既存システムの置き換え | 業務が未整理・ゼロからの新規構築・関係者が多い |
| 開発手法 | アジャイルで小さくリリース／既製パッケージ活用 | ウォーターフォールで全機能を一括開発 |
| 発注側の体制 | 意思決定者が明確・レビューが速い | 承認に時間がかかる・担当が兼務で多忙 |
手法別・スケジュール感の違い
| 手法 | 最初の成果が見えるまで | 全体完成まで | 向いているケース |
|---|---|---|---|
| ウォーターフォール | 遅い（リリース時） | 規模相応（一括） | 要件が固い・規制業界 |
| アジャイル | 速い（2〜4週） | 機能を足しながら継続 | 要件が変動・Web系 |
| パッケージ＋カスタマイズ | 速い | 短い（既製ベース） | 業務が標準的 |
※ 上記の期間・スケジュール感はいずれも一般的な目安であり、要件・体制・手法により変動します。
「最短でいつ？」より「最初の価値はいつ届くか？」
発注側が本当に知りたいのは総期間より「いつから業務が楽になるか」のはず。アジャイルやスモールスタート（後述）なら、全機能の完成を待たずに最重要機能だけを先行リリースできます。「全部できるまで半年」より「2ヶ月で一番困っている業務だけ先に解決」のほうが、現場の満足度もROIも高くなるケースが多くあります。
工程① 要件定義｜「何を作るか」を決める
すべての工程の中でもっとも重要なのが要件定義です。ここでの定義の精度が、プロジェクト全体の成否をほぼ決めると言っても過言ではありません。建築でいえば「設計図を描く前に、何階建てで誰が住むかを決める」工程です。
要件定義で決めること
- 業務要件：誰が、いつ、何のために使うシステムか
- 機能要件：システムが「できなければならないこと」の一覧
- 非機能要件：性能、可用性、セキュリティなど「ならなければならない状態」
- 優先順位：必須機能（Must）と望ましい機能（Want）の切り分け
- 制約条件：予算、納期、技術選定の制限
期間と費用の目安
中規模プロジェクトの場合、要件定義に1〜2ヶ月かかるのが一般的です。費用は開発費全体の10〜15%が目安。500万円のプロジェクトなら50〜75万円前後が目安となります（ケースにより変動）。
発注側がやるべきこと
- 業務フローを「現状（As-Is）」と「あるべき姿（To-Be）」で整理する
- 主要ユーザー（実際に毎日使う現場担当者）へのヒアリング機会を提供する
- 「絶対に必要な機能」と「あったら便利な機能」を明確に分ける
- 過去のシステム利用ログ・帳票サンプル・業務マニュアルを共有する
- 意思決定者を1人決め、「最後は誰が決めるか」を明確にしておく
要件定義を「短く・安く」は最も危険な選択
「要件定義は短い方が安く済む」と考えて2週間で済ませると、ほぼ確実に後工程で手戻りが発生します。要件定義を急いだ結果、開発フェーズで大量の追加修正が発生し、結局トータルで割高になる——これは最も多い失敗パターンのひとつです。上流の1時間の議論が、下流の10時間の手戻りを防ぎます。
工程② 基本設計｜システムの「外側」を設計
要件定義をもとに、システムの「外から見える形」を設計する工程です。発注側が最後にしっかりレビューできる、実質的に最後の砦でもあります。
基本設計で決めること
- 画面構成・画面遷移（UI/UX設計）
- データベース構造（ER図）
- 外部システム連携の仕様（API設計）
- 帳票・出力フォーマット
- セキュリティ・認証方式
- 運用に必要な管理画面
成果物
画面遷移図、画面定義書、ER図、API仕様書、機能一覧表、システム構成図など。非エンジニアが見ても理解できるレベルで詳細化されます。
発注側のチェックポイント
この工程の終わりに必ず設計書をレビューします。「この画面で本当に業務が回るか」「現場担当者が操作できるか」を、実際の業務担当者に確認してもらうことが重要です。ここを飛ばすと、完成後に「思っていたのと違う」となり、最も高くつく手戻りが発生します。
プロトタイプ作成を依頼するのも有効
基本設計の段階で簡易プロトタイプ（モックアップ）を作成してもらえば、完成イメージのズレを早期発見できます。Figma等での画面プロトでもOK。追加費用が発生する場合もありますが、後工程の手戻りを防ぐ投資としては安いものです。
工程③ 詳細設計｜プログラムの「内側」を設計
基本設計を実装可能なレベルまで落とし込む工程です。「内部設計」とも呼ばれ、プログラマーが実装する際の設計図となります。
詳細設計で決めること
- クラス・モジュール構造
- 関数・メソッドの仕様（入力/出力/処理ロジック）
- データベースの物理設計（テーブル、インデックス）
- 例外処理・エラーハンドリングのルール
- ログ出力の仕様
- テストケース設計
発注側の関わり
この工程は技術色が強いため、発注側が直接レビューすることは少ないです。ただし、「業務影響のある仕様変更」は確認の機会を設けてもらうべきです。設計レビュー会への参加権を契約段階で確保しておくと安心です。
工程④ プログラミング｜設計書をコードに翻訳する
もっとも工数の大きい工程ですが、設計書が完璧なら「翻訳作業」に近い性質を持ちます。逆に設計が不十分だとプログラマーが解釈に迷い、実装スピードが落ちます。
進捗管理のポイント
- 週次の進捗レポートを必須にする
- 実装済み機能のデモを月1回以上見る機会を確保する
- 機能ごとの完了基準（DoD: Definition of Done）を事前合意する
- 仕様変更があった場合の影響範囲を即座に確認できる体制を作る
AI活用でコーディング工数が削減
2025年以降、Claude CodeやGitHub Copilotをはじめとする生成AIの活用で、コーディング工数が大幅に削減されています。AI活用を前提とする開発会社を選べば、従来比で工数を抑えた実装が期待できます（削減幅はプロジェクトの性質によって変動します）。詳しくはAI活用で開発フローはこう変わるのセクションで解説します。
工程⑤ 単体テスト｜機能ごとの動作確認
プログラマーが実装した機能ひとつずつを、独立して動作確認するテストです。料理でいえば「全部混ぜる前に、各食材を味見する」段階です。
確認内容
- 仕様書通りの入力で正しい出力が得られるか
- 異常な入力に対して適切なエラー処理がされるか
- 境界値（最大値・最小値・空値など）で正しく動作するか
単体テストはテストコードとして実装されることが多く、自動化されているケースが一般的です。テストコードの保守性は、システムの長期運用コストに直結します。
工程⑥ 結合テスト｜機能同士の連携を確認
個別の機能を組み合わせて、業務シナリオに沿った動作確認を行うテストです。
確認内容
- 機能Aから機能Bへのデータ受け渡しが正しいか
- 外部システム連携（決済、CRM、基幹システム等）が正常か
- 業務フロー全体が想定通りに進むか
- 同時アクセスでも整合性が保たれるか
結合テストの軽視が最大の品質リスク
単体テストは丁寧でも、結合テストを軽視するとリリース後に「機能Aと機能Bを連携すると想定外の挙動」というバグが頻発します。結合テスト工数を削るのは絶対NGと覚えておきましょう。各部品が完璧でも、つなぎ目で問題が起きるのがシステムです。
工程⑦ システムテスト｜本番想定の総合確認
本番環境と同等の構成で、システム全体の動作を検証するテストです。「総合テスト」とも呼ばれます。
確認項目
- 機能テスト：全機能が業務シナリオで正しく動くか
- 性能テスト：想定ユーザー数・データ量で応答速度が許容範囲か
- 負荷テスト：ピーク時のアクセスで耐えられるか
- セキュリティテスト：脆弱性スキャン、不正アクセス対策の確認
- 障害テスト：サーバー停止時の挙動、データ復旧の確認
工程⑧ 受け入れテスト・リリース
発注者側が「依頼通りに作られているか」を確認する最終テスト（UAT: User Acceptance Test）と、本番環境への公開作業です。発注側が主役になる、唯一にして最重要のテストです。
受け入れテストの進め方
- 業務シナリオに沿ったテストケースを発注側で作成（または開発会社から提供してもらう）
- 実際に業務担当者が操作して動作確認する
- 不具合・改善要望をリストアップする
- 致命的な不具合はリリース前に必ず修正、軽微な要望は次フェーズで対応する
リリース作業
- 本番環境への構築・データ移行
- ドメイン・SSL証明書設定
- 監視・バックアップ体制の構築
- 関係者への展開（マニュアル配布、説明会開催）
「段階的リリース」で本番事故を最小化
大規模システムでは、いきなり全社導入せず、一部部署や少数ユーザーで試験運用 → 段階的に拡大するのが定石です。万が一不具合があっても影響範囲を限定でき、運用ノウハウも段階的に蓄積できます。
工程⑨ 運用保守・改善｜稼働後こそが本番
システムは「作って終わり」ではありません。リリース後の運用・改善が、長期的なROIを決定します。投資判断の考え方は業務システム化のROI計算の記事で詳しく解説しています。
運用保守に含まれるもの
| 分類 | 内容 | 頻度 |
|---|---|---|
| 監視・障害対応 | サーバー・アプリの稼働監視、障害発生時の対応 | 24時間 or 営業時間 |
| セキュリティ対応 | 脆弱性パッチ適用、SSL更新、不正アクセス監視 | 随時 / 月次 |
| 軽微改修 | 小さなバグ修正、軽微な要望対応 | 月次 |
| 機能追加 | 新規機能の開発（別契約となるケース多い） | 四半期 / 年次 |
| 運用報告 | 稼働状況、利用統計、改善提案のレポート | 月次 |
運用保守費の相場の目安
初期開発費の年10〜20%が一般的な目安です。500万円のシステムなら年間50〜100万円、月額にして約4〜8万円が目安（ケースにより変動）。サーバー費用は別途かかります。操作ログや監査証跡の管理が必要な業種では、操作ログ・監査証跡管理システムの記事もあわせてご確認ください。
開発手法による流れの違い｜ウォーターフォールとアジャイル
ここまで解説した9工程は、もっとも一般的な「ウォーターフォール型」の流れです。実際には、システムの性質や要件の確定度合いによって、別の開発手法も選択されます。
ウォーターフォール
各工程を順番に進める。要件が明確で変更が少ないプロジェクトに最適。基幹系・大規模・規制業界向き。
アジャイル / スクラム
2〜4週間の短いサイクルを繰り返す。要件が変動しやすい / 早期リリースが必要なプロジェクト向き。
プロトタイピング
早期に試作品を作って検証 → 本開発。UI重視のシステムや、要件が固まっていない案件向き。
スパイラル
ウォーターフォールとアジャイルの中間。リスクの高い大規模プロジェクトで、段階的に詳細化していく。
ウォーターフォールとアジャイルの流れの違い
| 観点 | ウォーターフォール | アジャイル |
|---|---|---|
| 進め方 | 9工程を順番に1回ずつ通す | 小さな開発サイクルを何度も繰り返す |
| リリース | 最後にまとめて1回 | 機能ごとに小刻みに何度も |
| 仕様変更 | 後工程ほど高コスト・苦手 | サイクル単位で柔軟に対応 |
| 進捗の見え方 | ドキュメントで管理 | 動くソフトで確認 |
| 向くケース | 要件が固い・規制業界・大規模 | 要件が変動・Web系・新規事業 |
選び方の目安
| 条件 | 推奨手法 |
|---|---|
| 要件が完全に固まっている / 規制業界（金融・医療） | ウォーターフォール |
| 要件が変動しやすい / Webサービス・新規事業 | アジャイル |
| UIの完成度が重要 / ユーザー検証が必要 | プロトタイピング |
| 大規模 / 段階的にリスクを潰したい | スパイラル |
中小企業はハイブリッドが現実解
「要件定義は丁寧にウォーターフォール的に固め、実装はアジャイル的に小さくリリースする」——このハイブリッドが、中小企業のシステム開発では最も現実的です。土台（業務の根幹）はブレないように設計し、画面や細かい機能は使いながら調整する。完璧な二者択一にこだわる必要はありません。
発注側がフェーズ毎にやるべきこと
「お任せ」では成功しません。発注側もフェーズに応じた役割を果たすことが、プロジェクト成功の鍵です。とくに、発注側が最初にやるべきことは「業務課題の整理」と「意思決定者の明確化」です。何を解決したいのかが曖昧なまま開発会社に相談しても、的確な提案は返ってきません。
フェーズ別アクションリスト
| フェーズ | 発注側がやること |
|---|---|
| 発注前（準備） | 解決したい業務課題の言語化、意思決定者の決定、概算予算の把握 |
| 要件定義 | 業務フロー整理、関係者ヒアリング、優先順位決定、過去資料共有 |
| 基本設計 | 画面遷移レビュー、業務担当者によるユーザビリティ確認 |
| 詳細設計 | 業務影響のある仕様変更だけ確認、設計レビュー会への参加 |
| プログラミング | 週次進捗レポート確認、月1回のデモへの参加 |
| テスト | テストケース作成への協力、不具合報告のレビュー |
| 受け入れテスト | 業務シナリオで実機テスト、本番リリース可否の最終判断 |
| 運用保守 | 月次運用報告のレビュー、改善要望のとりまとめ |
「丸投げ」は失敗の最短ルート
「専門家に任せたから大丈夫」と要件定義から手を引くと、現場の業務に合わないシステムが出来上がります。発注者の業務知識は誰にも代替できない資産です。週次の打ち合わせ参加と月次のデモ確認は、最低限の関わりとして死守してください。
【失敗事例から学ぶ】よくある進め方の失敗と回避策
ここでは、一般的なモデルケースとして、システム開発でよく見られる失敗のパターンと、その回避策を解説します。自社のプロジェクトに当てはまる兆候がないか、チェックしながら読んでください。
失敗パターン①：要件があとから膨らみ、手戻りが多発
典型的な状況：要件定義を急ぎ、開発が始まってから「あの機能も欲しい」「この画面も追加で」と要望が次々に出る。結果、設計やコードの作り直しが発生し、納期も予算も超過する。
- 回避策：要件定義で「Must（必須）／Want（あれば）／Won’t（今回はやらない）」を文書化する
- 回避策：追加要望は「変更管理票」に記録し、影響（工数・費用・納期）を必ず見える化してから判断する
- 回避策：「今回はやらないこと」を明記しておく。スコープの境界線が手戻りを防ぐ
失敗パターン②：予算超過——「安い見積もり」に飛びついた結果
典型的な状況：複数社の相見積もりで最安値の会社を選んだが、要件定義やテストが見積もりに含まれておらず、後から追加費用が積み上がって結局割高になる。
- 回避策：見積書の「内訳」を工程ごとに確認する。要件定義・テスト・運用が含まれているか
- 回避策：極端に安い見積もりは「何が抜けているか」を疑う。総額ではなく工程別の妥当性を見る
- 回避策：投資に見合うかの判断軸は業務システム化のROI計算の記事で事前に把握しておく
失敗パターン③：完成したのに現場で使われない
典型的な状況：管理者やシステム担当だけで要件を決め、現場の業務実態とズレたシステムが完成。現場が「前のやり方のほうが楽」と使わず、投資が無駄になる。
- 回避策：要件定義の段階から「実際に毎日使う現場担当者」を巻き込む
- 回避策：基本設計のレビューと受け入れテストは、必ず現場担当者に操作してもらう
- 回避策：リリース後のオンボーディング（操作説明・マニュアル）を計画に入れる
※ 上記は一般的なモデルケースであり、成果を保証するものではありません。
失敗の9割は「コミュニケーション設計」で防げる
3つの失敗パターンに共通するのは、技術ではなく「人と情報の流れ」の設計不足です。誰が要件を決め、誰がレビューし、いつ確認するか。この体制を最初に決めておくだけで、典型的な失敗の多くは回避できます。
システム開発の流れと費用・見積もりの関係
「各工程でいくらかかるのか」を流れに沿って理解すると、見積書が格段に読みやすくなります。ここでは費用比率の目安だけを示します。投資判断（ROI・回収期間・費用対効果）は業務システム化のROI計算の記事で、導入費用の内訳イメージ（セルフレジ等の実例）はセルフレジ導入費用の相場・内訳の記事で、それぞれ詳しく解説しています。
工程別・費用比率の目安（500万円のプロジェクト例）
| 工程 | 費用比率の目安 | 500万円の場合の目安 |
|---|---|---|
| 要件定義 | 10〜15% | 50〜75万円 |
| 基本・詳細設計 | 18〜24% | 90〜120万円 |
| プログラミング | 25〜35% | 125〜175万円 |
| 各種テスト | 18〜28% | 90〜140万円 |
| 受け入れ・リリース | 3〜5% | 15〜25万円 |
| 運用保守（年額） | 初期費の10〜20% | 年50〜100万円 |
※ 費用比率・金額はいずれも一般的な目安であり、要件・規模・手法・開発会社により変動します。正確な金額は個別の見積もりをご確認ください。
「設計とテストの費用」を削ると、運用で何倍にも跳ね返る
費用を抑えたいとき、目につきやすい設計やテストの費用を削りたくなります。しかし、上流の設計とテストは「品質を作り込む工程」。ここを削ると、リリース後の障害対応・改修コストが膨らみ、結果的に総コスト（TCO）は高くなりがちです。削るなら「機能の優先順位（スコープ）」で削るのが鉄則です。
中小企業がスモールスタートでシステム開発を進める手順
滋賀県をはじめ地方の中小企業では、いきなり大規模なシステムに数千万円を投じるのは現実的ではありません。私たちが中小企業のDX支援で重視しているのが、「小さく始めて、効果を見ながら育てる」スモールスタートの考え方です。
スモールスタートの5ステップ
- 一番困っている業務をひとつに絞る（在庫管理・予約受付・日報など、痛みの大きい1点）
- MVP（最小限の機能）だけを定義する（「あれもこれも」を捨て、コア機能に集中）
- 短期間（1〜2ヶ月目安）で作り、現場で使ってみる（机上の議論より、使ってからの気づきを重視）
- 使って分かった改善点を次の開発に反映する（運用 → 改善のループを回す）
- 効果が確認できたら、隣接業務へ段階的に拡張する（成功体験を横展開）
段階導入のメリット
初期投資を抑えられる
最初から全部作らないため、初期費用とリスクを小さくできる。失敗してもダメージが限定的。
現場が使いながら学べる
小さく導入することで、現場が新しいやり方に慣れる時間が取れる。定着しやすい。
効果を見て判断できる
第一段階の効果を確認してから次の投資を判断できる。経営判断のリスクが下がる。
滋賀の中小企業の現場で感じること
私たちが地域の中小企業を支援する中で繰り返し実感するのは、「完璧な仕様書より、まず動くものを触ってもらう」ことの効果です。紙の上では伝わらなかった業務の機微が、実際に画面を触ると一気に言語化されます。スモールスタートは、この「現場の暗黙知を引き出す」進め方でもあるのです。AI活用による効率化の考え方はAIコンサルタントの記事もご参照ください。
プロジェクトを成功させる7つのポイント
中小企業のシステム開発支援で培った知見から、成功するプロジェクトの共通点を7つにまとめました。
- 要件定義に予算の15%前後を確保する（短く済ませず、しっかり時間を使う）
- 「絶対必要」と「あったら便利」を明確に切り分ける（MVP発想）
- 現場担当者を要件定義から巻き込む（管理者だけで決めない）
- 週次の進捗レポート＋月次のデモを契約に明記する
- テスト工程の予算を死守する（全体の22〜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割程度の工数削減が現実的なラインとされています。ただし、AIが得意なのは「定型的な生成・補完」であり、要件の本質を見極める判断や、業務理解に基づく設計はあくまで人間の仕事です。AIは人間を置き換えるのではなく、人間がより価値の高い判断に集中するための道具と捉えるのが正確です。
AI活用ができる開発会社の見極め方
見積もり依頼時に「AIをどう活用していますか？」と質問してみましょう。具体的なツール名（Claude Code、GitHub Copilot、Cursor等）と工程別の活用方法を即答できる会社は、工数削減のノウハウを持っている可能性が高いです。曖昧な答えしかない会社は、従来手法のままのケースが多いでしょう。
用語集
- 要件定義
- 「何を作るか」を決める初期工程。業務要件・機能要件・非機能要件を整理する。
- 基本設計（外部設計）
- 画面、帳票、データ構造、外部システム連携などシステムの「外側」を設計する工程。
- 詳細設計（内部設計）
- プログラム内部の処理ロジック、クラス構造、関数仕様などを設計する工程。
- 単体テスト（ユニットテスト）
- 個々の機能・モジュールを単独で動作確認するテスト。
- 結合テスト
- 個別に作られた機能同士を組み合わせて、連携が正しく動くかを確認するテスト。
- システムテスト（総合テスト）
- 本番環境と同等の構成で、システム全体の動作・性能・セキュリティを検証するテスト。
- 受け入れテスト（UAT）
- User Acceptance Test。発注者側が「依頼通りに作られているか」を確認する最終テスト。
- 工程表（スケジュール表）
- 各工程の開始・期間・マイルストーンを時系列で整理した計画表。ガントチャート形式で表すことが多い。
- V字モデル
- 設計工程とテスト工程を左右対称に対応づけた開発モデル。各設計が対応するテストで検証される。
- ウォーターフォール開発
- 各工程を順番に進める開発手法。要件が明確なプロジェクトに最適。
- アジャイル開発
- 2〜4週間の短いサイクルを繰り返しながら開発を進める手法。要件変動に強い。
- MVP（Minimum Viable Product）
- 必要最小限の機能で構築した初期版。早期にユーザー検証することで、無駄な機能開発を防ぐ。
- DoD（Definition of Done）
- 「完了の定義」。各タスクが何をもって完了とみなされるかを事前に合意した基準。
- TCO（総保有コスト）
- 初期開発費だけでなく、運用・保守・改修を含めた、システムの生涯にわたる総コスト。
よくある質問（FAQ）
システム開発の流れは全部で何工程ありますか？
一般的には全9工程です。「①要件定義 → ②基本設計 → ③詳細設計 → ④プログラミング → ⑤単体テスト → ⑥結合テスト → ⑦システムテスト → ⑧受け入れテスト・リリース → ⑨運用保守」の順に進みます。これらを「企画・設計・実装・テスト・導入・運用」の6フェーズにまとめる整理もあります。区切り方は会社により多少異なりますが、本質的な流れは共通です。
システム開発の工程表（スケジュール表）はどう作ればいいですか？
縦軸に9工程、横軸に月（または週）を並べたガントチャート形式が基本です。ポイントは4つ。(1)全体の10〜15%をバッファ（予備期間）として確保する、(2)発注側のレビュー期間も明記する、(3)「要件確定」「設計完了」「リリース判定」などマイルストーンを3〜5個設定する、(4)各工程の完了条件（成果物の承認）を決めておく。本記事の規模別の工程表サンプルを雛形として活用してください。工程表は契約書の別紙にしておくと、進捗の認識ズレを防げます。
システム開発の流れを図で理解したいのですが、全体像はどうなっていますか？
各工程の「入力 → 作業 → 成果物 → 次工程」がバトンリレーのようにつながる構造です。本記事のシステム開発の流れ図【全工程フローチャート】で、9工程それぞれの入力と成果物を図解しています。重要なのは、(1)前工程の成果物が次工程の入力になること、(2)設計とテストがV字モデルで対応していること（単体テスト＝詳細設計の検証、受け入れテスト＝要件定義の検証）、(3)運用保守の改善要望が要件定義に戻り、円環としてループすること、の3点です。
システム開発の期間の目安はどれくらいですか？規模によってどう変わりますか？
一般的な目安は、小規模（100〜300万円）で1〜2ヶ月、中規模（400〜1,000万円）で3〜6ヶ月、大規模（1,000〜3,000万円）で6〜12ヶ月、基幹系（3,000万円〜）で12〜24ヶ月です。ただし期間は規模だけでなく、要件の確定度・開発手法・発注側の意思決定スピードで大きく変動します。要件が未整理だったり、承認に時間がかかると、同じ規模でも期間は伸びます。いずれもケースにより変動する目安としてご理解ください。
システム開発の進め方で、発注側が最初にやるべきことは何ですか？
最初にやるべきは「解決したい業務課題の言語化」と「意思決定者の明確化」です。「何が・どれくらい・なぜ困っているのか」を整理し、「最後は誰が決めるのか」を決めておくと、開発会社からの提案が的確になります。あわせて、現状の業務フロー（As-Is）と理想の姿（To-Be）を簡単に整理し、概算予算の上限を把握しておくと、要件定義がスムーズに進みます。完璧な仕様書は不要です——課題が明確なら、整理は開発会社が手伝えます。
ウォーターフォールとアジャイルでは流れがどう違いますか？
ウォーターフォールは9工程を順番に1回ずつ通し、最後にまとめてリリースします。要件が固く変更が少ない案件（基幹系・規制業界）向きです。アジャイルは「設計〜テスト〜リリース」の小サイクルを2〜4週間ごとに繰り返し、機能を小刻みにリリースします。要件が変動しやすい案件（Web系・新規事業）向きです。中小企業では「要件定義はウォーターフォール的に固め、実装はアジャイル的に進める」ハイブリッドが現実的なことが多いです。
システム開発の各工程にかかる費用の割合はどれくらいですか？
一般的な目安は、要件定義10〜15%、基本・詳細設計18〜24%、プログラミング25〜35%、各種テスト18〜28%、受け入れ・リリース3〜5%です。運用保守は初期開発費の年10〜20%が目安（別途）。注目すべきは、プログラミングは全体の3割程度で、設計とテストの合計が約半分を占める点です。費用を抑えたいときに設計・テストを削ると、運用で何倍にも跳ね返るため、削るなら機能の優先順位（スコープ）で調整します。投資に見合うかの判断は業務システム化のROI計算の記事をご覧ください。
小さく始めて段階的に進めるシステム開発は可能ですか？
はい、可能です。スモールスタート（MVP＝必要最小限の機能から始める）という進め方で、初期投資とリスクを抑えながら段階的に拡張できます。手順は、(1)一番困っている業務を1つに絞る、(2)コア機能だけを定義する、(3)短期間で作って現場で使ってみる、(4)気づきを次の開発に反映する、(5)効果が出たら隣接業務へ拡張する、の5ステップ。中小企業に特に適した進め方です。詳しくは本記事のスモールスタートのセクションをご覧ください。
まとめ
システム開発の流れを全9工程・工程表・期間目安・発注側の進め方の観点から解説しました。最後に重要ポイントを5つにまとめます。
- システム開発の流れは「企画→設計→実装→テスト→導入→運用」の6フェーズ・全9工程
- 期間の目安は小規模1〜2ヶ月／中規模3〜6ヶ月／大規模6〜12ヶ月（規模・要件・手法で変動）
- 費用比率はプログラミング約3割、設計とテストで約半分。削るならスコープで
- 発注側も「要件定義への参加」「基本設計レビュー」「受け入れテスト」は死守する
- AI活用前提なら工数を2〜3割削減できる可能性（ケースにより変動）。スモールスタートも有効
システム開発の流れ・工程表・スケジュール感を理解しておくだけで、発注精度・プロジェクト成功率は大きく向上します。投資判断（費用対効果）については業務システム化のROI計算の記事を、運用後のログ・内部統制対応については操作ログ・監査証跡管理システムの記事を、それぞれあわせてご覧ください。
システム開発の無料相談・お見積り
株式会社LUCRISでは、AI活用を前提とした開発体制で
コストと期間の最適化に取り組んでいます（効果はケースにより変動します）。
要件定義からのご相談・スモールスタートのご相談も歓迎です。
