AI 駆動開発の生産性向上、現場が静かに支払っているコストの話
「残業は減った、納期も守れている。なのになぜか疲れている」——Claude Code をはじめとする AI コーディング支援ツールが普及した現場で、こうした状況が静かに広がっています。Zenn に投稿された ShintaroAmaike さんの記事 が、この構造的な問題を鋭く分析しています。 生産性向上の便益は誰が受け取っているか AI 駆動開発で実装速度が上がったとき、その恩恵は組織内で均等に分配されるわけではありません。 立場 受け取る便益 経営・上層部 プロジェクトが早く回る、コスト効率が改善する PM・マネジメント 仕様変更のリカバリーコストが下がり、「とりあえず作ってみる」が選択肢になる 開発者 より多くのタスクをこなすことが前提化される。やり直しの回数が増える 便益の分配が偏ること自体はどの技術革新でも起きることです。問題は、偏りに気づかないまま運用が常態化してしまうことにあります。 「時間」では測れない疲労の蓄積 従来の働き方の問題は「長時間労働」という分かりやすい指標で捕捉できました。残業時間を見れば過度な負荷が可視化できたわけです。 しかし AI 駆動開発で起きている疲労は、労働時間に現れにくい性質を持っています。 表面上は問題がなさそうに見える: 実装時間そのものは短い 残業も発生しない しかし実際には負荷が増えている: 意思決定の回数が増えている タスクの切り替え頻度が上がっている やり直しによる心理的コストが蓄積している 結果として「忙しくないはずなのに疲れている」という、従来のフレームワークでは説明しにくい状態が生まれます。 これは精神論ではなく、意思決定疲労（decision fatigue） や 文脈切り替えコスト（context switching cost） として以前から知られている現象です。AI 駆動開発はこれらを構造的に増幅する性質を持っています。 構造的に起きる「やり直し」問題 AI による実装高速化の最も見えにくい副作用は、仕様を詰めるインセンティブが失われることです。 従来は仕様変更が実装の手戻りを意味し、納期や予算に直接響いたため、上流工程で仕様を固める動機が強く働きました。AI 駆動開発では実装コストが下がるため「作ってみてから考える」が現実的な選択肢になります。その結果、上流の不備を下流が吸収する構造が生まれやすくなります。 やり直しには性質の異なる 3 種類があります: 開発者自身の理解不足によるやり直し — スキルで減らせる、経験として積み上がる 本質的な複雑性の発見によるやり直し — 避けられない、価値のある発見 上流工程の不備に起因するやり直し — 繰り返されるが、学びにつながらない 3 つ目のやり直しが増えると、開発者の疲労は「働いた時間」ではなく「報われなさ」として蓄積します。何度こなしても同じパターンの問題が繰り返される労働は、量に関係なく人を消耗させます。 評価の問題: 貢献が可視化されにくくなる もう一つ重要な課題があります。開発者の貢献が従来の指標では測りにくくなっている点です。 実装が速いため「頑張った」が時間で示しにくい AI が書いたコードの比率が上がるほど、開発者の知的貢献がぼやける 仕様変更への柔軟な対応は曖昧に評価されがち 上流の不備を吸収した労力は貢献として認識されない 「AI でやれば速いのだから、速くて当たり前」という前提が広がると、評価されるハードルだけが上がり、評価される項目は減っていきます。放置すると、割に合わないと感じた開発者から静かに離脱が起きます。しかしその原因は、労働時間のような可視化された指標には現れません。 ...