「AI でコードを書かせたのに、3 回作り直しになった」。
ある製造業の DX 推進室から聞いた話です。
Cursor を導入し、エンジニアにプロトタイプを依頼した。
1 週間後、画面は動いている。
ただ、業務フローと合っていない。
修正を依頼すると、また別の箇所で齟齬が出る。結局、従来の開発より時間がかかった。
原因は、生成AI の性能ではない。
要件が、最初から固まっていなかった。
「在庫を一覧で見たい」という要望だけで作り始めると、
AI は画面を出力する。
だが、誰がどのタイミングで見るのか、どの項目を優先するのか、更新頻度はどうか。そこが決まっていなければ、何度作っても「違う」と言われる。
コードを書く速度が上がったことで、曖昧さが形になるまでの時間も短くなった。
つまり、要件の甘さが、より早く露呈するようになった。
生成AI で開発するなら、ディレクターが要る
以前は、エンジニアが実装しながら要件を補完していました。
コードを書く工数が大きかったため、
その過程で「ここはどうしますか」と確認する余地があった。
いまは違う。ai 生成でコードはすぐ出る。
確認の余地が生まれる前に、形ができてしまう。
だからこそ、実装に入る前の要件定義の精度が、そのまま成果を左右する。
誰が使うのか、どの業務のどこに組み込むのか、
どの情報を優先するのか。
ここを言語化し、構造として整える役割が、明確に必要になる。
その役割を担うのが、ディレクターであり PM です。
エンジニアではなく、業務と技術をつなぐ人。
AzRun の開発でも、プロトタイプに入る前の 90 分のヒアリングと、そこから書く仕様メモに、最も時間を使います。
要件が固まっていれば、Cursor や Claude Code は期待通りに動く。
曖昧なままなら、どれだけ速く書いても手戻りになる。
開発の決め手は、AI の性能ではなく、要件定義の精度です。
「誰が要件を決めるのか」
が、組織の課題になる
では、その要件を誰が決めるのか。
ここで多くの組織が止まります。
現場は業務を知っているが、システムの構造は分からない。
エンジニアはコードを書けるが、業務の優先順位は判断できない。DX 推進室は全体を見ているが、実装までは担えない。
結果、「とりあえず作ってみて」となり、手戻りが発生する。
大手ベンダーに丸投げして、現場と合わないシステムが納品される。
この間を埋めるのが、ディレクター職の役割です。
業務をヒアリングし、構造を整理し、エンジニアに渡す仕様をメモとして残す。コードは書かないが、何を作るかを決める人。
生成AI の時代では、この職種が重宝されます。
なぜなら、AI はコードを書くが、要件は決められないからです。
AzRun では、案件の初日にディレクターと開発担当が同席し、ヒアリングから仕様メモ作成までを一緒に進めます。
その日のうちに方向を固め、翌日から実装に入る。
仕様が明確なら、あとは Claude Code に渡すだけで大部分が動く。
逆に、要件が曖昧なまま進めると、どれだけ AI を使っても形にならない。
小さく試すなら、要件も小さく区切る
もうひとつ、実装前にやっていることがあります。
要件を、1 画面ごとに区切ることです。
「在庫管理をしたい」という話を、そのまま実装に渡さない。
まず「どの担当者が、いつ、何を確認するのか」
を具体化し、その場面を 1 画面として切り出す。
その画面だけを先に作り、動かして、業務フローに載せてみる。
うまくいけば次の画面に進む。
違和感があれば、その場で修正する。
この繰り返しで、手戻りを最小化します。
生成AI があるからこそ、小さく試せる。
ただし、試す単位を決めるのは人です。
その単位を決める精度が、開発の成否を分けます。
AzRun では、初回ヒアリングで必ず「最初に確かめたいこと」を 1 つに絞ります。
全部作ってから検証するのではなく、確かめたいことだけを形にして、翌日には触ってもらう。
そのサイクルを回すことで、要件のズレを早期に修正できます。
ディレクターの仕事は、そのサイクルを設計することです。
何を、どの順で、どこまで作るか。
その判断が、開発全体の工数を左右します。