AI製のPoCが仕様書として渡されてくる
非エンジニアがAIツールで画面の動くプロトタイプを作り、これと同じものを作ってほしいと開発チームに渡す。先日、これに近いことが実際に起こりました。
今はまだ単発の出来事です。ただ、PoCを作るコストが下がり続けている以上、近い将来これが当たり前になるはずです。そして、その先を想像するとエンジニアの未来がだいぶ暗い。
依頼する側に悪気はありません。むしろ仕様の解像度が上がるので助かる面も大きいです。問題は、渡した側と渡された側で、残作業の見積もりに致命的なズレがあることかと思います。
見た目8割、実態1割
PoCができた時点で、見た目の完成度は8割に達しています。一方、本番システムとしての実装量で見ると、1割に届いていないことがほとんどかと思います。
残りの9割は、全部が画面の外側にあります。データをどう持つか、どこで動かすか、誰に何を許すか、壊れたときに誰が気づくか。この手の問いに順番に答えていく作業で、答えを実装しても画面には何も現れません。数週間かけて堅牢にしても、外からは止まっているように映ります。
規模が大きくなるほど、乖離は広がる
厄介なのは、この8割と1割のズレが規模に比例しないことです。
画面が10枚から30枚に増えても、PoCの作成コストはほとんど変わりません。AIが同じ調子で量産できるためです。一方で本番側は、画面数に対して線形には増えません。
- 権限制御：ロール数 × 機能数
- データ整合性：エンティティ間の関連数
- 状態遷移：状態の組み合わせ
- 異常系：正常系フローごとの分岐数
どれも掛け算で増えます。小さなツールならPoCと本番の差が数倍で収まるところ、業務システム規模では桁が変わります。
それでも見た目8割という第一印象だけは、規模によらず一定です。大きい案件ほどギャップが開く。ここが一番危険なところかなと思っています。
PoC本番化を任される前に準備しておく5つのこと
1. 着手前に差分リストを共有する
ここがこの記事で一番言いたいところです。同じ内容でも、聞かれてから説明すると言い訳に聞こえ、先に出せば見積もりになります。
出すのは作業チェックリストではなく、PoCと本番の差分そのものです。1領域1行で足ります。
| 領域 | PoCの実態 | 本番で必要になること |
|---|---|---|
| 技術スタック選定 | AIが出力したまま、バージョンは成り行き | フレームワーク・DB・クラウドの選定、保守体制とバージョン方針、ライセンス確認 |
| アーキテクチャ | 画面ひとつに全部入り | 全体構成、レイヤー分割、モジュール境界、リポジトリ構成 |
| データ設計 | コンポーネントにベタ書きの配列 | ER設計、インデックス、マイグレーション |
| インフラ設計 | localhostで起動するだけ、デプロイ先なし | 実行環境、IaC、環境分離 |
| ネットワーク | ブラウザとローカルプロセスの間だけ | VPC、証明書、経路とアクセス制限 |
| API | サーバが存在しない | I/F設計、バリデーション、エラー規約 |
| ロジック層 | イベントハンドラに直書き | ドメイン分離、トランザクション境界、冪等性 |
| 非同期・バッチ | 概念がない | ジョブ基盤、定期実行、失敗時の再実行 |
| 外部連携 | ハードコードした戻り値 | 実接続、レート制限、障害時の縮退 |
| 認証・認可 | ログイン画面はあるがボタンで素通り | 認証基盤、ロール設計、API側の権限チェック |
| セキュリティ | 考慮ゼロ、キーはコードに直書き | 脆弱性対策、シークレット管理、依存の更新 |
| フロント | ハッピーパスの見た目だけ | 入力検証、ローディングとエラー表示、権限による出し分け |
| 性能 | ダミーデータ数件 | 想定件数での検証、キャッシュ、N+1の解消 |
| ログ・監視 | console.log | アプリログ、監査ログ、メトリクス、アラート |
| 運用・障害対応 | 概念がない | バックアップと復旧手順、データ修正手段、管理画面 |
| CI/CD | デプロイという工程自体がない | パイプライン、ロールバック手順 |
| テスト | 手で触って目視 | ユニット、結合、E2E、負荷試験 |
案件によっては、これに多言語化、決済、個人情報の取り扱い方針、監査対応あたりが乗ります。
真ん中の列を並べて見せると、PoCが手をつけているのは見た目だけだと伝わります。右の列は丸ごとこれから作るものです。あとは右端に工数の列を足せば、そのまま見積もりになります。
2. PoCのコードは流用せず、仕様として読む
PoCのコードは検証用に最短距離で書かれています。作り直す前提で、価値のある部分は仕様の情報として吸い上げるのが結局早いです。
3. 内部品質の作業を、見える成果物に変える
テストのカバレッジレポート、監視ダッシュボード、負荷試験の結果。成果物のスクリーンショットが1枚あるだけで、進捗の伝わり方が変わります。
4. 非機能要件を独立した工数項目として見積もる
機能一覧で見積もると、PoCで見えている機能しか工数に入りません。独立した項目として並べておくと、削る判断も相手側でできるようになります。
5. 完成の定義（Definition of Done）を先に合意する
同時アクセス数、レスポンス目標、障害時の挙動。ここを詰めておくと、なぜ時間がかかるのかという問いが、どこまでやるかの相談に変わります。
Known Issues：やりがちな失敗パターン
- PoCのコードをそのまま延命させ、後半で作り直しが発生する
- 差分の説明を実装完了後に回し、言い訳として受け取られる
- 非機能要件を暗黙のうちに自分の責任範囲として抱え込む
まとめ：作れることより、壊れないようにできること
作るコストは劇的に下がった一方で、本番化のコストはほとんど下がっていません。この非対称性がある以上、技術力とは別に、見えない仕事を説明する力が要求されるようになってきたなと感じています。