Mistake #16 : The Lone Hero

孤独な勇者の
最期

「あの人に任せておけば大丈夫」。
そのスーパーエンジニアは、残業も厭わず、休日も働き、全てのトラブルを解決してくれました。
だから誰も彼の仕事を理解しようとしませんでした。
彼が突然退職するまでは。

🦸‍♂️ 属人化診断
  • 特定の人が休むと、リリースや障害対応が止まる
  • 「コードが汚すぎて、彼以外には読めない」と言われている
  • ドキュメントがなく、全ての仕様が「彼の頭の中」にある
  • 彼に対する給与以外の報酬(感謝、称賛)だけでモチベーションを維持している
⚠️ 警告:あなたのチームの「バス係数(Bus Factor)」は 1 です。
彼が明日バスに轢かれたら、プロジェクトは即死します。

01. ヒーローは組織の害悪

🦸‍♂️
🚌💨

逆説的ですが、何でも一人でやってしまう優秀なエンジニアは、組織にとってリスク(単一障害点)です。
彼は知らず知らずのうちに、周囲から「学ぶ機会」を奪っています。
「彼がいるから覚えなくていいや」という空気がチームに蔓延すると、
組織全体のスキルレベルは低下していきます。

あなたが
不可欠な存在なら、
あなたは昇進できない。

02. ペアプログラミングの強制

ヒーロー依存を脱却する最良の方法は「ペアプログラミング」です。
ヒーローが書くコードを、隣(または画面共有)でもう一人が見る。
「なぜそう書いたのか?」をリアルタイムで言語化させる。
こうすれば、知識は少しずつチームに移転していきます。
最初はスピードが落ちますが、長期的にはチーム全体の速度が上がります。

03. ドキュメントを「納品物」にする

「忙しいからドキュメントは後で」と言わせないことです。
コードレビューの際、ドキュメントの更新が含まれていなければマージしない。
これを徹底するしかありません。
「記憶」ではなく「記録」に残すことだけが、システムを永続させます。

執筆:チームビルディング・コーチ

「全員野球」の提唱者。
特定のスタープレイヤーに頼らない、自律分散型の組織文化を醸成する。