「コードを書かないエンジニア」の生産性の正体
朝9時、Slackを開く。 AIが夜間に処理したPRのレビュー依頼が3件並んでいた。
コードエディタではなく、Slackから1日が始まる。 ここ数ヶ月、こういう朝が増えた。
気がつけば、1日の大半をコードエディタの外で過ごしている。 設計ドキュメントを書く。AIの出力を読む。 非エンジニアの同僚とミーティングする。 ツールの組み合わせを考える。
「今日、何行コードを書いた？」と聞かれたら、 正直に答えると「ゼロ」の日もある。
最初は焦った。 エンジニアなのにコードを書いていない。 これは退化なのか、それとも進化なのか。
同じ違和感を持っている人は多いと思う。 僕のある1日を追ってもらうことで、 その答えが見えてくるかもしれない。
「コードを書かない」は本当に問題なのか
まず、数字を見てほしい。
レバテックIT人材白書2025によると、 採用担当者が「より重要になった」と感じるスキルの1位は **コミュニケーションスキル（48.3%）**だった。
2位はプロンプトスキル（38.5%）、 3位はピープルマネジメント（29.8%）。
一方で、「以前ほど重要でなくなった」スキルの1位は プログラミングスキル（26.0%）。
4人に1人の採用担当者が、 コードを書く能力の優先度が下がったと感じている。
別の調査も同じ方向を指している。 フリーランスボードの2025年調査では、 生成AIを導入済みの職場の**54.3%**が 「業務効率が向上した」と回答。 ITエンジニアに限ると、**88.9%**が効率改善を実感している。
Findyが 188社に聞いた調査でも、 90%以上の企業がAIツールの導入に取り組んでいた。
エンジニアの仕事そのものがなくなったわけじゃない。 仕事の重心が移動しているんだと思う。
@ITが2026年1月に公開した 記事では、 AIがコードを書く時代にエンジニアの役割が4つの方向に変わると整理していた。
それを読んで自分の1日を振り返ったとき、 僕なりに設計者・審査官・翻訳者・指揮者という4つの役割に分類できることに気づいた。
細かな実装はAIに任せて、 人間は「どう作るか」「どこまで任せるか」を考える。
データを見ると納得感はある。 でもデータだけだとピンとこないかもしれない。
だから、僕のある1日を見てほしい。
9:00-10:30 — 設計者の朝：AIが出したPRを「読む」仕事
僕の朝は、コードを「書く」ことではなく 「読む」ことから始まる。
SaaS企業で生成AIの社内活用を担当している。 2023年からフルリモートで、 自宅のデスクにBlueのマイクを置いて AquaVoiceで音声入力するのが定番スタイルだ。
2026年に入ってから、働き方が大きく変わった。 「まずClaude Codeにやらせてみよう」 これが口癖になった。
朝いちばんでやるのは、前日に仕込んだタスクの確認。 Claude CodeのMAXプラン（月$100）を使っていて、 夜のうちにコードの生成や修正を走らせておくことがある。 朝はその出力を読んで、設計の意図通りかを判断する。
ここで大事なのは、ゴールの明確さだ。
実感として、ゴールが明確なほどAIは正しく動く。 曖昧なときは先に壁打ちをしてゴールを整理してから 実装に回す。 違和感があるところを頑張って言語化すると、 出力の精度がぐっと上がる。
これは人に仕事を頼むのと似ている。 うまく説明できないことは、AIにも伝わらない。
誰かに説明しようとして、 「あれ、ちゃんと言葉にできないな」と思ったとき。 そのままClaude Codeに渡しても、 同じように突っ込まれる。
だから朝の時間は、 コードを書くのではなく「設計の言語化」に使う。
AIに何を作らせるか。 どこまでを任せて、どこからは人間が判断するか。 この線引きが、午前中の最も重要な仕事になった。
10:30-12:00 — 審査官の時間：「ほぼ正しい」を見抜く目
設計意図を伝えてAIに実装させる。 ここまでは順調に進むことが多い。
問題はその後だ。
Stack Overflowの2025年開発者調査で 興味深いデータがある。 開発者が感じる最大の不満は **「AIの出力がほぼ正しいが、完全ではない」（66%）**だった。
2位は「AIが生成したコードのデバッグに 以前より時間がかかる」（45%）。
AIが書いたコードは 「それっぽく動く」ところまでは到達する。 でも本番環境に出せるかどうかは別の話だ。
エッジケースを見落としていないか。 既存のコードベースと整合しているか。 パフォーマンスに問題はないか。
この「ほぼ正しいを見抜く」スキルが、 午前後半の仕事の中心になる。
以前、OCRを使った請求書の読み取り精度を 改善するプロジェクトに携わったことがある。 従来のラベリングによるOCRモデルだと、 正解率が約1割しかなかった。
そこでAzureのOCRで文字情報を読み取り、 その結果をOpenAIのLLMで解析する 二段階方式に切り替えたところ、 読み取り率が劇的に向上した。
この経験から学んだのは、 AIの出力をそのまま受け入れるのではなく、 「何が正しくて、何が足りないか」を判断する目が 成果物の品質を左右するということだ。
コードレビューの本質は変わっていない。 変わったのは、レビュー対象が 「人間が書いたコード」から 「AIが書いたコード」に広がったこと。
AIのコードは人間とは違うパターンで間違える。 一見きれいに書かれているが、 ビジネスロジックの微妙なニュアンスを取りこぼす。
そこを見抜けるかどうかが、 審査官としてのエンジニアの価値だと思う。
13:00-15:00 — 翻訳者の午後：非エンジニアとの境界を溶かす
午後になると、仕事の性質が変わる。 技術の世界から出て、 ビジネス部門の同僚と話す時間が増える。
最近、非エンジニアの部門と仕事をする機会が増えた。 彼らがAIを使ってプログラムを出力したり、 動画データから内容を評価するような使い方をしている。
正直に言うと、最初は怖さを感じた。
ただ、今のところは単発でAIを使う シンプルな使い方が多い。 複数のツールを組み合わせて 何かを構築するという段階にはまだ至っていない。
その部分では、まだエンジニアの方が強い。 でも、その境界線はどんどん壊されてきている。
だからこそ、守りに入るのではなく 攻めの姿勢でいるようにしている。
非エンジニアから「AIでこういうことをやりたい」と 相談を受けたとき。 技術的な実現可能性を判断しつつ、 彼らの言葉で説明し直す。
逆に、エンジニアチームで決まった技術方針を 経営層やビジネス側に伝えるとき。 技術用語を使わずに、 「何ができるようになるか」 「どんなリスクがあるか」を ビジネスの言葉に置き換える。
この「翻訳」の仕事が、 午後の時間の中心になっている。
Findyの調査で、 AI時代のエンジニアに求められる能力として 「ビジネス感覚と理解力」が挙がっていたのは、 現場の実感と一致する。
レバテックの調査でコミュニケーションスキルが 48.3%でトップだったのも、 こういう翻訳の仕事が増えているからだと思う。
相手は敵じゃなくて仲間だ。 エンジニアと非エンジニアが お互いの領域に踏み込み合うことで、 チーム全体の能力が底上げされていく。
その接点に立つのが、 翻訳者としてのエンジニアの役割だ。
15:00-17:00 — 指揮者の夕方：人とAIのオーケストラ
1日の最後の時間帯は、統合の時間だ。
朝に設計し、午前中に審査し、午後に翻訳した。 夕方はそれらを束ねて、 プロジェクト全体の方向を調整する。
AIツールの選定も、指揮者の重要な仕事の一つ。
僕はGitHub Copilotを使っていたが、やめた。 Cursorも試したが、 アプリがPCのメモリに対して負荷が大きく重すぎた。 結果的にClaude Code一本に絞っている。
ツール選びは、 コーディング性能だけで決める時代じゃない。
Claude Codeはエージェントをワークフローのように使えたり、 ブラウザ操作ができたりと、 コーディング以外の業務でも活躍する場面が多い。
業務全体で「何をどのツールに任せるか」を考えるのが 指揮者としての仕事だ。
以前、LLMを使ったRAGの技術で 社内向けチャットボットを3つ作ったことがある。 今では回答精度が求められる水準に達しておらず、 正直あまり使われていない。
でも、先に手を出して形にしたこと自体が 社内で評価された。 AIに関心がある社員として認知されたことで、 AIチームへの参画につながった。 2026年4月からは生成AI特化の仕事を 任されるようになった。
指揮者の仕事は、 「何を作るか」だけじゃなく 「いつ手を出すか」の判断でもある。
完璧なタイミングを待つより、 不完全でも先に動くことで、 チームの中でポジションが生まれる。
その感覚は、 36歳で異業種からエンジニアに転職したときと似ている。 あのときも「準備が完了してから」ではなく、 「動きながら整えた」から2ヶ月で内定が出た。
「10xエンジニア」の意味が変わった
こうして1日を振り返ってみると、 あることに気づく。
朝から夕方まで、 「コードを書く」ことに費やした時間はほとんどない。 でも生産性が下がった感覚はない。 むしろ上がっている。
「10xエンジニア」という言葉がある。 かつては、普通のエンジニアの10倍速くコードを書ける人 という意味で使われていた。
でもAIがコーディング速度をコモディティ化した今、 その定義は通用しない。
DEV Communityの記事では、 今の10xエンジニアに求められるのは 「良い問いを立て、速く検証し、 自信を持ってリリースする」能力だとされている。
ボトルネックは 「コードを速く書くこと」ではなくなった。 「正しく動くことを確認すること」に移った。
生産性の単位が コードの行数から判断の回数に変わった。
設計者として方針を決める判断。 審査官として品質を見極める判断。 翻訳者としてビジネスと技術を橋渡しする判断。 指揮者としてリソースを配分する判断。
これらの判断の質と速度が、 AI時代のエンジニアの生産性を決める。
ただし、楽観的になりすぎるのも危険だ。
Stack Overflowの同じ調査では、 AIツールへの肯定的評価が 2023-2024年の70%超から、2025年には60%に低下している。
「ほぼ正しいが完全でない」出力に 疲弊している開発者も少なくない。
AIは万能じゃない。 でも、この変化の方向自体は不可逆だと思う。
コードを書く時間が減ることに不安を感じるなら、 代わりに増えている「判断の時間」に目を向けてみてほしい。 そこにこそ、エンジニアとしての価値がある。
まとめ：コードを書かない時間の価値を信じる
僕のある1日を切り口に、4つの役割を振り返ってみた。
- 設計者：AIに何を作らせるかを決める
- 審査官：AIの出力が正しいかを判断する
- 翻訳者：技術とビジネスの間を橋渡しする
- 指揮者：人とAIのリソースを統合管理する
どれも「コードを書く」以外の仕事だ。 でもどれも、エンジニアにしかできない仕事だと思う。
もし今、コードを書く時間が減っていることに モヤモヤを感じているなら、 3つのことを試してみてほしい。
1. AIの出力を読む時間を「設計時間」と捉え直す コードを「書いていない」のではなく、 「設計の精度を上げている」と認識を変える。
2. 非エンジニアとAIの話をする機会を作る 翻訳者としてのスキルは、 技術力とは別の軸でエンジニアの価値を高める。
3. 自分の1日を書き出して「判断」の時間を可視化する 1日の中で何回「判断」をしているか数えてみると、 コードを書いていない時間の密度に気づくかもしれない。
「今日、一行もコードを書いてない。」
その日が来たとき、焦る必要はないと思う。
