システム開発の流れを徹底解説｜工程管理の実務ポイント

9月1日
読了時間: 14分

「また仕様変更か…」と嘆く前に知っておくべきこと

情報システム部門の責任者として、こんな悩みを抱えていませんか?

「ベンダーとの認識がずれていて、想定と違うシステムが上がってきた」
「納期が2ヶ月遅延して、経営層に説明が立たない」
「予算が当初の1.5倍に膨らみ、プロジェクトが止まりそう」

実は、日本情報システム・ユーザー協会(JUAS)の「企業IT動向調査2024」によると、開発規模500人月以上のプロジェクトの51.7%が「予定より遅延」しています。予算超過・納期遅延・仕様の不一致など、何らかの形で当初の想定とズレが生じたプロジェクトは、決して少数派ではありません。

しかし、逆に言えば、適切な工程管理を行えば、成功確率を大幅に向上させられるということです。本記事では、情報システム部門を担う方に向けて、システム開発の全体像から各工程の実務ポイント、そして失敗を防ぐ実践的な知見まで、徹底的に解説します。

システム開発の全体像｜本記事では10の工程に整理

システム開発は、大きく分けて上流工程と下流工程に分類されます。工程の呼び方や区切り方はプロジェクトや開発手法によって多少異なりますが、本記事では代表的な10段階に整理して解説します。

【システム開発の基本フロー】

工程	分類	主な内容	所要期間の目安
1. プロジェクト計画	上流工程	目的・スコープの策定	2週間〜1ヶ月
2. 要件定義	上流工程	機能・性能の明確化	1〜3ヶ月
3. 基本設計(外部設計)	上流工程	ユーザー視点の設計	1〜2ヶ月
4. 詳細設計(内部設計)	上流工程	プログラム仕様の設計	1〜3ヶ月
5. 実装(開発)	下流工程	コーディング	2〜6ヶ月
6. 単体テスト	下流工程	モジュール単位の検証	1〜2ヶ月
7. 結合テスト	下流工程	モジュール連携の検証	1〜2ヶ月
8. システムテスト	下流工程	全体動作の検証	1〜2ヶ月
9. 運用テスト(UAT)	下流工程	実環境での検証	2週間〜1ヶ月
10. リリース・保守運用	下流工程	本番展開・継続改善	継続的

上流工程は要件定義から設計まで、つまり「何を作るか」を決めるフェーズ。下流工程は実装からテスト、運用まで、「どう作り、どう使い続けるか」を実現するフェーズです。

⚠️ ここが重要

上流工程での手戻りは、後工程になるほど修正コストが大きくなる傾向があるため、最初の設計精度がプロジェクト全体の成否を分けます。

各工程を深掘り｜実務で押さえるべきポイント

1. プロジェクト計画：全体の舵取りを定める

プロジェクト計画では、開発の目的・目標・制約条件を明文化します。ここで定義すべき項目は以下の通りです。

ビジネス目標：売上向上、業務効率化、コンプライアンス対応など
スコープ：何を実装し、何を実装しないか
QCD：Quality(品質)、Cost(予算)、Delivery(納期)
ステークホルダー：経営層、現場部門、ベンダー、運用チームの関係性
リスク想定：技術的リスク、人的リスク、外部環境リスク

❌ よくある失敗パターン：「とりあえず始める」マインドで要件が曖昧なまま進行し、後から大幅な仕様変更が発生。

✅ 成功の鍵：プロジェクト憲章やROI試算を作成し、経営層との合意を文書化すること。

2. 要件定義：システム開発の成否を決める最重要工程

🎯 ここで勝負が決まる。

IPA(情報処理推進機構)が公開する「ユーザのための要件定義ガイド第2版」では、JUAS(日本情報システム・ユーザー協会)のソフトウェアメトリクス調査(2016年)を引用し、工期遅延の大きな要因として要件定義工程の不十分さを挙げています。要件定義は、それだけプロジェクトの遅延・失敗につながりやすい工程だということです。

要件定義では、以下を明確にします。

機能要件

業務フローごとに必要な機能をリストアップ
入力項目、出力項目、処理ロジックの詳細化
権限設定、承認フロー、例外処理の定義

非機能要件

非機能要件は見落とされがちですが、システムの品質を大きく左右する要素です。IPAが提唱する「非機能要求グレード」では、以下のような項目を体系的に洗い出すことが推奨されています。

性能：レスポンスタイム、スループット
可用性：稼働率、障害復旧時間
セキュリティ：認証、暗号化、アクセス制御
保守性：ログ設計、バックアップ方針
拡張性：将来的な機能追加への対応

実務チェックリスト

☐ 現場ユーザーへのヒアリングは十分か?
☐ 「できるだけ」「なるべく」といった曖昧表現はないか?
☐ 要件の優先順位(Must/Want/Nice to Have)は明確か?
☐ ベンダーと認識のズレがないか確認したか?

💡 プロのコツ：要件定義書は「ベンダーに渡して終わり」ではなく、現場ユーザーにも読んでもらい、フィードバックを得ること。この一手間が後の大炎上を防ぎます。

要件定義でよくある失敗パターンと成功のコツは「要件定義失敗事例と成功のコツ」でさらに詳しく解説しています。

3. 基本設計(外部設計)：ユーザー体験を形にする

基本設計では、ユーザーが操作する画面や帳票のレイアウト、業務フローを設計します。

主な成果物

画面遷移図
画面レイアウト(ワイヤーフレーム)
帳票レイアウト
外部インターフェース仕様書
データフロー図

✅ ポイント：この段階で現場ユーザーに動くプロトタイプを見せ、フィードバックを得ることで、後工程での大幅な手戻りを防げます。ワイヤーフレーム（静止画のイメージ図）だけでは気づけない操作感のズレも、実際に触れるプロトタイプなら早い段階で洗い出せます。

4. 詳細設計(内部設計)：開発者が実装できるレベルまで落とし込む

詳細設計では、プログラマーがそのまま実装できるレベルまで仕様を詳細化します。

主な成果物

処理フロー図
データベース設計書(テーブル定義、ER図)
クラス図、シーケンス図
API仕様書
エラーハンドリング仕様

⚠️ 注意点：基本設計との整合性を常にチェックし、設計レビューを徹底すること。レビュー漏れが後工程のバグの温床になります。

5. 実装(開発)：コーディング規約と品質を守る

詳細設計書に基づき、実際にプログラミングを行います。使用する言語はプロジェクトにより異なりますが、Java、Python、C#、JavaScript、PHPなどが一般的です。

開発時のベストプラクティス

コーディング規約の徹底：命名規則、インデント、コメント記述
バージョン管理：Git、SVNなどを使った変更履歴管理
継続的インテグレーション(CI)：自動ビルド・自動テスト
コードレビュー：品質とセキュリティの担保

6〜9. テスト工程："一発合格しない"前提で設計せよ

🚦 テストは"保険"ではなく"品質の作り込み"です。

システム開発では、テストは次の4フェーズで行われます。

単体テスト(UT)：モジュール単位での動作確認。開発者自身が実施
結合テスト(IT)：複数モジュールの連携確認。データの受け渡しやAPI連携の検証
システムテスト(ST)：全体機能の動作確認。非機能要件(性能、セキュリティ、負荷)の検証
運用テスト(UAT)：実際の業務フローでの動作確認。エンドユーザーが主体となって実施

⚠️ 重要：各テスト工程で発見された不具合は、修正後に必ずリグレッションテスト(回帰テスト)を実施し、他機能への影響がないか確認します。

💡 現場の声：「納期がないからテストを短縮しよう」は絶対NG。本番稼働後に見つかったバグの修正は、テスト工程で見つけるより手間もコストも大きくなります。

10. リリース・保守運用：本番展開後が本当の勝負

システムのリリース後も、以下の活動が継続的に必要です。

運用監視：障害発生時の即応体制
保守対応：バグ修正、パッチ適用
エンハンス：機能追加、改善要望への対応
ドキュメント更新：運用手順書、マニュアルの最新化

🎯 リリースはゴールではなく、スタートライン。

開発手法の選択｜ウォーターフォールとアジャイル、どちらを選ぶ?

ウォーターフォール開発

特徴：各工程を順番に完了させていく手法。前工程に戻らないことを原則とします。

メリット

スケジュール管理がしやすい
進捗が可視化しやすい
大規模プロジェクトに向いている

デメリット

途中での仕様変更に弱い
実装開始まで時間がかかる
手戻りが発生するとコスト増大

✅ 向いているケース：要件が明確で変更が少ない、コンプライアンス対応など厳格な手順が求められるプロジェクト

アジャイル開発

特徴：小さな単位で「企画→設計→実装→テスト」を繰り返し、段階的にシステムを完成させる手法。

メリット

仕様変更に柔軟に対応できる
早期に動くものが見られる
ユーザーフィードバックを反映しやすい

デメリット

全体像が見えづらい
スコープ管理が難しい
経験豊富なチームが必要

✅ 向いているケース：新規サービス開発、市場の反応を見ながら改善したいプロジェクト

なぜベンダーがアジャイルを勧めるのか、ウォーターフォールとどちらが自社に向いているのかは「なぜベンダーは「アジャイル」を勧めるのか？現場視点で本音解説」で詳しく解説しています。

システム開発が失敗する7つの原因と対策

1. 要件定義の曖昧さ

❌ 原因：「便利なシステムがほしい」といった抽象的な要求のまま進行。

✅ 対策：IPAの要件定義ガイドに沿い、機能要件・非機能要件を詳細に文書化。ステークホルダー全員での合意形成を徹底。

2. コミュニケーション不足

❌ 原因：発注側とベンダー間、または部門間での情報伝達が不十分。

✅ 対策：週次の定例会議、チャットツール(Slack、Teams)の活用、議事録の徹底。

3. プロジェクト管理の甘さ

❌ 原因：進捗が遅れていることに気づかず、納期直前で発覚。

✅ 対策：WBS(Work Breakdown Structure)とガントチャートによる可視化。プロジェクト管理ツール(Backlog、Redmine、Jira)の導入。

4. 見積もりの甘さ

❌ 原因：楽観的な工数見積もりで、後から追加費用が発生。

✅ 対策：過去実績に基づいた見積もり、バッファ(20〜30%)の確保。

5. 技術選定のミス

❌ 原因：流行の技術を採用したが、自社に適していなかった。

✅ 対策：技術選定時にPoC(概念実証)を実施。長期的な保守性も考慮。

6. テスト不足

❌ 原因：納期に追われてテスト工程を短縮し、本番稼働後にバグ多発。

✅ 対策：テスト計画を最初から組み込み、テスト自動化(CI/CD)を導入。

7. 運用体制の未整備

❌ 原因：リリース後の運用体制が決まっておらず、障害対応が遅れる。

✅ 対策：リリース前に運用マニュアル、エスカレーションフローを整備。

プロジェクト管理の実務｜成功に導く5つの原則

1. 明確な目標設定

SMARTの原則(Specific, Measurable, Achievable, Relevant, Time-bound)に基づいた目標設定を行います。

例：❌「業務効率化」 → ✅「受発注処理時間を現状比40%削減(年間1,200時間削減)」

2. ステークホルダー管理

関係者全員の期待値を把握し、定期的にコミュニケーションを取ります。ツール：ステークホルダーマトリクス(影響力×関心度で4象限に分類)

3. リスク管理

潜在リスクをリストアップし、発生確率と影響度を評価。対策を事前に準備します。

主なリスク項目：技術的リスク(新技術の採用)／人的リスク(キーマンの退職)／外部環境リスク(法改正、競合動向)

4. 変更管理

仕様変更は必ず変更管理プロセスを通し、影響範囲とコストを評価してから承認します。

変更管理のフロー：変更要求の提出 → 影響分析(スコープ、コスト、スケジュール) → 承認/却下の判断 → 変更の実施と記録

5. 品質管理

QCD(品質・コスト・納期)のバランスを常に意識し、品質を犠牲にしない判断を行います。

実践チェックリスト｜プロジェクト開始前に確認すべき20項目

プロジェクト計画

☐ ビジネス目標が明文化されているか
☐ ROI(投資対効果)が試算されているか
☐ 経営層の承認を得ているか

要件定義

☐ 機能要件がリスト化されているか
☐ 非機能要件(性能、セキュリティ等)が定義されているか
☐ 要件の優先順位が明確か
☐ 現場ユーザーからのヒアリングが完了しているか
☐ ベンダーとの認識合わせができているか

体制・リソース

☐ プロジェクトマネジャーが明確か
☐ 各工程の担当者がアサインされているか
☐ 予算が確保されているか
☐ スケジュールにバッファが含まれているか

リスク管理

☐ リスク一覧が作成されているか
☐ 各リスクの対策が準備されているか

コミュニケーション

☐ 定例会議の頻度が決まっているか
☐ 報告フォーマットが統一されているか
☐ エスカレーションルールが明確か

ベンダー管理

☐ 契約内容が明確か(請負/準委任)
☐ SLA(サービスレベル契約)が定義されているか
☐ 検収基準が明確か

文書だけで固めず、動くもので確認するという選択肢

ここまで紹介したチェックリストや管理手法は、いずれも「文書・言葉の精度を上げる」アプローチです。要件定義書を丁寧に作り、定例会議で認識をすり合わせ、リスクを一覧化する——どれも欠かせない対策ですが、どれだけ丁寧にやっても、「言葉で説明されたものを想像する」段階と「実際に動くものを見る」段階の間には、埋めきれないズレが残ります。

アビココ株式会社が提供する「てにとる」は、要件定義が完全に固まる前の段階から実際に動くプロトタイプ（試作品）を作り、それを見ながら合意を積み重ねていく進め方です。打ち合わせ→プロトタイプ作成→お客様による確認→修正、を繰り返し、本番を想定したデータで検証したうえでご納得いただいてから正式契約に進みます。本番に近いプロトタイプが完成するまでは、原則無料で進められます。

要件定義フェーズ：「当然この機能もできるよね」といった思い込みを、文書ではなく実際に触れる画面で先に確認できる
基本設計フェーズ：ワイヤーフレームだけでは分からない操作感のズレを、動くプロトタイプで早期に洗い出せる
開発・テストフェーズ：仕様変更が発生する前に方向性を合わせられるため、大きな手戻りを減らせる

この「小さく作って早く確認する」という発想は、前章で紹介したアジャイル開発の考え方とも共通しています。開発手法としてウォーターフォールを採る場合でも、契約前の段階でプロトタイプ検証を組み合わせることで同じ効果を得られます。

まとめ｜システム開発成功への5ステップ

上流工程に時間をかける：要件定義の精度がプロジェクト全体を左右する
適切な開発手法を選ぶ：要件の明確度と変更頻度で判断
コミュニケーションを密にする：週次報告、課題の早期共有
プロジェクト管理を徹底する：WBS、ガントチャート、リスク管理
運用まで見据える：リリースがゴールではなく、継続的改善が重要

システム開発は決して簡単ではありませんが、正しい工程管理と適切なリスク対策により、成功率を大幅に向上させることができます。

自社プロジェクトを成功させたい方へ

「この内容を自社に当てはめると、どう進めるべきか？」「要件定義から開発まで一貫して任せられるパートナーがほしい」「既製品では対応できない、自社独自の業務要件がある…」

そんなご要望をお持ちの方は、アビココ株式会社にお気軽にご相談ください。

🎯 アビココができること

✅ システム受託開発：WEBシステムや業務システムなど、ビジネスの課題を一緒に解決します。対応範囲：企画・PoC検証・要件定義・基本設計・詳細設計・製造・テスト・運用サポートまで全フェーズ対応

✅ アプリ開発：iOSやAndroidなどのアプリ開発も得意です。「こんなアプリがあればいいな」を実現します。

✅ AI・画像解析システム開発：顔認証、画像解析、音声識別、OCR解析など、AI技術を活用したシステム開発に対応。OpenCV、TensorFlow、Amazon Rekognitionなど、最適な技術でご提案します。実績例：大手小売店向け顔認証勤怠管理システム（オフラインでも動作、独自ルールに対応）

🛠 アビココの強み

豊富な技術スタック：HTML/CSS, JavaScript, Python, PHP, Java, C#, Swift, Flutter, React, Laravel、AWS、Azure、GCPなど幅広い技術に対応
プロトタイプ「てにとる」を活用した開発：要件定義・基本設計の段階で実際に動くプロトタイプを作成し、お客様に触れて確認いただきながら開発を進めることが可能。契約前の段階から認識のズレを防ぎ、開発の効率化と短納期を実現します
既製品では対応できない要件にも対応：「自社独自の労務管理ルール」「シフト表示・店舗間の人材貸し借り」など、既製品では実現できない複雑な業務要件にも柔軟に対応します
マスターレス設計の推奨：通常の業務の中で自然な流れで操作を行うことで、自動でマスタデータが作成されるようなシステム設計を行います。運用負荷を最小限に

まずはお気軽にご相談ください

お客様のビジネス課題をヒアリングし、最適なソリューションをご提案いたします。

▼ プロトタイプから始める「てにとる」を見てみる

てにとるを見てみる

▼ アビココへのお問い合わせはこちら

相談してみる