スキルアンマッチな過酷な現場を、運良く先輩のサポートで離脱できた後、私は自分のメインスキルであるデータベースの知識を活かせる新しいプロジェクトへと移りました。
紆余曲折ありながらも、その職場には通算で約3年ほど在籍することになります。最初のうちは順風満帆で、他チームとのコミュニケーションやテスト業務を純粋に楽しめていました。しかし、プロジェクトがリリースを終えて運用フェーズに入り、私が「運用チームのリーダー」に抜擢されたところから、再びうつ病再発のカウントダウンが始まりました。
今回は、真面目なSEがリーダー職になった途端に陥りがちな「他人の責任まで背負い込むバグ」と、そこから脳のオーバーフローを防ぐための防衛策を解説します。
1. リーダー抜擢と、静かに忍び寄る「未知のプレッシャー」
運用が始まると、メンバーの入れ替わりや顧客との直接交渉、さらには契約関係の管理といった「これまで経験のないマネジメント業務」が一気に増えていきました。
自分の得意領域（UNIXやデータベース）は問題なく処理できたものの、門外漢であるJavaのコード調査を迫られたり、顧客の体制変更によって不慣れな事務手続きに圧迫されたりする中で、脳内には少しずつ「未知への不安」というノイズが溜まっていきました。
それでも「リーダーなのだから、自分がなんとかしなければならない」と、私はバックグラウンドで不安を処理し続けていたのです。
2. 決定打となった「メンバーへのクレーム」と、GWの熱暴走
そんな中、チームに新しく入ったメンバーの作業品質について、クライアントから会社宛てに激しいクレームが入りました。「なぜこんなことも分からないのか」「品質が低すぎる」という厳しい指摘です。
そのメンバーが担当していたのは私の知らない技術領域だったため、私は積極的に介入できず、どこかで「様子見」という逃げを打っていました。だからこそ、クレームが顕在化した瞬間に「自分が状況を把握していなかったせいだ」という猛烈な罪悪感に襲われたのです。
ゴールデンウィーク直前、顧客から「連休明けまでにジャンル別の対応策資料を作ってくるように」と指示されました。
ここから、私の脳は完全にバグを起こして熱暴走を始めます。
- 不慣れなタスクでの停滞： パワーポイントでの資料作成に慣れておらず、一般的な対策しか思い浮かばない自分に焦る。
- 過剰な義務感による孤立： 「連休が明けたら、どれほど厳しいことを言われるだろう」とネガティブな思考に支配され、休日を丸1日潰して友人を呼び出し、必死に対応策を練り上げる。
- 薬による強制引き下げ： 膨れ上がる不安に耐えきれず、一度はやめていた抗不安薬を再び服用して、なんとか精神の崩壊を食い止める。
これほどまでに自分を削り、苦しみ抜いて作成した資料を連休明けに提出したところ、顧客の反応は「じゃあ、これでやっておいて」と、拍子抜けするほどあっさりとしたものでした。
3. 「顧客の目」に過剰反応し、システムダウンへ
資料は受理されたものの、地獄はそこからでした。日々の定期報告のたびにメンバーへの嫌味や小言を言われ、月末の報告書でわずかな記載ミスをするだけで激しく叱責される毎日が続きました。
私の心身は、完全に恐怖に支配されていきました。 通勤電車の中でメンバーから「今、顧客が怒っています」とLINEが届いただけで心拍数が跳ね上がり、最寄り駅から職場までの15分の道のりを大汗をかきながら全力疾走で駆け込むほど、精神的に追い詰められていたのです。
結果として、かつてうつ病を発症した時と全く同じシグナル（危険ログ）が身体に出始めました。
- 頻発する激しい片頭痛
- 不安のあまり、物理的に胸が締め付けられるように痛む
- 職場へ向かうこと自体に強い拒絶反応が出る
このままでは完全に再発すると察知し、最終的にはこの現場を離任することを選びました。
4. この現場から学ぶ、リーダーSEの「認知リファクタリング」
当時は「顧客との関係を悪化させて終わってしまった、自分が無能だからだ」と自分を責めました。しかし、心理学や4nessコーピングを学んだ今の私なら、これが「典型的な認知のバグ」であったとはっきりと分かります。
もし今、チームのトラブルやクレームを一人で背負って潰れそうなリーダーは、以下のパッチを脳に当ててください。
① 「メンバーのスキル不足」は、リーダー個人の罪ではない
リーダーとしてチームの責任を持つことは標準仕様ですが、「メンバーの能力や成果」を100%コントロールすることは不可能です。クレームの本質的な解決には、本人の行動変容が必要であり、あなた一人が資料を書いて解決するものではありません。
② 「人出しのミスマッチ」には、リソース調整で返す
顧客とメンバーの相性が致命的に悪かったり、要求スキルと実態に明らかなアンマッチがある場合、取るべきロジックは「自分が血を流してカバーする」ことではなく、「交代要員を要請する（体制の変更）」というリソースマネジメントです。できない領域を「できません、体制を変えましょう」と上層部に上げるのは、リーダーとしての正当な防衛策であり職務です。
まとめ：できないことは「できない」と言っていい
当時の私は、「できない自分はダメだ」という認知のバグのせいで、客観的な状況判断が全くできていませんでした。顧客の顔色を伺うことに全リソースを割き、悲観的な予測で自らの首を絞めていたのです。
システムエンジニアとして、またリーダーとして現場に立つあなたに、これだけは覚えておいてほしいメッセージがあります。
- リーダーであっても、すべてを完璧にこなせるわけではない。
- 自分のキャパシティを超えること、専門外のことは「できない」と周囲にアラートをあげて全く問題ない。
あなたが一人で泥を被って潰れてしまっては、チームというシステム自体が完全に機能停止（ブレイクダウン）してしまいます。早期にアラート（NO）を検知し、適切に周囲へ処理を分散することこそが、長期にわたって現場を安定駆動させるベテランSEの真の生存戦略なのです。
