生成AIでコードを書く時間が短くなると、エンジニアの価値は実装そのものから、**実装の前（何を作るかを決める）と実装の後（業務上正しく動くかを確かめ、使われる状態にする）**に移っていきます。実装力が不要になるわけではありませんが、実装だけで差をつけることは難しくなります。この記事では、価値が移る先を具体的に整理し、そのために何を身につければよいかを説明します。
生成AIで速くなったのは「決まったものを作る」部分
生成AIのコーディング支援ツールを使うと、仕様がはっきりしている作業は大きく速くなります。画面の雛形を作る、APIを呼ぶ処理を書く、テストコードを書く、既存コードの意味を説明させる、といった作業です。
一方で、ツールに任せにくい部分も残っています。
- 何を作るかを決めること：ツールは指示されたものを作りますが、その指示が業務にとって正しいかは判断しません
- 業務のルールを正しく反映すること：締め日、端数処理、例外の扱いなど、現場ごとに違うルールは、聞き出さないとわかりません
- 作ったものが業務上正しいかを確かめること：コードとして動くことと、業務として正しいことは別です
つまり、実装の速さが上がるほど、実装の前後にある工程の比重が相対的に大きくなります。
価値が移る先1：何を作るかを決める
実装が速くなると、「作るものを間違えたときの損失」は、作り直しにかかる時間よりも、間違ったまま業務に入れてしまうことのほうが大きくなります。作るのは速くても、現場の業務が混乱すれば信頼は戻りにくいからです。
具体例：見積もり作成の効率化
営業部門から「見積書を自動で作れるようにしたい」と依頼されたとします。生成AIを使えば、見積書を生成する仕組みは短時間で作れます。しかし、業務を確かめていくと次のようなことがわかる場合があります。
- 見積もりに時間がかかっている原因は、書類の作成ではなく、過去の類似案件の価格を探すことだった
- 値引きの判断は課長の承認が必要で、承認待ちで数日止まっていた
- 見積書のフォーマットは取引先ごとに指定があり、一律の自動生成では使えなかった
この場合、最初に作るべきものは「見積書の自動生成」ではなく、「過去見積もりの検索」と「承認の流れの見直し」かもしれません。こうした判断は、業務を読み、現場に聞き、課題を原因まで分解して初めてできます。
課題を根本原因まで分解する方法はイシューツリーで扱っています。業務のどこにAIを使い、どこにはルールベースや最適化の手法のほうが向いているかを判断する考え方は、AIと最適化が参考になります。
価値が移る先2：業務の状態とデータの構造を設計する
業務システムの品質を大きく左右するのは、画面やコードより、業務の状態とデータの構造の設計です。ここは生成AIに任せきりにしにくい部分です。
たとえば検品業務なら、商品が「入荷待ち・検品中・合格・不合格・保留」のどの状態にあるのか、保留から合格に戻るのは誰の判断か、不合格品を返品したらどの状態になるのか、を決める必要があります。ここを曖昧にしたまま実装を進めると、ツールは一見動くものを作りますが、例外が起きたときに業務が止まります。
状態の洗い出しは、条件の組み合わせを漏れなく並べる作業でもあります。考え方はステータス管理とテーブル分割と俯瞰思考にまとまっています。
価値が移る先3：業務上正しく動くかを確かめる
生成AIが書いたコードは、テストが通っていても業務上の誤りを含むことがあります。ツールは業務ルールを知らないので、それらしいが違う処理を書いてしまうことがあるからです。
確認すべきなのは、たとえば次のような点です。
- 月末締めの請求で、締め日をまたいだ注文がどちらの月に入るか
- 消費税の端数処理が、取引先との取り決めどおりになっているか
- 在庫が足りないときの受注が、エラーになるのか、引当待ちになるのか
- 同じ注文が二重に登録されたとき、どこで気づけるか
これらは業務を知っている人でないと確認項目として挙げられません。テストの専門知識がなくても、業務上「ここが動けばよい」を判定する型は、動作確認の基本で整理されています。
価値が移る先4：現場で使われ続ける状態にする
作ったものが現場で使われ続けるかどうかも、実装の後の工程で決まります。
- 例外が起きたとき、誰がどう対応するかが決まっているか
- 操作に迷ったとき、誰に聞けばよいかがわかっているか
- 業務ルールが変わったとき、どこを直せばよいかがわかるか
導入後の1〜2週間は、現場の担当者と一緒に運用しながら手順を直す期間として確保しておくと、使われずに終わる事態を避けやすくなります。
実装力はどう位置づければよいか
価値が実装の前後に移るといっても、実装力が不要になるわけではありません。むしろ、実装を理解していることが、前後の工程で効いてきます。
| 場面 | 実装力が効く理由 |
|---|---|
| 何を作るかを決める | 作る手間の見当がつくので、範囲の判断や見積もりが現実的になる |
| 状態とデータを設計する | 設計がコードにどう反映されるかがわかる |
| 正しく動くかを確かめる | 生成AIが書いたコードを読み、誤りの原因を特定できる |
| 使われ続ける状態にする | 運用中の不具合や変更に、自分で対応できる |
実装ができて、前後の工程もできる人は、生成AIのツールを道具として使いこなし、少人数で業務改善を最後まで進められます。これはFDEとは？で説明したFDEの働き方そのものです。海外でFDEの求人が増えている状況はFDEの市場と求人動向で扱っています。
この記事のまとめ
- 生成AIで速くなったのは、仕様が決まっているものを作る部分
- 価値が移る先は、何を作るかを決める、状態とデータを設計する、業務上正しいかを確かめる、使われ続ける状態にすること
- 業務ルールや例外の扱いは、現場に聞かないとわからず、ツールに任せきりにできない
- 実装力は、前後の工程を現実的に進めるための土台として引き続き効く
FDE Guildのロードマップでは、ステップ6「進めて作る」で、AIで作ること、ステータス設計、動作確認をまとめて扱っています。実装の前後の工程を一度通して確認したい人は、ステップ1から順に見てみてください。