AI 時代の Developer Experience — 競争力のあるエンジニアであり続けてもらうために
Claude 研修の講師をしていたときのことです。受講者に使い方を見せるつもりで、Claude のチャットに「私のことを教えて」と入力してみました。軽い実演のつもりで、私が過去に書いた記事や登壇した内容を横断的に読み込んだ要約が返ってきて、その場はちょっとした余興として盛り上がりました。ところが、本当に考えさせられたのはそのあとでした。研修に参加していた一人のエンジニアから、こう問いかけられたのです。「AI 時代の Developer Experience の向上について、どのようにお考えですか」。
自分が長く大事にしてきたテーマを、現在時制の問いに変えて、目の前のエンジニアから突きつけられる。少し不思議な体験でした。教える側だったはずが、いつのまにか問われる側になっていた。私はその場で、いま考えていることをそのまま言葉にして答えました。ただ、口頭で答えながら、この問いは一度きちんと腰を据えて向き合う価値があるとも感じていました。この記事は、そのとき話したことを、フルリモートの組織で CTO として技術と組織を見ている立場から、あらためて整理して書き直してみる試みです。
そもそも Developer Experience とは何だったか
AI 時代の話をする前に、そもそも Developer Experience（開発者体験）とは何を指していたのかを確認しておきます。日本語圏ではこれを DX と略すこともありますが、DX は顧客向けの digital transformation と紛らわしいため、本記事では developer experience の略として DevEx と呼びます。ここでの DevEx は、ソフトウェアを作る人自身が日々どれだけ気持ちよく、迷いなく、集中して開発できるか、という意味での体験です。
この概念を実務的な言葉に落としたのが、Abi Noda・Nicole Forsgren らによる DevEx: What Actually Drives Productivity という論文でした。ここでは開発者体験を 3 つの軸で捉えます。フィードバックループの速さ（feedback loops）、認知負荷の低さ（cognitive load）、そしてフロー状態（flow state）に入れるかどうか。ビルドが速く返ってくるか、テストがすぐ結果を出すか、レビューが滞留しないか。理解しなければならない前提知識が過剰でないか。割り込みや文脈の切り替えに邪魔されず、深く没入できる時間があるか。DevEx とは、突き詰めればこの 3 つの摩擦を減らす営みでした。
計測の枠組みも整ってきていました。デプロイ頻度や変更のリードタイムを見る DORA の 4 指標、開発生産性を満足度から効率まで多面的に捉える SPACE フレームワーク。いずれも共通していたのは、生産性を単なるアウトプット量ではなく、開発者が置かれた環境と体験の総体として測ろうとする姿勢です。私がこれまで DevEx の向上と言ってきたのも、この意味での摩擦を一つずつ削り、エンジニアが本質的な仕事に集中できる状態を作る、という文脈でした。
AI が来て、何が変わったのか
では、AI が来て何が変わったのか。私の実感を一言でいえば、怒涛の時代が来た、ということに尽きます。
まず、コードを書くこと自体のコストが劇的に下がりました。Claude Code や Codex のようなコーディングエージェントを使えば、これまで半日かけて書いていた実装が数分で叩き台になり、慣れないライブラリの調査も、テストの雛形も、リファクタリングの下書きも、対話しながら一気に進みます。DevEx の言葉で言えば、フィードバックループが短くなり、認知負荷の一部が肩代わりされ、フロー状態を妨げる細かな詰まりが減った。見方を変えれば、AI ネイティブに開発を進められる人は、フィードバックループ・認知負荷・フロー状態という DevEx の 3 軸を、道具の力で一気に満たしてしまえる、とも言えます。従来の DevEx が目指していたものの一部は、ツールの側から急速に埋められつつあります。
しかし、話はそこで終わりません。摩擦が減った分だけ、ボトルネックがずれたのです。コードを書く速さが制約でなくなると、次に問われるのは、何を作るべきかを見極める力、生成された大量のコードを読み・評価し・責任を持って世に出す力、そしてシステム全体を設計し統合する力になります。AI が下書きを量産できる時代の開発者体験は、もはや「タイピングの摩擦をどれだけ減らすか」だけでは語れません。AI という新しい相棒と、どれだけうまく協働できるか。それ自体が DevEx の中身になってきました。
そして変化のスピードが尋常ではありません。使えるモデルもツールも数か月単位で塗り替わり、昨日の最適解が今日には陳腐化する。この環境で放っておくと、DevEx は簡単に劣化します。最新の道具を持たないエンジニアと、使いこなしているエンジニアの差が、これまでとは比べものにならない速さで開いていく。怒涛の時代というのは、そういう意味です。
経営として、環境は必ず与える
この状況で、経営に携わる私がまずやるべきことは、はっきりしています。AI を使える環境を、迷わず与えることです。
これは福利厚生ではなく、AI 時代の DevEx の土台そのものだと考えています。最新のコーディングエージェント、十分な利用枠、業務で安心して使えるための整備。ここをケチることは、エンジニアが最前線で戦うための武器を取り上げるのと同じです。ツールのライセンス費用は、生産性の向上と、何より人が伸びることへの投資として、圧倒的に割に合います。従来の DevEx が CI を速くし、開発環境を整え、無駄な会議を減らすことだったのなら、その延長線上に、AI をためらいなく使える環境を用意することが当然に加わる。私はそう理解しています。
同時に、ただアカウントを配れば済む話でもありません。どう使うと効くのか、どこに落とし穴があるのか、機密情報の扱いをどうするのか。そうした知見を共有し、安心して踏み込める土台を作ることまでが、環境を与えるということです。冒頭で触れた Claude 研修は社外の方に向けて開いたものですが、道具の渡し方についての考え方は、社内でもまったく同じだと思っています。道具を配るだけでなく、道具を使い倒すための足場まで含めて用意する。ここまでが、環境を与える側の責任です。
与えるだけでは足りない — 使い倒して最前線を走る
ただ、環境を与えることは必要条件であって、十分条件ではありません。ここから先は、エンジニア一人ひとりに託される部分です。私が心から願っているのは、与えられた環境を遠慮なく使い倒して、最前線を走り続けてほしい、ということです。
道具は、持っているだけでは意味がありません。触って、試して、失敗して、自分の仕事の中に馴染ませて、はじめて力になります。AI に任せられる部分は大胆に任せ、浮いた時間と認知の余力を、設計や検証や、より難しい問題に振り向ける。生成されたコードを鵜呑みにせず、読んで、疑って、直して、自分の責任で世に出す。この往復を高速で回せる人が、これからの最前線を走る人だと思います。AI が書いてくれるから楽をする、のではありません。AI が書いてくれるからこそ、人間にしかできない判断と設計に、より深く踏み込める。使い倒すというのは、そういう前のめりな姿勢のことです。
ここで一つ、逆説的なことを言います。AI が下書きを担う時代ほど、基礎の力がむしろ効いてきます。生成されたコードの良し悪しを見抜くには、自分の中に確かな評価軸が要る。設計の妥当性を判断するには、原理を理解していなければならない。AI に丸投げして思考を止めた人と、AI を梃子にして思考を加速させた人の差は、時間が経つほど残酷なほど開きます。だからこそ、使い倒すと同時に、学び続けてほしい。道具の使い方だけでなく、その下にある本質を。最前線を走るというのは、流行を追うことではなく、変化の速い表層と、変わらない基礎の両方を、同時に握り続けることだと考えています。
目指すのは「あの会社出身は優秀」と言われること
では、そこまでして、私は何を目指しているのか。最後に、いちばん言いたかったことを書きます。
私が目指しているのは、うちのエンジニアが、たとえ将来この会社を離れたとしても、「あの会社出身のエンジニアは優秀だ」と言われるような、市場で競争力を持ち続ける人であってほしい、ということです。会社の中でだけ通用する最適化ではなく、どこへ行っても通用する、持ち運び可能な実力。AI 時代の DevEx の向上とは、突き詰めればここに行き着くと思っています。
これは、経営者としては一見おかしなことを言っているように聞こえるかもしれません。自社での経験を通じて力をつけたエンジニアが優秀になればなるほど、他社からも引く手あまたになり、辞めていくかもしれない。それでも私は、囲い込むために能力を伸ばす機会を絞る、という選択はしたくありません。むしろ逆で、辞めても通用するほどの力をつけてもらうことが、結果的にいちばん強い組織を作ると信じています。ここにいれば市場価値が上がる、最前線の道具と経験が手に入る。そう思えるからこそ、優秀な人が集まり、留まる理由にもなる。離れても通用する力を約束することと、留まりたいと思える場所であることは、矛盾しません。
そしてこれは、DevEx という言葉の本来の主語を、組織から個人へ引き戻す試みでもあります。従来の DevEx は、ともすれば組織のアウトプットを最大化するための開発者体験、という語られ方をしてきました。けれど体験の主体は、あくまで一人ひとりのエンジニアです。彼ら自身が、この怒涛の時代を面白がりながら走り抜け、数年後に振り返って市場で戦える自分になっていること。その手応えこそが、私の考える最良の Developer Experience です。会社の生産性は、その結果としてあとからついてくる。順番を逆にしてはいけない、と思っています。
まとめ
研修で問われた「AI 時代の Developer Experience の向上」という問いへの、現時点での私の答えを 3 点にまとめます。
- 摩擦の解消からボトルネックの移動へ: AI がコードを書くコストを崩したことで、DevEx の焦点はタイピングの摩擦から、何を作るかの見極め、生成物の評価、システムの設計へと移った。AI との協働そのものが開発者体験の中身になった
- 環境は経営が与え、使い倒すのは本人: 最新の AI を迷わず使える環境を用意するのは経営の責任。しかしそれは必要条件にすぎず、遠慮なく使い倒し、基礎を学び続けて最前線を走るのは、エンジニア一人ひとりに託される
- 目指すのは持ち運び可能な競争力: 会社の中だけの最適化ではなく、辞めても「あの会社出身は優秀だ」と言われる実力を。DevEx の主語を組織から個人へ引き戻すことが、結果として最も強い組織を作る
研修の場で投げかけられた問いに、こうして腰を据えて答えを書いてみて、あらためて思います。道具がどれだけ賢くなっても、最後に走るのは人です。その人が、怒涛の時代を面白がり、競争力を保ち続けられるように環境を整えること。それが、AI 時代に私が果たしたい Developer Experience の向上の中身でした。
以上、フルリモート組織で技術と組織を見ている立場から、現場のエンジニアに問われて考えた Developer Experience について、現場からお送りしました。