こんにちは、HappyLifeCreatorsの橋本です。
昨今、AIの発展によりエンジニアという職業の働き方が明確に変わりつつあります。「いつか変わる」ではなく、現場レベルですでに変わってしまった、というのが正直な実感です。
時代に取り残されないためにも、直近で変化した働き方について、工数の変化という具体的な数字を交えてお話ししようと思います。
目次
これまでの働き方
直近の働き方
AI = シニアエンジニアが複数人
変化への対応
ではなぜ、その「本来の仕事」に、これまで注力できていなかったのか。
最後に
前提として、要件定義〜仕様策定〜実装〜テストの一貫したフローを想定します。
これまでの働き方
全体を10として、かつての自分の工数割合はこんな感じでした。
要件定義: 1
仕様策定: 2
実装: 5
テスト: 2入社してすぐはペーペーで上流工程が少なかったことや、社内環境の変化ももちろん影響しています。とはいえ、工数の半分以上がコーディングに費やされていたことは間違いありません。
「エンジニアの仕事 ≒ コードを書くこと」という感覚が、この割合にもそのまま表れてます。
直近の働き方
要件定義: 2
仕様策定: 3
実装: 2
テスト: 3AIの活用によって、次の変化が顕著に表れています。
- 実装工数の低下 … 仕様さえ固まっていれば、コーディングはAIが巻き取る
- 上流工程の比重増加 … AIに代替してもらう仕事を理解し、整理する。ここが最重要工程に
- テスト工数の増加 … 2 → 3(体感ではもっとかかっているかもしれません)。AIの成果物は正しいとは限らないため、しっかりと検証
以前は「仕様は軽く決めて、あとは書きながら考える」が、実装者が自分自身だったため通用しました。しかし、AIは仕様をよしなにしてくれるわけではありません。曖昧な仕様は曖昧な実装で返却されます。
同時に、テストの位置づけも変わりました。自分で書いたコードなら「どこが怪しいか、どこが原因になりそうか」を考えながらコーディングを行うため、体で分かっていました。
他人が書いたコードの意図を把握するのは以前から難しいことではありましたが、人間相手なら実装者に実装意図を確認することができました。AI相手にはそれができません。
だからこそ設計と仕様策定、レビューとテストに以前より工数を割く必要がある。実装が軽くなった分、品質保証の責任を背負うための検証工数が必要です。
AI = シニアエンジニアが複数人
これらを包括すると、今の自分の動き方はこうなっています。
- 実装はPG(≒AI)に任せる
- 自らはPMとしてコントロール
- 実装が上がってくれば、テスト部隊としてアサイン
これが自分ひとり+AIの動き方です。
さらに革命を起こしているのが並列性です。仕様さえ策定してしまえば、実装はバックグラウンドで複数並行して進められます。
Aの機能の実装をAIに投げている間に、自分はBの仕様を詰め、上がってきたCのテストをする──
最近の実感としては、シニアエンジニアを部下に複数人抱えているの感覚に近いです。
私自身は全然シニアエンジニアではないのに。
変化への対応
この変化は、エンジニアにおいて小気味良い話ばかりではないです。
実装工数が格段に減少したということは、「コードを書くこと」自体の市場価値がそれだけ圧縮されたということです。実装だけを行うプログラマは、今後AIと直接競争することになります。
そしてスピードとコストでAIに勝つのは、かなり厳しいところまで来ていると感じます。
特にコスト面は顕著だと考えています。
一方で、価値が上がっている仕事もはっきりしています。
- プログラマでなくエンジニアとして、顧客と話し要件を引き出す力
- 上がってきた成果物の良し悪しを見抜き、品質に責任を持つ力
どちらも今に始まった話ではなく、昔から「エンジニアの本来の仕事」と言われてきたものです。
ではなぜ、その「本来の仕事」に、これまで注力できていなかったのか。
答えはシンプルで、コーディングが工数の半分を飲み込んでいたからです。要件定義や品質保証が重要だと分かっていても、目の前の実装に追われて、物量的に手が回らない。それがこれまでのエンジニアの現実でした。
「顧客と向き合う」「品質に責任を持つ」これらを重んじてお仕事ができる人が、この先も通じるエンジニアだと考えています。
最後に
HappyLifeCreatorsでは、時代に取り残されないよう、都度都度認識をアップデートしながら、今後も求められる人材となる仲間を募集しています。
興味があればぜひカジュアル面談へご応募いただければ幸いです!