「自分がいないと回らない」はマネージャーの敗北である
「アーキテクチャの最終決定は、マネージャーである自分が判断しなければならない」
「休日に障害アラートが鳴ったら、責任者である自分が全部巻き取って対応すべきだ」
「チームの責任者なのだから、難易度の高いトラブルや重要局面はすべて自分がフロントに立って処理すべきだ」
こうした強烈な「〜すべきだ」「〜しなければならない」という【べき論】を背負い、深夜や休日のインシデント対応に一人で駆けつけ、Slackで飛んでくる技術的な相談に即断即決を下し続けているマネージャーやテックリードは少なくありません。外から見れば、重責を一手に引き受けて現場を支える「頼れるリーダー」に映るはずです。
ですが、あえてハッキリ言います。
「自分が判断し、自分が対応しなければならない」というべき論で動いている時点で、マネージャーとしては明確な構造的敗北なんです。
この行動の根底にあるのは、不安でもメンバーへの気遣いでもなく、「責任者なのだから自分がやるべきだ」という硬直した役割認識です。しかし皮肉なことに、その真面目すぎる「べき論」こそがチームの自律性を奪い、メンバーから「自ら判断し、自ら責任を持って能動的に動く機会」を根こそぎ奪い去っています。
なぜ優秀なマネージャーほどこの「べき論の罠」にハマるのか、そしてどうやってチーム全体で責任を背負い、能動的に判断して戦う体制へシフトすべきなのか、構造を分解してみます。
1. なぜ「自分がやらなければならない」というべき論に縛られるのか
この問題の根底にあるのは、エゴや配慮ではなく、「責任者とはこうあるべきだ」という役割定義のズレです。
「判断を下すことこそがマネージャーの責務である」という固定観念
「技術選定やアーキテクチャの最終決定を下すことこそがマネージャーの仕事だ」と信じ込んでいるケースです。プレイヤー時代に培った深い技術的バックグラウンドがある人ほど、「最後にクオリティを保証し、Go/No-Goを判断する役割は自分が果たすべきだ」と考えてしまいます。
しかし、マネージャーがすべての判断の関所（ゲートキーパー）として振る舞い続けると、チームは「自分たちで判断し、その責任を引き受ける」というスタンスを手放してしまいます。本来はチーム自身が技術的なトレードオフと向き合い、自らの意思決定に責任を持って推進すべきなのに、「決めるのはマネージャーの仕事だから」と、能動的な判断とそこに伴う当事者意識から降りてしまうんですよね。
「平時の判断独占」が引き起こす、有事の孤立と「声がけ依存」
平時にマネージャーが「自分が判断すべきだ」と意思決定を抱え込んでいると、システムの設計思想やトレードオフの文脈はすべてマネージャー個人の頭の中にしか残りません。これが有事において何を引き起こすかというと、単なる「マネージャーの抱え込み」に留まらない、より根深い組織の機能不全です。
休日に本番エラーの監視アラートがSlackなどの通知で鳴り響いても、チームのチャンネルは静まり返ったまま。メンバーから「自分が見ます」「ログを確認します」という自発的なアクションが起きることはありません。システムの背景も判断基準も平時から渡されていないため、メンバー側からすれば「何が起きているか判断できない」し、何より「マネージャーが判断・対応するものだ」という前提が出来上がっているからです。
その結果、どうなるか。マネージャーは一人で原因究明に追われ、キャパシティを超えた段階で「休日にわざわざメンバーに個別メンションを飛ばして『手が足りないから協力してもらえないか』とお願いして回る」という本末転倒な状況に陥ります。
本来は自分たちが開発・運用しているプロダクトの異常であるにもかかわらず、マネージャーが声をかけてお願いしない限り誰も動かない。平時に判断と責任を独占してきたツケが、有事における「チームの完全な傍観者化」と「マネージャーの孤立無援」という形で跳ね返ってくるわけです。
2. チームから「能動的な判断と責任感」が失われるメカニズム
マネージャーが「自分が判断すべき」「自分が対応すべき」と振る舞い続けると、チームの能動性と責任感は驚くほどのスピードで摩耗していきます。
「判断はマネージャーの仕事」という責任の外部化
アーキテクチャや設計の決定を「自分が判断すべきだ」とマネージャーが握り続けていると、メンバーは徐々に「自分でリスクを取って決めること」を放棄します。
「マネージャーが判断すべきなのだから、言われた通りに手を動かすのが一番安全だ」
「問題が起きました。どうすればいいですか？」
このように、課題に直面しても自ら解決策を検討・判断せず、マネージャーにそのまま判断を丸投げする姿勢が定着します。「決めるのは自分ではない」という前提があるため、判断が必要な局面になると手が止まり、マネージャーの指示を待つだけの状態に陥ってしまうのです。自らリスクを負って意思決定した経験がないエンジニアは、「決めたことに対して最後まで責任を持ってやり切る」という能動的な推進力を発揮できなくなっていくんですよね。
「当事者」から「善意の協力者（ヘルパー）」への退行
休日にエラーが起きた際、マネージャーが「自分がやるべき」と巻き取り続け、手が回らないときだけ「声をかけて手伝ってもらう」運用を続けていると、メンバーのスタンスは完全に歪みます。
アラートが鳴っても、メンバーにとってそれは「自分たちのシステムが脅かされている緊急事態」としては響かず、どうしても関心が低い状態にとどまってしまいます。「きっとマネージャーが把握しているだろう」という無意識の前提があるため、悪意があるわけではなくとも、自ら率先して調査に乗り出そうという熱量は生まれません。
そして、マネージャーから声をかけられて対応に入ったとしても、彼らの意識は「チームの責務としてプロダクトを復旧させている当事者」ではなく、「休日にマネージャーの仕事を手伝ってあげている協力者」にとどまります。このスタンスの違いは致命的です。「手伝い」として参加している以上、能動的に根本原因を突き止めたり、再発防止のために自律して動いたりはしてくれません。
マネージャーが「自分が対応すべき」というべき論に縛られている限り、メンバーは永遠にシステムの信頼性に対するオーナーシップを持てず、「指示されて初めて動く下請け」へと退行していってしまいます。
バス係数1による運用の脆弱性
マネージャーがいないと「技術的判断が下せない」「休日の本番障害を誰も自発的に調査・復旧できない」チームは、単一障害点（SPOF）を抱えたシステムと同じです。
マネージャーが体調を崩したり、オフラインの場所にいたりするだけで、チームは判断停止に陥り、本番障害のダウンタイムは致命的に跳ね上がります。「自分が判断・対応すべき」という責任感で回している状態は、チームを守っているどころか、事業にとって最大の運用リスクそのものです。
3. 「個人のべき論」から「チームの自律と責任」へ主権を移譲する
「自分がやるべき」という個人の責任感に依存し、有事に声をかけないと動かない体制を断ち切るには、チーム自身がリスクを引き受けて能動的に判断・対応するための仕組みを整える必要があります。
① 意思決定のボールをチームに返し、責任の所在を移譲する
マネージャーが判断を下すのではなく、チーム自身が判断し、その決定に責任を持つプロセスを仕組みとして定義します。
- 「どうすればいいですか？」を受け取らない:メンバーから判断を丸投げされた際、マネージャーが即座に答えを出してしまうのをやめる。「あなた自身はどう考え、どう進めるべきだと思うか？ その根拠は何ですか？」と必ず問い返し、チーム自身に解決策を考えさせて判断の道筋を立てさせます。マネージャーの役割は「決めること」ではなく、「チームが自ら論理的根拠を持って決定を下すプロセスを支援すること」です。
- マネージャーは「決定者」ではなく「壁打ち役」に徹し、最後に背中を押す:チームが設計や技術選定を進める際、マネージャーが一人で答えを決めるのではなく、論理の穴や見落としているリスクを指摘する壁打ち相手に回ります。そして、チームが悩み抜いて導き出した結論に対して「その思考プロセスと根拠なら大丈夫、この方針でいこう」と最後に背中を押してあげる。「マネージャーに決められた」ではなく「自分たちが考えて導き出し、後押しを受けて選んだ」という体験を積ませることで、不確実性への恐怖を和らげつつ、決定に対する推進力と当事者意識をチーム側にしっかり根付かせることができます。
② 障害対応を「お願いして手伝ってもらうもの」から「チームの共同責任」へ変える
有事のたびにマネージャーが一人で抱え込んだり、休日に声をかけて頼み込んだりする悪循環を完全に断ち切ります。
- 持ち回りなどの「形式」に固執せず、「誰でも初動の旗を立てられる」状態をつくる:障害対応の属人化を防ごうとすると、「とりあえず当番制（持ち回り）を導入しよう」と考えがちですが、この持ち回りという制度そのものにこだわりすぎるのも罠なんです。厳格な当番制に固執すると、「今日は自分の番ではないから関係ない」と非当番メンバーの関心が急速に薄れたり、当番ルールの整備自体に疲弊して制度が形骸化したりします。持ち回り制を敷くかどうかは組織規模やフェーズに応じた一つの手段に過ぎません。本質は形式ではなく、「マネージャー以外の誰でも、気づいた人が初動の旗を立てられ、周囲が自然とフォローに入れる土壌」を平時から作っておくことです。「トラブルを一人で解決し切る」必要はまったくなく、「アラートに気づいた人が状況をオープンなチャンネルに投げて一次確認を始める。それを見た別のメンバーが手を差し伸べる」という共同責任の前提を共有しておく。「マネージャーが個別に頼み込まないと誰も動かない」状態から、「気づいた誰かが初動を起こし、チーム全体で呼応できる」状態へと文化を移行させることが肝心なんですよね。
- マネージャーが反射的に飛びつかず、チームが動く「余白」を残す:休日にアラートが鳴った瞬間、マネージャーが「自分が対応すべきだ」と反射的に手を動かしてしまうと、チームが自発的に動く機会はその瞬間に奪われてしまいます。「どうせ今回もマネージャーが拾うだろう」という無意識の前提を壊すためにも、マネージャーはあえて即座に作業へ飛び込まず、チームが気づいて初動を起こすための「時間的な余白」を残す必要があります。マネージャーが手を出さないことで初めて、チームが当事者としてボールを拾うスペースが生まれます。トラブル対応をマネージャーが奪わないこともまた、自律性を引き出すための重要な規律なんです。
- Blameless（非難なし）なポストモーテム:障害が起きた際に個人を責めず、システムや運用の課題として全員で解決策を導き出す。失敗を許容する文化があって初めて、メンバーは恐れずに責任を引き受けるようになります。
③ 自律的な判断と行動を支える「失敗してもやり直せる仕組み（可逆性）」を整える
チームに能動的な判断や対応を任せようとしても、「万が一間違えたら、取り返しのつかない大惨事になるかもしれない」という恐怖があれば、メンバーの手は止まってしまいます。マネージャー側も「大事故が怖いから自分が巻き取るべきだ」という呪縛から抜け出せません。
自律性を機能させるために必要なガードレールとは、小難しいインフラ要件のことではなく、「ミスをしても致命傷にならず、安全にやり直せるセーフティネット」そのものです。
- 「いつでも安全に元の状態へ戻せる（ロールバックできる）」仕組み:「何かあってもワンアクションで直前の正常な状態に切り戻せる」という確証があれば、メンバーは過剰な恐怖を抱かずに自分たちの判断でリリースや復旧作業に踏み切れます。「元に戻す手段がある」という事実そのものが、チームの意思決定を後押しする最大の安全弁になります。
- 「最悪の事態でも影響範囲を限定できる」仕組み:万が一障害や誤判断が発生しても、システム全体が全断するのではなく、影響を特定の一部機能や特定ユーザーに閉じ込められる設計にしておく。被害の上限が最初から見えていれば、リスクを取った判断のハードルは劇的に下がります。
「失敗してもすぐにやり直せる（可逆である）」というセーフティネットが敷かれていて初めて、メンバーはマネージャーのお伺いを立てるのをやめ、自らの判断と責任で能動的にシステムを動かせるようになるのです。
4. 目指すべきは「チーム自身が判断し、責任を持って動く状態」
マネージャーの本来の責務は、「自分が現場の誰よりも正しく判断し、トラブルの最前線で戦うこと」ではありません。「自分がいなくても、チーム自身がリスクを引き受けて能動的に判断を下し、休日の障害にも自発的・組織的に責任を持って対処できる環境を構築すること」です。
「自分が判断しなければならない」「休日の障害は自分が対応すべきだ」というべき論が頭をもたげたときこそ、立ち止まる必要があります。その義務感は、チームから意思決定の筋力と当事者意識を奪い、休日に声をかけないと誰も動かない「受動的な協力者」へとスポイルしてしまうシグナルに他なりません。
マネージャーが判断を独占するのをやめ、責任の所在をチームへ正しく手放す。それによって初めて、メンバー一人ひとりがプロダクトの信頼性とアーキテクチャに責任を持ち、能動的に動き出す自律型組織が完成するのだと言えます。