なぜ「エース」から壊れるのか？
精神論が隠す「組織設計」の致命的エラー

組織が個人の優秀さに依存する設計を採用したとき、その組織は「属人化」という猛毒を抱えることになる。属人化は単なる非効率の問題ではない。それは組織の継続性を脅かす「リスク設計」の問題である 4。

バス係数（Bus Factor）によるリスクの定量化

このリスクを客観的に示す指標として、ソフトウェア工学で用いられる「バス係数（Bus Factor）」が挙げられる。これは「チームのうち何人がバスに轢かれたら（突然いなくなったら）、プロジェクトが完全に停止するか」という最低人数を指す 5。

優秀な人が壊れる組織の多くは、このバス係数が「1」である 6。一見すると、特定のスーパーマンがすべてを回している状態は、コミュニケーションコストが低く、効率的に見えるかもしれない。しかし、そのスーパーマン（優秀な個人）にとっては、自らの離脱が組織の死を意味するという過度な心理的プレッシャーが常時かかっている 8。これは「組織開発 仕組み」の観点から見れば、単一障害点（Single Point of Failure）を放置した極めて未熟な設計であると言える。

属人化を加速させる「評価の空白」

なぜ、多くの現場で属人化が解消されないのか。それは、多くの場合、属人化を解消するための「ナレッジ共有」や「ドキュメント作成」が、業務として正式に定義されず、評価の対象にもならないからである 6。優秀な人は、目の前の難題を「自分で解くこと」には長けているが、それを「他人が解けるように設計すること」には、組織からの明確なインセンティブがない限り動機づけられない。ナレッジの共有を「個人の善意」に委ねている時点で、その組織設計は失敗している。

「優秀な人材を育てたい」という願いとは裏腹に、多くの企業が実施する人材育成施策は、優秀な人をさらに追い詰める結果となっている。「研修 効果が出ない 理由」を探ると、そこには個人の能力の問題ではなく、構造的な断絶が横たわっている 3。

研修の転移失敗（Training Transfer Failure）の構造

研修で学んだ高度なスキルが現場で活かされない最大の理由は、研修の設計と現場の業務設計が完全に切り離されていることにある 3。

1. 実践の場の欠如: 研修で学んだ新しい手法を試そうとしても、現場の業務フローが従来通りの「個人の経験則」に基づいたままであれば、新しい知識はノイズとして排除される 3。
2. 測定指標の誤り: 研修の効果を「受講者の満足度」や「テストの点数」といった表層的な数値で測り、現場での「行動変容」や「アウトプットの質の変化」を測定する設計がなされていない 3。
3. 指導の非業務化: 指導責任が「多忙な優秀層」に無償の追加タスクとして丸投げされており、指導のための時間や権限が正式な業務設計（ジョブ・ディスクリプション）に含まれていない 3。

指導者としての優秀層の摩耗

「人材育成 設計」における典型的な失敗は、最も高い付加価値を生むべきトッププレイヤーを、そのまま教育担当者としてアサインし、かつ自身の高い数値目標も据え置くことである。これは、一人の人間に「アクセル」と「ブレーキ（後輩のケア）」を同時に全力で踏ませるようなものであり、エンジンの焼き付き（燃え尽き）を引き起こすのは物理的な必然である 3。育成を「仕組み」として設計せず、個人の「背中を見て学べ」という精神論に逃げる組織が、優秀な人材を最も早く破壊する。

ここまでの分析で明らかになったのは、優秀な人が壊れる背景には「人間は強く、完璧であり、無限に頑張れる」という非現実的な人間観に基づいた組織設計がある、ということだ。しかし、真の組織開発とは「人は弱く、ミスをし、疲れる存在である」という冷徹なリアリズムから出発しなければならない。

安全工学に学ぶ：フェイルセーフとフールプルーフ

製造現場や医療現場では、個人の注意力が欠如しても事故を防ぐための「フェイルセーフ（Fail-safe）」や、そもそもミスが起こり得ないようにする「フールプルーフ（Fool-proof）」の考え方が徹底されている 9。これを組織設計、特に知識労働の分野に応用することが、優秀な人を守るための鍵となる。

優秀な人を壊さないための設計とは、彼らが「いなくても回る」状態を意図的に作ることである。これは彼らの存在意義を否定することではなく、彼らにしかできない高度で創造的な業務にエネルギーを集中させるための「聖域」を作ることと同義である 10。

読者が翌日から実践できる、組織設計の変革ステップを提示する。

1. 属人化マップの作成（可視化）: 自部署の業務をリストアップし、それぞれの「バス係数」を算出する。係数が1の業務があれば、それは明日から取り組むべき「設計のエラー」である 5。
2. 「判断の委譲」マップの作成: エースが抱えている業務のうち、「仕組みがあれば他人に任せられるもの」を特定する。エースの役割を「自分で解決すること」から「解決の仕組みを作ること」へと再定義する 10。
3. 80点の仕組みで運用開始: 100点の完璧なマニュアルを待つのではなく、まずは「誰がやっても80点が出る」簡易的な手順書で業務を回し始める。残りの20点は現場の創意工夫（関係性）で補完する 10。
4. 育成の「業務化」: 部下の指導やナレッジの共有に要する時間を算出し、それを指導者の「主業務」としてスケジュールに組み込む。その分、既存の個人目標数値を適切に下方修正する（設計の調整） 3。
5. リソース供給の定点観測: JD-Rモデルの視点で、チームの「資源（支援・裁量・フィードバック）」が不足していないか、定期的なサーベイや対話でチェックする 2。