---
note: 開発プロセス全体の見取り図。各工程が何を決め、何を残すか
created: 2026-08-08T17:32:14+09:00
---

# 開発プロセスの全体像

システム開発は「作るものを決める」工程と「作って届け、動かし続ける」工程からなる。
本ハンドブックでは前半の4つを **4層モデル** と呼び、中心的に扱う。

この分類は本ハンドブックの独自定義であり、ISO/IEC/IEEE 12207(共通フレーム)・ISO/IEC/IEEE 29148・V字モデルなどを源流に実務向けへ整理したもの(後述「標準規格との対応」を参照)。

## 定義する工程(4層モデル)

### 要求

**なぜやるか**。ビジネスと業務の話であり、唯一システムの話をしない層。
主語はユーザーや発注者。背景・目的・成功基準(数値)・制約・スコープ外を明らかにする。

- 例(設備保全):「設備の突発停止による生産ラインの停止を月20時間から5時間に減らしたい」
- 例(動画レコメンド):「初月で解約する利用者を減らし、継続率を60%から75%にしたい」
- 例(社内文書検索):「類似の社内文書を探す時間を半日から30分にしたい」
- 残す文書: 要求定義書(PRD)

### 要件

**何を実現するか**。要求を満たすためにシステムに求める機能・性質。
ここから主語が「システムは〜」になる。

- 例(設備保全):「設備の振動と温度から異常の兆候を検知し、担当者に知らせられること」
- 例(動画レコメンド):「利用者ごとに視聴傾向に沿った作品を提案できること」
- 例(社内文書検索):「全部門の社内文書をキーワードで横断検索できること」
- 残す文書: 要件定義書

### 仕様

**どう振る舞うか**。システムを外から見た振る舞いの取り決め。
入力・出力・条件・例外を定め、「正しい/間違い」を判定できる基準になる。

- 例(設備保全):「振動が基準値の1.5倍を10分超え続けたら警告、同一設備への通知は1時間に1回まで」
- 例(動画レコメンド):「トップに10件、視聴済みは除外、視聴履歴が3件未満の利用者には人気順を返す」
- 例(社内文書検索):「キーワードは100文字まで、結果は関連度順に20件表示」
- 残す文書: 画面仕様書、API仕様書、バッチ仕様書

### 設計

**どう作るか**。仕様を実現する内部構造と技術の選択。
ここで初めて実装の中身の話になる。

- 例(設備保全):「センサー値を1分間隔で時系列データベースに蓄積し、移動平均との乖離で判定」
- 例(動画レコメンド):「協調フィルタリングを日次バッチで計算し、結果を利用者ごとにキャッシュ」
- 例(社内文書検索):「Elasticsearchでkuromoji解析、match_phraseクエリ」
- 残す文書: 設計書(アーキテクチャ、DB設計、シーケンス)

## 作り、届け、動かす工程

### 実装

設計に従いコードを書く。決め事はコーディング規約・レビュー観点・ブランチ戦略として残す。
実装中に仕様や設計の矛盾が見つかったら、コードで勝手に解決せず上の層へ差し戻す。

### テスト

作ったものが**上の層の決め事どおりか**を確かめる。検証対象は層と対応する:
単体テスト↔設計、結合テスト↔仕様、システムテスト↔要件、受入テスト↔要求(V字モデル)。

- 残す文書: テスト計画、テスト観点表

### リリース

作ったものを利用者に届ける。手順の再現性と、失敗時に戻れることが要点。

- 残す文書: リリース手順書、チェックリスト、ロールバック基準

### 運用

動かし続け、問題から学ぶ。監視・障害対応・改善のサイクル。
ここで得た知見が次の要求の種になり、プロセスは一周する。

- 残す文書: 運用手順、障害対応フロー、ポストモーテム

## 標準規格との対応

本ハンドブックの分類は独自定義だが、以下の標準・モデルを源流としている。

### ISO/IEC/IEEE 12207 と共通フレーム

ソフトウェアライフサイクルプロセスの国際規格。開発だけでなく、企画・運用・保守・廃棄まで含むプロセス全体を定義する。IPAの「共通フレーム」はこれを日本向けに拡張したもので、日本のSIにおける工程分割(企画→要件定義→設計→実装→テスト→運用・保守)の事実上の出どころ。

- 共通フレームの工程との対応: 企画・要件定義プロセス ≈ 要求/要件、方式設計〜詳細設計 ≈ 仕様/設計、以降は実装〜運用にそのまま対応
- 特徴は要件定義より前の「企画(超上流)」を明示的に工程化していること。本ハンドブックの「要求」はここに相当する

### ISO/IEC/IEEE 29148(要求工学)

要求の獲得・分析・記述に関する規格。要求を段階の異なる文書として区別する:

| 文書 | 内容 | 本ハンドブックでの対応 |
|---|---|---|
| StRS (Stakeholder Requirements) | ステークホルダーが何を必要としているか | 要求 |
| SyRS (System Requirements) | システムが何を満たすべきか | 要件 |
| SRS (Software Requirements) | ソフトウェアが何を満たすべきか | 要件〜仕様 |

英語ではいずれも requirements であり、「要求/要件」の訳し分けは日本語圏の工夫。この規格の「ステークホルダーの要求とシステムの要件は別物」という区別が、4層モデルの上2層の根拠になっている。

### V字モデル

工程とテストレベルの対応関係を示すモデル。左辺(定義)と右辺(検証)が層ごとに対になる:

| 定義(左辺) | 検証(右辺) |
|---|---|
| 要求 | 受入テスト |
| 要件 | システムテスト |
| 仕様 | 結合テスト |
| 設計 | 単体テスト |

「各層はそれぞれ検証できる相手が違う」という4層モデルの根拠はこの対応にある。層を省くと、対応する検証が根拠を失う。

### 日本のSI慣行(外部設計/内部設計)

「仕様」を要件と設計の間の独立した層として立てるのは、外部設計(外から見た振る舞い)/内部設計(中身)という日本の伝統的な工程分割に由来する。海外では仕様(functional spec)を要件側に含めるか設計側に寄せるかは揺れており、独立層として扱うのはこのハンドブックの選択である。

## 全体の関係

```
なぜ        要求
何を         └ 要件
振る舞い        └ 仕様
作り方           └ 設計
                  └ 実装 → テスト → リリース → 運用 ─┐
なぜ(次) 要求 ←──────────────────────────┘
```

- 前半4層は**抽象から具体への段階的詳細化**。工程であると同時に、完成後も残る文書の階層でもある
- 変更が起きたら「どの層の変更か」を最初に見極める。要求の変更を仕様の修正だけで受けると、文書と実態がズレていく
- 確定の順序は開発形態で前後する。受託はおおむね上から下へ、自社プロダクトではプロトタイプ(仕様・実装)が先行して要求が後から明確になる逆流も起きる