経験談

僕がSIer時代にメンタルを病んでしまった時の話をします。

 

 

今回は、僕がSIer時代にメンタルを病んでしまった時の話をします。

 

☑本記事の内容

SIer時代にメンタルがやられた時にやっていた仕事
メンタルがやられた要因
SIerでメンタルをやられないようにするためには?

 

☑本記事の信頼性

・SIer/SESを10年近く経験
・運用監視や運用構築等、いろいろ経験

 

このような形でいろいろ経験し、現在はWEB系企業でインフラエンジニアとして勤務しています。

僕の詳しい経歴が知りたい方は、以下のブログ記事を読んで頂ければと思います。

 

 

※スマホだと読みづらいため、PCにて読むことをお勧めします。

 

本記事を読むメリット

・SIerでメンタルを病んでしまった人の実体験が分かる。
・メンタルを病まないようにするためにやるべきことが分かる。

 

今回は、僕が実際にやっていたSIer時代の仕事をベースにお話をしていきたいと思います。

 

では、本題に入っていきたいと思います。

 

SIer時代にメンタルがやられた時にやっていた仕事

 

僕は、丁度去年の今頃(2022/08下旬)にメンタルが壊れて2ヶ月程休んでいました。

 

その時に、以下のプロジェクトを2つ掛け持ちしておりました。

 

掛け持ちしていたプロジェクト

・メールサーバーの移行方針策定支援プロジェクト
・AWS基盤への移行支援プロジェクト

 

月の工数で言うと、0.5 人月ずつ案件に参画しているような感じになります。

 

扱っていた技術の一例についてもご紹介します。

 

メールサーバーの移行方針策定支援プロジェクト

  • Exchange Server
  • Exchange Online
  • Azure AD Connect
  • Windows Server 2012 R2

 

AWS基盤への移行支援プロジェクト

  • AWS (Lambda,EC2,EBS,CloudWatch,SNS)
  • RHEL8系
  • WindowsServer2019

 

立ち位置は、両方のプロジェクトともプロジェクトリーダーという立ち位置で仕事をしておりました。

そのため、顧客定例や内部定例でファシリテーションをしたり、課題管理をすることが多かったです。
(手を動かすこと作業は、基本メンバーに任せておりました。)

 

各プロジェクトの人数や役割については、以下になります。

 

人数/役割

■メールサーバー移行方針策定支援プロジェクト
人数:3人
それぞれの役割:
・プロジェクトリーダー (自分)
・メンバー : 1人
・アーキテクト : 1人

■AWS基盤への移行支援プロジェクト
人数:6人
それぞれの役割:
・プロジェクトリーダー (自分)
・メンバー : 4人
・アーキテクト : 1人

 

期間はそれぞれですが、去年の8月時点で上記のプロジェクトを2つ掛け持ちしておりました。
どちらも常駐案件というよりは、社内の受託案件(請負案件)になります。

 

「プロジェクトで何をやっていたのか?」の概要が気になる形は、こちらも併せてご覧頂ければと思います。

 

 

 

この時が人生の中で一番辛かったです。

さっとん

 

メンタルがやられた要因

 

僕のメンタルがやられた要因としては、以下になります。

  • プロジェクトの掛け持ち&慣れないプロジェクトリーダー
  • 今まで経験したことがない技術の上流工程を担当したこと

では、掘り下げていきたいと思います。

 

プロジェクトの掛け持ち&慣れないプロジェクトリーダー

プロジェクトの掛け持ちと慣れないプロジェクトリーダーをやっていたことが一番の要因だと考えています。

 

僕のプロジェクトリーダーをやる前の背景は、以下になります。

  • メンバーポジションで案件に参画することが多かった
  • 僕のキャリアの80%が常駐案件
  • 常駐案件で人を指導した経験は有り
  • 受託案件(請負案件)の経験は1年のみ
  • 運用監視案件でシフトリーダーの経験は有り

このようにキャリアの大半が常駐案件で受託案件(請負案件)の経験が1年のみの状態になります。

 

この状態で受託案件(請負案件)のプロジェクトリーダーをやらなければいけない状況でした。

 

最初は、メールサーバーの移行方針策定支援案件の1つだけを進めていたので、まだメンタルに余裕がありました。
しかし、AWS基盤への移行支援プロジェクトに途中からアサインされ、掛け持ちをやり始めた時からメンタルが徐々に崩壊していきました。
片方の案件の管理をしながら、もう片方の案件のキャッチアップをする必要がある状況だったため、今思えば地獄でした。

 

特に一番地獄だったエピソードとしては、AWS基盤への移行支援プロジェクトの顧客定例に参加している最中に別のプロジェクト(メールサーバーの移行方針策定支援案件)のお客様から電話がかかってきたことです。
※当時、まだ僕が参画したばかりということもあり、顧客定例は他の方がファシリテーションをしていました。

 

お客様とはTeamsのチャットでやり取りができたので、

 

「今、打ち合わせ中で応対は厳しいです」

 

とチャットで伝えたのですが、

 

「今、どうしても連絡しておきたいことがあるんです!」

 

と言われ、途中で顧客定例を抜けて電話応対をしたことがあります。

 

電話の内容としては、システムの障害に関する話でした。
(説明すると長くなるので、今回は割愛します。)

 

この時は、どうにかしないといけないので、人に聞きながらも頑張って対応していました。

 

このように、「片方のプロジェクトを気にしながら、もう片方のプロジェクトもキャッチアップしなければいけない!」という状況が自分にとっては相当苦痛だったかなと感じます。

 

当時は、朝8時から勤務開始して、深夜0時迄働くようなことを1〜2ヶ月ぐらい続けていました。
このような生活をする中で、大きなプレッシャーと長時間勤務で心と身体が壊れていきました。

 

上司に何回も訴えかけたのですが、状況が変わることがありませんでした。
そのため、最終手段として心療内科に行って診断書を貰う選択しかなかったです。

 

このように、慣れないプロジェクトリーダーとプロジェクトの掛け持ちによってメンタルが崩れ、休職に追い込まれていきました。

 

プロジェクトリーダーの掛け持ちは、慣れてからやった方が絶対良いです。

さっとん

 

今まで経験したことがない技術の上流工程を担当したこと

今まで経験したことがない技術の上流工程を担当したこともメンタルが削れていった要因の一つだと思っています。

 

今まで経験したことがない技術というのは、メールサーバー周りになります。

 

例えば、

  • ExchangeServer
  • ExchangeOnline

などです。

 

この辺の技術に関しては、運用経験もなければ構築経験もなく、過去に勉強したこともなかったです。
AWS周りに関しては、資格取得や自己学習をしていたので、前提知識はありました。

 

もちろん、プロジェクトに参画が決まってからメールサーバーの勉強はしましたが、要件定義のフェーズだったのでお客様からの質問に回答できないことが多かったです。
技術的な質問への回答は、一緒に参画していたアーキテクトの方に基本的にお願いしておりました。

 

何も技術に関する経験がないため、お客様から詰められ、内部から詰められと大変だった記憶しかないです。
その一方で片方のプロジェクトの技術のキャッチアップをする必要があったため、生き地獄でした。

 

余程のことがない限り、対応する技術の運用構築経験がない状態で要件定義フェーズ等の上流工程のプロジェクトには参画するのはやめておいた方がいいです。
メンバーレベルなら何とかなりますが、リーダーだとかなりきついです。

さっとん

 

SIerでメンタルをやられないようにするためには?

 

SIerでメンタルをやられないようにするため大事なことは、以下だと思います。

  • プロジェクトに参画する前に要員募集の背景を確認する
  • 無理であれば無理とはっきり言う

では、掘り下げていきたいと思います。

 

プロジェクトに参画する前に要員募集の背景を確認する

プロジェクトに参画する前に要員募集の背景をしっかり確認しておくことは、本当に大事だと考えております。

 

なぜなら、要員募集の背景によってプロジェクトでの働きやすさが変わってくるからです。

 

僕がAWS基盤への移行支援プロジェクトに参画した背景としては、休職したプロジェクトリーダーの代わりでした。
ただ、前任のプロジェクトリーダーが休職したことを参画前は知らされておらず、「AWS」という言葉につられ「やります」と言ってしまいました。
「リーダーは厳しい」とは事前に伝えてはいたのですが、蓋を開けてみたらリーダーでした、、

 

こちらに関しては、要員募集の背景をきっちり確認しておけば、このようなことは無かったと今では思います。

 

実際にプロジェクトに入ってからも色々と大変なことが多かったです。
「なぜ前任者が休職したのか?」ということが実際にプロジェクトで働いていてよく分かりました。

 

このようなことにならないように、プロジェクト参画の打診があった場合は背景についてきっちりと確認しておく必要があります。

 

プロジェクトの要員募集の背景が「増員」の場合は問題ないですが、「要員交代」の場合は注意する必要があります。
特に「休職者の代わり」と言われたら、断っておいた方が良いです。

さっとん

 

無理であれば無理とはっきり言う

自分が無理であれば無理とはっきり言うことも大事です。

 

理由としては、無理と言えない場合、自分にとって無理なプロジェクトにアサインされてしまう可能性が高まるからです。

 

例えば、1つのプロジェクトでプロジェクトリーダーをやっていて、もう1つのプロジェクトのプロジェクトリーダーを打診された場合に「キャパオーバー」と思っていればはっきり伝えておくおいた方が良いです。
口頭でプロジェクトの参画を打診された場合に「無理です」と伝えた場合は、しっかりチャットやメールで履歴を残しておきましょう。

 

履歴を残しておけば、何かあったときの証拠になります。
上司が信用できなければ、何度もプッシュしておいた方が無難です。

 

僕の場合は、プロジェクトの参画を打診された際に「無理です」と言ったのですが、結果的のプロジェクトリーダーという立ち位置になってしまいました、
人によっては「無理です」と伝えても強制させる人もいるので、念押しはかなり大事です。

 

このように、「無理なものは無理だ」と自分の意見をはっきり言うことは本当に大事です。

 

SIer勤務で流されやすい人こそ、自分の意思はしっかり持った方が良いです。
一度プロジェクトに入ると、余程のことがない限り抜けづらいです。

さっとん

 

さいごに : メンタルはマジで大事

 

今回は、SIer時代にメンタルが病んでしまった話についてざっくばらんに記事を書きました。

おそらく、僕と同じような悩みを持っている方は、元請等のITピラミッドの上位のSIer勤務の方で多いと思います。

 

Twitterで何回も言っているのですが、メンバーだったとしても安易にプロジェクトの掛け持ちに手を出すべきではないと僕は思います。
プロジェクトリーダーという役割で2つのプロジェクトの掛け持ちをする場合、お客様からの問い合わせや苦情等がダイレクトに来るので慣れない内は本当におすすめしないです。

 

メンタルが一度でも病んでしまうと、社会復帰をする際に大変です。
そのため、無理なら無理で撤退する勇気や断る勇気を持っておいた方が絶対に良いです。

 

SIer以外もそうですが、仕事をする場合は自分のメンタルを最優先に考えましょう。

 

今回は、以上です。

 

  • Twitter
  • YouTube

 







-経験談
-,