はじめに：「俺がいないと回らない」という甘い毒
「〇〇さーん！例のバッチ処理、またエラーで止まってるんですけど…」
「あ、はいはい。それ俺しか触れんやつね。ちょっと待ってて」
チームの中で、特定のレガシーシステムを自分だけが直せるという状態。
正直に言います。最初はちょっと気持ちよかったんです。「俺がいないとプロダクトが止まる」という、ある種の**「不可欠感」という甘い毒**に酔っていました。
しかし、その代償は想像を絶するものでした。
・旅行中も緊急電話が鳴る
・有給を取っても「これだけ教えてください」のSlackが飛ぶ
・体調不良で休んだ日、チームが完全に機能停止した
そしてある日、先輩からこう言われました。
「お前のバス係数、1だぞ。お前がバスに轢かれたら、あのシステムは終わりだ」
どの会社でも神のような存在はいると思います。そんな神も1人の人間です。敬うのではなく、負担を減らす仕組みをチームで考えましょう。
技術解説：「バス係数（Bus Factor）」とは何か
「チームの何人がバスに轢かれたら（＝突然いなくなったら）、
そのプロジェクトが知識不足で破綻するか」
その最低人数 ＝ バス係数
ブラックジョークのような名前ですが、ソフトウェア工学で属人化リスクを定量的に示す、極めて真面目な指標です。
バス係数 = 1。これは、たった一人の離脱でプロジェクトが崩壊することを意味します。
属人化が起きるメカニズム
なぜ属人化は起きるのか。多くの場合、悪意ではなく構造的な問題です。
- 時間がない：「ドキュメント書くよりコード書いた方が速い」→ 知識が頭の中に留まる
- 評価されない：「ナレッジ共有」は業務として評価されにくく、自然と後回しになる
-
無意識の自己防衛：「自分しかできない仕事」がある方が、リストラされにくいと感じてしまう
しかし、その「安心感」の裏側で、あなた自身が最も搾取されていることに気づいてください。
休めない、成長できない（他の技術を触る余裕がない）、そしてチームも育たない。
バス係数を上げる3つの実践
1. 「俺しか知らない」を書き出す（暗黙知の形式知化）
まず、自分の頭の中にしかない知識を洗い出します。
「あのバッチが失敗した時の対処法」「あの設定ファイルの意味」──それをWikiやREADMEに書き出すだけで、バス係数は劇的に改善します。完璧な文章でなくていいのです。箇条書きのメモでも、ゼロとイチの差は計り知れません。
2. ペアプログラミング / ペアオペレーション
一番効果が高いのは、レガシーシステムの障害対応を「自分一人で直す」のではなく、必ず誰かと一緒にやる」ことです。横で見ているだけでも、手順と勘所が伝わります。
3. 「ヒーロー文化」を称賛しない
「〇〇さんがまた一人で直してくれた！すごい！」──この称賛が、実は属人化を加速させます。
チームとして称えるべきは「一人で解決したこと」ではなく「知識を共有して、誰でも対応可能にしたこと」です。
「自分しか直せないコード」は、あなたの価値の証明ではありません。それは「チームと自分自身の首を絞めるロープ」です。
バス係数を上げることは、プロジェクトを守ると同時に、あなた自身を「休めないエンジニア」から解放する唯一の方法なのです。