Work Cost Note

時間の使い方から、働き方を見直す

AIでコードを書く時代、現場エンジニアの仕事はどう変わったのか

AI活用によって調査や実装の負担が軽減され、エンジニアが「調整や意思決定」といった本来注力すべき業務へ可処分時間をシフトできるようになった実体験と考察。

AIでコードを書く時代、現場エンジニアの仕事はどう変わったのか

ここ1〜2年で、開発現場の空気はかなり変わった気がしています。特に変化が大きいのは、「コードを書く」という行為そのものです。

以前は、以下の作業にかなり時間を使っていました。

  • 仕様を調査する
  • 関連コードを追う
  • 実装する
  • テストを書く

自分は大規模な既存システムを触ることが多いのですが、正直、実装より調査の方がしんどいことも多いです。「この値どこで変わってるんだ…」「なんでここだけ別実装なんだ…」みたいなコードを半日以上追い続けることも普通にありました。

ただ最近は、その時間感覚がかなり変わってきています。AIを使うことで、調査や実装の“空の状態から考え始める時間”が減った感覚があります。

今回は、実際に現場でAI活用が進んで感じた変化を、会社員エンジニア目線で整理してみます。

1. AIで「コードを書く時間」はかなり減った

最近、一番変わったと感じるのはここです。以前は、実装そのものにかなり時間を使っていました。特に大規模な既存システムだと、

  • どこで値が変わるのか
  • どのクラスが関連するのか
  • 既存仕様はどうなっているか

を追うだけで半日以上消えることも普通にありました。しかも大規模な既存システムだと、仕様が積み重なり続けているので、「過去対応との整合性」みたいな文脈も大量にあります。単純にコードを書くだけでは終わらないんですよね。

ただ最近は、AIにコードベースを読ませながら進めることで、この調査時間がかなり短縮されるようになってきました。以前なら1日かかりそうだった調査が、30分〜1時間くらいで大枠を掴めることも増えています。

もちろん、最終的な確認は必要です。AIは普通に間違えるので、そのまま信用すると危ないです。それでも、「ゼロから全部自分で読む」よりは圧倒的に楽です。

2. 触ったことのないリポジトリでも進めやすくなった

最近、ほぼ初見のリポジトリで大きめの機能追加を担当することがありました。とはいえ、完全新規開発というより、「既存構造を踏襲すれば実現できる」タイプの開発です。

以前なら、

  • 担当者に聞く
  • 関連仕様を探す
  • 実装方針を確認する

みたいな時間がかなり必要だったと思います。特に、誰に聞けばいいか分からない時間が地味につらいです。

ただ今回は、AIに既存構造を確認させながら進めることで、細かい質問をほとんどせずに最後まで持っていけました。必要だったのは、認識合わせ、状況共有、最終レビューくらいです。

生産性が上がった実感はかなりありました。その一方で、「今まで人間が時間を使っていた部分って、かなり置き換わるんだな」という感覚も強かったです。少し便利になった、というより、仕事の重心が変わり始めている感じに近いかもしれません。

3. AIが特に強いのは「仕様調査」と「コーディング」

現時点で、AIがかなり強いと感じるのは「仕様調査」と「コーディング」の2つです。

特に仕様調査は変化が大きいです。自分の管理外のドメインでも、「これ、調査だけで1日消えるな…」と思っていたものが、プロンプトを投げて少し待つだけで、大枠を掴めるケースが増えました。

大規模な既存システムだと、機能単体よりも、他機能との整合性、過去仕様との兼ね合い、データ更新タイミングみたいな部分でハマることが多いです。そのあたりをAIが横断的に整理してくれるだけでも、かなり助かります。

もちろん精度は100%ではないです。存在しない仕様を当然のように説明してくることもあります。でも今は、「AIの出力を確認する」という前提で使えば、十分実務に入り込めるレベルになってきたと感じています。

4. テストコード作成もかなり変わった

地味に変化が大きいのがテストコードです。既存実装の参考例が揃っているプロジェクトだと、AIが生成したコードをほぼそのまま使えることもあります。

もちろん、プロジェクト構成、テスト文化、命名規則、ドキュメント整備にはかなり依存します。ただ少なくとも、「叩き台を作る速度」はかなり速いです。

以前は、「さて、どこから書くか…」と空のエディタを前に考え込む時間がありました。でも最近は、その“最初の重さ”がかなり減りました。個人的には、ここが結構大きいです。コードを書く疲労というより、「考え始めるエネルギー」が減った感覚があります。

5. 最近増えたのは、「決める仕事」

逆に、人間側に残っている感覚があるのは「決めること」です。例えば、

  • 同じ機能を実現する方法が複数ある
  • 他機能との整合性が必要
  • 今後の開発予定も考慮する
  • 関係者との調整が必要

みたいなケースです。このあたりは、単純なコード生成だけでは完結しづらいです。特に会社員開発だと、どの判断軸を優先するか、どこで折り合いをつけるか、誰と認識合わせするか、みたいな調整コストがかなり大きいです。

自分自身、将来的にはもっと上流寄りの仕事もやってみたい気持ちはあります。ただその一方で、「調整と会議ばかりになって、可処分時間が減るのは嫌だな」という感覚もかなりあります。

ここはまだ答えが出ていません。AI時代になるほど、“何を頑張るか”より、“どこに時間を使うか”の方が重要になっていく気もしています。

6. 「AIを使う人」と「使わない人」の差は少しずつ出ている

現場では、AIを積極的に使う人と、まだ慎重な人が分かれ始めています。特に年次が高い人ほど、まだ様子見しているケースは多い印象があります。

ただ、経験値で埋まる部分もかなり大きいです。なので、「AIを使えば若手がベテランに勝てる」みたいな単純な話ではないと思っています。

一方で、キャッチアップ速度、不具合調査、未知領域への入りやすさ、このあたりは、かなり差が出始めています。特に、自分が触ったことのない領域へ入るハードルは、かなり下がった感覚があります。

7. 実際、自分がAI活用で減らそうとしているもの

AIを使っていて、単純に「生産性を上げたい」という感覚はそこまで強くありません。むしろ減らしたいのは、

  • 調査で詰まる時間
  • 空の状態から考え始める疲労
  • “誰に聞けばいいかわからない時間”

みたいな部分です。実際、自分が最近よく使っているのは、

  • 「関連クラスだけ先に整理して」とAIに投げる
  • 「この処理の流れを図っぽく説明して」と聞く
  • テストコードの叩き台だけ作らせる

みたいな使い方です。完成品を作らせるというより、“最初の重い部分を減らす”用途に近いです。このあたりは、今日からでもかなり試しやすいと思います。

8. まとめ|「頑張る」より、可処分時間をどう守るか

AIによって、エンジニアの仕事はかなり変わり始めていると思います。少なくとも自分の中では、コードを書く、調査する、テストを書く、みたいな時間は明確に減りました。その代わりに増えたのが、判断する、調整する、方針を決める、といった仕事です。

ただ、個人的には、「全部を高速化してもっと働きたい」という感覚ではあまりないです。むしろ、調査時間を減らす、無駄な疲労を減らす、可処分時間を増やす、みたいな方向に興味があります。

昔は、「頑張ること」自体が価値になりやすかった気がします。でも最近は、“頑張らなくても回る状態を作る”ことの方が大事になってきている気がしています。AIは、そのための道具としてかなり強力です。

だからこそ、単純に生産性を上げる話だけじゃなく、「浮いた時間をどう使うか」まで含めて考える時代になってきたのかもしれません。