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

システム開発の話をするとき、「ウォーターフォールで作ったけど要件が変わって大変だった」という話をよく聞きます。アジャイルが注目された理由が、この「変化に対応できるか」という点にあることを学んで、開発手法の選び方に経営戦略的な視点があることに気づきました。

この記事でわかること

ウォーターフォールモデルの流れと特徴・問題点
プロトタイプモデル・スパイラルモデルの違い
アジャイル開発（スクラム）のメリットと適用場面
システム化計画からリリースまでのプロセス
テスト手法（単体・結合・システム・受入テスト）

ウォーターフォールモデル——順番に下る滝

最も古典的なシステム開発手法。各工程を順番に完了させてから次へ進む。前工程への戻りを原則認めない。

ウォーターフォールの工程（試験頻出）

要件定義 → 外部設計（概要設計）→ 内部設計（詳細設計）→ プログラム設計 → コーディング → テスト → 運用・保守

外部設計：ユーザー視点でシステムの機能・画面・帳票を設計
内部設計：プログラマー視点でモジュール構造・アルゴリズムを設計
コーディング：プログラムを実際に書く
テスト：単体→結合→システム→受入の順に検証

ウォーターフォールのメリット

・計画・進捗管理がしやすい
・大規模プロジェクトに向く
・ドキュメントが整備される
・コスト・スケジュールが見通しやすい

ウォーターフォールのデメリット

・途中で要件変更が困難
・動くものが見えるのは終盤
・手戻りコストが大きい
・要件定義の精度に依存する

プロトタイプ・スパイラル・RAD

手法	概要	特徴・向く場面
プロトタイプモデル	試作品（プロトタイプ）を早期に作成し、ユーザーに確認してもらいながら開発	要件が不明確なとき。ユーザーの合意を得やすい。画面デザイン重視のシステムに向く
スパイラルモデル	小さなサイクル（計画→設計→実装→評価）を繰り返しながら機能を拡張	リスク分析を各サイクルで行う。大規模・長期プロジェクトに向く。ボーム提唱
RAD（Rapid Application Development）	CASE（自動化ツール）を活用して短期間で開発	短納期が求められるとき。ツール依存のため拡張性に制限あり
インクリメンタルモデル	機能を分割して段階的にリリース（増分追加）	早期に一部機能を提供できる。優先順位の高い機能から使い始められる

アジャイル開発——変化に対応する反復型

アジャイル（Agile）は「俊敏な」という意味。短い期間（イテレーション・スプリント）を繰り返しながら、動くソフトウェアを継続的にリリースします。2001年に「アジャイルソフトウェア開発宣言」として定式化されました。

スクラム（Scrum）——アジャイルの代表的フレームワーク

スプリント：1〜4週間の反復サイクル
プロダクトバックログ：開発すべき機能の優先順位付きリスト
スプリントバックログ：今回のスプリントで取り組む作業リスト
デイリースクラム：毎日15分の進捗共有ミーティング
スプリントレビュー：完成した機能をステークホルダーが確認
スプリントレトロスペクティブ：チームの改善点を振り返る

観点	ウォーターフォール	アジャイル
要件の変更	困難（変更コスト大）	柔軟に対応できる
リリース	開発終了後に一括	スプリントごとに継続リリース
向く開発	要件が明確・大規模・安定	要件が変化しやすい・Web・スタートアップ
ドキュメント	重視する	動くソフトウェアを優先（最低限でよい）

テスト手法——V字モデルで整理

V字モデル（テストの対応関係）

単体テスト（ユニットテスト）：プログラム設計に対応。個々のモジュール（関数・クラス）を単独で検証
結合テスト（統合テスト）：内部設計に対応。モジュール間のインターフェースを検証
システムテスト：外部設計に対応。システム全体として要件を満たすか検証
受入テスト（UAT）：要件定義に対応。ユーザーが実際の業務で使えるか検証

テスト技法	内容
ブラックボックステスト	内部構造を考慮せず、入力と出力（仕様）の観点で検証。同値分割・境界値分析
ホワイトボックステスト	内部ロジック（分岐・ループ）をすべて通るよう検証。命令網羅・分岐網羅
リグレッションテスト	修正後に既存機能が壊れていないか確認する回帰テスト