システム開発手法まとめ｜ウォーターフォール・アジャイル・見積手法
結論から
システム開発手法は「要件が固まっているか」「変化に対応する必要があるか」で選択が変わります。試験では各手法の特徴・向いている場面・弱点を問われます。見積手法はFP法（機能数ベース）とCOCOMO（コード行数ベース）の違いを押さえれば得点源になります。
1. ウォーターフォール開発
概念
ウォーターフォール（滝）という名前の通り、工程を上から下へ一方向に流れるように進めるシステム開発モデルです。各フェーズが完了してから次のフェーズに進みます。
flowchart TD
A[要件定義\nユーザーの要求を整理・文書化] --> B[外部設計\n画面・帳票・データ構造の設計]
B --> C[内部設計\nプログラム内部のロジック設計]
C --> D[実装・コーディング\nプログラムの製造]
D --> E[単体テスト\n個々のモジュールの動作確認]
E --> F[結合テスト\nモジュールを組み合わせた動作確認]
F --> G[システムテスト\nシステム全体の動作確認]
G --> H[受入テスト\nユーザーによる最終確認]
H --> I[運用・保守\n本番稼働・メンテナンス]
特徴
| 項目 | 内容 |
|---|---|
| 進行方向 | 原則として前の工程に戻らない |
| ドキュメント | 各フェーズで成果物（仕様書）を確定させる |
| 計画管理 | スケジュール・コスト管理がしやすい |
| 向いている場面 | 要件が最初から明確に決まっているシステム、大規模・長期プロジェクト |
| 弱点 | 途中の仕様変更が困難・コスト増大につながる |
試験での問われ方
「ウォーターフォール開発において、後の工程になるほど手戻りのコストが増大する。この原則を何というか」→ コストの増大（ゴールデンルール）
2. アジャイル開発
概念
アジャイル（Agile）とは「俊敏な」という意味です。要件の変化に柔軟に対応するため、小さな機能単位で「計画→開発→テスト→リリース」を繰り返す開発手法です。
flowchart LR
A[プロダクト\nバックログ作成] --> B[スプリント計画\n1〜4週間分の作業選定]
B --> C[スプリント実行\n設計・実装・テスト]
C --> D[スプリント\nレビュー]
D --> E{完成?}
E -- Yes --> F[リリース]
E -- No --> B
D --> G[スプリント\nレトロスペクティブ\n振り返り]
G --> B
スクラムの主要概念
スクラム（Scrum）はアジャイル開発の代表的なフレームワークです。
| 用語 | 意味 |
|---|---|
| スプリント | 1〜4週間の固定された開発サイクル |
| プロダクトバックログ | 実装すべき機能要求の優先順位付きリスト |
| スプリントバックログ | そのスプリントで実施する作業の一覧 |
| ベロシティ | 1スプリントでチームが完了できる作業量の指標 |
| デイリースクラム | 毎日15分の進捗共有ミーティング |
| プロダクトオーナー | 要件・優先順位を決定する役割 |
| スクラムマスター | スクラムの円滑な進行を支援する役割 |
向いている場面と弱点
- 向いている場面：要件が変化しやすいWebサービス開発、スタートアップ、仕様が不明確な初期段階
- 弱点：大規模プロジェクトへの適用が難しい、ドキュメント化が不足しやすい、プロジェクト全体の見通しが立てにくい
3. その他の開発モデル
プロトタイピングモデル
要件定義の段階でプロトタイプ（試作品）を作成し、ユーザーに確認しながら仕様を固めていくモデルです。
- メリット：ユーザーの要求を早期に確認できる・認識のズレを防げる
- デメリット：プロトタイプの作成コストがかかる・品質管理が難しい
- 適用場面：ユーザーインターフェースが重要なシステム、要件が不明確な場合
スパイラルモデル
ウォーターフォールとプロトタイピングを組み合わせたモデルです。「計画→リスク分析→開発→評価」のサイクルを繰り返しながら段階的にシステムを完成させます。
flowchart LR
A[計画] --> B[リスク分析]
B --> C[開発・テスト]
C --> D[評価・見直し]
D --> A
- メリット：リスクを早期に発見・対処できる
- デメリット：管理が複雑・コストがかかりやすい
各手法の比較
| 手法 | 特徴 | 向いている場面 |
|---|---|---|
| ウォーターフォール | 工程が明確・管理しやすい | 要件確定済み・大規模 |
| アジャイル（スクラム） | 変化に柔軟・頻繁なリリース | 要件変動あり・小〜中規模 |
| プロトタイピング | 早期にユーザー確認 | UI重視・要件不明確 |
| スパイラル | リスク管理を重視 | リスクが高い大規模開発 |
4. ソフトウェア見積手法
ファンクションポイント（FP）法
ソフトウェアの機能規模をもとに開発工数を見積もる手法です。「ユーザーから見た機能の数と複雑さ」で規模を定義します。
見積もりの対象（FPカウント対象）
| 種別 | 例 |
|---|---|
| 外部入力 | 入力画面・フォーム |
| 外部出力 | 出力帳票・レポート |
| 外部照会 | 検索機能・問い合わせ |
| 内部論理ファイル | システム内部で管理するデータ |
| 外部インタフェースファイル | 外部システムとのデータ連携 |
特徴：プログラム言語に依存しない。プログラム行数（LOC）は関係しない。
COCOMOモデル
COCOMO（Constructive Cost Model）は、**ソースコードの行数（LOC: Lines of Code）**を基準に開発工数・期間を見積もるモデルです。
開発工数 = a × (KLOC)^b × 補正係数
（KLOCはキロ行単位のソースコード行数）補正係数には、「要求の信頼性」「技術者の能力」「ハードウェアの制約」などが含まれます。
FP法とCOCOMOの比較
| 項目 | ファンクションポイント法 | COCOMO |
|---|---|---|
| 見積もり基準 | 機能の数と複雑さ | ソースコード行数（LOC） |
| 使用タイミング | 設計初期（コーディング前でも可） | コーディングある程度進んだ後 |
| 言語依存性 | 依存しない | 依存する（言語で行数が変わる） |
| ユーザー視点 | ○（機能ベース） | △（技術者視点） |
よくある疑問
Q. ウォーターフォールとアジャイルはどちらが優れているのですか？
A. 優劣ではなく「適用場面が違う」という理解が正しいです。要件が固まっていて変更がほぼない大型基幹システム（ERPの導入など）はウォーターフォール、Webサービスや機能追加が頻繁なシステムはアジャイルが適しています。試験でも「どちらが優れているか」ではなく「どの場面で何を選ぶか」が問われます。
Q. プロトタイプとMVPはどう違いますか？
A. プロトタイプは開発手法の文脈で「仕様確認のための試作品」を指します。MVP（Minimum Viable Product）はリーンスタートアップの文脈で「最小限の機能で市場に出す製品」を指します。診断士試験ではプロトタイプの概念が出題対象です。
Q. FP法は実際にどうやってFPを数えるのですか？
A. 入力画面・出力帳票・データファイルなどを「簡単/普通/複雑」の難易度に分類し、それぞれの重み（ポイント数）を掛けて合計します。試験ではFP法の「特徴と用途」が問われることが多く、具体的な計算手順は深入りしなくて大丈夫です。
Q. COCOMOのKLOCはプログラムを書く前には分からないのでは？
A. その通りです。だから実際には「過去の類似プロジェクトのデータ」「概算設計からの推定」を使います。COCOMOは「設計後の見積精度向上」に使われることが多く、プロジェクト初期より中期以降の精緻化に向いています。
まとめ
- ウォーターフォール：要件確定済みの大規模開発向き。工程が明確で管理しやすいが、仕様変更に弱い
- アジャイル（スクラム）：要件変化への柔軟な対応が強み。スプリント・バックログ・ベロシティが重要キーワード
- プロトタイピング：早期のユーザー確認で認識ズレを防ぐ。UI重視の開発に向く
- スパイラル：リスク管理を組み込んだ反復型。大規模・高リスク開発に向く
- FP法：機能数ベースの見積。言語非依存で開発初期から使える
- COCOMO：LOCベースの見積。技術的詳細が固まってから精度が上がる
試験では「どの手法がどの場面に適しているか」の選択問題と、各キーワードの定義が主な出題パターンです。