エースに背負わせるほど、その組織は脆くなる——20年PMが見てきた「全員センター」という属人化ゼロ設計

プロローグ

正直に言う。

私は昔、優秀なエンジニアが一人いると、その人にすべてを任せていた。

「彼がいれば大丈夫」

そう思って、設計もレビューも障害対応も、気づけば一人に集中させていた。

ある日、その人が退職した。

引き継ぎ資料はほとんどなかった。頭の中にしかない判断基準が、山ほどあった。

プロジェクトは、半年止まった。

「なんで代わりを育てておかなかったんですか」

上から、そう聞かれた。私は答えられなかった。

そして全部、現場をさらに悪くした。

今は違う。

「エースに任せる」ことと、「エースに背負わせる」ことは、まったく別の設計だと分かるようになった。

20年現場にいて、結局そこに戻ってくるのである。

——強いチームは、強い一人ではなく、強い「配分」でできている。

第1章:「エースに任せれば早い」という正論の、矛盾

「得意な人に任せたほうが、早いし質も高い」というのは、正論である。

実際、その通りだ。エースに任せれば、初速は圧倒的に速い。

ここで、ひとつ事実を置いておく。

アイドルグループ「=LOVE(イコラブ)」は、楽曲ごとにセンターを固定しない制度を採っている。これまでの80曲以上の楽曲において、複数のメンバーが入れ替わりでセンターを務めてきた。2026年3月には、当時在籍する全メンバーが、それぞれ単独のセンター曲を持つに至ったと報じられている。

一人のエースを立て続けたグループではない。

代わりに、役割を意図的に配り続けたグループだ。

この設計は、短期的には非効率に見える。センターを固定したほうが、練習も演出も安定するはずだからだ。

だが、QCD(品質・コスト・納期)の議論と同じ構造がここにある。

短期のコスト最適化だけを見れば、「得意な一人に任せる」が正しい。しかし納期を「その日」ではなく「10年」で見た瞬間、話が変わる。

一人に依存した設計は、その人が抜けた瞬間に、品質もコストも納期も同時に崩れる。

「エースに任せれば早い」という正論は、間違ってはいない。

だが、それは「短い時間軸でしか正しくない」という点で、静かに矛盾を抱えている。

PMとしての教訓:「今日の最適解」と「10年の最適解」は別物である。短期の効率だけで役割配分を決めると、長期的な脆さを埋め込むことになる。

第2章:属人化を選ぶリーダーの、隠れた動機

ここからは、特定の誰かの話ではない。

私がこれまで現場で出会ってきた、「とりあえず、あの人に任せておけばいい」と言うタイプのリーダーの話である。

このタイプの人は、悪意があるわけではない。

むしろ、チームの成果を最短距離で出したいという、真っ当な動機がある。

だが、その判断の裏に、もうひとつの動機が隠れていることが多い、と私は思うようになった。

それは「育成の手間を、今払いたくない」という先送りである。

新しい人に任せれば、教える時間がかかる。失敗も増える。レビューの負荷も上がる。

それに比べて、得意な人にもう一度頼むほうが、圧倒的に楽だ。

だから、「適材適所」という正しい言葉を使いながら、実際には「今の自分が一番楽な配分」を選び続けてしまう。

これが、厄介なところだ。

PMとしての教訓:「適材適所」という言葉が出たときは、それが本当に長期最適な配分なのか、それとも今の自分の手間を減らすための配分なのかを、一度疑ったほうがいい。

第3章:その人が本当に恐れているもの

20年で一番厄介だったのは、実は「エースに任せる」という判断そのものではなかった。

その判断の奥にある、リーダー自身の不安だった。

何度か本音で話す機会があって、見えてきたことがある。

多くの場合、彼らの内側には、こんな声がある。

・「新しい人に任せて失敗したら、自分の判断ミスになる」

・「育成には時間がかかるが、その間の遅れを自分が説明しなければならない」

・「自分がいなくても回るチームになったら、自分の役割が薄まる気がする」

・「エースに頼っている今のほうが、まだ安心できる」

これは特定の誰かの内面を断定しているわけではない。私がこれまでのプロジェクトで、繰り返し見聞きしてきた、共通する不安のパターンである。

面白いのは、最後の一文だ。

属人化は、リスクであると同時に、リーダー自身にとっての「安心材料」でもある。

エースがいる限り、リーダーは大きな決断をしなくて済む。

その安心を手放すことが、実は一番怖い。

**PMとしての教訓:**属人化を手放せないのは、能力の問題ではなく、不確実性への恐れであることが多い。まず責めるべきは人ではなく、その不安を許してしまっている構造のほうだ。

第4章:NGな属人化対応と、機能する分散対応の違い

NGの対応例は、だいたいこの3つに集約される。

・「とりあえず、あの人に任せておけば安心」とだけ言って、他の人の経験機会を作らない

・「今回は急いでいるから」と言って、毎回同じ人に重要な役割を戻す

・失敗を恐れて、新しい人には簡単な仕事しか渡さない

なぜこれが逆効果か。

これらはすべて、「今の効率」を優先した結果、「未来の選択肢」を静かに減らしているからだ。

減らされた本人は、いつまでも経験を積めない。

任せる側も、いつまでも一人に依存したままになる。

私が今、心がけているのは、こういう順番だ。

まず、「今回は重要度が高いから、経験のある人と、まだ経験のない人を組ませたい」と言う。

そして次に、「次回は、今日サポートに回った人がメインをやってほしい」と言う。

一気に交代させない。

だが、いつまでも交代させない、とも言わない。

役割の移行に、あらかじめ順番をつける。それだけでいい。

**PMとしての教訓:**分散とは、今のエースを外すことではない。次にエースになれる人を、今のうちから並走させておくことである。

第5章:人を変えるのではなく、役割の配り方を変える

ここで、もう一度、事実に戻る。

=LOVEというグループの設計を見ていて、私が「これは仕組みだ」と感じたことがいくつかある。以下は、公表されている事実と、そこから私が受け取った教訓を分けて書く。

役割を案件ごとに回す。 事実:=LOVEは楽曲ごとにセンターを固定せず、これまでの80曲以上でメンバーが入れ替わりながらセンターを経験してきた。 教訓:固定の主担当を決めるのではなく、案件・フェーズごとに担当を回す前提にする。役割は「その人のもの」ではなく「その案件のもの」として扱う。

経験を記録し、可視化する。 事実:誰がいつ、どの曲のセンターを務めたかは、公式・非公式を問わず一覧として整理・蓄積されている。 教訓:誰が何を経験済みで、誰が未経験かを可視化しておくと、次の機会に「経験のない人」を選びやすくなる。属人化は、記録の不在からも生まれる。

「いつまでに全員」という期限を切る。 事実:2026年3月、当時のメンバー全員が、それぞれ単独のセンター曲を持つに至ったと報じられている。「いつかは全員に」ではなく、達成に向けた積み上げが継続されていたことがうかがえる。 教訓:「そのうち機会を作る」ではなく、「いつまでに全員に経験させるか」を先に区切る。期限のない配慮は、たいてい実現しない。

同時に前に立つ機会を作る。 事実:=LOVEには、複数人が同時にセンターを務める曲や、他グループとの合同編成でセンターを分け合う曲も存在する。 教訓:一人ずつ順番に任せるだけでなく、複数人が同時に責任を持つ機会をあえて作る。属人化の解消と、孤立の防止は、同じ設計で両立できる。

**PMとしての教訓:**続いている組織には、たいてい「特別な一人」ではなく「配分の設計」がある。人を入れ替える発想をやめて、役割そのものを回す前提に作り替える。それが、構造を変えるということだ。

エピローグ|一人のセンターより、全員のセンター

20年、いろんな現場を見てきた。

一人のエースに支えられたチームを、私は何度も見た。

そして、そのエースが抜けた瞬間に傾いたチームも、同じ数だけ見てきた。

=LOVEというグループが、80曲以上かけて役割を配り続けてきた事実を見ながら、そんなことを、あらためて思った。

もし今、あなたのチームに「あの人がいれば大丈夫」という空気があるなら、こう聞いてみてほしい。

「その役割、来年も同じ人にお願いするつもりですか。」

答えに詰まったなら、そこにあるのは信頼の証ではない。

ただ、次の担い手を、まだ決めていないだけの話だ。

エースを探すより、配り方を一つ作るほうが、チームは長く続く。

そう思える日が、きっとある。

関連記事

▼ ＝LOVEの「全員センター制度」を組織論としてより詳しく読み解きたい方へ
【イコラブ8周年】＝LOVEが8年で証明した「全員センター」の組織論——属人化を排除し、個とチームを両立させるPMの配分設計
https://note.com/quiet_emu2080/n/n9343382ad9e2

▼ 特定の人に負荷が集中し、「不毛な調整」で現場が疲弊している方へ
不毛な調整をスコープアウトする、現場の調停プロトコル
https://note.com/quiet_emu2080/n/n3a49f518e1d2

▼ 20年の現場経験から生まれた「教則本」の全目次を見たい方へ
PMの心得——20年が教えてくれた、知識体系では学べないこと
https://note.com/quiet_emu2080/n/nc727b32351ab

▼ 記事で扱った「配分の設計」を、そのまま明日から現場で実装したい方へ（有料記事）
『=LOVE』に学ぶ、属人化を排除するマルチアサイン設計の技術——構造で読む、最強の個とガバナンスの両立とPM・コンサル現場での実装アーキテクチャ(¥1,980)
※マルチアサイン成熟度診断シート、役割分担マトリクス等のテンプレート五雛形、90日文化定着プログラムを収録。
https://note.com/quiet_emu2080/n/n63a77196d41a

構造学。──人を責めず、構造を見る。
問題は、人ではない。構造が、人をそう動かしている。

▼ 現場の運用をさらに深めたい方へ

「配分の設計」をさらに実務に落とし込みたい方は、こちらの有料記事もあわせてどうぞ。本記事で扱った「属人化排除」というテーマを、要件定義・診断シート・90日実装プログラムまで含めて、そのまま現場で使える形に落とし込んでいます。

『=LOVE』に学ぶ、属人化を排除するマルチアサイン設計の技術——構造で読む、最強の個とガバナンスの両立とPM・コンサル現場での実装アーキテクチャ(¥1,980) マルチアサイン成熟度診断シート、役割分担マトリクスなどのテンプレート五雛形、90日文化定着プログラム、品質チェックリスト80項目超、ガバナンス設計書五部構成を収録しています。 https://note.com/quiet_emu2080/n/n63a77196d41a