AI時代の要件定義——機能要件は「翻訳レイヤ」に過ぎない

結論から言う

「業務要件 →（人間向けの）機能要件を飛ばして → 実装にマッピングする」

この世界観は、AI時代にはむしろ"正しい進化"だ。

従来のシステム開発では、業務要件を機能要件に落とし、それを実装に変換するという三段階のプロセスが常識だった。だが、この「機能要件」というレイヤは、本当に必要なのか？

機能要件は「本質」ではなく「翻訳レイヤ」

そもそも機能要件とは何か。

機能要件というのは、人が作る時にプログラマーが理解するためのレイヤ

これは正解だ。

もともと機能要件は 人間同士（業務担当 ⇄ エンジニア）の翻訳装置 として存在している。

| レイヤ | 役割 | 誰のため | |--------|------|----------| | 業務要件 | 何を達成したいか、何が困っているか | ユーザー | | 機能要件 | 人が実装できる粒度に分解するための中間言語 | エンジニア | | 実装 | 実際に動くもの | システム |

AIが間に入るなら、「人間向け翻訳レイヤ」は不要になる。

これは自然な帰結だ。

ユーザーは「機能要件」を理解したいわけじゃない

現場で何が起きているか。

ユーザーからすると、業務要件を渡した後、機能要件の確認なんかわからない

これは100%正しい。

ユーザーが本当に確認したいのは：

この要望はちゃんと伝わったか？
それを作ると、どういう動きになるのか？
業務的にズレてないか？

つまり、「業務要件 → 実装の対応関係」 だけが重要なのだ。

機能要件そのものは、

開発者のため
監査・契約・責任分界のため

に存在していただけで、価値の最終受益者はユーザーではない。

AI前提なら「業務要件 → 実装」の直結でいい

だから、この結論はかなり妥当だ。

業務要件がいきなり機能・実装になる世界観でいい

ただし、1点だけ注意すべきことがある。

機能要件を「消す」のではなく「内部化」する

おすすめの整理はこうだ。

レイヤ構造（人間視点）

[ 業務要件（ユーザーが書く） ]
        ↓
[ 実装イメージ（ユーザーが確認する） ]

レイヤ構造（AI内部）

業務要件
  ↓（解釈）
暗黙の機能要件（AIの思考・中間表現）
  ↓
実装設計
  ↓
コード

つまり：

ユーザーには機能要件を見せない
AIの内部では機能要件的な構造は持たせる

この分離が重要だ。

「機能要件」の代わりに見せるべきもの

では、ユーザーに何を返すか。

おすすめは 機能要件ではなく「業務⇄実装マッピング」 だ。

例

業務要件：

「見積依頼を入力したら、すぐ概算金額を知りたい」

AIが返す確認用テキスト：

この要件は、次の動作として実装されます：

入力フォームを1画面で提供

入力内容をもとに規模・難易度を自動評価

即時に概算金額レンジを表示

人手での確認が必要な場合は、その旨を明示します

これは機能要件っぽいが、語り口は完全に業務目線だ。

ユーザーは「何が起こるか」を理解できる。エンジニア向けの中間言語ではない。

「業務関数」という思想との接続

この考え方は、業務を関数として扱うという思想と完全に一致する。

入力 → 処理 → 出力

実際の設計はこうなる：

業務要件テキスト
  ↓
業務関数定義（入力 / 出力 / 制約）
  ↓
AIによる実装生成

機能要件＝業務関数の内部実装

この位置づけが一番しっくり来る。

三段階モデルの終焉

従来のシステム開発モデルを振り返ろう。

| フェーズ | 成果物 | 担当者 | |----------|--------|--------| | 要件定義 | 業務要件書 | 業務担当 + コンサル | | 基本設計 | 機能要件書 | SE | | 詳細設計 | 設計書 | SE + PG | | 実装 | コード | PG | | テスト | テスト結果 | PG + QA |

このモデルは、人間の認知限界と分業体制を前提としていた。

担当者レイヤの変化

従来、各フェーズには専門の担当者が必要だった。AI時代にはこれが劇的に変わる。

【従来モデル】

  業務要件        機能要件        実装
┌──────────┐    ┌──────────┐    ┌──────────┐
│          │    │          │    │          │
│  コンサル  │ →  │    SE    │ →  │   PG    │
│  上流SE   │    │          │    │          │
└──────────┘    └──────────┘    └──────────┘
   人間が定義      人間が翻訳      人間が実装

【AI時代モデル】

  業務要件                    機能要件 + 実装
┌──────────┐              ┌─────────────────┐
│          │              │                 │
│  コンサル  │ ──────────→ │       AI        │
│  上流SE   │              │                 │
└──────────┘              └─────────────────┘
   人間が定義                 AIが翻訳＆実装

中間層（SE・PG）が不要になるのではなく、AIに置き換わる。

コンサル・上流SEの役割は変わらない。むしろ重要度が増す。なぜなら、業務要件の質がそのまま実装の質を決めるからだ。

AI時代には、こう変わる：

| フェーズ | 成果物 | 担当者 | |----------|--------|--------| | 要件定義 | 業務要件テキスト | ユーザー + コンサル/上流SE | | 確認 | 業務⇄実装マッピング | AI + ユーザー | | 実装 | コード + テスト | AI | | 検証 | 動作確認 | ユーザー |

機能要件書、設計書という中間成果物が消える。

この思想の言語化

もし言語化するなら、こんなフレーズが使える：

本ツールでは、従来の「業務要件 → 機能要件 → 実装」という分離を前提とせず、業務要件をそのまま実装に変換することを基本思想としています。機能要件はAI内部の翻訳レイヤとして扱われ、ユーザーには業務と実装の対応関係のみを提示します。

この思想は、書籍にもプロダクト思想にもそのまま使える。

まとめ

**機能要件は「人間同士の翻訳装置」**だった
AIが翻訳を担うなら、ユーザーに見せる必要はない
ただし、AIの内部では機能要件的な構造は持たせる
ユーザーには「業務⇄実装マッピング」を返す
「業務を関数として扱う」思想と完全に一致する

AI時代の要件定義は、中間翻訳を内部化し、ユーザーには本質だけを見せるという方向に進化する。

これは手抜きではない。本来あるべき姿への回帰だ。