ハクソク

世界を動かす技術を、日本語で。

認知的負債：速度が理解を超えるとき

86日前原文(rockoder.com)

概要

  • AI支援開発により、コード生産速度と理解速度の乖離が拡大
  • コードの迅速な出荷が組織的な知識形成を阻害
  • 可視化されない「認知的負債」が蓄積し、組織の長期的リスクに
  • レビューや評価指標が実際の理解度を反映できていない現状
  • 組織的な測定・評価方法の見直しが急務

コード生産と理解の乖離

  • AI支援開発 により、エンジニアは短期間で多くの機能を出荷可能
  • DORAメトリクス やパフォーマンス指標は一見優秀に見える状況
  • 数ヶ月後のアーキテクチャ変更時に、 誰もコードの意図や構造を説明できない問題 が顕在化
  • コード理解より生産が容易 になり、コードの「認知的負債」が発生

認知的負債の発生メカニズム

  • 手作業による開発では、 生産と吸収（理解） が同時進行
  • AI支援では、 生産速度のみ加速し、理解速度は人間の限界に依存
  • 出荷速度と理解速度のギャップ が認知的負債として蓄積
  • 認知的負債は、 MTTR（平均復旧時間）やChange Failure Rate などの遅行指標でしか表面化しない

組織が測定しているもの・していないもの

  • 組織の評価指標は 出荷物やストーリーポイント など「見える成果」に偏重
  • かつては「出荷＝理解」とみなされていたが、 その前提が崩壊
  • 組織的知識の蓄積が不十分 となり、パフォーマンス評価委員会も認知的負債を把握できない

レビュワーのジレンマ

  • AI支援によりジュニアエンジニアの出力速度がシニアレビュワーのレビュー速度を上回る
  • 結果として レビューの質が低下 し、表面的な確認だけで承認が進む傾向
  • レビュワー自身も 内容を十分理解せず承認するため、組織的な「理解済みコード」の前提が崩れる

新しいバーンアウトパターン

  • AIツール利用エンジニア特有の「認知的切断」型疲弊
  • 進捗は早いが、 自分の出力物への理解や自信が希薄
  • 「説明には再構築が必要」「予測が困難」などの症状
  • 可視化された成果主義 がこの傾向を助長し、認知的負債が加速

組織的記憶の喪失

  • 組織知識は 明示的（ドキュメント等）と暗黙的（経験・直感） の2種類
  • AI支援開発で暗黙知の形成が阻害 され、エンジニアの離脱とともに知識も消失
  • システムの維持・拡張時に 理解者不在という遅延型の失敗モード が発生

認知的負債の累積による失敗パターン

  • 長期間動いているコードへの信頼が逆転 し、むしろ危険度が増す
  • インシデント対応時に「ブラックボックス化」 し、復旧コストが増大
  • ジュニアエンジニアの成長阻害 により、将来のシニア人材不足を招く

組織リーダーの視点と測定問題

  • AI支援開発は生産性向上として認識されやすい
  • 「理解度」や「説明可能性」を測る指標が存在しない
  • リーダー層は 可視化されたデータに基づき合理的判断 を下すが、データ自体が不完全
  • 測定できないものは最適化できず、 組織は出荷速度を優先し続ける

モデルの限界と今後の対応

  • 全ての開発業務に認知的負債の問題が当てはまるわけではない
  • ドキュメントやツールの進化でギャップを補える可能性 も
  • 本質的課題は「測定できるものしか最適化できない」組織構造
  • 理解度の可視化や評価方法の刷新 が今後の課題

Hackerたちの意見

このスレッドは関連性が高いよね: https://news.ycombinator.com/item?id=47194847 「AIの適切な量はゼロじゃないし、最大でもない。」

└

別のスレッドの著者だよ。こんなに似てる点が多いとは驚きだけど、善意で考えれば、これは偶然だと思う。多くの開発者が今後の問題に気づき始めてるからね。

組織の記憶やオンコールデバッグのセクションがこれに触れてるけど、他の部分にも大きな影響があるんだよね。例えば、プロダクトサポートで働いていて、顧客が製品の挙動について質問してきたら、ドキュメントが少なかったり（AIが書いたものだったりすると）、エンジニアが自分の書いたコードの基本をすぐに理解していなかったりすると、答えを見つけるのがすごく難しくなる。たとえドキュメントが素晴らしくて、エンジニアが自分のコードについて話し合えるとしても、アップデートのペースについていくのは他のチームにとって大きな課題になることがある。

└

手動でコードを書く時間が減った分、ドキュメント作成もワークフローの一部にすべきだよね。これから始めようと思う。

大企業に4年間いて、あちこちで進行中の無数のプロジェクトを追いかけていると、彼らがどうやって相互作用しているか（良い場合も悪い場合も）を理解するのが一つの仕事になっちゃった。技術的なスキルが全体像を明確にするのに役立つと思ってたのに、実際にはその逆のことが起こってる。

└

一つの（複雑な）製品を持つ会社にいたけど、50倍の製品を持つ10倍大きな会社に入ったら、全体像を理解するチャンスはゼロだよ。とはいえ、私たちの中にはそれをある程度把握することが期待されている人もいる。かなりの挑戦だし、LLMsがあったら本当に不可能だと思う。

└

知識企業の中で人々がどのようにやり取りして物事を進めるかが、その企業の運営の基盤になってるんだ。最近のSaaS CEOの記事では、これを「言語ゲーム」って呼んでるよ。

投稿の前提、つまりコーダーが6ヶ月前に何を書いたか、なぜ書いたかを覚えているというのは間違ってる。コードを書くときに理解するのは簡単だけど、自分が書いたコードを理解するのは難しいっていう問題はずっとあった。だから、AIが登場する前にJoel Spolskyが「コードを読むのは書くより難しい」と言ったんだよね。

└

「難しい」というのは遅いという意味じゃないよ。自分のコードを読むのと理解するのは、書いたりテストしたりするよりもずっと早いけど、簡単ではない。AIツールは、自分が作っているコードを理解するのを妨げないし、実際にはそんなに時間がかからない。でも、難しい作業を避けようとする自然な傾向があるんだよね。もちろん、AIのコードは一般的にひどいから、プロセスがさらに辛くなるけど、君はそれを生み出したコンテキストを見ていたから、少し有利だよ。

└

初めて学ぶときは、手でコードを書くことが大事だと思う。苦労することで批判的思考が身につくし、どうやって「センス」を持つかっていうと、こういう経験が必要だよね :) これがプロダクションコードになるかはわからないけど、Jupyterノートブックみたいに、段階を追って解決策を作る必要があると感じることが多い。もちろん、コードベースの中で意味のないことを理解する必要はないけど、いくつかのことは慎重に考える必要がある。

└

最近、4年前に触ったコードベースで作業したんだけど、全ての行を覚えてるわけじゃないけど、どうやって組み立てられているかはかなり理解してたよ。（追記：いや、特別な記憶力があるわけじゃないからね）

└

何を書いたか、ロジックがどうなっているかは正確には覚えてないけど、全体の流れは大体覚えてるから、どこにコードがあるのか理解しやすいんだ。

└

いろんなコードベースを定期的に行き来してるんだけど、自分が書いたのもあれば他の人が書いたのもある。何年も経ってから戻ってくることも多いけど、6ヶ月後に戻るのと1週間後に戻るのとで、あんまり違いは感じないんだよね。大変なのは、そのプロジェクトのコーディングスタイルや全体の構造に慣れること。どこに何があるかの「直感」を掴むのが重要で、過去にその努力をしていたら、意外とすぐに思い出せる。昔覚えてた曲を、久しぶりに最初の一節を聞いたら急に思い出すみたいな感じ。もちろん、自分が書いた曲を覚えるのはもっと簡単で、自然に頭に残るよね。

└

ここでもAIが役立つと思うよ。ただコードを書かせるだけじゃなくて、始める前に自分が忘れてる部分のアーキテクチャの概要を教えてもらったり、以前からの変更点をまとめてもらったり、これからやることの全体像を見てもらったり、デザインを批評してもらったりするといいよ。コードを書く手助けをしてもらうなら、ただコードを書くのだけじゃなくて、もっと広い認知負荷を軽減してもらうといい。

└

長期間にわたって細かいことを記憶しておくのは難しいけど、全体の詳細はしっかり覚えてるよ。パターン、型、インターフェース、API、アーキテクチャの決定。だからこそ、コメントを書いたり、徹底的なテストをするんだ。細かいことのドキュメンテーションは重要で、リファクタリングの時にガードレールになる。今、職場のコードベースに対して認知的負債を感じてる。AIのおかげで機能を早く出せてるわけじゃなくて（確かにそういう面もあるけど）、以前は「ノー」と言ってたようなもっと複雑な仕事に取り組んでるんだ。

└

OPは、こういった出来事が増えていることについて話していて、これは新しい問題じゃないってことだよね。例えば、手書きのコードはチームの他のメンバーによって手動でレビューされることが多かったから、誰かが思い出す確率は高かった。対して、LLMが生成したコードはLLMによってレビューされるから、その確率は低くなる。

└

他の人のコードを理解するのは、自分のコードを理解するより難しいけどね。

└

Perlとの経験。「書き込み専用」の言語。

すごく共感する。週末にSaaSプロジェクトを書いたんだけど、Claudeが機能を実装するのがめちゃくちゃ早くて驚いた。1文がTDDに変わって、見た目は良かったし機能も動いたけど、今は3週間後にその仕組みのアウトラインしか残ってなくて、システムのコンテキストを取り戻すのが辛そう。手書きでプロジェクトをやってたら、数年離れても主要なファイルを見つけたり、システムアーキテクチャを思い出したりできたと思う。

自分が作ったものを深く理解するために立ち止まるエンジニアは、速度の指標で遅れをとる。これが最も厄介な部分だよね。悪いコードがデプロイされること自体が問題じゃなくて、それは修正できるし、（定義上）市場がそれを排除してくれるはず。でも、市場はそう動いてないみたいで、気にかけているエンジニアが指標を達成できないから仕事を失うんだ。

└

もちろん反例もあるけど、何かを生産することとそれを販売することの間には、ほぼ対立する目標があるんだ。無限のお金と時間があれば、多くのエンジニアやアーティストが完璧になるまで書き直すだろうけど、制約が必要だよね。世界は真空の中で動いているわけじゃないし、みんながユートピアに住んでいるわけじゃないから、顧客や資源を競わなきゃいけない。制約があることで、より良い結果が生まれることが多い。Duke Nukem Foreverを思い出してみて、何もないものをリリースするのにどれだけ時間がかかったか。最近、「七王国の騎士」っていう番組を見たんだけど、シャワーランナーたちは従兄弟の番組に比べて限られた予算を与えられていて、その結果、より良い製品ができたんだ。時には、そういう指標が物事を軌道に乗せてくれることもある。

記事の内容に反対するつもりはないけど、ちょっと視点を加えたいな… 「誰も理解できないコード」についての不満は、手書きのコードでも同じように起こってたよ。例えば、こんな話がある： - https://devblogs.microsoft.com/oldnewthing/20121218-00/?p=58... より：> 二人でプログラムをデバッグしようとしたけど、数年前に外部の会社が書いたコードで、Microsoftの誰もそのコードがどう動いているか理解していなかったし（今でも理解してない）、ほとんどのコードにコメントが全くなかったから、衝突検出が動かない理由が全くわからなかった。衝突検出器すら見つけられなかったし、数百万行のコードを移植しなきゃいけなかったから、数日間もコードを調べて浮動小数点の丸め誤差が原因で衝突検出が失敗している理由を探る余裕はなかった。そこで、ピンボールを製品から外すという決断をしたんだ。 - もう一つは、Oracle RDBMSのコードベースについての話で、https://news.ycombinator.com/item?id=18442941 から（そのHNスレッドは大きくて、Oracle以外のスパゲッティプロジェクトについても話しているトップレベルのコメントがたくさんあるよ）。

└

これってOPの主張を裏付けてるよね？提示されているのは、誰もそのコードがどう書かれているか、なぜそうなっているのか分からない状況が、AIによってもっと頻繁に、早く起こるってこと。

└

おそらく、プロンプトをバージョン管理で保存し始める必要があるね。プロンプトは人間と機械の両方にとってコンテキストになるから。

ここまで来たら、もう全力で行っちゃおうよ：「LGTM, LLM」。業界はいつも行き過ぎてから修正するから、もしかしたら正しいアプローチは、コードを完全に忘れて、他の方法で制約をかけたり、正しさを確保したり、理解が必要な時とオプションの時を見極める方法を考えることかも。嫌なのは、みんなに出力を20倍にしつつ、100%のコードに対して全責任を負わせるような不可能な中間地点。これは市場が最終的に消し去るような魔法のような考え方だと思う。理解を諦めるか、せいぜい20%の生産性向上を受け入れるかのどちらかだね。

└

私も今のところ20%程度の向上しか見てないけど、コードを書く以外にもLLMのもっとクリエイティブな応用があって、製品をエンドツーエンドで提供する際に生産性を何倍にも引き上げる可能性があると思う。今、そういったことを発見してブログに書いてる人たちがいるけど、ダークファクトリーやエージェントがエージェントを監視するみたいな話がその声をかき消してる。私たち一人一人が選べば、パイオニアになれるんだ。業界としてはまだ表面をかすっただけだよ。

└

生産性の向上は、ソフトウェアの書き方に完全に依存してるよね。神クラスがあって、何百万行ものコードがあって、複数のチャネルで一貫して動かなきゃいけない古いプロジェクト？でも、実際には書かれたコードからそれらをつなげるものが何もない？そんなの、20%の向上すら無理だよ。自分でやった方がほぼいつも早いし、得られるのは疲労ボーナスだけ。つまり、同じ出力のために自分をあまり投資しなくなるけど、誰もそんなコードベースを頭に入れておけないから、複数のエージェントに展開するのが難しくなるんだ。LLMが所有するように設計されたプロジェクトなら？モジュラーなモディリスで、すべてのチャネルをつなぐヒントがあるとか？うん、そしたら大きな生産性向上が得られるし、実際にどうやってLLMにプロジェクトを進めさせるかを考えるのに頭を使うことになるよ。おもちゃみたいな週末プロジェクトの範囲を超えて（100k-MM LOC）ね。でも、現実を見よう。ほとんどの社員は前者のようなコードベースで働いてる。俺もまだ後者をどうやってやるか学んでるところだ。1年前に始めてからかなり改善したけど、まだマスターとは言えないな。いろいろ試してみて、最終的に元に戻したり（ベストケースでは）マージ前に捨てたりすることが多いのは、特定のアーキテクチャで機能を修正・追加するのが大変だから。マジで、今は最先端だよ。まだまだ落ち着いてないし、業界がLLMを中心に正常化するには早すぎる。

この記事は、ここ数ヶ月の俺の経験とめっちゃ共鳴する。俺が関わってるプロジェクトは何年も着実に成長してるけど、担当してるエンジニアの数は変わらないか、ちょっと減ってる。ほとんどの機能は孤立してて、何かが起こるまで数ヶ月放置されてる。今のところ、テストに頼ることでスコープを広げることができた。そしたら、シミュレーターに対してだけ開発するように切り替えた。実際のシステムで変更を確認するのは珍しくなって、より手間がかかるようになった。確認しなきゃいけない時は、たいてい最も厄介な部分なんだ。去年、いくつかの機能について質問に答えられなくなってることに気づいた。数ヶ月間その機能に取り組んでPRをレビューしても、すぐに詳細を頭に入れておけないんだ。これは、エージェントがプロセスに深く入り込む前の話なんだけど。エージェントがいると、まさにこの記事が言ってることに気づいた。PRのレビューがさらに暗黙的になって、意識的に努力しないといけない。文脈の暗黙知がまだ形成されてないから、以前よりも多くレビューしなきゃいけない。情報が一耳に入ってもう一耳から出て行く感じ。チームメイトも似たような経験を報告してる。今、いろんなアプローチを試してるけど、まだ早すぎて結果は分からない。今は、エージェントの計画をコードと一緒にコミットして、開発中に得た洞察を失わないようにしてる。あいまいな要件のタスクは、以前は暗黙的に理解してたけど、今はボトルネックになってる。エージェントに計画のための要件を入力すると、バックログの整理中に思いつくようなさまざまな問題がすぐに浮かび上がる。スキルMDは、以前はあまり正式でない方法で分散して保持していた暗黙知のダンプみたいなもんだ。エージェントは、俺たちのプロセスを向上させることを強いてるし、実際の人間もそれから恩恵を受けてる。記事にもあったけど、ツールがその負担を軽減してくれるのを楽しみにしてる。もう一つ驚いたのは、俺のエンジニアマネージャーが、増大する認知負荷や混乱率についての俺の不満にまったく気づいていないようだったこと。まるでその概念が彼らにとって異質なもので、他の人が自分たちとは違うキャパシティでそれを処理していることを理解できないかのようだった。

解決策は皮肉なことに、LLMだよ。コードレビューを手伝ったり、コードを理解したりするためのClaudeスキルのセットを構築できる。理解の圧縮のこの複雑さは、今後大きな市場になるだろうね。

└

チャット履歴をLLMに見せると、面白いことがたくさんあるよ。