ドキュメントフェーズ概要
Document Phases Overview
本ドキュメントは、要求 → 要件 → 仕様 → 設計 → 実装 の各フェーズにおける整理内容について定義します。
| フェーズ | 本質 |
|---|---|
| 要求 | なぜやりたいか |
| 要件 | 何を満たす必要があるか |
| 仕様 | どう振る舞うべきか |
| 設計 | どう実現するか |
| 実装 | 現実に適用・定着させる |
定義に当たっては、高齢のおばあちゃんが一人で営んでいる駄菓子屋の業務システム構築を想定して、 例を記述します。おばあちゃんの駄菓子屋では、常連の子どもは多いが、
商品の値段計算, 在庫の把握, 売上の記録
が負担になってきている。そこで 駄菓子屋を無理なく続けられる仕組み を考えたい、というシナリオです。
1. フェーズ全体対応表
| フェーズ | 用語 | 5W1H | 対象 | 定義 |
|---|---|---|---|---|
| 1 | 要求（Needs） | Why | 業務・人 | 目的・価値・困りごと |
| 2 | 要件（Requirements） | What（条件） | 業務＋システム | 満たすべき条件 |
| 3 | 仕様（Specifications） | What（振る舞い） | 業務＋システム | 振る舞いの定義 |
| 4 | 設計（Design） | How（方式） | 業務＋システム | 実現方式・構造 |
| 5 | 実装（Implementation） | How（具現） | 業務＋システム | 実行・適用 |
2. フェーズ横断で特に危険なアンチパターン
2.1. 典型的なアンチパターン
| フェーズ | 典型的失敗 |
|---|---|
| 要求 | 目的を言語化しない |
| 要件 | 条件を検証可能にしない |
| 仕様 | 振る舞いを曖昧にする |
| 設計 | 業務を設計しない |
| 実装 | 現場に適用しない |
2.2. 横断的なアンチパターン
| アンチパターン | 影響 |
|---|---|
| Why → What → How のトレースがない | 変更に耐えない |
| 粒度が混在 | 読めない・更新できない |
| 用語定義がない | 人・AIともに誤解 |
| 非機能を後回し | 使えない完成品 |
2.3. 補足
地図を持たずに歩き出せば、 速く歩ける人ほど、遠くまで迷う。
多くの失敗は能力不足ではなく、 目的（Why）・条件（What）・方法（How）を 区別せずに進んでしまうことで起きる。 本ガイドは、その混乱を防ぐための思考の整理である。
3. 要求（Needs）
業務の目的・価値を定義するフェーズ
| 観点 | 内容（駄菓子屋の例） |
|---|---|
| 困りごと | 暗算や在庫管理がつらくなってきた |
| 続けたい理由 | 子どもとの交流、地域の居場所 |
| ゴール | 無理せず駄菓子屋を続けられること |
3.1. 要求フェーズのアンチパターン
| アンチパターン | 原因 | 起きる問題 | 駄菓子屋の例 |
|---|---|---|---|
| 要求を書いたつもりで「手段」を書く | WhyとHowの混同 | 目的が不明確 | 「タブレットを導入したい」が要求になる |
| 要求を一文スローガンで終わらせる | 合意の浅さ | 判断軸が残らない | 「店を続けたい」だけで理由がない |
| 要求をエンジニアに丸投げ | 役割誤解 | 価値が実装に反映されない | 「あとはいい感じに」 |
3.2. 補足
マゼラン艦隊は、 航路や手段を失っても航海を続けられた。 それは「西回りで香料諸島へ到達する」という 目的が明確に共有されていたからである。
要求フェーズの失敗は逆である。Why が文書として残らなければ、途中で正しさを判断できなくなる。
4. 要件（Requirements）
要求を満たすための条件を定義するフェーズ
| 種別 | 要件（例） |
|---|---|
| 業務要件 | 子どもを待たせないこと |
| 業務要件 | 会計ミスを防ぐこと |
| システム要件 | 合計金額を正しく算出できること |
| 制約・前提 | 機械が苦手でも使えること |
制約・前提も要件として明文化する。
4.1. 要件フェーズのアンチパターン
| アンチパターン | 原因 | 起きる問題 | 駄菓子屋の例 |
|---|---|---|---|
| 要件を飛ばす | 早く作りたい | スコープ崩壊 | いきなりUI設計に入る |
| 要件が抽象的 | 検証意識不足 | 受入不能 | 「簡単に使える」だけ |
| 要件に設計を混ぜる | Shall/How混同 | 変更不能 | 「SQLiteで在庫管理する」 |
4.2. 補足
測定できない条件は、管理も検証もできない。
要件が検証可能な条件として定義されなければ、それは合意でも約束でもない。 要件フェーズの本質的な失敗は、「満たすべき条件」が検証可能でないことである。
5. 仕様（Specifications）
要件を満たすための振る舞いを定義するフェーズ。業務仕様とシステム仕様を区別する。 業務仕様は、現場のルール（人の判断を含む）。システム仕様は、入力・状態・出力として観測可能な振る舞い。
5.1. 業務仕様（Business Specification）
| 条件 | 業務の振る舞い |
|---|---|
| 子どもが商品を持ってきたら | 店主が合計金額を提示する |
| お金が足りない場合 | 販売は成立しない |
| 販売成立時 | 在庫を減らす |
| 営業終了時 | その日の売上を確認する |
5.2. システム仕様（System Specification）
| 条件 | システムの振る舞い |
|---|---|
| 商品を選択したとき | 合計金額を表示する |
| 会計確定時 | 在庫数を1減らす |
| 在庫が0のとき | 選択不可とする |
| 日付変更時 | 日次売上を集計する |
5.3. 仕様フェーズのアンチパターン
（業務仕様・システム仕様）
| アンチパターン | 原因 | 起きる問題 | 駄菓子屋の例 |
|---|---|---|---|
| 業務仕様を書かない | 暗黙知前提 | 現場不適合 | 売上確認のやり方が未定義 |
| 画面仕様＝仕様だと思う | 視覚偏重 | ルール抜け | 例外処理がない |
| 例外・境界を書かない | 正常系思考 | 現場停止 | お金が足りない時が未定義 |
5.4. 補足
「気をつけて運転せよ」という指示だけでは、交通は成立しない。
信号・優先・停止線といった具体的な振る舞いが定義されて、初めてルールになる。 仕様フェーズの本質的な失敗は、振る舞いを具体的に定義しないことである。
6. 設計（Design）
仕様をどう実現するかを決めるフェーズ。業務設計とシステム設計に分けて整理する。
| 観点 | 業務設計 | システム設計 |
|---|---|---|
| 会計 | 商品をまとめて一括会計 | 会計処理コンポーネント |
| 在庫 | 営業後に在庫確認 | 在庫管理データ構造 |
| 操作 | 声出し確認を行う | 大きなボタンUI |
| 責務 | 店主の判断を明確化 | 処理を自動化 |
6.1. 設計フェーズのアンチパターン
| アンチパターン | 原因 | 起きる問題 | 駄菓子屋の例 |
|---|---|---|---|
| 設計＝IT設計だけ | 業務軽視 | 業務が壊れる | 新レジ導入で会計が遅くなる |
| 設計で仕様を変更 | フェーズ逆転 | 合意崩壊 | 設計段階で会計ルールを変える |
| 将来変更を考えない | 近視眼 | 保守不能 | 商品追加が毎回改修 |
6.2. 補足
なぜそこに柵があるか分からないなら、まずそれを理解するまで壊してはならない。
仕様（What）を理解せずに設計（How）を変えると、本来守るべき目的まで壊してしまう。 設計フェーズの本質的な失敗は、How が勝手に What を書き換えることである。
7. 実装（Implementation）
設計した内容を現実に適用するフェーズ。業務実装とシステム実装を区別する。
| 観点 | 業務実装 | システム実装 |
|---|---|---|
| 会計 | 新しい会計手順に慣れる | 会計ロジック実装 |
| 在庫 | 紙メモをやめる | 在庫更新処理 |
| 運用 | 毎日売上を確認 | 日次集計機能 |
| 検証 | 実務で問題ないか | 単体・結合テスト |
7.1. 実装フェーズのアンチパターン
| アンチパターン | 原因 | 起きる問題 | 駄菓子屋の例 |
|---|---|---|---|
| 作ったら終わり | 業務実装軽視 | 使われない | 新手順の説明なし |
| 現場検証をしない | テスト偏重 | 運用事故 | 実際はボタンが小さい |
| 実装で仕様を補完 | 文書不足 | 属人化 | 例外対応を口頭で処理 |
7.2. 補足
処方箋は、書かれただけでは患者を治さない。 実際に服用され、継続されて初めて効果を持つ。
実装フェーズの本質的な失敗は、設計した内容が現実に適用されないことである。
8. おわりに
正しい答えは、正しい問いと順序からしか生まれない。
要求から実装までを一貫して整理することは、遠回りではない。最短で「使われる成果」にたどり着くための道です。