こんにちは、株式会社カンリーの波多野（@hatamasa1988）です。

同じ言葉を使っているのに、話が通じない。

最近、技術負債よりも厄介だと感じている負債の話をします。それが今回書く「認識負債」です。

私はカンリー店舗集客プロダクトのエンジニアリングマネージャー（EM）をしています。前回は「AI時代のEMの仕事は、組織のハーネスエンジニアリングである」という記事を書いたんですが、今回はその裏側でずっと感じていたモヤモヤを、ひとつの言葉にしてみます。

前回の記事はこちら。
https://zenn.dev/canly/articles/fbf3a3277ad5a5

ざっくり先にひとことで整理しておくと、認識負債は、

• 理解負債・認知負債：コードと、個人の頭の中の話
• 認識負債：組織と、方向性の話

という、AI時代に語られている既存の負債とは一段違うレイヤーの話だと思っています。

現時点での自分なりの整理ですが、いまのフェーズで感じていることをアウトプットします。

前提として、自分のエンジニア&マネージャー人生の中から起きた出来事を振り返り言語化しているので、ここに記載できない話もあるのはご了承くださいませ。。。

技術負債は、見える

先に技術負債のほうを整理しますと、
技術負債って、厄介ではあるのですが、可視化されて共通認識を得られる箇所が開発フローでいくつかあります。

• コードに現れる
• レビューで気づける
• CIで検知できる
• 複雑度やカバレッジでメトリクス化できる
• ADR等で負債を受け入れる判断をする事がある

少なくとも、存在を観測する手段がある。「ここ、やばいよね」という会話が成立する。リファクタしようとか、いつか返そうとか、チケットに積むこともできます。

つまり技術負債は、向き合おうと思えば向き合える相手で厄介ですが、輪郭があります。

問題は、観測しづらい方の負債です。

認識負債は、見えない

認識負債とは、ひとことで言うと、

組織の「なぜ・何を・どこへ」がズレたまま積み上がった状態のこと。

もう少し丁寧に言うと、「なぜやるのか」「何を成功とするのか」「どこへ向かうのか」という方向性についての認識のズレが、複利で増えていく負債です。

自分が現場で感じているものに名前をつけてみた、くらいの温度感で読んでもらえると嬉しいです。

技術負債と決定的に違うのは、認識負債は見えないことです。

• 見えない
• 指摘しづらい
• そもそも気づきにくい
• だから放置されやすい

最初は、本当に小さなズレだったりします。同じMTGに出て、同じ言葉を使って、同じ資料を見て、全員うなずいている。なのに、頭の中で描いている絵が、実は一人ひとり微妙に違う。

その時点では問題にならないので指摘されません。そのまま放置され、後から大きなズレとして表面化します。

しかも、認識負債は「複利で膨らむ」性質を持っています。前のズレが次の議論の土台になり、その土台の上でさらに新しいズレが生まれる。3回目のMTGでは、参加者それぞれが「2回目までに揃ったはず」の前提でさらに違う方向に話を進めている、ということが起きます。最初の小さなボタンの掛け違いが、議論を重ねるたびにズレ幅を広げていく構造です。

イメージで言うと、

全員が同じ地図を見ているはずなのに、気がつくと違う場所に向かっている。

これが認識負債が溜まった組織の景色です。

なぜ見えないのか、自分なりに整理してみました。

技術負債は、「変化量（フロー）」として現れます。コードが変更されたり、レビューが入ったり、CIが走ったりするタイミング、つまり何かが動いた瞬間に、開発フローの観測装置が反応する仕組みです。

一方で認識負債は、「維持された状態（ストック）のズレ」です。新しく何かが起きるから生じる差分ではなく、組織の中に静かに維持され続けるズレ。観測装置が反応する「変化」ではない、ということです。

つまり、

動いていないものは見えない。

これが、認識負債が観測装置に引っかからない構造的な理由だと思っています。

認識負債が生むコスト

認識負債が溜まってくると、組織はこういう状態になります。心当たりがないか、ちょっと自分の組織を思い浮かべながら読んでみてください。

• 議論が、なぜか噛み合わない
• 会議がやたら長くなる
• 全員うなずいたはずなのに、次の週バラバラに動いている
• 議事録は完璧なのに、何も進んでいない
• 優先順位がチームごとに揃わない
• それぞれ良かれと思って動いているのに、局所最適があちこちで始まる

そして極めつけがこれです。

『同じ言葉を使っているのに、話が通じない。』

ひとつでも心当たりがあったら、けっこう認識負債、溜まっているかもしれません。

個人的には、技術負債より厄介だと感じています。一人ひとりは優秀で、サボっているわけでもない。むしろ全力で前に進もうとしている。なのに、組織としての推進力がなぜか出ない。

技術負債なら、CIが赤くなったりレビューで指摘が飛んだりして、わりと早い段階で「やばい」に気づけます。でも認識負債は、発見がとにかく遅い。気づいたときには、もうけっこう広い範囲に影響が出ています。

つまり、

コードのバグより、組織のバグの方がタチが悪い。

これが認識負債の本質だと感じています。

過去に経験した、認識負債のリアル

以前関わっていたプロジェクトでは、こんなことがありました。

いち早くリリースしたい重要な機能を、数人のエンジニアで開発していました。エンジニアそれぞれ、QCD（Quality（品質）、Cost（コスト）、Delivery（納期））の認識が揃わないまま走っていて、ある人は「納期最優先。納期のためなら品質を犠牲にしてもいい」と考え、別の人は「納期は重要だが、守らないといけない品質がある」と考えており、設計やレビューのたびに、意見が衝突していました。

対立は長引きました。最終的には、PdMやCTOまで巻き込んで、プロジェクトの前提から会社に与える影響まで認識を合わせる長時間の会を設けることに。そのあとプロジェクトのインセプションデッキを作り、コミュニケーションのグランドルールも整えて、ようやく対立がおさまった、という流れです。

ただ、対立を解消するまでに数週間かかり、その間、本来開発に充てられたはずの時間はごっそり溶けました。1on1や各種会議に関わった人を含めれば、組織として相当の工数が消えています。

同じような状況を経験したことがある方なら、想像できるんじゃないかと思います。

いま振り返ると、これも典型的な認識負債でした。コードがどうこうではなく、「このプロジェクトで何をどれくらい最優先するのか」という一段手前の認識がズレたまま、全員が全力で走っていた状態でした。

そして、これはカンリーや特定の会社の話ではありません。スタートアップでもエンタープライズでも、AI時代に動いている組織なら必ずどこかで起きていると感じています。

AI時代は、認識負債を増幅する

ここで前回の記事ともつながる話をします。

前回、AI時代に起きているのは単なる開発速度の向上ではなく、ボトルネック移動速度と負債蓄積速度の高速化だ、という話を書きました。作れることが増えたぶん、設計のズレや責務の崩れが、以前より速く広がるようになったという話です。

認識負債も、まったく同じことが起きていると感じています。

AIによって速くなっているのは、開発速度や問題解決速度だけじゃありません。意思決定の回数も増えるし、判断のサイクルも速くなる。一日に下せる判断の量が、明らかに増えています。

AIで実装速度が上がると、認識のズレが成果物として積み上がるスピードも上がります。昔なら実装が追いつかない間に気づけたズレが、そのまま大量の成果物になって表れてくる。

つまり、

認識がズレたまま全力で走れてしまう

ということでもあります。認識がズレていることを認知する機会が少ないため、気づくのが遅れる。これが、AI時代に認識負債の影響範囲が一気に広がる構造です。

そして、これは現場の話だけでは済みません。判断のサイクルが速くなるということは、経営判断のスピードにも直結します。組織の認識がズレたまま速く走れる時代は、経営として見たときの組織コストとして可視化されない最大の損失が、ここに溜まっていく時代でもあります。

個人的には、AI時代の組織運営でいちばん先に手を打つべきテーマだと考えています。

顧客移行フェーズで、認識負債を感じた話

ここから、いまの自分たちの具体的な話です。

カンリー店舗集客は、フルリニューアルのカットオーバーを終えて、既存顧客の移行フェーズに入っています。新機能をどんどん出すフェーズではなく、一社ずつ着実に移行を完遂しにいく、という地味に重たい時期です。

この「移行」というテーマに対して、人によって見え方がけっこう違っていました。

• ある人にとっては、移行は「作業」
• ある人にとっては、技術的な「後片付け」
• ある人にとっては、顧客への「価値実現」
• ある人にとっては、次の成長への「投資」

どれも間違っていません。むしろ全部正しい。ただ、ここの認識が揃っていないと、同じ「移行」という言葉を使いながら、温度感も優先順位もバラバラになっていきます。

前提として顧客と合意形成をした上で顧客ごとに移行作業をしています。また初期の移行作業は、店舗ごとに目視で旧→新へのデータマイグレーションを確認し、間違いがあれば手入力するという作業があり、ここのスループットが最大のボトルネックとなっていました。

その上で、移行作業では下記のようなことが発生していました。

• 一人が出せる移行作業のスループットを他の人が出せなく、その原因がわからない
• 一人一人の優先度が異なっていて、移行作業の進捗が異なる
• 一人一人が思っている原因が散らばり、根本原因の特定に時間がかかる

これはまさに認識負債だなと感じた瞬間でした。作業フローや使っている手順書やスクリプトは同じでも、目線や定義がずれていて作業進捗が出ない状況になっていました。

この時は下記の対策を行いました。

• 合宿での移行の目的と事業への影響や重要度のinput（次章の合宿）
• 移行作業のグランドルール整備
• コミュニケーションフローの確立

また、仕組みの面では属人化を防ぐために作業の大部分を管理画面化し、データマイグレーションの確認部分にはClaude Code Skillsで標準化することで、スループットは初期の6倍まで加速させることができました。

ここで強調したいのは、仕組み改善が効いた、そもそもその動きがとれたのは、その前に合宿で認識が揃っていたから、という順番です。

合宿前は、同じ手順書・同じスクリプトを使っていても、人によって使い方や優先度の置き方にブレがありました。移行の重要度の目線が揃っていなかったので、仕組み化を進めて移行を完遂せねば、というモメンタムが生まれていなかったです。

合宿で「顧客移行は、顧客にとって本当の意味でのリニューアルのリリースだ」と再定義された後は、仕組み化の意思決定もチームで自律的に一気に行い、管理画面化もClaude Code Skillsによる標準化も短期間で実装が進みました。全員が同じ目的を持って活用したので、使い方のブレが消え、スピーディーに仕組み改善ができた形です。

つまり、仕組み改善が6倍を生んだのではなく、認識合わせが「仕組み改善が効くチームの状態」を作り、その結果として6倍が出たというのが正直な順序です。

「我々はなぜここにいるのか」

前回も少し触れましたが、カンリー店舗集客では四半期ごとにオンサイト合宿をやっています。

最初の合宿のテーマは「我々はなぜここにいるのか」でした。

合宿は判断基準を細かく作るための場ではなく、方向性を揃えるための場としています。いまの言い方をすると、認識負債を返済するための時間 として企画しています。

直近の合宿では、CPOによるトークセッションも実施しました。そこで共有してもらったのは、

• なぜ移行の完遂が重要なのか
• そもそもリニューアルにどんな意義があったのか
• 移行を終えた先に、どんな未来が待っているのか
• 顧客と事業にとって、これがどういう価値になるのか

といった、「何をやるか」より一段手前の話です。

このCPOセッションのあと、合宿の中でメンバー自身が、顧客移行を「顧客にとって本当の意味でのリニューアルのリリースだ」と価値を再定義してくれました。こちらが定義を配ったわけじゃなくて、認識が揃った結果、自分たちの言葉で意味づけし直してくれた。

認識が揃うと、ここまで意味づけが変わるのかと感じた瞬間でした。

OKRも、認識負債を返済する仕組み

もうひとつ、認識負債の返済装置として効いているのがOKRです。

以前、OKRを本来の形に近づけて再定義したという記事を書きました。

https://zenn.dev/canly/articles/31d3cae0bf5755

このとき自分の中では、OKRを単なる目標管理ツールとして捉えていませんでした。むしろ、

• 組織としていまどこへ向かうのか
• いま何を重要視するのか
• 何に集中するのか

を継続的に同期するためのフレーム、つまり方向性同期の仕組みとして捉え直しています。

いま振り返ると、これも認識負債を返済し続けるための装置だったんだな、と腑に落ちる感覚があります。合宿が四半期に一度の「向き直し」だとすれば、OKRはもう少し短いサイクルで認識を揃え続けるためのもの。役割が違うだけで、やっていることの本質は同じだと思っています。

そしてここで前回の記事ともつながります。前回書いた「組織のハーネス」というのは、つまるところ、認識負債を返済し続けるための装置一式だったんだなと、いま整理し直しています。OKR・合宿・1on1・定例といったハーネスを束ねている目的が、認識負債の返済だったわけです。

認識負債は、返済し続けるしかない

技術負債には、リファクタリングやリプレイスという「返し方」があります。一度きれいにすれば、その部分はしばらく安定する。完済に近い状態を作ることもできます。

でも認識負債は、たぶん違います。

人が入れ替わり、フェーズが変わり、優先順位が動き、AIで判断の量が増えていく。そのたびに、認識のズレは新しく生まれます。一度揃えたから終わり、にはならない。放っておけば、必ずまた溜まっていく。

だから認識負債は、

完済するものではなく、返済し続けるもの

なんだと思っています。

そのための場が、カンリー店舗集客でいうと、

• 四半期ごとの合宿
• CPOセッション
• OKR
• 1on1
• チームの定例

このあたりです。どれも派手な施策ではないし、「やってる感」だけのイベントにすると一瞬で形骸化します。でも、ここを地道に回し続けることが、自律自走する組織を支えているんだろうな、と感じています。

明日からできる『認識負債チェック』

ここまで読んで、「うちの組織、認識負債が溜まっているかも」と思った方向けに、自分が普段ざっくり使っている3つのチェックを置いておきます。明日のチームMTGや1on1で試してみてください。

本文でも繰り返し言及している「なぜやるのか・何を成功とするのか・どこへ向かうのか」の3要素を、そのままチェック軸にしています。

チェック1: Why（なぜやるのか）が揃っているか

いまのプロジェクト・移行・OKRについて、「なぜこれをやるのか」をメンバー全員に1分で説明してもらう。全員の言葉に共通点が見えれば揃っている。バラバラだったり、「やれと言われたから」が混じっていたら、Whyの認識負債が溜まっています。

チェック2: What（何を成功とするか）が揃っているか

「このプロジェクトが終わったとき、何が起きていれば成功か」をメンバー各自に書いてもらう。成功基準が揃っていれば、ゴールが共有できている。人によって「リリースすれば成功」「顧客が使い始めて成功」「数字が出て成功」のようにバラバラなら、Whatの認識負債が溜まっています。

チェック3: How（進め方の優先順位）が揃っているか

直近1〜2週間で「議論が噛み合わなかった瞬間」「優先度の判断が分かれた瞬間」がなかったか振り返る。噛み合わなかったとき、多くは「進め方の優先順位」や「いまどこに集中すべきか」の認識がズレています。Howの認識負債が溜まっているサインです。

3つともシンプルですが、地味に効きます。
これらがずれている場合、まずはインセプションデッキをチームで見直し、対話をすることで認識負債の返済を図りましょう。

おわりに

技術負債はコードに現れます。
認識負債は、組織に現れます。

そして組織の負債は、ときとしてコードの負債より高くつくことがある、というのが、いまの自分のいちばんの実感です。

しかもAI時代は、開発速度だけじゃなく、認識負債が顕在化する速度まで上げてきます。速く作れるようになったぶん、「なぜやるのか」「何を成功とするのか」「どこへ向かうのか」がズレていることのコストが、これまでより容赦なく跳ね返ってきます。

だからこそ、合宿やCPOセッションやOKRを通じて、認識負債を返し続ける。AI時代の組織運営では、こうした認識負債への継続的な対処がますます重要になると考えています。

エンジニアリングマネージャーに限らず、AI時代のマネージャーの役割の大部分が、認識負債の返済になると思っています。そして、もう一段引いた言い方をすると、

AI時代に組織として勝てるかは、認識負債をどう扱えるかで決まる。

これが、いまの自分のいちばん強い仮説です。

みなさんのチームには、認識負債、溜まっていませんか?
「うちはこういう場で返済している」みたいな話があれば、ぜひXあたりで教えてください。この手の話、めちゃくちゃ好きなので、EM・テックリード・スタートアップのエンジニアの方とゆるく雑談できたら嬉しいです。

カンリーの開発組織に興味を持っていただいた方は、採用ページもチラッと覗いていただけると嬉しいです。

ではでは、またよろしくお願いします!