AIを使うほど、エンジニアはマネージャーになっていく
株式会社iCAREでDevelopment部 部長 兼 VPoE 兼 PdMをしています、でんでん(@shogodenden)です。
本格的にAIを使い始めて、1年ちょっとが経ちます。この記事を読んでいる方も、すでに開発にAIを取り入れている方が多いと思います。コーディングが速くなった、調べものが楽になった——その恩恵は、肌で感じているかと思います。ここで書いているのは、個人の話ではなく、組織としてAIを組み込んでいく中で起きたこと、そこから見えてきた気づきです。まだ答えが出ていないことも多いですが、何かひとつでもヒントになれば幸いです。
このシリーズについて
開発メンバーへのインタビューを基に、AI導入後に起きた変化を私が観察・振り返りながら書いています。インタビュー記事のまとめではありません。現場の声は「こう返ってきた」という形で紹介しています。「生産性」や「アウトプット」をどう捉えるか——アウトプット・アウトカム・事業インパクトの3層については、シリーズ最終回の#5で整理しています。
コードを書かなくなったとき、何が残るか
「最近、自分が何をしている人なのかよくわからなくなってきました」——メンバーからそう言われたとき、正直どう答えればいいかわかりませんでした。
コードを書く量が減ってきた、という報告が上がってきたとき、最初は「よいことだろう」と思っていました。AIに実装を任せられるなら、エンジニアはもっと高度なことに集中できます。速く作れるなら、その分だけ多くのものを届けられます。そういうイメージを持っていました。
でもメンバーと話すたびに、少しずつズレが見えてきました。
速く作れているのは確かでした。実装の量は増えています。でも「楽になった」という感覚ではなく、「どこか疲れている」という話が混じってきます。コードを書く量が減ったのに、仕事が減っているわけではありません。むしろ何かが増えている感じがある、という声が出てきました。
そして、もう少し踏み込んで話を聞いてみると、「エンジニアとして自分が何をしているのかよくわからなくなってきた」という声も出てきました。
これはツールの話ではないな、と思いました。役割の話です。コードを書くことが仕事の中心だったエンジニアが、コードをほとんど書かなくなったとき、何者になっていくのか。それが今、現場で起きていることだと思います。
「マネージャーみたいな感じになる」
AIに実装を任せると、自分の仕事の中心が変わっていきます。
コードを書くのではなく、「何を作るか」を指示します。出てきたものを確認します。足りなければ修正を指示します。また確認します。そのループが仕事の大半を占めるようになります。
その変化を、あるエンジニアは「マネージャーみたい」と捉えていた。
マネージャーみたいな感じになる。数人のAIエンジニアをマネジメントしているような。チームリーダーみたいな立ち位置
チームリーダー、という表現が妙にリアルでした。AI部下を複数抱えて、それぞれに仕事を割り振り、進捗を確認して、成果をレビューします。かつてコードを書いていた手が、今はそのマネジメント作業に使われています。
自分の仕事がなくなったわけではありません。むしろ忙しいです。でも「エンジニアとしてコードを書いている」という感覚は薄れていきます。これはよいことなのか、悪いことなのか。正直、まだ整理がついていません。
「怠惰を確保するための努力は惜しまない」
AIを使い始めた動機を聞くと、率直な答えが返ってきた。
基本的にあまり仕事したくないタイプなので、指示を出して仕事が済む状態を作れれば楽だと思っている。怠惰を確保するための努力は惜しまないように、最近はしている
エンジニアの3大美徳のひとつが「怠惰」だ、という話があります。無駄な仕事を省くための工夫を惜しまないこと。その精神でAIを使い倒しているという話で、とても健全だと思いました。
ただ、その後に続く現実があります。
同じエンジニアは、複数のAIエージェントを同時に走らせながら「疲れる」とも漏らしていた。楽になるための仕組みを作ることに、新しいエネルギーを使っています。怠惰のための努力が、それ自体としてひとつの仕事になっています。
楽になりたくてAIを使い始めたはずが、AI管理という新しい負荷が生まれました。その逆説が、今の現場には静かに漂っています。
「子どもを育ててるみたい」
AIが期待と違う動きをしたとき、どうするか。
「使えなかった」と諦めて戻るのではなく、「次からこれをやらないでね」と言い聞かせながら使い続ける。その関係性を、あるエンジニアは育児に例えた。
違和感をきちんと言語化して、次からやらないでねと伝える。子どもを育てているのと同じかもしれない
叱りながら育てる、という感覚。ルールを言語化して、プロンプトに落とし込んで、また試して、また修正します。その繰り返しで少しずつ「うちのAI」が形になっていきます。
組織がそう設計したわけではありません。誰かが指示したわけでもありません。現場が自分たちで、試行錯誤しながらたどり着いた関係性でした。
「使ってしまったんで、もう戻れない」
エンジニアの話は、疲れと楽しさが混ざっていた。
AIが回答を返してくるのを待ちながら、ご飯を食べます。でも気になって戻って確認してしまいます。また投げて、また食べて、また確認します。「自分は何をしているんだろう、という気持ちがあった」と言っていた。
それでも、やめようとは言わない。
便利になった。今までできなかったことも、少しずつできるようになってきた。なんだかんだ楽しい
知らない方が幸せだったかもしれない。でも、使ってしまった。もう戻れない
別のエンジニアは、この時期を「過渡期」と呼んでいた。「今は過渡期なのかもしれない」。
「過渡期」という言葉がリアルでした。振り返れません。でも着地点もまだ見えません。その途中に全員がいます。
コードを書く量が減ったことで、失われつつある何かがあります。コードを書く中で積み上げてきた感覚、手を動かしながら考える習慣、実装を通じた問題への解像度。それが薄まっていく感覚は、現場のメンバーも感じています。
一方で、確かに生まれてきているものもあります。指示を出し、確認し、違和感を言語化してフィードバックする——それ自体が仕事として確立されてきました。「子どもを育てるみたい」——この比喩が刺さるのは、そういう関係性が実際に機能しているからだと思います。
そして、「楽しいので」という言葉は本物でした。疲れながらも、できることが増えていくことの面白さ。その感覚がある限り、過渡期はきっと前に進んでいきます。
その設計のひとつとして、iCARE開発部では日々の開発から得た知見をAI開発ワークフローとして整備し、チーム全員に展開する専任チームを作りました。コードを書く量は減ったかもしれませんが、チームみんなが使う「型」を設計して磨き続ける仕事が生まれました。「マネージャーみたいな」という感覚の延長線上に、こういう役割が形になってきています。
「コードを書かなくなったとき、何が残るか」という問いへの答えは、まだすべては見えていません。でも、そこに向かって動いている人たちを見ていると、失われるものばかりではないとは思えてきました。部長として今できることは、その過渡期を安全に渡れるように環境を整えることだと思っています。役割の変化を受け止めながら、新しい形で力を発揮できる場所を作ること。「戻れない」なら、その先をきちんと設計するしかありません。
【全5回】CarelyのAI開発を紐解くシリーズ
この記事でお伝えした内容の他にも、AI開発を成功に導くための重要なフェーズや落とし穴があります。全5回のシリーズを通して、企画から組織への定着までの全体像をぜひチェックしてみてください。
ボトルネックは消えない、移動するだけ──AIワークフロー開発組織の現在#1｜Carely開発チーム / iCARE
AIは行間を読まない──AIワークフロー開発組織の現在#2｜Carely開発チーム / iCARE
AIが正しくても、正解とは限らない──AIワークフロー開発組織の現在#3｜Carely開発チーム / iCARE
コードを書かなくなったとき、何が残るか──AIワークフロー開発組織の現在#4｜Carely開発チーム / iCARE
アウトプットの先に、何を見るのか──AIワークフロー開発組織の現在#5｜Carely開発チーム / iCARE
iCAREではエンジニアを募集しています
iCAREでは、産業保健クラウド「Carely」を共に開発していくエンジニアを募集しています。 これまでの経験を活かし、複雑な社会課題の解決に技術で挑戦したい方、ぜひ下記より詳細をご覧ください。
