属人化という麻薬――「自分にしかできない」という幻想が組織を蝕む理由
「この機能の改修、誰が拾う？」 「あ、そこは〇〇さんしか分からない領域だから、〇〇さんにお願いしよう」
スプリントプランニングや日々のスタンドアップで、誰もが一度は耳にしたことがある会話ではないでしょうか。
短期的には「一番詳しい人がやるのが最速」という判断は合理的に見えます。しかし、これを繰り返した果てにあるのは、特定エンジニアへの極端な負荷集中、心理的ボックスタワー、そしてチーム全体の開発速度の不可逆な低下です。
「属人化は避けるべきだ」なんて、どの教科書にも書いてあります。テストやリリースの自動化を進め、柔軟なアジャイル開発を取り入れ、最新の技術や設計を揃えているチームであっても、現場の運用レベルではなぜか属人化で乗り切ろうとしてしまう。
なぜ私たちは、この分かりきった罠に自ら落ちていくのでしょうか。
「自分にしかできない」という固執の正体
属人化が起きる大きな要因の一つは、エンジニア個人の心理的な防衛本能です。
「自分にしかできない」という考えは、自分の価値はそこにあるという固執
厳しい言い方かもしれませんが、まさにこの通りなんです。
複雑怪奇なレガシーコード、自分しか知らない外部連携の仕様、ドキュメント化されていないデプロイ手順。これらをブラックボックスとして抱え込むことで、「このシステムには自分が必要だ」「自分がいなければプロジェクトが止まる」という歪んだ承認欲求を手に入れようとしてしまうわけです。
ですが、特定のコードや業務を抱え込むことは、専門性の証明ではありません。ただの「情報の囲い込み」であり、エンジニアとしての停滞です。
本当に価値のあるエンジニアは、「誰にでも触れる状態を作った上で、次の新しい価値創出やアーキテクチャの改善に向かう人」のはずです。既存の仕様を独占して居場所を確保しようとするスタンスは、個人のキャリアにとっても明確なアンチパターンと言えます。
「あの人にしかできない」は、ただの思い込みと共有化の怠慢である
一方で、この問題をエンジニア個人のマインドセットだけに帰結させるのも筋違いです。それを受け入れているチームやマネジメント層にも大きな責任があります。
ここで混同してはならないのが、「〇〇さんにしかできない」と「〇〇さんが一番うまく（速く）できる」は全くの別物だということです。
特定のドメインに長く携わってきたメンバーが、最も高い品質で最速でコードを書けるのは至極当然の話です。それは単なるこれまでの経験値やコンテキストの蓄積に過ぎず、決して「他の人には不可能な領域」ではありません。しかし、現場ではいつの間にか「一番うまくできる」という事実が「その人にしかできない」という不可侵の前提へとすり替わってしまいます。
「この人にしかできないという」のは思い込みと共有化の怠慢
「あの人にしかできない」と口にして思考停止するのは、まさに共有化を放棄した側の甘えなんですよね。
もちろん、「今はリリースが迫っていて納期が非常に厳しいから、一番速い人に任せよう」という判断そのものを否定するつもりはありません。厳しい納期という明確な前提条件があるなら、それは現場を預かるマネージャーとして極めて合理的であり、ビジネスを守るために取るべき当然の手段です。
本当に問題視すべきなのは、この緊急避難的なカードを「定常化」させてしまうことです。
火事が収まった後も振り返りをせず、「次もまた速い人に頼めばいいや」と惰性で回し続ける。その結果、エース級エンジニアは常にボトルネックとなって疲弊し、他のメンバーはいつまで経ってもキャッチアップの機会を奪われます。非常時のトレードオフを平時の運用に持ち込み、共有化への投資を後回しにし続けることこそが、組織を蝕む本当の怠慢なのです。
人間をSPOF（単一障害点）にする組織設計の破綻
システムアーキテクチャを設計する際、サーバーやデータベースの冗長化には心血を注ぐエンジニアが、なぜか組織の冗長性には無頓着になりがちです。
仕事としてやっている以上、誰かが辞めてしまうこともあるし、病気で休むこともあるので、ある程度、複数の人が当たらる状況を作るのが理想
プロとしてソフトウェアを開発・運用している以上、メンバーの離脱リスクを考慮しない設計はプロフェッショナルとは呼べません。退職や転職はもちろん、急な体調不良や家庭の事情による休職など、メンバーが一定期間不在になる事態は日常茶飯事です。
誰か一人が倒れただけでリリースが止まる、あるいは障害対応ができなくなるシステムは、人間を単一障害点（SPOF）として組み込んでいる時点でアーキテクチャとして破綻しています。
「複数人が対応できる状況」を作ることは、単なる理想論ではなく、事業継続性（BCP）の観点からも必須の非機能要件なのです。
属人化を解体するためのプラクティス
では、どうやってこの属人化ループを断ち切るべきでしょうか。「ドキュメントを書きましょう」と号令をかけたり、完了の定義（DoD）にチェック項目を形式的に追加したりするだけでは、現場の属人化は絶対に解決しません。書いた本人しかニュアンスが分からないテキストが形骸化して放置されるだけです。
本当に属人化を解体するには、運用の「構造」そのものを変える必要があります。
1. 一番詳しい人に「実装」をさせない（リバース・アサイン）
属人化を崩す最も直接的で効果的な手段は、平時において「その領域に最も詳しい人以外」に実装タスクを割り振ることです。
一番詳しいメンバーには、コードを書く担当から外れてもらい、「設計の壁打ち相手」や「PRレビュー」「ペアプロのナビゲーター」といったサポート役に回ってもらいます。詳しい人が書けば半日で終わるタスクに、未経験者が2日や3日かけることになるかもしれません。しかし、その差分の工数は無駄ではなく、「チームの冗長化」と「知識獲得」に対する極めて純度の高い投資です。
「自分でコードを書き、テストを通し、本番へデプロイして動かした」という成功体験がない限り、他人のドキュメントをいくら読んでも本当の意味で触れるようにはなりません。
2. ペアプロ・モブプロによる「暗黙知」の強制分散
ドキュメントに落ちない暗黙知（デバッグ時の勘どころ、ツールの使い方、仕様の背景にある文脈）を共有するには、ペアプログラミングやモブプログラミングが不可欠です。
特にトラブルシューティングや複雑なリファクタリングをエースが1人で抱え込んで解決してしまうと、その解決手法自体が新たな属人化を生みます。「作業画面を共有しながら、思考プロセスを声に出して進める」こと自体を通常業務に組み込むことで、属人化の温床となる暗黙知を強制的にチームへ溶け込ませることができます。
3. 「手放した人」を正当に評価する
マネジメントが最も意識すべきは評価制度のメッセージングです。 夜間に一人で障害対応をしてヒーロー扱いされるエンジニアよりも、「他の誰でも障害対応ができるようにRunbookを整備し、通知や自動化を整えて障害対応を不要にしたエンジニア」を圧倒的に高く評価しなければなりません。
知識を抱え込んで手放さない人間が得をする評価構造のままでは、どれだけ共有を促しても属人化が撲滅されることはありません。
属人化を手放すことでしか、次のステージには行けない
属人化で目先の案件を乗り切るのは、刹那的な快楽を得る麻薬のようなものです。その場は凌げても、じわじわと組織の体力を奪い、最終的にはコードベースもチームも身動きが取れなくなります。
エンジニアの市場価値は、「何を知っているか」ではなく、「チーム全体が価値を出し続けられる仕組みをどう作れるか」にシフトしています。
自分の城を守るためにコードを抱え込むのか、それともオープンにしてチームに委ね、自分はさらに困難で面白い課題へ挑むのか。属人化を解消できるかどうかは、エンジニアとマネージャー双方の覚悟にかかっています。