同じ手順書を渡したはずなのに、部下ごとに優先度も進捗もバラバラになる瞬間がある。あなたが疑うべきは、部下の理解力ではない。
何が起きているか、優秀な部下ほど足並みが揃わなくなる#
私が観察してきた現場でも、同じ構造は繰り返されている。優秀な部下を集めたチームほど、進捗報告の場で「え、そこ実装するんでしたっけ」という一言が出る。
能力の差ではない。全員が同じ会議に出て、同じ言葉を使って、同じ資料を見ている。それでも頭の中に描いている絵は、一人ひとり微妙に違う。これはAIによる認識負荷の増大とも無関係ではない。
Zennの記事「優秀な人ばかりなのに、組織が重い」(株式会社カンリー、2026年7月1日公開)は、この状態を「認識負債」と名付けている。
同じMTGに出て、同じ言葉を使って、同じ資料を見て、全員うなずいている。なのに、頭の中で描いている絵が、実は一人ひとり微妙に違う
技術負債と違い、この負債は指摘しづらい。誰も間違ったことは言っていないし、誰も手を抜いていない。だから会議の空気だけが重くなる。課長は部下の心理状態を丹念に観察する必要があるが、この非言語的なズレは検知が難しい。
なぜ起きるか、AIの実装速度が認識ズレを複利にする#
認識負債そのものは、AI以前から存在した。だが実装が速くなるほど、この負債が積み上がる速度も比例して上がる。
記事が指摘する構造はこうだ。1回目の会議で生まれた小さなズレが、2回目の会議の前提になる。3回目の会議では、参加者それぞれが「2回目までに揃ったはず」という思い込みのまま、別の方向に走り出す。ズレはズレの上に積まれ、利子を生む。
AIによる実装は、この3回目に到達するまでの時間を極端に縮めた。手順書からコードや資料までが、検証を挟む間もなく数時間で形になる。ズレは議論の途中で止まらず、成果物という完成形で固定されてしまう。
部下の手が速いほど、課長が異変に気づいた時点で、すでに数周分のズレが積み重なっている。優秀な人ばかりなのに組織が重い、という現象の正体はここにある。
どうハックするか、問いの設計でズレを早期検知する#
認識負債は、実装を止めて解消するものではない。速度を落とさずにズレを検知する「問い」を差し込む方が、課長の燃料は残る。このアプローチは、AI時代の判断設計の本質と合致している。
- 着手前に「なぜこれを作るか」を一行で書かせる: 手順書を渡すだけでなく、部下自身に目的を一文で言語化させる。この一文がズレていれば、実装に入る前に気づける
- 会議の冒頭で「今日、前提が違うと感じた点」を一つ挙げさせる: 進捗報告より先にこの問いを置く。申告に評価は付けない。申告しやすさが検知の速さを決める
- レビュー基準に「速さ」ではなく「一致度」を混ぜる: 早く仕上がったかではなく、目的と実装がどれだけ一致しているかを見る。確認・報告の場でこの一致度を定期的に砂丘にすることで、ズレの早期発見に繋がる
この3つは、成果物のスピードを落とす仕組みではない。ズレを1回目・2回目の段階で見つけるための、小さな検問だ。
逃げの一手#
この問いを差し込んでも認識がまとまらないなら、そもそも手順書自体が「何を・なぜ」を書けていない可能性がある。まず手順書の解像度を疑う。
それでも改善しないなら、無理に全員の認識を揃えようとしなくていい。ズレたまま進めていい範囲と、揃うまで止める範囲を線引きすれば、負債は管理できる額に収まる。全員を毎回揃える必要はない。
認識負債には利子が付く。放置した分だけ、次の会議の手戻りが増える。
関連:
- 役員説明で3回手戻りされる課長が、問いの設計で決定を引き出す方法
- 1on1で部下が黙るたびに消耗する管理職が、問いの設計で沈黙を解体する手順
- 課長が手放すのはコードで、AIへの仕様書きという新しい居場所に移る
本記事は AI が下書きし、管理人が監修しています。
