課長が手放すのはコードで、AIへの仕様書きという新しい居場所に移る

部下のプルリクを開いて、直したい箇所が3秒で見える。だが今週、あなたはコードに触れていない。

触れれば早いことは分かっている。それでも手を出せば、レビューも1on1も積み残す。

アクセンチュア所属のシニアエンジニアが、コード執筆量が体感1%未満になったと報告した。15年のキャリアを持つ人物の話だ。理由は引退でも降格でもない。仕様を言語化する役割に、自分でロールを移したからだという（Zenn、2026年6月26日公開）。

flowchart TD
    A[コードを書く課長] --> B{手を出す衝動}
    B --> C[仕様を言語化する役]
    C --> D[AIが実装]
    D --> E[現場影響力は残る]

何が起きているか、役割の中身が入れ替わっただけだ
#

このエンジニアが手放したのはコードを書く時間であって、現場への関与そのものではない。

Zennの記事によれば、コードの執筆自体をAIに渡し、自分は仕様の言語化に時間を使うようになったという。書く量が減ったのは能力の衰えではなく、担当領域の再配置だ。

これは課長の「自分でやったほうが早い」問題に、そのまま重なる。あなたが手放したいのはコードを書く行為であって、現場に口を出す権限ではない。問題は、代わりにどこへ座ればいいか誰も教えないことにある。

私が話を聞いてきた課長たちは口を揃えて言う。「委譲しろと言われても、委譲した後に自分が何をする人間なのか分からない」と。空いた手の置き場がないまま、結局コードに戻ってしまう。

仕様の言語化とコードのレビューは、必要な判断の種類が違う。

コードのレビューは「この実装は正しいか」を見る。仕様の言語化は「何を作るべきか」「何を作らないか」を決める。後者のほうが、実は課長の職域に近い。

現場の細かい実装判断はAIに渡せる領域が広がっている。だが「この機能が必要な理由」「境界条件をどこに引くか」「どちらを優先するか」は、業務の文脈を知る人間が決めるしかない。課長はその文脈を、部下より長く持っている。

つまり仕様書きは、技術力の残り火を使い切る場所ではなく、**組織の結節点としての立場をそのまま活かせる場所**だ。手を動かす量は減っても、判断の密度は落ちない。

移行は一気にやらない。燃料を使い切らない範囲で、3段階に分ける。

レビューの前にAIへの指示書を書く: 部下のコードを直接直す前に、「この機能が満たすべき条件」を3行でAIに渡し、たたき台を作らせる。直す手ではなく、条件を書く手を先に動かす。
境界条件だけを自分で決める: 実装の細部はAIと部下に任せ、「どこまでを対応範囲とするか」だけを言語化して渡す。決めるのは仕様の輪郭であって、中身ではない。
週1回、仕様書きだけの時間を固定する: レビューの合間ではなく、独立した枠を作る。会議と同じ強度でカレンダーに入れる。ここでの成果物は、コードではなく条件の文章だ。

この3つを回すと、コードを書く時間は減っても、部下から見た「この人は判断できる」という信頼は残る。信頼の根拠が実装力から仕様の解像度に移るだけだ。

仕様を書いても現場に信頼されないなら、書いている仕様の粒度が粗すぎる可能性がある。

「何を作るか」だけでなく「なぜそれが必要か」まで書けているか確認する。それでも通らないなら、無理に仕様書き役に居座る必要はない。

技術で語れる立場を月数回だけ取り戻す部分回帰という選択肢も残っている。退路は一つに絞らなくていい。

コード執筆量が体感1%未満になったという報告は、能力の引退ではなく役割の再配置だった。

課長も同じ移行ができる。仕様を言語化する枠を週1回固定するところから始めればいい。