属人化がシステムをブラックボックス化するまで
2026.06.02執筆者：DigKnow株式会社 CTO 桑原 脩
「それ、○○さんに聞いてみて」——チームの会話で、特定の名前が何度も出てくる瞬間があります。最初は頼もしさの証拠だと思っていたのですが、同じ名前が二週間続けて別々のチャンネルに現れ始めると、別の感情が湧いてきます。これは強みなのか、それとも静かに積み上がっている脆さなのか、と。
属人化は個人ではなく構造の問題
属人化という言葉は、「あの人が抱え込んでいる」という非難のトーンで語られがちです。でも、私が現場を見ていて思うのは、属人化のほとんどは意図ではなく、組織の構造が勝手にそちらに収束していくことで起きているということです。
結論から書いてしまうと、属人化は三つの力学——情報の偏在、質問コストの非対称性、信頼のショートカット——が噛み合って生まれる構造現象です。個人の善悪では動きません。そして、AIコーディングが普及した現代では、この三つが揃って悪化しています。
属人化を構造的に生み出す三つの力学
力学①：情報は最初に触れた人に偏在する
ソフトウェアプロジェクトでは、情報は一次情報に最初に接触した人に集まります。問題は、そこから先に起きる非対称性です。
A本人にとって「当たり前すぎて言語化されない前提」は、伝達のたびに必ず欠けます。AからB、BからCへと伝わるたびに、文脈は静かに減衰していきます。一方で、Aがコードに触り続ける限り、Aの情報は減らず、むしろ増え続けます。周囲の情報量は減衰し、Aの情報量は蓄積していく——この差分が、時間とともに複利で拡大していくのです。
「あの人しか知らない」という状態は、Aが独占しようとした結果ではありません。伝達における情報減衰と、当事者における情報蓄積の差分が放置されると、そうなるだけなのです。
力学②：質問コストの非対称性
何かを調べるとき、選択肢は二つあります。
①コードやドキュメントを読んで自力で理解する方法
②詳しい人に聞く方法
②のほうが圧倒的に速く済みます。だから合理的なエンジニアほど「聞く」を選びます。
でも、聞いて解決したことは、聞いた本人の中にしか残りません。ドキュメントは更新されず、Slackのやりとりはチャンネルの奥に沈んでいきます。他のメンバーは、同じ疑問に遭遇したとき、また同じ人に聞きます。
質問される側——仮にAさんとしましょう——は、答えるたびに数分のコストを払っているだけなので、「ドキュメントに書いておこう」というインセンティブが弱いままです。ところが一週間に10回聞かれる頃には、Aさんの仕事時間は明らかに削られています。そのときにはもう、書き起こす時間そのものが捻出できない状態になっています。
質問するコストは低いのに、質問されるコストは複利で溜まっていく——この非対称性が、各人の合理的な行動の積み重ねによって、組織全体としては最悪に近い均衡を生んでしまうのです。
力学③：信頼のショートカットが根拠を消す
チームである程度の時間が経つと、「この領域はAさんが一番詳しい」という共通認識が暗黙に形成されます。そうなると「Aさんがそう言っているなら、そうなんだろう」で議論が決着するようになります。
問題は、この信頼のショートカットが積み重なると、Aさんの判断の根拠そのものがレビューされなくなることです。信頼されているから根拠を問われず、問われないから言語化もされません。数年後、その判断の理由は誰にも——Aさん本人にさえ——思い出せなくなります。
信頼されている人ほどブラックボックスを作りやすいという逆説。組織のコア人材ほど、構造的にブラックボックスの供給源になりやすい——これは、「属人化はサボっている人が作る」という素朴な感覚とは真逆の現実です。
AIコーディング時代に三つの力学が一斉に悪化する
ここまで書いた三つの力学は、AI以前からある古典的な組織問題でが、AIコーディングが普及した現場では、三つともが悪い方向に増幅されています。
情報減衰の加速：Claude CodeやCursorとの対話の中で生まれた判断は、本人の頭にすら明示的な形で残らないことが多くあります。「AIと会話しながら決めた」ものを後から説明しようとしても、もはや情報の発生源そのものが曖昧になっています。
質問コスト非対称性の歪み：以前なら「Aさんに聞けば答えてくれる」で済んだのが、「Aさんに聞いても『AIがそう書いたから』と返ってくる」状況が発生します。聞く側は答えを得られず、聞かれる側の負荷も下がりません。最悪の組み合わせです。
信頼ショートカットの変質：Aさん自身の詳しさの総量は、実は以前より減っているかもしれません。にもかかわらず、信頼は過去の実績で維持され続けます。実態より大きな信頼残高が、組織のリスクを見えにくくしたまま残ってしまうのです。
三つの力学が揃って悪化しているのに、表面上は何も起きていないように見える——これが、AIコーディング時代の属人化の不気味さです。
バス係数が突きつける組織の脆さ
ソフトウェア開発の世界には「バス係数（Bus factor）」という言葉があります。「何人がバスに轢かれたら、このプロジェクトが止まるか」を表す指標で、1なら一人辞めるだけで詰みます。
多くのチームは、自チームのバス係数を真面目に見積もっていないのではないでしょうか。本気で領域を棚卸ししてみると、「深く理解しているのは一人だけ」という場所が想像以上に多いことに気づきます——マネージャー経験のある方なら覚えがあると思います。
AIコーディングが実装スピードを上げた今、コードの増加速度に対して、バス係数が上がる速度が圧倒的に遅い——これが、属人化がじわじわ進行している正体だと私は考えています。
解消ではなく圧力を下げるという発想
属人化をゼロにすることは、現実的には不可能です。一次情報に触れた人に情報が集まるのは避けられませんし、全員が全領域を同じ深さで理解することもできません。
目標にすべきは「属人化の解消」ではなく、「属人化の圧力を下げる」ことだと私は思います。情報が一人に溜まる流れを完全には止められませんが、溜まったものが共有される仕組みは作れます。質問コストの非対称性を少しでも均し、信頼のショートカットに根拠のログを残すクセをつける——できることはあります。
具体的な打ち手やこの問題の本質的な解決方向については、今後の記事で改めて掘り下げていきます。まずこの記事で伝えたかったのは、属人化が個人の善悪ではなく組織の構造として起きているということです。「Aさんが抱え込んでいる」という見方をしている限り、たぶん何も解決しません。
まとめ
属人化は個人の問題ではなく、情報減衰の非対称性・質問コストの非対称性・信頼のショートカットという三つの構造的な力学が噛み合って起きる組織現象です。AIコーディング時代にはこの三つがすべて悪化し、しかも表面上は何も起きていないように見えるため、進行が気づかれにくくなっています。バス係数で棚卸ししてみると、多くのチームが思っている以上に脆い構造になっているはずです。目指すべきは属人化の解消ではなく、圧力を下げることだと私は考えています。
あなたのチームで、明日あなたが突然いなくなったとして、あなたしか答えられない質問はいくつありますか？そしてその質問を次に受け取るのは、誰でしょうか。
次回は、その質問を受け取る側——新人エンジニアがチームに入った初日の視界を、新人側の視点から描きたいと思います。