仕事忙しくてメンタルやばい
今の職場合わないかも
どうすればいいか頭も回らない
そんな状況にならないように、もしくはなっていても回避できるような対策案を提示します！
システムエンジニアの仕事をしている中で、私がうつ病になったのは中堅クラスのキャリアだった時です。
自分の意識の持ち方（無意識の認知も含む）も大きく関係して、それが改善されることで回避できることも多いのですが、これに気づくには時間がかかります。
私も自分の認知に気づいて、うつ病のようなメンタル不調になってしまう原因がわかるまでに8年程度かかりました。
そこまでなる前に予防も含めて、やっておいた方がいいことなど、私がうつ病になった後、いろいろ考えている中で再発予防になったことを書いていきたいと思います。
自分の得意なこと言えますか？
システムエンジニアの仕事だけではないとは思いますが、それなりに長く同じ業界で仕事をしていると、自分の得意分野が１つ、２つできています。
自分の得意な分野はこれですと明確に言えますか？
それが言えないと、うつ病になってしまうような現場への配属や希望を出しての離任（異動）ができない場合が出てしまいます。
それは以下の通りです。
- 配属前の面談で間違って配属されてしまう
- 配属された現場でのスキルが合わないとき
- 転職を考えたとき
細かく解説したいと思います。
配属前の面談で間違って配属されてしまう
新しい職場に配属される場合、お客様先であればお客様と面談をし、問題ないと判断されると配属という流れが一般的です。
自社のプロジェクトへの配属の場合でも、上司やプロジェクトのマネージャーやリーダーと面談をして、やっていけそうであれば、配属という流れになると思います。
どちらも、若手であれば勉強をすることを含めて、とりあえず配属ということもあるのですが、ある程度の経験がある場合、その人のスキルを見てマッチしているかが判断基準になります。
その時に自分の得意なスキルが明確に言えないで、なんとなくこんなことやってきましたという言い方をしてしまうと、実はスキルが合っていないのに配属されてしまうことがあります。
私の場合を例にすると、うつ病になった後、しばらくは同じプロジェクトで休み休み作業をしており、その後に配属されたプロジェクトがまさにそうでした。
どういうことかというと、私はUNIX系の操作はそれなりにできたので、面談の際にそのことはなんとなくできると話していました。それ以外はプログラムに関してはC言語ができますと。
その情報だけ伝えて、問題ないということになり配属されたのですが、行った先のプロジェクトの作業は、LINUXのＯＳの保守で、私がやったことがないインフラよりの作業がメインのプロジェクトでした。
入ってすぐに今までやったことがないような作業ということはすぐにわかり、わからないことで日々不安、かつその現場のメンバーは何も教えてくれないという酷い状況。
詳しくは以下の記事を読んでいただけるとわかるのですが、これが自分のできることを明確にできていなかったことによる弊害で、知らないことが多すぎる職場に配属されてしまった例です。
これが、自分のスキル、できることを正確に把握していれば、もしかしたら回避できたことかもしれないものです。
最初の面談の際、仕事内容をもう少し聞き、自分の持っているスキルと照らし合わせる、もしくは自分が持っているスキルをはっきり言えれば、その職場には配属されなかったかもしれないということでした。
もちろん、それでも人で不足の昨今、多少のスキルアンマッチでは配属されてしまう可能性があります。
その点は、２点目以降で対策を提示します。
派遣された現場のスキルが合わない
配属前の面談で自分のスキルを話して、それで配属を決めてくれる場合はいいのですが、私がうつ病になった現場に配属された時、その配属先は典型的なトラブルプロジェクトだったため、とりあえず空いている人を呼び込んでなんとかしようとしている現場でした。
なのでスキルどうこうというものではなかったのですが、実際のスキルとしてはどうだったでしょうか。
そこで必要だったスキルは、
- オブジェクト指向言語のスキル
- Windowsサーバーでの開発スキル
- 開発途中での見積を実施するスキル
- 結構な人数（30人以上）のメンバーをまとめるためのマネジメントスキル
今考えると、当時の私の得意分野というかスキルは以下の通りでした。
- C原語（オブジェクト指向言語以外）のスキル
- LINUXでの開発スキル
- データベースがメインスキル
- 見積がとても苦手（あまりやったことがなかった）
- メンバー数名ならなんとかまとめられる程度のマネジメントスキル（サブリーダークラス）
どう思います？完全にスキルアンマッチだと思いません？
自分の得意なものがまったく使えない状態で、トラブルプロジェクトであるために、上司含めてみんなが忙しかったこともあり、特に教えてもらえるわけでもなく、はい、やって！と言われた状況です。
普通の現場であれば、ここまでスキルアンマッチであれば、行くこと自体を拒否できますし、行ったとしても行く前から難しいかもということを言っておいて、行ってから無理でしたということも可能ではあります。
この時に、自分の得意分野が明確であると、あまりにもスキルアンマッチである場合、それをプロジェクトから抜け出す理由にできます。
それでもプロジェクトに無理やり留めようとするのは、取引先にも自社としてもデメリットしかありません。
それでも、離任させてもらえないようであれば、メンタルが持たないと思います。
その場合がその会社がよくない、もしくは合っていないということになるため、転職を考えてもいいかもしれません。
そんな時にも自分の持っているスキルを知っておくことが大事になります。
それは次の項目でお話します。
転職を考えたとき
配属時、配属後にうつ病にならないように自分のスキルを明確にする必要性をお話してきました。
その２つの場面でうつ病になる前に異動、離任するなどができず、無理に継続させられてしまう場合があります。
人手不足のプロジェクトなど、なんとかしろ！と言われて続けさせられることもあると思います。
そんな会社にうつ病になってまでいる価値はあるのでしょうか？
私ははっきりNO!だと言いたいです。
世の中にはたくさんの会社があり、あなたの培ってきた技術を求めている会社、職場はいくらでも存在します。
うつ病に一回なってしまうと回復するまでに時間がかかりますし、もっと役に立つ仕事ができるのに、できないで自分がダメだと責めてしまうかもしれません。
そんなことに時間を使うのは無駄だと思いませんか？
そうなったら転職しかないと思います。
ただ、この転職時でも面談は必須です。なので、自分のスキル、得意なことをまとめておくことが重要になります。
面談で自分のスキルを明確にアピールすることで、そのスキルを使って仕事ができる職場がある会社に入れる可能性が高まります。
ここが曖昧なままだと、結局同じようなことを繰り返してしまい、うつ病になってしまう確率を上げてしまいます。
そして、転職後、配属が決まる時は１番目に記載した内容の問題にぶつかるわけです。
しっかり自分というものに向き合っておきましょう！
それができていないと私と同じ地獄を味わうことになるかもしれません。
スキルの把握する際の注意点
ここまで書いてきましたが、システムエンジニアの仕事をやっていて、定期的に経歴書の書き換えは実施しているかもしれません。
それだけでも自分のできること、得意なことを見つめなおす機会になっているかもしれません。
ただ、システムエンジニアの仕事は多岐に渡るため、技術スキルだけをピックアップしてまとめておいても足りません。
ある程度の経験を積んでくると、プログラミングができなくても仕事ができる立場になっていきます。
そこで技術スキルだけを把握しておくだけではなく、以下のようなこともまとめておくことをおススメします。
それぞれ、細かく解説します。
- 要件定義～システムテスト、運用など、どこのフェーズを実施したことがあるか
- チームリーダーとしての経験（配下は何人まで経験、プロジェクトの規模など）
- どの程度の規模の見積を実施したことがあるか（どの程度の規模を扱えるか）
要件定義～システムテスト、運用など、どこのフェーズを実施したことがあるか
システムエンジニアの仕事には、多少の違いがありますが、フェーズというものが存在します。
- 要件定義
- 外部設計
- 内部設計
- 開発（プログラミング）
- 単体テスト
- 内部結合テスト
- 外部結合テスト（システムテスト）
- リリース
- 運用保守
ざっくりこのような分類になります。それぞれの詳細な内容を書きませんが、実施するためのスキルがそれぞれ違います。
どのフェーズをやったことがあるかを明確にしておくことはとても大事で、それがわからずに配属されてしまうと、どう実施していいのかわからずに、不安に苛まれてうつ病までまっしぐらなんてことも起きえます。
内部設計～単体テストくらいのフェーズは、それをやってことがあるで済むかもしれませんが、それ以外のフェーズでは、その中で細かく自分ができるスキルを分類、まとめておかないとできないこともできるように伝わってしまい、酷い目にあう場合があります。
そんなことにならないようにスキルを詳細に分解してまとめておきましょう。
たとえば、システムテストなどは実施したことがあるだけ、というのと計画を立てた、実際の実施でいろいろなチームとの橋渡しをしたというのでは、レベルが違います。
その辺りも含めて詳細にまとめておくことをおススメします。
チームリーダーとしての経験（配下は何人まで経験、プロジェクトの規模など）
ある程度の経験を積んだ人はプロジェクト内でチームリーダーをやってことがあったり、もう一段階上のプロジェクトマネージャーを経験したことがあるかもしれません。
どの程度の規模のチームをまとめたことがあるのかは結構大事です。
チームリーダーを例にしますが、配下１名でもチームをまとめていればリーダー、配下が２０人でもリーダーです。
この規模が面談などで話す際に重要なこととなります。
この規模によって配属が大きく違ってくるからです。ここで間違えてしまうと、配下が数名のチームリーダーだったのに、いきなり配下２０人の大所帯を任されることになってしまったりします。
私は過去数名のチームリーダーしかやったことがなかったのに、うつ病になった時は配下３０名超のチームリーダーになり、勝手がわからず、やり方も数名の時と同じようにやろうとして失敗、結局うつ病でリタイアしました。
もちろんうつ病になってしまった原因は、それだけではありませんが、いきなり任されるにはギャップが大きいのは、かなりつらいものだと思います。
どこまでを扱えるのか、やれそうというより実際にやったことがあるレベルを正確に把握しておくことが大事です。
どの程度の規模の見積を実施したことがあるか（どの程度の規模を扱えるか）
これは私が痛い思いをしたので、項目を分けて書きたいと思います。
私は最初の入った会社は４年間在籍しましたが、その在籍期間中にまともな見積を実施したことがありませんでした。
やったこととしては、このプログラムの改修にどのくらいのかかる？程度のこと。
４年目になった時、チームのサブリーダーになりましたが、すでに終わっていた見積とスケジュールに合わせて配下１名を管理していただけ。
それが転職後２年目（キャリア６年目）にいきなり要件定義作業を任され、その後の見積も実施させられることになりました。
プログラムの改修に何時間？は答えられます。ただ、この時に求められたのは１システム全部の見積です。
当時そのやり方など誰も教えてくれず、結構大きな見積だったのに自分の会社のメンバーのレビューもありませんでした。
結果は酷いもので、完全に見積過少。実際に作業量、開発量に対してまったく足りていない見積だったため、集めた人の数が足りず、その失敗を責めた私は残業でなんとかしようとしてうまくいかず、結果うつ病になりかけました。
この時は、チームの体制や会社の対応もまずかったので、自分のスキルを把握しなかったことだけが問題ではないのですが、それをしていれば、自分が持っているスキルとあまりにもかけ離れたフェーズの仕事を任された時に、会社に働きかけて有識者を入れてもらうことや、それこそ離任することを相談することもできたのではないかと思います。
まとめ
ここまで書いてきましたが、ある程度の経験を積んでいるシステムエンジニアは、自分のスキルを把握せずに曖昧にしておくとうつ病になってしまうリスクがあるというお話でした。
これは若手の方も意識して定期的にスキルの棚卸しを実施しておくことで、先々痛い目にあうことを回避することに繋がるかと思います。
できることを増やしつつ、できることの把握を定期的に実施してください。
少しでもメンタル不調に陥ってしまう方が減ることを祈りつつ、今日はここで終わりたいと思います。
ここまで読んでいただいて、ありがとうございました。
