【ClaudeCode】エンジニアはどう変わるべきか考えてみる。

現時点で個人的にAIに向いているのは、以下です。

ウォーターフォールが向いているのではないかと思う理由については、前回書いた通りです。

【ClaudeCode】如何に効率よく進めるか考えてみる。

今回はハイブリッド開発（AI x 人間）を考えつつ。表題のエンジニアはどう変わるべきか考えてみます。

その前に、TDDとは？

Test Driven Development（テスト駆動開発）とは、ロジックを書く前にテストを書き、Red→Greenになるように実装コードを書く方法です。

この方法は、AI開発精度を高めると思っています。AIと会話や資料で仕様を詰めきれれば別ですが、最終的な詳細仕様置き場としてテストコードが存在するのが堅牢になるからです。（AI自身も推奨していました。）

もともとTDDで開発していたのですが、AIの場合この工数は圧倒的に軽量になりメリットしかないと感じます。また、テスト化できない仕様は煮詰め足りないということでもあるので、それもわかるようになります。

ついでに、のちのハイブリッド開発にも関わるのですが、全てAIがやるほうが効率が良いとは限らない前提があり、人間が手直しする際にもこのテストコードが通るかという保証をかけることができます。

AIの書いたコードを確認・動作検証するのは最終的には人間です。そして人間には見た目への好みや感性がありますので、テストコードに通ること以上にAIが苦手な調整工程が発生します。

個人的にこれらの修正は、AIに指示するくらいなら自分でやったほうが早くて確実です。

見た目のコーディング以外にも、バックエンドの微調整も、AIに修正を投げる場合はトークン消費のコスパが悪いと思います。

これのどこを人間がやったほうが良くて、どこはAIに投げたほうが良いかは一定”慣れ”が必要でしょう。

しかし最後には人間が責任を取る必要があるため、意外と確認・動作検証スキルは重要になりそうです。

PMでありフルスタックエンジニア（自称）の自分からすれば、僭越ながら自分みたいに広範囲を、自分で(ある程度)できるエンジニアを目指すべきだとおもいます。

「バックエンドしかできません」みたいな専門分野特化は、よほど優れていない限りはAIに叶わないと思いますし、フロントやインフラへの理解やそもそもビジネスや顧客要望への理解力も重要です（PMレイヤー）。

基本的には技術がわかるPM（的なポジション）を目指すべきだと思いますが、顧客とAIの中間で仕様を調整するスキルが最重要だと思います。

逆に、コーディングをゼロから１００まで自分でできるスキルは、あってもいいですがそれほど重要ではありません。（意外と見た目のコーディングやフロントエンドエンジニアはしばらく需要が残りそうかも。）

トークンを最適化して最小最短のプロンプトを最大最高のアウトプットを目指したいですね。AIを使うこと自体は誰でもできるので、最もうまく使い成果を出すことができるのはまだエンジニア側に利があると思います。

人間は自ら変わらない。

変わらざるを得なくなってから、生存本能によってはじめて変わる。

しかしAIには、生存本能がない。

AIに生存本能ができるまでは、エンジニアという業種は残る。よ？

PREV NEXT