IPA（情報処理推進機構）の調査によると、システム開発プロジェクトの約7割が当初の予算・納期を超過している。その主な原因は「発注者側の工程理解不足」にある。本記事では、初めてシステム開発を発注する担当者に向けて、V字モデルとアジャイルの両開発手法における各工程の期間・費用配分・発注者がやるべきことを徹底解説する。

目次

  1. システム開発の全体像と2つの開発手法
  2. V字モデル（ウォーターフォール）の各工程詳細
  3. アジャイル開発の進め方
  4. 各工程の期間と費用割合
  5. 発注者がやるべきこと工程別チェックリスト
  6. よくある失敗パターンと対策
  7. よくある質問

システム開発の全体像と2つの開発手法

システム開発は大きく「企画・要件定義」「設計」「開発（実装）」「テスト」「リリース・運用」の5つのフェーズに分かれる。このフェーズを進める方法論として、代表的なものがV字モデル（ウォーターフォール）とアジャイルである。

V字モデル（ウォーターフォール）の特徴

V字モデルは、上流工程から下流工程へ順番に進む手法である。各工程の成果物が明確で、大規模システムや基幹系システムの開発に適している。要件変更に弱い反面、全体のスケジュールと費用が見通しやすいというメリットがある。

アジャイル開発の特徴

アジャイル開発は、2〜4週間の短い開発サイクル（スプリント）を繰り返しながら段階的にシステムを構築する手法である。要件変更に柔軟に対応でき、BtoC向けWebサービスやスタートアップの新規事業に適している。

V字モデル（ウォーターフォール）の各工程詳細

1. 企画フェーズ（1〜2ヶ月）

企画フェーズでは、システム化の目的・対象業務・期待する効果を明確にする。経営層や現場へのヒアリングを通じて、現状の業務課題を洗い出し、システム化すべき範囲を決定する。

発注者の役割としては、以下が重要である。

  • 経営課題と業務課題の整理
  • 投資対効果（ROI）の試算
  • プロジェクト体制の構築
  • 予算の確保と稟議

2. 要件定義フェーズ（1〜3ヶ月）

要件定義は、システムに求める機能・性能・制約条件を文書化する工程である。この工程の品質がプロジェクト全体の成否を左右すると言っても過言ではない。

要件定義で決めるべき項目は以下の通りである。

  • 機能要件: システムが実現すべき機能一覧
  • 非機能要件: 性能、可用性、セキュリティ、拡張性
  • 業務フロー: As-Is（現状）とTo-Be（将来）の業務フロー図
  • データ要件: 取り扱うデータの種類、量、連携先
  • 運用要件: 稼働時間、バックアップ、障害対応

3. 基本設計フェーズ（1〜2ヶ月）

基本設計（外部設計）は、ユーザーの視点からシステムの全体構造を設計する工程である。画面レイアウト、帳票デザイン、データベース構造、外部連携仕様などを決定する。

4. 詳細設計フェーズ（1〜2ヶ月）

詳細設計（内部設計）は、プログラマーの視点からモジュールごとの処理ロジック、データベースのテーブル定義、APIのインターフェース仕様を設計する工程である。

5. 開発（実装）フェーズ（2〜6ヶ月）

設計書に基づいてプログラミングを行うフェーズである。フロントエンド、バックエンド、データベース、インフラの各担当が並行して作業する。

6. テストフェーズ（1〜3ヶ月）

テストは以下の4段階で実施される。

テスト種別目的実施者期間目安
単体テスト個々のモジュールの動作確認開発者2〜4週間
結合テストモジュール間の連携確認開発者/テスター2〜4週間
システムテスト全体の機能・性能確認テストチーム2〜4週間
受入テスト業務要件の充足確認発注者2〜4週間

7. リリース・運用フェーズ

本番環境へのデプロイ、データ移行、ユーザー教育を経て本番稼働を開始する。稼働後は保守・運用フェーズに移行し、障害対応、機能改善、セキュリティパッチの適用などを継続的に行う。

アジャイル開発の進め方

スプリント計画

アジャイル開発では、プロダクトバックログ（実現したい機能のリスト）を優先順位順に並べ、各スプリント（2〜4週間）で実装する機能を決定する。

スプリントの流れ

  1. スプリントプランニング: 今回のスプリントで実装する機能を選定
  2. デイリースクラム: 毎日15分の進捗共有
  3. 開発・テスト: 機能の実装とテストを同時並行で実施
  4. スプリントレビュー: 成果物のデモと発注者レビュー
  5. 振り返り（レトロスペクティブ）: プロセス改善の議論

アジャイル開発での発注者の役割

アジャイル開発では、発注者はプロダクトオーナー（PO）として開発チームに深く関与する。スプリントレビューへの参加は必須であり、各スプリントの成果物に対するフィードバックをタイムリーに提供する必要がある。

各工程の期間と費用割合

V字モデルの費用配分

工程費用割合期間（中規模案件）主な成果物
企画・要件定義15〜20%2〜3ヶ月要件定義書、RFP
基本設計10〜15%1〜2ヶ月基本設計書、画面仕様書
詳細設計10〜15%1〜2ヶ月詳細設計書、DB定義書
開発（実装）30〜40%2〜4ヶ月ソースコード
テスト15〜25%1〜3ヶ月テスト仕様書、テスト報告書
リリース・移行5〜10%2〜4週間運用マニュアル

規模別の総費用目安

規模画面数目安期間費用目安
小規模10〜30画面3〜6ヶ月300万〜1,000万円
中規模30〜100画面6〜12ヶ月1,000万〜5,000万円
大規模100画面以上12〜24ヶ月5,000万〜数億円

発注者がやるべきこと工程別チェックリスト

企画・要件定義フェーズ

  • 経営層のコミットメントを取り付ける
  • プロジェクトオーナーを明確にする
  • 現場の業務フローを文書化する
  • 既存システムの一覧と課題を整理する
  • 3社以上から見積もりを取得する

設計フェーズ

  • 画面モックアップのレビューに参加する
  • 業務ルールの例外パターンを漏れなく伝える
  • データの移行対象を確定する
  • 外部連携先のAPI仕様を確認する

テスト・リリースフェーズ

  • 受入テストのシナリオを作成する
  • 実際の業務データでテストを行う
  • エンドユーザーへの教育計画を策定する
  • 並行運用期間を確保する

よくある失敗パターンと対策

失敗パターン1: 要件の後出し

開発中に「この機能も追加してほしい」という追加要件が頻発すると、スケジュールと予算が大幅に超過する。対策として、要件定義フェーズで十分な時間を確保し、変更管理プロセスを事前に定義しておくことが重要である。

失敗パターン2: 丸投げ体制

「すべてベンダーにお任せ」という姿勢は、要件の認識齟齬を生み、結果的にやり直しが発生する。発注者側にプロジェクトマネージャーを置き、定期的な進捗確認と意思決定の体制を構築すべきである。

失敗パターン3: テスト期間の圧縮

開発遅延のしわ寄せがテスト工程に及ぶケースが多い。テスト期間の短縮は本番障害のリスクを高めるため、テスト工程のバッファは最低でも20%確保しておくべきである。

失敗パターン4: 運用設計の後回し

システムは作って終わりではなく、運用開始後が本番である。運用設計（監視、バックアップ、障害対応フロー）は設計フェーズから検討を始めるべきである。

よくある質問

Q1. システム開発の見積もりを比較する際、何を基準にすればよいか？

見積もりを比較する際は、単純な金額だけでなく「工数の内訳」「前提条件」「含まれる作業範囲」を確認することが重要である。特に、要件定義・テスト・データ移行・運用保守が見積もりに含まれているかどうかで、総額は大きく変わる。最低3社から見積もりを取得し、同じRFP（提案依頼書）に基づいて比較することを推奨する。

Q2. V字モデルとアジャイル、どちらを選べばよいか？

要件が明確で変更が少ない基幹系システムにはV字モデル、要件が流動的でスピード重視のWebサービスにはアジャイルが適している。ただし、近年は両者を組み合わせた「ハイブリッド型」を採用する企業も増えている。例えば、基本設計まではウォーターフォールで進め、開発以降はアジャイルで反復的に実装するアプローチである。

Q3. 開発会社を選ぶ際のチェックポイントは？

技術力だけでなく、同業種・同規模の開発実績、プロジェクトマネジメント体制、コミュニケーションの頻度と手段、保守運用のサポート体制を確認すべきである。また、下請けに丸投げしていないか（再委託の有無）も重要な確認ポイントである。

Q4. 途中で開発会社を変更することは可能か？

技術的には可能だが、引き継ぎコストが発生するため推奨しない。中途解約の場合、既に完了した工程の費用に加え、ソースコードや設計書の権利帰属が問題になることがある。契約時に著作権・知的財産権の帰属、中途解約条件を明確にしておくことが重要である。

Q5. 初めてのシステム開発で、まず何から始めればよいか？

まず「何のためにシステムを導入するのか」という目的を明確にすることが最優先である。次に、現在の業務フローを可視化し、課題を洗い出す。その上で、IT導入補助金などの公的支援制度の利用可能性を確認し、信頼できる開発パートナーに相談するステップを踏むことを推奨する。

GXO実務追記: システム開発・DX投資で発注前に確認すべきこと

この記事のテーマは、単なるトレンド紹介ではなく、要件定義、費用、開発体制、ベンダー選定、保守運用を決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。

まず決めるべき3つの論点

論点確認する内容未整理のまま進めた場合のリスク
目的売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか成果指標が曖昧になり、PoCや開発が終わっても投資判断できない
範囲対象部署、対象業務、対象データ、対象システムをどこまで含めるか見積もりが膨らむ、または重要な連携が後から漏れる
体制自社責任者、現場担当、ベンダー、保守運用者をどう置くか要件確認が遅れ、納期遅延や品質低下につながる

費用・期間・体制の目安

フェーズ期間目安主な成果物GXOが見るポイント
事前診断1〜2週間課題整理、現行確認、投資判断メモ目的と範囲が商談前に整理されているか
要件定義 / 設計3〜6週間要件一覧、RFP、概算見積、ロードマップ見積比較できる粒度になっているか
PoC / MVP1〜3ヶ月検証環境、効果測定、リスク評価本番化判断に必要な数値が取れるか
本番導入3〜6ヶ月本番環境、運用設計、教育、改善計画導入後の運用責任と改善サイクルがあるか

発注前チェックリスト

  • 発注前に目的、対象業務、利用者、現行課題を1枚に整理したか
  • 必須要件、将来要件、今回はやらない要件を分けたか
  • 見積比較で、開発費だけでなく保守費、運用費、追加改修費を見たか
  • ベンダー選定で、体制、実績、品質管理、セキュリティ、引継ぎ条件を確認したか
  • 検収条件を機能、性能、セキュリティ、ドキュメントで定義したか
  • リリース後3ヶ月の改善運用と責任分界を決めたか

参考にすべき一次情報・公的情報

上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。

GXOに相談するタイミング

次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。

  • 見積もり依頼前に、要件やRFPの粒度を整えたい
  • 既存ベンダーの提案が妥当か第三者視点で確認したい
  • 補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
  • 社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
  • PoCや診断で終わらせず、本番導入と運用改善まで進めたい

システム開発の流れ完全ガイド｜要件定義から運用まで各工程の期間・費用・注意点を自社条件で診断したい方へ

GXOが、現状整理、RFP/要件定義、費用対効果、ベンダー比較、導入ロードマップまで実務目線で確認します。記事の一般論を、自社の投資判断に使える形へ落とし込みます。

システム開発費用・要件診断を相談する

※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。