U「ウォーターフォールとアジャイル、どっちがどうだっけ?」試験直前によく混乱するテーマですが、各モデルの”思想”から押さえると一気に整理できます。図解と比較表で確実に定着させましょう。
ソフトウェア開発プロセスとは——なぜ「作り方」が重要なのか
- ウォーターフォール・アジャイル・スパイラル各モデルの特徴と使い分け
- Vモデルによるテスト工程の対応関係
- DevOpsとCI/CDパイプラインの概念
- 試験頻出:各手法の適用条件と選択基準
ソフトウェア開発プロセスとは、システムを設計・実装・テスト・運用するまでの一連の手順とルールのことです。「どの順序で何をやるか」を定義することで、品質の安定・コスト管理・スケジュール管理が可能になります。
中小企業診断士試験の経営情報システムでは、各開発モデルの特徴・メリット・デメリット・適用場面が繰り返し出題されます。単純な暗記ではなく「なぜそのモデルが生まれたのか」という背景から理解すると、応用問題にも対応できます。
ウォーターフォールモデル——古典的だが今も現役
ウォーターフォールモデルは、開発工程を上流から下流へ一方向に流れるように進めるモデルです。水が滝(ウォーターフォール)のように上から下へ落ちるイメージから命名されました。
| 項目 | 内容 |
|---|---|
| メリット | 工程が明確で進捗管理しやすい。ドキュメントが充実する。大規模プロジェクトに向く |
| デメリット | 要件変更に弱い。動くシステムを見るのが遅い。手戻りコストが大きい |
| 向いているケース | 要件が最初から明確・安定している。官公庁・金融系の大規模システム |
| 向いていないケース | 要件が変わりやすい。スタートアップ・新規サービス開発 |
各フェーズの詳細
「何を作るか」を明確にする工程。ユーザーのニーズをヒアリングし、システムが満たすべき機能要件・非機能要件(性能・セキュリティ等)を文書化します。
ユーザーから見たシステムの姿を設計。画面レイアウト・帳票・データの入出力インターフェースを定義します。「何を見せるか」の設計。
エンジニアが実装するための詳細なロジックを設計。データベース構造・モジュール分割・処理アルゴリズムを定義します。「どう動かすか」の設計。
詳細設計書をもとにプログラムを実際に書く工程。モジュール単位で開発し、コードレビューを行います。
作ったプログラムが仕様通りに動くかを検証。単体テスト→結合テスト→システムテスト→受入テストの順に実施します(詳細は後述)。
システムを本番環境で稼働させ、不具合修正・機能追加・性能改善を継続的に行います。
Vモデル——テスト工程と開発工程の対応関係
Vモデルは、ウォーターフォールモデルのテスト工程を視覚的に整理したものです。開発工程(左の縦軸)と対応するテスト工程(右の縦軸)を示し、V字の形になることから「Vモデル」と呼ばれます。
| 開発工程(左側) | 対応するテスト工程(右側) | 確認する内容 |
|---|---|---|
| 要件定義 | 受入テスト(UAT) | ユーザーの要件を満たしているか |
| 基本設計 | システムテスト | システム全体の機能・性能・セキュリティ |
| 詳細設計 | 結合テスト | モジュール間の連携が正しく動くか |
| 実装 | 単体テスト | 個々のモジュールが仕様通りに動くか |
テスト手法の詳細
| テスト種別 | 実施タイミング | テスト手法 | 主な観点 |
|---|---|---|---|
| 単体テスト | モジュール完成後 | ホワイトボックス・ブラックボックス | 個々の機能の正確性 |
| 結合テスト | 複数モジュール統合後 | インターフェーステスト | モジュール間のデータ連携 |
| システムテスト | 全モジュール統合後 | 負荷テスト・セキュリティテスト | 性能・信頼性・セキュリティ |
| 受入テスト(UAT) | 本番移行前 | ユーザーによる実際の業務シナリオ | 業務要件の充足 |
| 回帰テスト(リグレッション) | 修正・変更後 | 既存機能の再テスト | 変更による既存機能への影響 |
アジャイル開発——変化に強い反復型アプローチ
アジャイル(Agile)は「機敏な・素早い」を意味します。2001年に発表された「アジャイルソフトウェア開発宣言」を基盤とし、短期間のサイクルを繰り返して動くソフトウェアを段階的に届けるアプローチです。
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を
スクラム(Scrum)
スクラムはアジャイル開発の代表的なフレームワークです。ラグビーのスクラムのように、チームが一体となって目標に向かうイメージから命名されました。
| 要素 | 内容 |
|---|---|
| スプリント | 1〜4週間の短い開発サイクル。各スプリント終了時に動く機能を届ける |
| プロダクトバックログ | 実装すべき機能・要求の優先順位付きリスト。プロダクトオーナーが管理 |
| スプリントバックログ | そのスプリントで実装するタスク一覧 |
| デイリースクラム | 毎日15分の朝会。昨日やったこと・今日やること・障害を共有 |
| スプリントレビュー | スプリント終了時にステークホルダーへデモ・フィードバック収集 |
| レトロスペクティブ | チームの改善点を振り返る会議(振り返り) |
| 役割 | 責任 |
|---|---|
| プロダクトオーナー | プロダクトバックログの優先順位管理。ビジネス価値の最大化 |
| スクラムマスター | スクラムの実践支援。障害の除去。チームのコーチ役 |
| 開発チーム | 自律・横断的なチーム。3〜9人。全員でソフトウェアを届ける |
エクストリームプログラミング(XP)
XP(Extreme Programming)はアジャイル開発の手法の一つで、エンジニアリングプラクティスを極限まで高めることに特化しています。
| プラクティス | 内容 |
|---|---|
| ペアプログラミング | 2人1組でコーディング。リアルタイムレビューにより品質向上 |
| テスト駆動開発(TDD) | コードを書く前にテストを書く。テストが通るコードを実装 |
| リファクタリング | 機能を変えずにコードの内部構造を改善。技術的負債の解消 |
| 継続的インテグレーション(CI) | 頻繁にコードを統合・ビルド・テストして問題を早期発見 |
| シンプルデザイン | 今必要な機能だけを最もシンプルに実装する |
| コレクティブオーナーシップ | コードの所有権はチーム全員。誰でも任意のコードを変更できる |
スパイラルモデル——リスクを中心に置いた反復開発
スパイラルモデルはBarry Boehmが1988年に提唱したモデルで、ウォーターフォールとプロトタイピングを組み合わせ、リスク分析を中心に螺旋(スパイラル)状に開発を繰り返します。
- 計画策定:目標・代替案・制約を確定する
- リスク分析:代替案を評価し、リスクを特定・対策する(プロトタイプ作成も)
- エンジニアリング:設計・コーディング・テストを実施する
- 評価・計画:顧客レビューを実施し、次サイクルの計画を立てる
| 項目 | 内容 |
|---|---|
| 最大の特徴 | リスク分析が中心。プロジェクトの不確実性が高い場合に有効 |
| メリット | リスクを早期に発見・対処できる。要件変更への柔軟性が高い |
| デメリット | プロセスが複雑。リスク分析に専門知識が必要。コスト管理が難しい |
| 適用場面 | 大規模・高リスクなシステム。技術的な不確実性が高いプロジェクト |
プロトタイピングモデル——早期に「動くもの」を見せる
プロトタイピングモデルは、本格的な開発に入る前に試作品(プロトタイプ)を素早く作りユーザーに確認してもらう手法です。要件が曖昧な場合や、UIの使い勝手をユーザーと一緒に確認しながら進める場合に特に有効です。
| 種類 | 内容 |
|---|---|
| 使い捨て型プロトタイプ | 確認のためだけに作り、本番開発では使わない。要件確定が目的 |
| 進化型プロトタイプ | プロトタイプを改良し続け、最終的に本番システムに育てる |
開発手法の選択基準——どのモデルをいつ使うか
| 選択基準 | ウォーターフォール | アジャイル | スパイラル | プロトタイピング |
|---|---|---|---|---|
| 要件の安定性 | 安定している | 変わりやすい | 不明確・高リスク | 曖昧・不明確 |
| プロジェクト規模 | 大規模 | 小〜中規模 | 大規模 | 小〜中規模 |
| 納期の柔軟性 | 固定納期 | 段階的リリース | 柔軟 | 短期で確認 |
| チーム特性 | 分業・専門化 | 小さな自律チーム | リスク分析の専門家 | ユーザーと密連携 |
| 代表的な適用領域 | 官公庁・金融 | スタートアップ・Web | 防衛・宇宙システム | UI検討・新規事業 |
DevOpsとCI/CDパイプライン——開発と運用の融合
DevOpsは「Development(開発)」と「Operations(運用)」を組み合わせた造語です。開発チームと運用チームがサイロを壊して連携し、高速かつ安定したソフトウェアデリバリーを実現する文化・手法・ツールの組み合わせです。
| 概念 | 内容 |
|---|---|
| CI(継続的インテグレーション) | 開発者が頻繁にコードをリポジトリに統合し、自動ビルド・テストで問題を早期発見 |
| CD(継続的デリバリー) | テスト済みコードを本番環境に自動でデプロイできる状態を常に維持 |
| 継続的デプロイメント | テストを通過したコードを自動で本番リリース(CDよりさらに自動化) |
| Infrastructure as Code(IaC) | サーバー設定をコードで管理。再現性・自動化・バージョン管理が可能 |
| 監視・フィードバック | 本番システムを常時監視し、メトリクスをもとに継続的改善 |
各開発モデルの総合比較
| モデル | 開発の進め方 | 最大の強み | 最大の弱み | 適用場面 |
|---|---|---|---|---|
| ウォーターフォール | 直線型(上流→下流) | 工程明確・管理しやすい | 要件変更に弱い | 要件安定・大規模 |
| アジャイル(スクラム) | 反復型(スプリント) | 変化への適応・早期デリバリー | ドキュメントが少ない | 要件変動・スタートアップ |
| スパイラル | 螺旋型(リスク中心) | リスク管理が強力 | 複雑・コスト高 | 高リスク・大規模 |
| プロトタイピング | 試作→フィードバック反復 | 要件の早期明確化 | 試作に甘えて本番が遅れやすい | 要件不明確・UI重視 |
| DevOps/CI-CD | 開発〜運用の継続的連携 | 高速・安定リリース | 組織文化変革が必要 | 継続的改善・クラウドサービス |
試験対策まとめ——頻出パターンと覚え方
① Vモデルの「要件定義↔受入テスト」「基本設計↔システムテスト」の対応関係
② ウォーターフォール:要件安定・大規模向け。アジャイル:要件変動・小規模向け
③ スパイラルモデルの中心は「リスク分析」
④ プロトタイピングは「要件が曖昧なとき」に有効
⑤ スクラムの3役割(PO・SM・開発チーム)と3つのイベント(レビュー・レトロ・デイリー)
よくある質問(FAQ)
ソフトウェア開発プロセスは、経営情報システムの中でも実務と直結した分野です。単に「ウォーターフォールは直線型」と覚えるだけでなく、「なぜウォーターフォールが生まれ、なぜアジャイルが必要とされたのか」という時代背景まで理解すると、応用問題にも自信を持って答えられます。Vモデルの対応関係・スクラムの役割・スパイラルのリスク中心という3点は特に押さえておきましょう。









