はじめに
この記事は、先日Rehab for JAPANのエンジニア月次定例で話した内容の外向け版です。社内向けに用意したスライドをもとに、要旨をあらためて整理し直しました。
テーマは「これからのITエンジニア」。AIコーディングが実務で使えるものになってきた今、エンジニアの仕事は「コードを書く人」から「AIとプロダクトを動かし、成果に責任を持つ人」へと、少しずつ移り始めているのではないか、という話です。
話しながら、自分自身にも同じ問いを投げかけているような感覚がありました。「このままの働き方でいいのか」を、個人と組織の両方に置いてみた、という位置付けに近いと思います。似たような迷いのなかにいるエンジニアやテックリード、EM、CTOの方に、少しでも参考になればと思い公開することにしました。やや長めですが、気が向いたタイミングで読んでもらえればと思います。
AIコーディングは、もう「補助」ではない
まず前提として、AIコーディングは「補助ツール」のフェーズを終えつつある、という実感があります。体感だけでなく、公開されている数字にも傾向として表れていて、定例では次のような流れを紹介しました。
- 2022年ごろ：GitHub Copilot利用者は同じタスクを約55%速く終える、という調査結果が出始めた（GitHub: Quantifying Copilot's impact）
- 2024年ごろ：Googleの新規コードのうち、25%超がAIによって生成され、そのあとエンジニアがレビュー・受け入れしているという発表（Alphabet Q3 2024 earnings）
- 2025〜2026年：GitHubではCopilot code reviewの利用が一気に伸び、コードレビューの5件に1件超をAIが占めるようになっている（GitHub: 60 million Copilot code reviews and counting）
実装の速さだけでなく、仕事の内訳そのものも変わりつつあります。AI活用が進むチームほど「コアなコーディング活動」が増え、「プロジェクト管理・事務作業」が減り、「以前なら工数がなくて後回しにしていた仕事」にも手が届くようになってきている、という報告が出てきています。自分のチームでも、同じ傾向を感じる場面が少しずつ増えてきました（Anthropic: 2026 Agentic Coding Trends Report / Anthropic: How AI is transforming work at Anthropic）。同じ方向の観察は、開発者調査（Stack Overflow Developer Survey 2025）や、マネジメントの時間配分の研究（HBS: Can AI help managers love their jobs again / HBS working paper 25-021）でも確認できます。
ここで言いたいのは、単にコードを書く時間が短くなった、という話ではありません。その結果として、エンジニアが一日のうちで何に頭を使っているかの中身が変わりつつある、ということです。重心が「書く」から「決める・任せる・確かめる」へと少しずつ移っていて、自分自身の時間の使い方も、ここ半年で劇的に変わってきたと感じています。
これからのエンジニアは、AIチームを率い、何を作るかまで担う
この変化を一言でまとめると、次のような言い方になると思います。
これからのエンジニアは、AIチームを率い、何を作るかまで担う。
分解すると、論点は二つです。
ひとつは、AIチームを率いる側に立つという話です。AIを便利なツールとして使う段階から、複数のAIエージェントをメンバーとして動かす段階に入りつつあります。一人で黙々と書くのではなく、複数のエージェントに同時に仕事を振り、途中で軌道修正し、最後に品質と責任を引き受ける。好みの問題というより、仕事のやり方そのもののアップデートに近いと感じています。
もうひとつは、「何を作るか」まで踏み込むという話です。AIで作れる量が増えるほど、差がつくポイントは「実装の速さ」ではなく、顧客理解・課題設定・分解・品質の質に寄っていきます。渡された要件をきれいに実装するだけでは、差を付けにくくなっていく。これまで分業化が進んできたソフトウェア開発において、ここの切り替えは簡単ではないとも感じています。それでも、向き合っておきたい論点です。
外部企業の発信は、ほぼ同じ方向を向いている
ここまでの話は「Rehabが独自に言っているだけなのでは」と受け取られかねないので、定例では外部の発信もあわせて紹介しました。AIモデル側・開発ツール側の各社が、エンジニア像をどう語り直しているか。並べてみると、言い回しはそれぞれ違うのに、向いている方向はかなり近いという印象です。
- Anthropic：実装者から"オーケストレーター"へ。「AIに全部やらせる人」ではなく、どこまで任せ、どこで止め、どこを人間が判断するかを線引きできる人が中心になっていく（AI fluency index / 2026 Agentic Coding Trends Report）
- OpenAI：agentが最初の実装者、engineerはレビュー・編集・指示を出す役割に変わる。AIが迷わない環境を設計し、ガードレールをコード化し、品質を継続的に維持できる人（"harness engineering" / Build an AI-native engineering team）
- GitHub：developerは strategic orchestrator へ。単に会話がうまい人ではなく、曖昧さを減らし、型・規約・レビュー・テストで事故率を下げられる人（The new identity of a developer / Why AI is pushing developers toward typed languages）
- Shopify：AIを前提に置いた、構造化・再現可能な開発フローを設計する役割。AIの結果だけを見る人ではなく、AIの手順を分解し、再現可能にし、監査できる人（Shopify Engineering: Introducing Roast / First Round Review: Shopify / TechCrunch: Shopify CEO memo）
決済領域でも同じようなトーンの発信があって、Stripeも「AIエージェントが実際の統合コードをどこまで書けるか」を正面から問うています（Stripe: Can AI agents build real Stripe integrations / Stripe Sessions 2025 Developer Keynote）。
改めて並べ直すと、エンジニアの役割は「自分で全部作る人」から「AIを率いて、レビューし、方向づけする人」へ移っていく、と各社がそれぞれの言葉で語っています。立場の違う会社が同じ方向を向いているということは、好き嫌いとは別に、業界全体の標準そのものが動いていると受け止めておいたほうが無難だと思います。これまでの評価軸のまま走り続けていると、気づいたときにずれが大きくなっている、ということは起こり得ます。
国内企業に共通して見える「これからのエンジニア像」
国内の発信も似た方向を向いています。準備しながら、各社の語り方に重なる部分が多いことに気付きました。代表的なところを拾うと、次のようなものです。
- 領域を越境して、課題発見・要件定義から設計・実装・運用まで一気通貫で担う人、いわゆるテックリード／ビジネスリードエンジニア（CyberAgent Developers Blog）
- 技術をどう使うかだけでなく、その技術で何を変えたいかを語れる存在。PdMに任せきりにせず、プロダクトや顧客価値に深くコミットする人（Sansan Builders Blog）
- 職種の壁にとらわれず、全員が顧客理解と価値向上に責任を持つ。エンジニアは「何を解くべきか／どう価値を出すか」に向き合うべき、という主張（LayerX Tech Blog）
- アウトプットではなくアウトカムを目的にできる人。さらに、組織づくりや環境整備まで自分で担える人（SmartHR Tech Blog）
似たトーンの発信は他の会社にも広がっていて、EM・PdLの役割そのものを問い直している動き（freee Developers Blog: PdL/EM role in AI age）や、全社的にAI活用体制を宣言する動き（メルカリ Mercan / DeNA ニュース / LINEヤフー プレスリリース / LINEヤフー Tech Blog）などでも、だいたい同じ方向が語られています。
並べて眺めてみると、業種も規模もバラバラなのに、透けて見える共通項は4つくらいに集約されると思っています。
- AI前提で仕事を設計する力
- PdM／事業視点への越境
- 最終判断と品質の責任を引き受ける姿勢
- 個人技で終わらせず、組織の学習に変えていく力
偶然この4つに揃った、というよりは、いま評価される型そのものが少しずつ動いてきている、と受け止めるのが自然だと思います。
実装コストが下がるほど、判断コストが上がる
もう少し構造的に言うと、ここで起きているのは単なる高速化ではなく、ボトルネックの位置そのものが動いている、という話です。
これまでのエンジニアリングのボトルネックは、おおむね「作る側」にありました。実装速度、ステップ数、ボイラープレート、コードを書く工数。このあたりをどう削るかが勝負どころで、個人的にも長くそのあたりをチューニングしてきた記憶があります。
ところが、AIでコードを出すこと自体のコストが大きく下がった結果、ボトルネックはこちら側に移りつつあります。課題設定、仕様の明確化、優先順位、品質保証、運用設計。作るコストが下がった世界では、間違ったものを速く作ることも同じくらい容易になります。実際、「速く作れた分だけ速く捨てる」ような場面にぶつかったこともあります。
そう考えると、これからの差は「実装量」ではなく「判断の質」に寄っていきます。
この「判断の質」をもう一段具体化するために、普段からエンジニアリングをB/S（バランスシート）で見るようにしています。流動資産にあたる「使われて利益を生んでいる機能」を増やし、流動負債・固定負債にあたる「顧客に悪影響を与えている機能」「開発体験を損なっている機能」を戦略的に減らしていく。判断の質とは、自分たちのB/Sをどう整えるかという意思決定の質だ、というのが現時点の整理です。このあたりは以前、別記事にまとめているので、興味があれば参考にしてください。
エンジニアは、AIに任せる側になる
少し踏み込んだ言い方をすると、これからのエンジニアはAIを部下に持つマネージャーに近い役割へ寄っていくのではないか、と考えています。
ただし、これは「AIに丸投げすればよい」という話ではありません。むしろ逆で、丸投げはあまりうまくいかないやり方だと感じています。そうではなく、
- 仕事を分解する
- 必要な文脈と制約を渡す
- 途中成果を確認する
- 出力をレビューする
- 最後に品質と責任を引き受ける
という、マネジメントに近い仕事になります。AIが出したコードを「よさそうだからマージ」で済ませない。人に任せるときと同じように、背景を伝え、期待値を揃え、途中で方向を直し、最後に自分で責任を持つ。やっていることはほとんど同じで、違うのは相手がAIか人間か、くらいの差です。（AIは感情がない分、指示に対して忠実に動くという特徴があります）
AIと仕事を始めた頃に効いたのは、「AIにどう任せるか」よりも「自分がどう任せる人だったか」を振り返る作業でした。普段の指示出し・レビュー・方向修正の癖が、そのままAIとの仕事の質に出る感覚があります。ここを置き去りにしたまま進めると、結果も安定しにくい、というのが実感です。
AIに任せる仕事は、実はマネジメントそのもの
AI活用は、良いプロンプトを一度入れて終わりという類の作業ではありません。ここは定例でも繰り返し触れた部分です。実際のサイクルは、次のような流れになります。
課題定義 → 分解 → 指示 → 実行(AI) → レビュー → 統合
↑ │
└──────── やり直し ──┘
図にするとシンプルですが、実際にやってみると、サイクルを何周も回せる人と、一周で止まってしまう人の差が案外はっきり出ます。速く、何周も、軽く回せる人が強い、というのが現時点での見立てです。
このサイクルで効いてくるのは、突き詰めると、
- 任せる力（どこまで切り出すか、何を渡すか）
- 疑う力（本当に満たしているか、抜けていないか）
この二つがセットで動いているかどうかだと考えています。どちらか一方だけだと、速いけれど壊れやすい形か、慎重すぎて止まってしまう形か、どちらかに寄っていきやすい。両方が揃って初めてサイクルとして回ります。
そして、正しく任せて正しく疑うためには、その時・そのタスクで何を優先するのかを自分の中で言語化できている必要があります。チームで決めたQCDのバランス定義やインセプションデッキのような古典的な道具が効いてくる場面だと感じます。地味ではありますが、ここがあいまいだとAIと組んでも同じだけあいまいさが残ってしまう、という印象です。
作る前の判断に、エンジニアも責任を持つ
念のため補足しておくと、これは全員がPdM職になる、という話ではありません。職種を変えるべきだ、と言いたいわけでもない。実装に没頭する時間は、これからも価値のある時間だと考えていますし、自分もその時間は好きです。
ただ、これからのエンジニアは、受け取った要件をそのまま実装するだけでは少し足りなくなっていく、という話です。
- 誰の・どの課題を解くのか？
- なぜ今やるのか？
- どこまで作れば"十分"か？
- 何を成功とみなすか？
- どう検証するか？
こうした問いに、PdMと一緒に踏み込む側に寄っていく必要がある。実装チケットを受け取ってから考え始めるのではなくて、チケットになる前の段階から関わる、というイメージです。
その結果、これから相対的に増えていく仕事は、こういうものだと思っています。
- 顧客課題の言語化
- 業務フローと例外の理解
- MVPの切り方
- リリース後の学習
- 優先順位の議論への参加
特にRehabのように、介護現場という人が実際に動くドメインに寄り添うプロダクトでは、「作ること」以上に「どの運用であれば現場に根づくか」を見極める重要度が上がります。作る前と、リリースした後の両方で、エンジニアもアウトプットだけでなくアウトカム（成果）への責任に一歩踏み込むことが求められる。ここ数年で、自分の中で少しずつ固まってきた結論です。
ここは、以前まとめた「AI駆動開発（ADD）」の考え方とも地続きの話です。Rehabではアウトカム ＝ Σ(アウトプット量 × 品質 × ユーザーアウトカム × ビジネス価値) という式で、この「成果」の中身を分解しようとしています。AIによって式の左側の「アウトプット量」は伸びやすくなりますが、残り3つの因子を一緒に上げていかないと、アウトカムの総和はむしろ下がり得る、という認識です。ADD側の話に興味がある方は、あわせて読んでもらえると文脈がつながると思います。
組織としてどう備えるか
ここまでの話はどうしても個人スキルに寄りがちですが、組織側の準備も同じくらい、むしろそれ以上に重要だと考えています。Rehabで動き出している取り組みを、少し一般化しつつ紹介します。
1. AI利用の標準フローとハーネスエンジニアリング
- CLAUDE.mdなどのリポジトリ内ガイドの整備
- レビュー基準の明文化
- 共有プロンプト・テンプレートの整備
- ガードレール（型・規約・自動テスト）の強化
- テスト効率化
AIに安定した品質を出し続けてもらうには、AIが迷わない環境を人間側で設計しておく必要があります。最初はプロンプト個別の工夫に目が向きがちですが、実際に効いてくるのはリポジトリ側の整備のほうです。ここは個人の工夫というより、組織として取り組むべき領域だと考えています。
自社では、AIコーディングツール関連のイベントに登壇しているまさきさんがエンジニア組織全体のAI活用を推進しています。
2. 顧客接点と業務理解の機会を増やす
- デイサービス訪問と中継施策
- ミニPdMとしての経験機会
「何を作るべきか」に踏み込むためには、顧客と業務を見る機会そのものを組織が用意する必要があります。「顧客視点を持とう」とエンジニアに声をかけるだけで視点が育つわけではない、というのは、自分が経験を通じて感じてきたことでもあります。機会がなければ視点は育ちにくいし、その機会を用意するのは組織の側の役割だと考えています。
自社では、デイサービスへの訪問しつつ、現場から中継してオフィスのメンバーからの質問を受け付けるといった施策を開発マネージャーのホセさんが推進しています。
「ミニPdMとは、エンジニアが実際にどこまで現場に出るのか」「やってみて、何がどう変わったのか」── こうした問いへの実際の答えは、動いてくれているメンバー自身が社内noteで書いてくれています。Rehabで「作る前の判断」にエンジニアが踏み込み始めた現場の手触りは、この記事よりも具体的に読み取れると思います。同じような仕組みを自チームで検討している方の参考にもなるはずなので、よければ覗いてみてください。
3. 評価制度自体のアップデート
そして、これがもっとも大きな論点かもしれないと考えています。評価軸が「実装量・ステップ数・スピード」のままだと、ここまで書いてきた話はどうしても絵に描いた餅に近づいてしまいます。「判断の質」や「アウトカムへの貢献」をきちんと評価に反映できるよう、制度側もあわせて動かす必要があります。この部分はVPoEの宇井さんを筆頭に現在進行形で試行錯誤している最中で、まだ「こう変えました」と明確に共有できる段階ではありません。整理がついたタイミングで、またどこかで書きたいと思います。
おわりに ― 書く人から、動かす人へ
最後に、社内定例の締めに使ったスライドの一言を、そのまま置いておきます。
これからのエンジニアは、コードを書く人から、AIとプロダクトを動かし、成果に責任を持つ人へと変わっていく。
この変化は、業界の各所で既に語られ始めているだけでなく、現場でも少しずつ姿を変えつつあります。大きなニュースとして目に入る話と、自分のチームのSlackやPRのやり取りのなかで気付く小さな変化と、その両方が重なりながら進んでいる、という感覚に近いかもしれません。
自分自身、「実装量」から「判断の質」へと評価の重心をどう移していくかについて、まだ明確な答えを持っているわけではありません。評価制度にしても、組織としての備え方にしても、まさにこれから進めながら悩み、直しながら前に進めていく段階です。同じように試行錯誤しているチームや個人の方に、この記事が少しでも考えるきっかけや、言語化の材料になれば嬉しく思います。似たテーマで取り組まれている事例や、異なる立場からの意見にも興味があるので、気付きがあればぜひ共有してもらえるとありがたいです。
参考文献
本記事の主張は、以下の一次情報・公開発信を参照して組み立てました。
海外企業の発信
- Anthropic: How AI is transforming work at Anthropic / AI fluency index / 2026 Agentic Coding Trends Report (PDF)
- OpenAI: Harness engineering / Build an AI-native engineering team / Building an AI-native engineering team (PDF)
- GitHub: The new identity of a developer / Why AI is pushing developers toward typed languages / Quantifying Copilot's impact on productivity / 60 million Copilot code reviews and counting
- Shopify: Introducing Roast / First Round: Shopify's AI playbook / TechCrunch: Shopify CEO memo
- Stripe: Can AI agents build real Stripe integrations / Stripe Sessions 2025 Developer Keynote
- Google: Alphabet Q3 2024 earnings message
研究・調査
- Harvard Business School: Can AI help managers love their jobs again? / HBS Working Paper 25-021 (PDF)
- Stack Overflow: Developer Survey 2025 — AI
国内企業の発信
Discussion