3階層から2階層へ——Pixieが実現するAI時代の開発体制
従来の開発体制：3階層モデル
システム開発は、長らく3階層の分業体制で行われてきた。
┌─────────────┐
│ コンサル │ ← 業務調査・要件定義
│ 上流SE │
└──────┬──────┘
↓
┌─────────────┐
│ SE │ ← 機能要件定義・システム設計
└──────┬──────┘
↓
┌─────────────┐
│ PG │ ← 実装・テスト
└─────────────┘
| 階層 | 役割 | 成果物 | |------|------|--------| | コンサル・上流SE | 業務調査、要件定義 | 業務要件書 | | SE | 機能要件定義、システム設計 | 機能要件書、設計書 | | PG | 実装、テスト | コード、テスト結果 |
この3階層は、人間の認知限界に基づく分業だった。
- コンサルは業務を知っているが、実装はできない
- SEは設計はできるが、業務の深い理解はない
- PGはコードは書けるが、なぜその機能が必要かはわからない
だから、翻訳者が必要だった。業務→機能→実装という翻訳チェーン。
3階層モデルの構造的問題
この3階層モデルには、構造的な問題があった。
1. 伝言ゲーム
業務担当者の意図が、コンサル→SE→PGと伝わるうちに歪む。
業務担当者：「すぐに概算が知りたい」
↓
コンサル：「見積依頼画面で概算金額を表示」
↓
SE：「見積依頼テーブルに概算金額カラムを追加、計算ロジックを実装」
↓
PG：「計算式はどうすればいいですか？」
最初の「すぐに」という要望が、どこかで消える。
2. フィードバックの遅延
実際に動くものを見るまでに、何ヶ月もかかる。
要件定義：2ヶ月
設計：2ヶ月
実装：3ヶ月
テスト：1ヶ月
──────────
合計：8ヶ月後にようやく触れる
8ヶ月後に「なんか違う」と気づいても、もう遅い。
3. 責任の分散
問題が起きたとき、誰の責任かわからない。
- 「要件には書いてあった」（コンサル）
- 「設計通りに作った」（SE）
- 「仕様通りに実装した」（PG）
全員が正しいのに、システムは使えない。
AI時代の開発体制：2階層モデル
AIが開発を担うようになると、この構造が根本的に変わる。
┌─────────────┐
│ コンサル │ ← 業務調査・要件定義（変わらない）
│ 上流SE │
└──────┬──────┘
↓
┌─────────────┐
│ AI │ ← 機能要件定義・設計・実装・テスト（すべて）
└─────────────┘
| 階層 | 役割 | 成果物 | |------|------|--------| | コンサル・上流SE | 業務調査、要件定義 | 業務要件テキスト | | AI | 機能要件定義、設計、実装、テスト | 動くシステム |
中間層（SE・PG）がAIに置き換わる。
これは「人が要らなくなる」という話ではない。翻訳の自動化だ。
なぜ2階層で済むのか
AIが中間層を担えるのは、以下の理由による。
1. AIは業務言語と技術言語の両方を理解する
従来、コンサルは業務言語を話し、PGは技術言語を話した。だから翻訳者（SE）が必要だった。
AIは両方を理解する。業務要件を読んで、直接コードを書ける。
2. AIは伝言ゲームをしない
業務要件がAIに直接渡される。間に人が入らないから、意図が歪まない。
3. AIはフィードバックを即座に反映できる
「なんか違う」と言われたら、数分で直せる。8ヶ月待つ必要がない。
Pixie：2階層モデルを実現するファクトリー
私が構築した「Pixie」は、この2階層モデルを実現する開発ファクトリーだ。
Pixieの処理フロー
┌─────────────────────────────────────────────────────────────┐
│ Pixie │
├─────────────────────────────────────────────────────────────┤
│ │
│ ① 業務要件を入力 │
│ ↓ │
│ ② 自動で要約・構造化 │
│ ↓ │
│ ③ 機能一覧を生成 │
│ ↓ │
│ ④ 機能単位で実装 │
│ ↓ │
│ ⑤ テスト生成・実行 │
│ ↓ │
│ ⑥ 動くシステムを出力 │
│ │
└─────────────────────────────────────────────────────────────┘
各ステップの詳細
| ステップ | 処理内容 | 所要時間 | |----------|----------|----------| | ① 業務要件入力 | ユーザーが自然言語で要件を記述 | ユーザー次第 | | ② 要約・構造化 | AIが要件を解釈し、構造化された形式に変換 | 〜1分 | | ③ 機能一覧生成 | 必要な機能を洗い出し、一覧化 | 〜1分 | | ④ 機能単位で実装 | 各機能を順次コード化 | 機能数×数分 | | ⑤ テスト生成・実行 | 各機能のテストを自動生成・実行 | 〜2分 | | ⑥ システム出力 | 動作するシステムとして統合 | 〜1分 |
業務要件を入れたら、動くシステムが出てくる。
これが Pixie の基本思想だ。
業務コンサルタントが直接アプリを作る時代
この2階層モデルは、業務コンサルタントの役割を根本的に変える。
従来のコンサルタント
業務調査 → 要件定義書を書く → SEに渡す → 待つ → レビュー → 待つ → ...
コンサルタントの仕事は「書類を書くこと」だった。実際に動くものを作るのは、別の人の仕事。
AI時代のコンサルタント
業務調査 → 要件をPixieに入力 → 動くものを見る → フィードバック → すぐ修正 → ...
コンサルタントが直接アプリケーションを作る時代になった。
これは「プログラミングができるようになった」という話ではない
コンサルタントがコードを書くわけではない。AIが書く。
コンサルタントがやることは変わらない：業務を理解し、要件を定義する。
変わったのは、その要件が直接システムになるということだ。
SE・PGの役割はどこへ行くのか
「SE・PGは不要になるのか？」
これは誤解を招きやすい問いだ。
不要になるもの
- 要件書を機能要件書に「翻訳」する作業
- 設計書を見てコードに「翻訳」する作業
- 定型的な実装作業
不要にならないもの
- AIが生成したコードのレビュー・監査
- セキュリティ・パフォーマンスの専門的判断
- AIが苦手な領域（レガシー連携、特殊なハードウェア等）
- AIの出力品質を担保する仕組みづくり
役割の変化
【従来】
SE：要件→設計→実装の「翻訳者」
PG：設計→コードの「実装者」
【AI時代】
SE/PG：AIの出力を「監査・改善する人」
AIが苦手な領域の「専門家」
開発プロセス全体の「設計者」
翻訳者から監査者へ。実装者からアーキテクトへ。
コンサル・上流SEの重要度が増す理由
2階層モデルでは、業務要件の質がそのまま実装の質を決める。
従来は、要件が曖昧でも、SE・PGが「多分こういうことだろう」と補完してくれた。良くも悪くも、中間層がバッファになっていた。
AI時代には、そのバッファがない。
- 曖昧な要件 → 曖昧なシステム
- 的確な要件 → 的確なシステム
コンサル・上流SEの仕事の質が、直接アウトプットに反映される。
だから、この層の重要度は下がるのではなく、むしろ上がる。
Pixieが目指す世界
Pixieは単なる自動化ツールではない。
「本当に欲しいもの」を発見するための環境だ。
雑に言う → すぐ触れる → 気づく → また言う → すぐ触れる → ...
このサイクルを、コンサルタントとユーザーが一緒に回す。AIはそのサイクルを支える基盤として機能する。
従来の「納品」という概念の終わり
【従来】
要件定義 → 設計 → 実装 → テスト → 納品 → 終わり
【Pixie】
要件入力 → 即座に動く → フィードバック → 即座に反映 → また動く → ...
└───────────── 継続的な進化 ─────────────┘
「完成」はない。「進化し続ける」だけ。
まとめ
- 従来の開発は3階層（コンサル→SE→PG）だった
- AI時代は2階層（コンサル→AI）になる
- Pixieは業務要件→動くシステムを自動化する
- 業務コンサルタントが直接アプリを作る時代になった
- SE・PGは翻訳者から監査者・アーキテクトへ役割が変わる
- コンサル・上流SEの重要度はむしろ上がる
3階層から2階層へ。
これは人が要らなくなる話ではない。役割が変わる話だ。
Pixieは、その変化を実現するファクトリーとして機能する。