ソフトウェア開発プロセス | 中小企業診断士1次試験 経営情報システム

U
U

「ウォーターフォールとアジャイル、どっちがどうだっけ?」試験直前によく混乱するテーマですが、各モデルの”思想”から押さえると一気に整理できます。図解と比較表で確実に定着させましょう。

目次

ソフトウェア開発プロセスとは——なぜ「作り方」が重要なのか

📌 この記事で学べること
  • ウォーターフォール・アジャイル・スパイラル各モデルの特徴と使い分け
  • Vモデルによるテスト工程の対応関係
  • DevOpsとCI/CDパイプラインの概念
  • 試験頻出:各手法の適用条件と選択基準

ソフトウェア開発プロセスとは、システムを設計・実装・テスト・運用するまでの一連の手順とルールのことです。「どの順序で何をやるか」を定義することで、品質の安定・コスト管理・スケジュール管理が可能になります。

中小企業診断士試験の経営情報システムでは、各開発モデルの特徴・メリット・デメリット・適用場面が繰り返し出題されます。単純な暗記ではなく「なぜそのモデルが生まれたのか」という背景から理解すると、応用問題にも対応できます。

ウォーターフォールモデル——古典的だが今も現役

ウォーターフォールモデルは、開発工程を上流から下流へ一方向に流れるように進めるモデルです。水が滝(ウォーターフォール)のように上から下へ落ちるイメージから命名されました。

要件定義
基本設計
詳細設計
実装(コーディング)
テスト
運用・保守
⚠️ 前の工程に戻ることを原則認めないのがウォーターフォールの特徴です。要件定義で曖昧な点を残すと、後の工程で大きな手戻りが発生します。
項目内容
メリット工程が明確で進捗管理しやすい。ドキュメントが充実する。大規模プロジェクトに向く
デメリット要件変更に弱い。動くシステムを見るのが遅い。手戻りコストが大きい
向いているケース要件が最初から明確・安定している。官公庁・金融系の大規模システム
向いていないケース要件が変わりやすい。スタートアップ・新規サービス開発

各フェーズの詳細

① 要件定義

「何を作るか」を明確にする工程。ユーザーのニーズをヒアリングし、システムが満たすべき機能要件・非機能要件(性能・セキュリティ等)を文書化します。

② 基本設計(外部設計)

ユーザーから見たシステムの姿を設計。画面レイアウト・帳票・データの入出力インターフェースを定義します。「何を見せるか」の設計。

③ 詳細設計(内部設計)

エンジニアが実装するための詳細なロジックを設計。データベース構造・モジュール分割・処理アルゴリズムを定義します。「どう動かすか」の設計。

④ 実装(コーディング)

詳細設計書をもとにプログラムを実際に書く工程。モジュール単位で開発し、コードレビューを行います。

⑤ テスト

作ったプログラムが仕様通りに動くかを検証。単体テスト→結合テスト→システムテスト→受入テストの順に実施します(詳細は後述)。

⑥ 運用・保守

システムを本番環境で稼働させ、不具合修正・機能追加・性能改善を継続的に行います。

Vモデル——テスト工程と開発工程の対応関係

Vモデルは、ウォーターフォールモデルのテスト工程を視覚的に整理したものです。開発工程(左の縦軸)と対応するテスト工程(右の縦軸)を示し、V字の形になることから「Vモデル」と呼ばれます。

開発工程(左側)対応するテスト工程(右側)確認する内容
要件定義受入テスト(UAT)ユーザーの要件を満たしているか
基本設計システムテストシステム全体の機能・性能・セキュリティ
詳細設計結合テストモジュール間の連携が正しく動くか
実装単体テスト個々のモジュールが仕様通りに動くか
💡 試験ポイント:「受入テストは要件定義に対応する」「システムテストは基本設計に対応する」という対応関係を正確に覚えましょう。

テスト手法の詳細

テスト種別実施タイミングテスト手法主な観点
単体テストモジュール完成後ホワイトボックス・ブラックボックス個々の機能の正確性
結合テスト複数モジュール統合後インターフェーステストモジュール間のデータ連携
システムテスト全モジュール統合後負荷テスト・セキュリティテスト性能・信頼性・セキュリティ
受入テスト(UAT)本番移行前ユーザーによる実際の業務シナリオ業務要件の充足
回帰テスト(リグレッション)修正・変更後既存機能の再テスト変更による既存機能への影響

アジャイル開発——変化に強い反復型アプローチ

アジャイル(Agile)は「機敏な・素早い」を意味します。2001年に発表された「アジャイルソフトウェア開発宣言」を基盤とし、短期間のサイクルを繰り返して動くソフトウェアを段階的に届けるアプローチです。

アジャイル宣言の4つの価値
  • プロセスやツールよりも個人と対話
  • 包括的なドキュメントよりも動くソフトウェア
  • 契約交渉よりも顧客との協調
  • 計画に従うことよりも変化への対応

スクラム(Scrum)

スクラムはアジャイル開発の代表的なフレームワークです。ラグビーのスクラムのように、チームが一体となって目標に向かうイメージから命名されました。

要素内容
スプリント1〜4週間の短い開発サイクル。各スプリント終了時に動く機能を届ける
プロダクトバックログ実装すべき機能・要求の優先順位付きリスト。プロダクトオーナーが管理
スプリントバックログそのスプリントで実装するタスク一覧
デイリースクラム毎日15分の朝会。昨日やったこと・今日やること・障害を共有
スプリントレビュースプリント終了時にステークホルダーへデモ・フィードバック収集
レトロスペクティブチームの改善点を振り返る会議(振り返り)
役割責任
プロダクトオーナープロダクトバックログの優先順位管理。ビジネス価値の最大化
スクラムマスタースクラムの実践支援。障害の除去。チームのコーチ役
開発チーム自律・横断的なチーム。3〜9人。全員でソフトウェアを届ける

エクストリームプログラミング(XP)

XP(Extreme Programming)はアジャイル開発の手法の一つで、エンジニアリングプラクティスを極限まで高めることに特化しています。

プラクティス内容
ペアプログラミング2人1組でコーディング。リアルタイムレビューにより品質向上
テスト駆動開発(TDD)コードを書く前にテストを書く。テストが通るコードを実装
リファクタリング機能を変えずにコードの内部構造を改善。技術的負債の解消
継続的インテグレーション(CI)頻繁にコードを統合・ビルド・テストして問題を早期発見
シンプルデザイン今必要な機能だけを最もシンプルに実装する
コレクティブオーナーシップコードの所有権はチーム全員。誰でも任意のコードを変更できる

スパイラルモデル——リスクを中心に置いた反復開発

スパイラルモデルはBarry Boehmが1988年に提唱したモデルで、ウォーターフォールとプロトタイピングを組み合わせ、リスク分析を中心に螺旋(スパイラル)状に開発を繰り返します

スパイラルモデルの4ステップ(各サイクルで繰り返す)
  1. 計画策定:目標・代替案・制約を確定する
  2. リスク分析:代替案を評価し、リスクを特定・対策する(プロトタイプ作成も)
  3. エンジニアリング:設計・コーディング・テストを実施する
  4. 評価・計画:顧客レビューを実施し、次サイクルの計画を立てる
項目内容
最大の特徴リスク分析が中心。プロジェクトの不確実性が高い場合に有効
メリットリスクを早期に発見・対処できる。要件変更への柔軟性が高い
デメリットプロセスが複雑。リスク分析に専門知識が必要。コスト管理が難しい
適用場面大規模・高リスクなシステム。技術的な不確実性が高いプロジェクト

プロトタイピングモデル——早期に「動くもの」を見せる

プロトタイピングモデルは、本格的な開発に入る前に試作品(プロトタイプ)を素早く作りユーザーに確認してもらう手法です。要件が曖昧な場合や、UIの使い勝手をユーザーと一緒に確認しながら進める場合に特に有効です。

種類内容
使い捨て型プロトタイプ確認のためだけに作り、本番開発では使わない。要件確定が目的
進化型プロトタイププロトタイプを改良し続け、最終的に本番システムに育てる
⚠️ 試験頻出の落とし穴:プロトタイピングは「要件が不明確なとき」に有効です。「要件が明確で大規模なとき」はウォーターフォールが適切です。この使い分けを正確に押さえましょう。

開発手法の選択基準——どのモデルをいつ使うか

選択基準ウォーターフォールアジャイルスパイラルプロトタイピング
要件の安定性安定している変わりやすい不明確・高リスク曖昧・不明確
プロジェクト規模大規模小〜中規模大規模小〜中規模
納期の柔軟性固定納期段階的リリース柔軟短期で確認
チーム特性分業・専門化小さな自律チームリスク分析の専門家ユーザーと密連携
代表的な適用領域官公庁・金融スタートアップ・Web防衛・宇宙システムUI検討・新規事業

DevOpsとCI/CDパイプライン——開発と運用の融合

DevOpsは「Development(開発)」と「Operations(運用)」を組み合わせた造語です。開発チームと運用チームがサイロを壊して連携し、高速かつ安定したソフトウェアデリバリーを実現する文化・手法・ツールの組み合わせです。

DevOpsのコアコンセプト
概念内容
CI(継続的インテグレーション)開発者が頻繁にコードをリポジトリに統合し、自動ビルド・テストで問題を早期発見
CD(継続的デリバリー)テスト済みコードを本番環境に自動でデプロイできる状態を常に維持
継続的デプロイメントテストを通過したコードを自動で本番リリース(CDよりさらに自動化)
Infrastructure as Code(IaC)サーバー設定をコードで管理。再現性・自動化・バージョン管理が可能
監視・フィードバック本番システムを常時監視し、メトリクスをもとに継続的改善
CI/CDパイプラインの流れ
コードコミット
自動ビルド
自動テスト
ステージング環境デプロイ
本番環境デプロイ

各開発モデルの総合比較

モデル開発の進め方最大の強み最大の弱み適用場面
ウォーターフォール直線型(上流→下流)工程明確・管理しやすい要件変更に弱い要件安定・大規模
アジャイル(スクラム)反復型(スプリント)変化への適応・早期デリバリードキュメントが少ない要件変動・スタートアップ
スパイラル螺旋型(リスク中心)リスク管理が強力複雑・コスト高高リスク・大規模
プロトタイピング試作→フィードバック反復要件の早期明確化試作に甘えて本番が遅れやすい要件不明確・UI重視
DevOps/CI-CD開発〜運用の継続的連携高速・安定リリース組織文化変革が必要継続的改善・クラウドサービス

試験対策まとめ——頻出パターンと覚え方

🎯 試験頻出ポイント TOP5
① Vモデルの「要件定義↔受入テスト」「基本設計↔システムテスト」の対応関係
② ウォーターフォール:要件安定・大規模向け。アジャイル:要件変動・小規模向け
③ スパイラルモデルの中心は「リスク分析」
④ プロトタイピングは「要件が曖昧なとき」に有効
⑤ スクラムの3役割(PO・SM・開発チーム)と3つのイベント(レビュー・レトロ・デイリー)

よくある質問(FAQ)

Q1. ウォーターフォールとアジャイルは対立するものですか?
必ずしも対立するものではありません。大規模プロジェクトでは全体のフレームをウォーターフォールで管理しつつ、個々のサブシステムをアジャイルで開発する「ハイブリッドアプローチ」も現実には多く使われます。試験では「それぞれの適用場面の違い」を問われます。
Q2. スパイラルモデルとプロトタイピングモデルの違いは何ですか?
スパイラルモデルは「リスク分析」を中心に据え、大規模・高リスクなプロジェクトに使われます。プロトタイピングは「要件の確認」が主目的で、比較的小規模でUIや機能の方向性を早期に確かめたい場面に使われます。
Q3. DevOpsは「モデル」ではなく「文化」と聞きましたが、試験にはどう出ますか?
DevOpsはモデルというより組織文化・プラクティスの集合体です。試験ではCI/CDの定義、開発と運用の融合という概念、アジャイルとの親和性が問われることがあります。「継続的インテグレーション」「継続的デリバリー」の意味を正確に説明できるようにしましょう。
Q4. ブラックボックステストとホワイトボックステストの違いは?
ブラックボックステストは「内部構造を知らずに」入出力で機能を検証するテストです。外部仕様に基づきます。ホワイトボックステストは「内部構造(コード)を見ながら」網羅的にテストします。単体テストで主に使われます。試験では両者の特徴の違いが問われます。
Q5. スクラムのスプリント期間は固定ですか?
スクラムガイドでは「1ヶ月以内」とされており、一般的には1〜4週間です。期間はチームが決めますが、一度決めたら同じプロジェクト内では一貫させることが推奨されます。試験では「短い反復サイクル」という概念を押さえれば十分です。
Q6. 受入テスト(UAT)は誰が実施しますか?
受入テストはエンドユーザーまたは発注者(クライアント)が実施します。開発者ではなく、実際に使う人が業務シナリオに沿って検証します。「本当に業務に使えるか」を確認する最後の関門です。

ソフトウェア開発プロセスは、経営情報システムの中でも実務と直結した分野です。単に「ウォーターフォールは直線型」と覚えるだけでなく、「なぜウォーターフォールが生まれ、なぜアジャイルが必要とされたのか」という時代背景まで理解すると、応用問題にも自信を持って答えられます。Vモデルの対応関係・スクラムの役割・スパイラルのリスク中心という3点は特に押さえておきましょう。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

中小企業診断士試験勉強中のアラフィフシングルマザーです。
大学卒業後から現在まで、数々の失敗をしながらずっと自営業として試行錯誤を重ねてきました。
もっときちんと経営やビジネスの知識を身につけて、将来は他の事業者の方のお役にも立てたらいいな、と思うようになり、中小企業診断士の試験に挑戦中です。

目次