経験談

SIer時代に一番きつかったプロジェクトの話をします。

 

今回は、SIer時代に一番きつかったプロジェクトについてざっくばらんに語っていきます。

 

☑本記事の内容

・どんなプロジェクトだったのか?
・プロジェクトで辛かったこと
・辛いプロジェクトに当たった時の回避方法

 

☑本記事の信頼性

・SES/SIer の経験が合計で10年程
・請負と常駐の両方の経験有り

 

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

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

 

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

 

本記事を読むメリット

・実体験でのSIerの辛いところがわかる

 

今回は、僕が実際にやっていた実務をベースに記事を書いています。
ちなみに、ノンフィクションです。

 

Twitterでもこのように呟いております。
この時のプロジェクトの話になります。

 

 

 

今思えば、休職者が3人出ている時点で客観的に見てもヤバいプロジェクトだったなと思います。

 

以前に、このような記事も書いているので、併せて見てもらえればと思います。

 

 

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

 

どんなプロジェクトだったのか?

 

メンタルがやられた時にどんなプロジェクトに参加していたのかご紹介していきたいと思います。

 

  • プロジェクトについて
  • プロジェクト参画の背景
  • ポジション
  • 実際にやっていたこと

 

プロジェクトについて

当時、僕が参画していたプロジェクトは、某ICT企業向けクラウド移行支援プロジェクトになります。

某ICT企業の名前は出せませんが、数千人規模の会社になります。

 

内容としては、既存オンプレミス環境からAWS環境にシステムを移行するために、顧客先のAWS環境の整備や移行を支援するプロジェクトになります。

 

期間は、2021/01頃〜スタートしているプロジェクトになります。
僕は、2021/06の中旬に参画しました。

 

契約としては、準委任契約でした。
主に触るのがAWS環境だったため、客先常駐ではなく自社内勤務でした。

 

商流は、具体的に覚えていませんが二次請けだったような気がします。

 

プロジェクト参画の背景

僕のプロジェクト参画の背景は、

  • 僕の月の工数が「0.5」空いていた。
  • 1人メンバーが抜けるので、代わりに入ってほしいと言われた。

になります。

 

プロジェクトの参画については、直属の上司ではなく別の部署の上司から「どう?」と言われて承諾しました。
(当時の部署の構成については、説明すると長くなるので割愛します。)

 

社内のいろいろな部署から人を集めてチームを作って、プロジェクトを進めるような感じでした。

 

良いなと思った点

・AWSの実務経験が詰める
・メンバーとして参画できる
(片方のプロジェクトでリーダーをやっているのでリーダーは厳しいと事前に伝えた。)

 

その後に僕のプロジェクト参画が決定したとのことで話を聞いてみると、「プロジェクトリーダー」をやってもらうという話でした。
また、参画決定後に「休職したプロジェクトリーダーの代わり」と言われ、「それは聞いてないよ」と心の中で思いました。

 

当時、「プロジェクトリーダー」を任命されましたが「なんとかなる」と心の中では思っていました。
この慢心が後にメンタルの崩壊に繋がっていくことは、まだ知りませんでした。

 

プロジェクトへの参画決定後、プロジェクトマネージャーの方とTeamsで面談をしました。
その時のことを思い出すと、「言語化できない違和感」みたいなものがあったことを今でも覚えています。

 

現職で知識や経験が活きてはいますが、「AWS」という言葉に釣られて飛びついてしまったことを今でも後悔しています。

さっとん

 

ポジション

僕が当時やっていたポジションは、上で紹介している通り「プロジェクトリーダー」になります。

 

メンバーは全員で7人でした。

組織図で表すとこんな感じです。

 

 

 

途中からプロジェクトに参画したということもあり、代打でBPさんがリーダーのポジションを担当しておりました。
そこから、リーダー業務を徐々に自分に引き継いでいくという流れでした。

 

キツめの案件のプロジェクトリーダーを別でやっていたので、片手間で仕事を覚えなければいけない状況は鬼のようにきつかったです。

さっとん

 

実際にやっていたこと

当時の業務で実際にやっていたことは、以下になります。

 

実際にやっていたこと

・会議のファシリテーション
・課題の進捗管理
・AWS作業
・EC2インスタンスの構築
・AutoRecovery設定
・CloudWatch Logs設定

 

特に「会議のファシリテーション」や「課題の進捗管理」を対応することが多かったです。
AWS作業は、基本的にメンバーに任せていました。

 

「扱っていた技術」や「実際にどんな設定をしたのか?」の説明は、今回は割愛します。

 

「話が違うじゃん!」という気持ちと「とりあえず、やってみるか!」という気持ちが入り混じっていました。

さっとん

 

プロジェクトで辛かったこと

 

プロジェクトで辛かったことは、以下になります。

  • 1.5人月ぐらい働いているのに0.5人月契約であること
  • PMと馬が合わない

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

 

1.5人月ぐらい働いているのに0.5人月契約であること

これが一番辛かったです。

 

僕含め、メンバーの工数の契約が0.5人月でした。

 

しかし、実態としては、0.5人月で仕事が終わるどころか、1.5人月ぐらい働いていました。
長い時だと、朝8時〜深夜2時まで働いていました。
こちらのプロジェクト1つだけではなく、もう1つのプロジェクトを掛け持ちしながら対応していたのでキャパオーバーでした。

 

他のメンバーも同様の0.5人月契約のため、プロジェクトを掛け持ちしながら対応していました。
メンバーの中には、毎日朝9:00頃から深夜0:00迄働いている方もいました。
(その方も過労で休職をしています。)

 

このような状況を見ていて、

 

「なんで、0.5人月でお客さんと契約したの?」

 

と毎日思っていました。

 

エンジニア目線から見れば、「無理な契約を結ぶなよ」という話です。

 

個人的な意見になりますが、プロジェクトの掛け持ちは業務に慣れてからやった方が精神的にも良いです。
無理な契約を結んでプロジェクトを意地でも取ってこようとするのは、残念ながらSIerあるあるです。

さっとん

 

PMと馬が合わない

当時のPMと馬が合わなかったことも要因の1つです。

 

理由は、以下になります。

  • 頭ごなしに怒る
  • メンバーの苦労を理解しようとしていない
  • 前任のプロジェクトリーダーが休職したことに対しての改善の姿勢が見えない

 

もっと理由があったような気がしますが、挙げた3つの理由が大きいです。

 

僕もプロジェクトリーダー経験が浅く至らないところがあったことは自覚をしていましたが、とにかく頭ごなしに怒ってくるので毎日精神的にやられていました。
何か不明点を聞くと、口調強めで発言をしてくるので、非常にコミュニケーションが取りづらかったです。

 

また、他のメンバーが長時間労働で苦労しているのに労いの言葉が一切なく、自分のことばかり考えているよう思えました。
前任のプロジェクトリーダーが疲弊して休職してしまったことが働いてみてよく分かりました。

 

「前任のプロジェクトリーダーが休職された案件なので、プロジェクトリーダー経験が少ない自分で務まるか不安です」

 

とプロジェクトに入った時にプロジェクトマネージャーに言ったら

 

「え?なんで?」

 

という感じの反応をされたことを今でも覚えています。
その時に「この人は全然、悪い状況を改善しようとする意識がないな」ということを直感的に感じました。

 

メンバーへの理解がないプロジェクトマネージャーの下で働くと心が疲弊します。
お客さんが良い人だっただけに、非常に残念なプロジェクトだったという印象です。

 

こういうプロジェクトマネージャーにはなりたくないという典型的な例でした。
「そりゃあ休職するわ」と働いてみて感じました。

さっとん

 

辛いプロジェクトに当たった時の回避方法

escape

 

辛いプロジェクトに当たって、精神的に参った時の僕なりの回避方法は以下になります。

 

  • 「なぜなぜ分析」をして上司に相談する
  • 心療内科に行く

 

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

 

「なぜなぜ分析」をして上司に相談する

一番最初に取り組む回避方法としては、これが王道かなと思います。

 

この際に「なぜなぜ分析」をするということが特に重要です。
論理的にプロジェクトから外れたい理由を説明ができる必要があります。

 

「なぜなぜ分析」とは、「なぜ」を繰り返して根本原因を探る分析手法になります。
インフラのオペレーションミスをしてしまった際によく「なぜなぜ分析」をします。

 

僕はこの「なぜなぜ分析」が甘く、上司にうまく説明することができませんでした。
「人間関係」「業務」「勤務時間」に関して思うことを箇条書きにしてチャットで報告しましたが、「そのぐらいできる」という感じで一蹴されました。
今思えば、月75時間ペースで残業していたので、残業時間を掘り下げておけば良かったというのが反省です。

 

また、身体に出ている異常についても話をしましたが、受け入れてもらえなかったです。
(相談した相手はプロジェクトマネージャーではなく、直属の上司になります。)

 

実際に出ていた症状

  • 朝起きられない
  • 会社のパソコンの電源を入れると頭が痛くなる
  • 休日も仕事のことばかり考えている状態

 

上司も人それぞれで根性論の方も多くいます。
そのような方に話をしてプロジェクトから外れたい場合は、以下の本のフレームワークを利用して「なぜなぜ分析」をしてみることをおすすめします。
こちらの本は、会社の人から教えてもらい、今読んでいます。
(「なぜなぜ分析」や「As-Is / To-Be分析」等の分析手法がたくさん載っています。)

 

ビジネスフレームワーク図鑑 すぐ使える問題解決・アイデア発想ツール70 Kindle版

 

このように、上司にプロジェクトから外してほしいと説得をする場合は、納得感のある理由を話せる必要があります。

 

上司に相談しても厳しいようであれば、上司の上司等の決定権のある方に相談しましょう。

さっとん

 

心療内科に行く

会社内でいろいろ手を尽くしても厳しいようであれば、潔く心療内科に行って診断書を貰ってくるのが一番です。

 

なぜなら、診断書の効力は絶大だからです。

 

診断書は「お医者さんが働けないと判断した」という証明書であるため、プロジェクトから外れる大きな根拠になります。

 

僕も心療内科にはとてもお世話になりました。
社内で手を尽くしても改善されない状況だったので、「最終手段」ということで心療内科に行きました。
結果、休職ということにはなりましたが、自分を守るために行っておいて良かったと思います。

 

ただ、休職をするとキャリアにハンデを負うことになってしまうので、そこは理解しておく必要があります。
僕は精神的にも肉体的にも限界だったので、キャリアよりも自分の健康を重要視しました。

 

休職時の心情については、いずれ記事としてUPしたいと思います。

さっとん

 

さいごに : 無理なものは無理。大事なのは自分のメンタルと身体。

NG

 

今回は、SIer時代に一番きつかったプロジェクトについて記事を書きました。

このプロジェクトに携わったことによって、僕のメンタルがボロボロになってしまいました、、

 

何度もプロジェクトから外れようと試みましたが、簡単には抜けられなかったプロジェクトでもあります。

僕がプロジェクトから抜けてから1週間程度で代わりの人が参画していたので、

「代わりがいるなら、早く外してくれよ」

と心の中で思っていました。

 

元々、プロジェクトに参画した際に「無理だ」と思っていましたが、やはり無理でした。

このように一度、プロジェクトに参画すると簡単に抜けられないので、何度も言っていますが要員募集の背景はきっちり確認しておきましょう。

 

では、現場からは以上です。

 

  • Twitter
  • YouTube

 







-経験談
-,

Copyright© 元監視者のエンジニアブログ , 2022 All Rights Reserved Powered by AFFINGER5.