AI時代に問われるのは「コードを書く力」ではなく「作るものを定義する力」

ソフトウェア開発に長く関わっていると、「仕様書は最後に整えるもの」という開発現場に出会うことがあります。

最初から十分な仕様を作らず、打ち合わせや口頭での説明をもとに開発を始める。細かな部分は実装しながら決め、最後に出来上がったシステムに合わせて仕様書や設計書を整える。

日本のソフトウェア開発では、以前から見られた開発の進め方です。

もちろん、すべての開発現場がそうだという話ではありません。しかし、このような方法でも、これまでは何とか開発を成立させることができました。

なぜなら、コードを書いているのが人間だったからです。

エンジニアは仕様書だけを見てコードを書いていたわけではない

実際の開発では、仕様書にすべてが書かれていることの方が珍しいと思います。

• 顧客との打ち合わせで聞いた話。
• 過去に決めたこと。
• 既存システムの動作。
• 既存のソースコード。
• 業務上の常識。
• そして、これまでの開発経験。

エンジニアは、こうした情報を頭の中で組み合わせながらコードを書いてきました。

「この場合はこちらの処理も必要になるはずだ」
「このデータがなかった場合も考えておこう」
「ここを変更すると、あちらにも影響する」
「仕様には書いていないが、この業務ならこう動くべきだろう」

仕様の不足を、エンジニア自身が考えながら補っていたわけです。

これは決して望ましい開発方法という意味ではありません。

ただ、人間が実装することによって、曖昧な部分を人間の経験や暗黙知で補完できていたことは確かです。

ところが、コーディングエージェントを本格的に使うようになると、この前提が崩れます。

AIは驚くほどコードを書ける。しかし、何を作るべきかは知らない

現在のコーディングエージェントを使っていると、その実装能力には驚かされます。

こちらが適切な指示を与えれば、既存コードを調査し、複数のファイルを変更し、必要な処理を実装し、テストまで作成する。

人間が一つずつ実装していた頃と比較すると、作業速度は大きく変わりました。

しかし、当然ながらAIは、そのシステムを作る本当の目的を最初から知っているわけではありません。

• 担当者の頭の中にある仕様も知りません。
• 以前の打ち合わせで口頭だけで決まったことも知りません。
• 顧客との会話の中で感じ取った微妙なニュアンスも知りません。

AIが利用できるのは、基本的には与えられた情報です。

• 何を実現するのか。
• なぜその機能が必要なのか。
• 何を入力し、何を出力するのか。
• どのような条件で処理するのか。
• 何をしてはいけないのか。
• 既存機能との整合性をどうするのか。
• 異常時にはどう振る舞うのか。
• 何をもって完成とするのか。

こうした情報が曖昧であれば、AIも曖昧な情報を基に実装することになります。

一番怖いのは「それらしいコード」が出来上がること

コーディングエージェントを使っていて特に注意しなければならないと感じるのは、仕様が曖昧でもコードを書けてしまうことです。

情報が不足していれば、AIは既存コードや一般的な実装方法などから不足部分を推測します。

そして、かなりもっともらしいコードを生成します。

• コンパイルも通る。
• 画面も表示される。
• テストも通る。

一見すると完成しているように見えます。

しかし、

「動くこと」と「正しいこと」は同じではありません。

本来の要求そのものが定義されていなければ、その実装が正しいかどうかを判断する基準もありません。

これはAIの性能だけで解決できる問題ではないと思います。

むしろAIの実装能力が高くなればなるほど、間違った前提からでも完成度の高いコードが出来上がってしまう。

そこに別の怖さがあります。

振り返ると、コードを書いている時間に考えていた

コーディングエージェントを使うようになって、改めて気づいたことがあります。

人間がコードを書いていた時間は、単なる「文字を入力する時間」ではなかったということです。

コードを書きながら、

「ここはどうするべきか」
「この条件が抜けている」
「この設計だと後で困る」
「このデータ構造では拡張できない」

と考えていました。

• 書いて、考える。
• 動かして、考える。
• 修正して、また考える。

実装と設計の境界は、それほど明確ではありませんでした。

ところがコーディングエージェントは、この実装部分を猛烈な速度で進めます。

これは大きなメリットです。

一方で、人間がコードを書きながら自然に確保していた「考える時間」まで一緒に高速化してしまうと危険です。

AIが10分で実装できるからといって、人間が10分で仕様を考えられるようになったわけではありません。

ここは分けて考える必要があります。

コードを書く速度が上がるほど、その前で考える必要がある

これから重要になるのは、AIと同じ速度で人間がコードを書くことではないと思います。

• 要求を整理する。
• 要件を定義する。
• 仕様を明確にする。
• 制約条件を洗い出す。
• データ構造を考える。
• インターフェースを定義する。
• 受入条件を決める。

実装が高速化するのであれば、むしろその前にこれらをきちんと考えておく必要があります。

AIに渡すプロンプトを細かく書けばよい、というだけの話でもありません。

その前に、人間自身が「何を作るのか」を理解していなければ、正確な指示など出せないからです。

プロンプトを書く能力より前に、要求を仕様へ変換する能力が必要になります。

ドキュメントの意味も変わってくる

これまで仕様書や設計書を「最後に納品するためのもの」と考えていた開発現場では、ドキュメント作成は実装とは別の作業だったかもしれません。

しかし、コーディングエージェントを使うようになると、ドキュメントの意味が変わります。

ドキュメントを最後に作るのではなく、ドキュメントを入力としてコードを作る。

要求、仕様、制約、設計方針などを明文化しておけば、それを人間だけでなくAIとも共有できます。

そして実装後には、その仕様を基準として、

「本当に要求どおりなのか」

を確認できます。

昔のように何十ページ、何百ページもの仕様書を作ればよい、という意味ではありません。

重要なのは量ではなく、実装するために必要な情報が、実装する前に存在していることです。

エンジニアに求められる能力の重心が変わる

AIがコードを書くようになると、「これからプログラマーは不要になる」という話が出てきます。

私は、それほど単純な話ではないと思っています。

確かに、コードを記述するという作業の価値は相対的に下がっていくでしょう。

しかしソフトウェア開発には、その前にもっと大きな仕事があります。

• 曖昧な要求を整理する。
• 問題を分解する。
• データや処理の構造を考える。
• 矛盾や不足を見つける。
• 将来の変更を考える。
• そして、それらを実装可能な仕様として表現する。

AIがコードを書けるようになるほど、こうした能力の重要性は高くなると考えています。

つまり、エンジニアに求められる能力がなくなるというより、能力の重心が移動するのではないでしょうか。

「どうコードを書くか」から、

「何を、なぜ、どのように作るべきかを定義する」ことへ。

これまで「仕様書を書くよりコードを書いた方が早い」で済ませることができた開発も、コーディングエージェントが当たり前になれば、その考え方自体を見直す必要が出てきます。

AIは、コードを書く速度を大きく変えました。

しかし、考える速度まで同じように速くなったわけではありません。

だからこそ、これからのエンジニアには、コードを書く能力だけではなく、コードを書く前に考え、それを明確に定義する能力が、これまで以上に求められるのではないかと思います。