この記事の要点

ソフトウェア開発の典型工程: 要件定義 → 基本設計 → 詳細設計 → 実装 → テスト → リリース → 運用・保守 テストは 4 段階: 単体 (UT) / 結合 (IT) / 総合 (ST) / 受入 (UAT) 進め方: ウォーターフォール（順番）/ アジャイル（反復、Scrum / Kanban / XP） V 字モデル: 左側の各工程設計に対応するテストが右側に並ぶ 見積もり手法: FP (Function Point) / COCOMO / Story Points / 三点見積 レビュー: 設計レビュー / コードレビュー / ペアレビューで品質を担保

開発工程の全体像

ソフトウェア開発は典型的に次の 7 工程で進みます。プロジェクトの性質によりウォーターフォール（順番）かアジャイル（反復）で実施します。

工程	目的	成果物
1. 要件定義	「何を作るか」を決める	要件定義書 (RFP/SRS)
2. 基本設計（外部設計）	ユーザから見える仕様	画面遷移図 / 帳票レイアウト / ER 図
3. 詳細設計（内部設計）	プログラム構造	クラス図 / シーケンス図 / テーブル定義書
4. 実装	コードを書く	ソースコード / 単体テストコード
5. テスト	品質確認	テスト仕様書 / 結果報告書
6. リリース	本番投入	リリース手順書 / 移行データ
7. 運用・保守	稼働継続・改善	運用マニュアル / 監視ルール

1. 要件定義

もっとも重要かつ失敗しやすい工程。発注者と開発者が「何を作るか」をすり合わせます:

• 機能要件: システムが何をするか（業務フロー、画面、帳票）
• 非機能要件: 性能 / 可用性 / セキュリティ / 運用性（IPA「非機能要求グレード」が参考）
• 制約条件: 予算 / 期限 / 既存システム連携 / 技術指定

2. 基本設計（外部設計）

ユーザーや外部システムから見える「外側」を設計します:

• 画面設計（ワイヤーフレーム / 画面遷移図）
• 帳票設計（PDF / Excel レイアウト）
• 外部インターフェース（API 仕様、ファイル受渡し）
• データベース論理設計（ER 図）
• バッチ処理の概要

3. 詳細設計（内部設計）

プログラム内部の構造を設計。UML（統一モデリング言語）で表現することが多い:

図	表すもの
クラス図	クラスと関連
シーケンス図	オブジェクト間の時系列メッセージ
アクティビティ図	業務フロー / 処理フロー
ステートマシン図	状態遷移
テーブル定義書	物理 DB スキーマ（カラム・型・制約・INDEX）

4. 実装

コードを書く工程。実装時に守るべき基本:

• コーディング規約に従う（PEP 8 / PSR-12 / Airbnb など）
• Linter / Formatter を CI で強制
• 単体テストを同時に書く（理想は TDD）
• こまめに git commit、Pull Request 単位でレビュー
• セキュアコーディング（OWASP Top 10 を意識）

5. テスト工程（V 字モデル）

V 字モデル — 設計工程と対応するテスト

要件定義 ─────────────► 受入テスト (UAT)
   ＼                                    ／
    基本設計 ────────► 総合テスト (ST/システムテスト)
       ＼                            ／
        詳細設計 ──► 結合テスト (IT)
           ＼                  ／
            実装 ── 単体テスト (UT)

階層    対象        誰が
UT      関数・クラス  開発者
IT      モジュール間  開発者・QA
ST      システム全体  QA
UAT     業務シナリオ  発注者・現場ユーザー

テスト技法	意味
ホワイトボックス	内部構造を見て分岐網羅、命令網羅
ブラックボックス	仕様だけ見て同値分割、境界値分析
回帰テスト (Regression)	既存機能が壊れていないか確認
負荷テスト	性能・スループット (JMeter / k6)
セキュリティテスト	脆弱性スキャン (OWASP ZAP / Burp)

6. リリース・デプロイ

• Blue/Green デプロイ: 旧環境(Blue)を残しつつ新環境(Green)へ切替
• カナリアリリース: 一部ユーザーに先行公開して問題検知
• ローリングデプロイ: 1 台ずつ順次更新（Kubernetes 標準）
• フィーチャーフラグ: 機能 ON/OFF を実行時に切替

7. 運用・保守

分類	内容
是正保守	バグ修正
適応保守	OS / ライブラリのバージョンアップ対応
完全化保守	性能改善、UI 改善
予防保守	潜在的な問題の事前対処

ウォーターフォール vs アジャイル

項目	ウォーターフォール	アジャイル
進め方	工程を順番に	2-4 週の反復
要件変更	困難・高コスト	歓迎
計画	事前に詳細策定	適応的
適している	仕様が固い基幹系	変化の多い Web / モバイル
納品	最後にまとめて	反復ごとに動くもの

アジャイル開発の代表手法

• Scrum: 1-4 週のスプリント、Product Owner / Scrum Master / 開発チーム。デイリースクラム、レトロスペクティブ
• Kanban: WIP 制限、フローの可視化、トヨタ生産方式由来
• XP (Extreme Programming): TDD、ペアプログラミング、継続的統合、リファクタリング
• Lean: ムダの排除、価値の最大化

見積もり手法

手法	方式	適性
Function Point (FP)	機能数を係数で換算	業務系の規模見積
COCOMO II	LOC + 補正係数	大規模ソフト
Story Points	相対サイズ (1/2/3/5/8/13)	アジャイル
三点見積	(楽観 + 4×標準 + 悲観) ÷ 6	不確実性の表現
類推見積	類似実績との比較	経験豊富な領域
プランニングポーカー	チームでカード合議	Scrum

レビューの種類

• 設計レビュー: 基本設計書 / 詳細設計書の妥当性
• コードレビュー: Pull Request ベースが主流、自動 Lint + 人の目
• インスペクション: チェックリストに基づく形式的な欠陥摘出
• ウォークスルー: 著者主導で説明、参加者から指摘
• ペアレビュー: 2 人で同時に書く（XP の手法）

FAQ

Q: アジャイルなら設計しなくていい？
A: 誤解です。アジャイルでも設計はします。ただし「先に全部決める」のではなく、必要な分を随時設計します。

Q: 単体テストはどこまでやる？
A: カバレッジ 80% が一つの目安。ただし数値より「重要なビジネスロジック」と「複雑な分岐」を網羅することが優先。

Q: 見積もりが当たらない
A: 過去実績ベース、複数手法併用、不確実性込みのバッファ、定期的な再見積もりが基本対策です。