執筆者：DigKnow株式会社 CTO 桑原 脩

「それ、○○さんに聞いてみて」——チームの会話で、特定の名前が何度も出てくる瞬間があります。最初は頼もしさの証拠だと思っていましたが、同じ名前が二週間連続で別々のチャンネルに現れ始めたあたりから、少し違う感情が湧いてきます。これは強みなのか、それとも静かに積み上がっている脆さなのか。

　

属人化は個人ではなく構造の問題

属人化という言葉は、ネガティブな響きで語られることが多いと思います。「あの人が抱え込んでいる」「情報を出してくれない」——そういう非難のトーンで使われがちです。
でも、私が現場を見ていて思うのは、属人化のほとんどは意図して起きているのではなく、組織の構造が勝手にそちらに収束していくということです。誰かが悪意で情報を独占しているのではなく、放っておくと情報は特定の個人に集まるように「物理」が働いています。
前回の[エンジニアが退職するとき何が失われるか]で、退職時に本当に失われるのは「判断の経緯」だと書きました。この記事ではもう一歩踏み込んで、なぜ情報は特定の個人に集まるのか、そしてその集中がシステムをどうブラックボックス化していくのか、その力学そのものを解剖したいと思います。
結論から先に書いてしまえば、属人化は三つの力学——情報の偏在、質問の非対称性、信頼のショートカット——が噛み合って生まれる構造現象です。個人の善悪では動きません。そして、AIコーディングが加速する現代では、この三つの力学が全部悪い方向に増幅しています。

　

属人化を構造的に生み出す三つの力学

力学①：情報は最初に触れた人に偏在する
ソフトウェアプロジェクトにおいて、情報は最初から均等に分散しているわけではありません。システムをゼロから作った人、特定モジュールを最初に実装した人、顧客から直接要件を聞いた人——こういう「一次情報に接触した人」に、構造的に情報が集まります。
ここまでは当たり前の話です。問題は、そこから先に起きる非対称性の拡大にあります。
一次情報を持っている人Aが、後から入ってきた人Bに情報を伝える場面を考えてみます。このとき、Aは自身が知っていることの100%を伝えることはできません。なぜなら、Aにとって「当たり前すぎて言語化されない前提」が必ずあるからです。「これは常識でしょう」「これは普通そうするでしょう」——こうした暗黙の前提は、本人にとって空気のようなもので、意識的に取り出すことができません。
結果、AからBに伝わるのは、Aが持っている情報の一部でしかありません。体感的には「大事なところの多くは伝わっている」つもりでも、実際には当たり前すぎて省かれた前提が必ず欠けます。さらにBが次の人Cに伝えるときも同じ減衰が起きるので、Cに届くころには、Aの中にあった文脈のかなりの部分が途中で落ちていることになります。
一方で、A本人がコードに触り続ける限り、Aの情報は減りません。むしろ新しい変更を加えるたびに、Aだけが知っている文脈は増えていきます。周囲の人の情報量は減衰し、Aの情報量は増え続けていきます。この非対称性が、時間とともに複利で拡大していきます。
「あの人しか知らない」という状態は、Aが情報を独占しようとして生まれたのではありません。伝達における情報減衰と、当事者における情報蓄積の差分が、放置されるとこうなるだけなのです。

力学②：質問コストの非対称性
二つ目の力学は、質問する側とされる側のコスト構造です。
チームで何かを調べる場面を想像してみてください。選択肢は二つあります。
①コードやドキュメントを読んで自力で理解する方法
②詳しい人に聞く方法
②のほうが圧倒的に速く済みます。詳しい人に聞けば、数分で答えが返ってきます。①をやると、下手をすると半日かかります。だから、合理的なエンジニアほど「聞く」を選びます。
ここまでは自然な流れです。でも、この選択には副作用があります。聞いて解決したことは、聞いた本人の中にしか残らないということです。ドキュメントは更新されませんし、Slackでの一対一のやりとりはチャンネルの奥に沈んでいきます。チームの他のメンバーは、同じ疑問に遭遇したとき、また同じ人に聞きます。
質問される側——仮にAさんとしましょう——にも問題があります。Aさんは答えるたびに数分のコストを払っているだけで、「これはドキュメントに書いておこう」と思うインセンティブは弱いままです。一回数分の中断は、まとめて書き起こす作業より軽く感じるからです。ところが一週間に10回聞かれるようになると、Aさんの仕事時間は明らかに削られます。でも、そのときにはもう「書き起こす時間」自体が捻出できない状態になっています。
この構造を一言でまとめると、質問するコストは低いのに、質問されるコストは複利で溜まっていく——という非対称性になります。個々の取引は「聞いた方が早い」で合理的なのに、全体としては明らかに非効率な状態が生成されてしまうのです。

力学③：信頼のショートカットが根拠を消す
三つ目の力学が、たぶん一番見えにくいものです。意思決定における「信頼のショートカット」の問題です。
チームである程度の時間が経つと、「この領域のことはAさんが一番詳しい」という共通認識が暗黙に形成されます。そうなると、議論の中で「Aさんがそう言っているなら、そうなんだろう」という判断が増えていきます。これは必ずしも悪いことではありません。全員が全領域を深く調べることは不可能ですし、信頼できる専門家を信頼するのは合理的な分業です。
問題は、この信頼のショートカットが積み重なると、Aさんの判断の根拠そのものがレビューされなくなるということです。Aさんが「これは同期的にやるべき」と言ったら、そのまま決まります。なぜ同期的なのかの理由は深掘りされません。
そして数年後、その判断の理由は誰にも——Aさん本人にさえ——思い出せなくなります。コードには結果だけが残り、根拠は人間の記憶の曖昧さとともに消えていきます。
この現象の厄介なところは、信頼されている人ほどブラックボックスを作りやすいという逆説です。信頼されているから根拠を問われず、問われないから言語化されず、そのロジックはAさんの頭の中にしか存在しない状態で固着していきます。
組織のコア人材ほど、構造的にブラックボックスの供給源になりやすい——これが冷静に観察すると見える現実で、「属人化はサボっている人が作る」という素朴な感覚とは真逆のことが起きています。

　

AIコーディング時代に三つの力学が一斉に悪化する

ここまで書いた三つの力学は、AI以前からある古典的な組織問題です。でも、AIコーディングが普及した現場では、三つともが悪い方向に増幅されています。

情報減衰の加速：Claude CodeやCursorとの対話の中で生まれた判断は、本人の頭にすら明示的な形で残らないことが多くあります。「AさんがAIと会話しながら決めた」ものを、Aさんが後からBさんに説明しようとしても、もはや減衰どころか情報の発生源そのものが曖昧になっています。[コード残るが、使用は誰も知らない]で書いた「書いた本人にも文脈がない」という状態は、力学①をより深刻にしています。

質問コスト非対称性の歪み：以前なら「Aさんに聞けば答えてくれる」で済んでいたのが、「Aさんに聞いても『AIがそう書いたから』と返ってくる」状況が発生します。結局、質問する側は答えを得られないまま、どこにも書かれていない文脈を探して彷徨うことになります。一方、Aさんの負荷が下がるわけではありません。聞かれる頻度は変わらないのに、答えの質が下がる、という最悪の組み合わせが起きています。

信頼ショートカットの変質：チームの中に「Aさんが詳しい」という認識は残っているけれど、Aさん自身の詳しさの総量は、実は以前より減っているかもしれません。にもかかわらず、信頼は過去の実績に基づいて維持され続けます。つまり、実態より大きな信頼残高が、組織のリスクを見えにくくしたまま維持されてしまうのです。

三つの力学が揃って悪化しているのに、表面上は何も起きていないように見える——これが、AIコーディング時代の属人化の不気味さです。

　

バス係数が突きつける組織の脆さ

ソフトウェア開発の世界には「バス係数（Bus factor）」という言葉があります。「何人がバスに轢かれたら、このプロジェクトは止まるか」を表す指標です。バス係数が1なら、一人辞めるだけで詰みます。3や4なら、ある程度の冗長性があるということです。

多くのチームは、自チームのバス係数を真面目に見積もっていないのではないでしょうか。だいたい「まあ大丈夫だろう」で済ませてしまっています。でも本気で一つずつ領域を棚卸ししてみると、「この領域を深く理解しているのは一人だけ」という場所が、想像以上に多いことに気づきます——というのは、マネージャー経験のある方なら覚えがあるのではないかと思います。

バス係数が低い領域は、組織の中で静かに広がっていきます。採用で人が入っても、新しい領域を新しい人が任されるので、既存の属人領域はそのまま残ります。むしろ「あの人に任せておけば安心だから」という理由で、さらに情報が集中していくことすらあります。

AIコーディングが実装スピードを上げた今、コードの増加速度に対して、バス係数が上がる速度が圧倒的に遅い——これが、属人化がじわじわ進行している正体だと私は考えています。

　

解消ではなく圧力を下げるという発想

ここまで読んで、「では属人化をなくせばいいのか」と思った方もいるかもしれません。残念ながら、属人化をゼロにすることは現実的には不可能です。一次情報に最初に触れた人にはどうしても情報が集まりますし、全員が全領域を同じ深さで理解することはできません。

私が現場を見ていて思うのは、目標にすべきは「属人化の解消」ではなく、「属人化の圧力を下げる」だということです。情報が一人に溜まっていく流れを完全に止めることはできませんが、溜まったものが共有される仕組みは作れます。質問コストの非対称性を少しでも均すことはできますし、信頼のショートカットに根拠のログを残すクセをつけることもできます。

具体的な運用の打ち手や、この問題の本質的な解決方向については、今後改めて掘り下げていきます。

まずこの記事で伝えたかったのは、属人化が個人の善悪ではなく組織の構造的問題として起きているということです。「Aさんが抱え込んでいる」という見方をしている限り、たぶん何も解決しません。Aさんに情報が集まるようにチームの構造が設計されてしまっている——この視点に立つと、初めて打ち手の方向が見えてくるのだと思います。

　

まとめ

属人化は個人の問題ではなく、三つの構造的な力学——情報減衰の非対称性、質問コストの非対称性、信頼のショートカット——が噛み合って起きる組織現象です。AIコーディング時代にはこの三つがすべて悪化し、しかも表面上は何も起きていないように見えるため、問題の進行が気づかれにくくなっています。バス係数という残酷な指標で棚卸ししてみると、多くのチームが思っている以上に脆い構造になっているはずです。目指すべきは属人化の解消ではなく、圧力を下げることだと私は考えています。

　

あなたのチームで、明日あなたが突然いなくなったとして、あなたしか答えられない質問はいくつありますか？そしてその質問を次に受け取るのは、誰でしょうか。

次回は、その質問を受け取る側——新人エンジニアがチームに入った初日の視界を、新人側の視点から描きます。彼らが目の前にしているのは、先輩たちの頭の中にしか存在しない地図なのだという視点から、属人化の影響をもう一度別の角度で照らし直してみたいと思います。

• « エンジニアが退職するとき、何が本当に失われるのか——引き継げない「文脈」の正体