「残業は減った、納期も守れている。なのになぜか疲れている」——Claude Code をはじめとする AI コーディング支援ツールが普及した現場で、こうした状況が静かに広がっています。Zenn に投稿された ShintaroAmaike さんの記事 が、この構造的な問題を鋭く分析しています。

生産性向上の便益は誰が受け取っているか

AI 駆動開発で実装速度が上がったとき、その恩恵は組織内で均等に分配されるわけではありません。

立場受け取る便益
経営・上層部プロジェクトが早く回る、コスト効率が改善する
PM・マネジメント仕様変更のリカバリーコストが下がり、「とりあえず作ってみる」が選択肢になる
開発者より多くのタスクをこなすことが前提化される。やり直しの回数が増える

便益の分配が偏ること自体はどの技術革新でも起きることです。問題は、偏りに気づかないまま運用が常態化してしまうことにあります。

「時間」では測れない疲労の蓄積

従来の働き方の問題は「長時間労働」という分かりやすい指標で捕捉できました。残業時間を見れば過度な負荷が可視化できたわけです。

しかし AI 駆動開発で起きている疲労は、労働時間に現れにくい性質を持っています。

表面上は問題がなさそうに見える:

  • 実装時間そのものは短い
  • 残業も発生しない

しかし実際には負荷が増えている:

  • 意思決定の回数が増えている
  • タスクの切り替え頻度が上がっている
  • やり直しによる心理的コストが蓄積している

結果として「忙しくないはずなのに疲れている」という、従来のフレームワークでは説明しにくい状態が生まれます。

これは精神論ではなく、意思決定疲労（decision fatigue） や 文脈切り替えコスト（context switching cost） として以前から知られている現象です。AI 駆動開発はこれらを構造的に増幅する性質を持っています。

構造的に起きる「やり直し」問題

AI による実装高速化の最も見えにくい副作用は、仕様を詰めるインセンティブが失われることです。

従来は仕様変更が実装の手戻りを意味し、納期や予算に直接響いたため、上流工程で仕様を固める動機が強く働きました。AI 駆動開発では実装コストが下がるため「作ってみてから考える」が現実的な選択肢になります。その結果、上流の不備を下流が吸収する構造が生まれやすくなります。

やり直しには性質の異なる 3 種類があります:

  1. 開発者自身の理解不足によるやり直し — スキルで減らせる、経験として積み上がる
  2. 本質的な複雑性の発見によるやり直し — 避けられない、価値のある発見
  3. 上流工程の不備に起因するやり直し — 繰り返されるが、学びにつながらない

3 つ目のやり直しが増えると、開発者の疲労は「働いた時間」ではなく「報われなさ」として蓄積します。何度こなしても同じパターンの問題が繰り返される労働は、量に関係なく人を消耗させます。

評価の問題: 貢献が可視化されにくくなる

もう一つ重要な課題があります。開発者の貢献が従来の指標では測りにくくなっている点です。

  • 実装が速いため「頑張った」が時間で示しにくい
  • AI が書いたコードの比率が上がるほど、開発者の知的貢献がぼやける
  • 仕様変更への柔軟な対応は曖昧に評価されがち
  • 上流の不備を吸収した労力は貢献として認識されない

「AI でやれば速いのだから、速くて当たり前」という前提が広がると、評価されるハードルだけが上がり、評価される項目は減っていきます。放置すると、割に合わないと感じた開発者から静かに離脱が起きます。しかしその原因は、労働時間のような可視化された指標には現れません。

誰が、何を変えるか

経営・上層部が変えること

AI による生産性向上を「タスク量の増加」ではなく 「余白の創出」 に使う方針を明示する。

浮いた時間をすべてタスクに充てる方針は短期的には成果を最大化しますが、長期では開発者の離脱リスクとして現れます。生産性向上の恩恵の一部を技術的負債の解消・ドキュメント整備・学習時間に割り当てることを、スプリント計画の構造として組み込む必要があります。

PM・マネジメント層が変えること

やり直しの発生原因を記録し、上流起因と下流起因を分けて振り返る。

例: 「今回のやり直し 10 件のうち 7 件は要件定義起因、3 件は実装判断起因」のように分類する習慣を持つことで、改善すべきポイントが具体化します。加えて「時間」以外の負荷指標を観測する仕組みも有効です:

  • 意思決定の頻度
  • 文脈切り替えの回数
  • 仕様変更からの復旧時間

開発者が変えること

やり直しの原因を記録し、上流に伝えられる言語で報告する。

「また仕様変更だ」と消耗するだけでは構造は変わりません。やり直しが発生するたびに原因を分類して記録しておくことで、振り返りの場で「感情の訴え」ではなく「データの報告」として伝えられるようになります。

「仕様を詰めること」の価値を再定義する

AI による実装の高速化は、上流工程の重要性を下げるものではありません。むしろ 仕様の精度が成果物の質を決める比重が以前より大きくなっています。

「AI で速く作れるから仕様は後でいい」ではなく、「AI で速く作れるからこそ仕様の質がボトルネックになる」 という認識転換が必要です。

まとめ

AI 駆動開発が当たり前になりつつある今、開発現場が「速く、静かに、残業なく」回っているとき、それが必ずしも健全な状態を意味するとは限りません。

表面的な指標の裏で何が起きているかを見ようとする姿勢が、AI 時代のマネジメントには従来以上に求められています。静かな疲労感に気づいたとき、それはあなた個人の問題ではなく、業界全体が向き合うべき構造的な課題かもしれません。

元記事: その生産性向上、現場が静かに支払っているコストの話 by ShintaroAmaike