産業医から見たエンジニアのうつ病対策

みなさん、こんにちは！
産業医の榎本純也(@EJ_appdate)です。

　企業で働くエンジニアの従業員さんがメンタル不調(イメージしやすくするため以下うつ病という単語に置き換えます)を起こしてしまい、困った経験はないでしょうか？

　エンジニアさんと一言で言っても業務内容は企業により多種多様です。しかし、その中でも共通して言えることは多くあります。今回の記事は、企業の労務担当者さんに向けて、エンジニアさんが うつ病 を起こす成因と事例を交えて紹介することで、エンジニアのうつ病を未然に防ぐことを目標といたします。

エンジニアのうつ病対策

目次

1. メンタル不調総論
2. エンジニアの うつ病 の特徴
3. エンジニアの うつ病 が起きる原因
4. エンジニアの うつ病 の予兆
5. エンジニアの うつ病 の対応
6. エンジニアの うつ病 を起こさないようにするには

＜メンタル不調総論＞

厚生労働省によると、「精神及び行動の障害に分類される精神障害や自殺のみならず、ストレスや強い悩み、不安など、労働者の心身の健康、社会生活及び生活の質に影響を与える可能性のある精神的及び行動上の問題を幅広く含むもの」と定義されています。
　
　一般的にエンジニアはメンタル不調発生が多いと言われております。誰にでも起きる可能性があり、100%防ぐことのできるものではありませんが、高ストレスの状態を極力発生させないように作業環境や作業手順を管理することで大部分が未然に防ぐことができます。よりイメージしやすくするため、うつ病という言葉に置き換えます。

＜エンジニアの うつ病 の特徴＞

　前提としてエンジニアの業務内容は非常に特殊性が高く、非エンジニアにとっては原因を探るだけでも大変なケースが多いです。そのため、ある程度進行してから初めて周囲が気づく、ということが多いです。原因としては以下の４つに大別されます。

＜エンジニアにうつ病が発生する原因とその結果起きうるストレスのタイプ＞

　大きく分けて４パターンに分類されるかと思われます。実際にはこれらの要因がオーバーラップして存在しております。

➀コミュニケーションの問題

①-１ 非エンジニアとエンジニアのコミュニケーションの問題
まずは、非エンジニアとのコミュニケーション不足が挙げられます。　プログラムを動かすために「プログラミング言語」と呼ばれるエンジニア特有の「言語」があります。この点が非エンジニアさんと満足度の高い「コミュニケーション」を取れなくしている要因になりえます。プログラミング言語を非エンジニアが理解すれば解決する、という単純なものではありませんが、お互いが歩み寄る時の大きなハードルとなっているのは間違いありません。同様に非エンジニアとの認識のズレが原因となることがあります。例えばバグは必ず存在するもの、ということはエンジニア界では常識ですが、非エンジニアにはなかなか理解されないところであります。
また、非エンジニアにとっては些細な変更指示でも、システムの内情を熟知したエンジニアから見れば骨幹を揺るがしかねない仕様変更となっているという例もあります。

①-2　エンジニア同士のコミュニケーションの問題
　また、エンジニア同士でも過去に経験した開発手法や仕事の進め方によってはそもそもお互いが合わないということがあります。その結果、ストレスチェックの項目でいう「対人関係」、「職場環境」でのストレスは増大し、サポート体制が不十分となってしまいます。

②ノルマの問題
　

昨今、テクノロジーの進歩によりビジネスの成長速度が過去にないほど速く、そのためストレッチ目標を大幅に超えた無理なノルマ設定となってしまうことが多々あります。また慢性的にエンジニア不足であることも背景にあります。またノルマ設定は後述するコードの健全さに大きく影響します。　無理なノルマ設定は、「心理的な仕事の負担(量)」を増悪させてしまいます。

③技術的な問題

③-１エンジニアの能力が職責や組織、ポジションに合致していない
　冒頭で説明した通りエンジニアと言っても色々な仕事があるため担当領域が広く分類されます。今回はのブログではエンジニア分類に関する詳細は省略致します。すべてを一人で行えるようなフルスタックのエンジニアはフリーランスで仕事をしたりイケてるベンチャー企業が取り合ったりしているため、一般的なエンジニアさんは何らかの領域があると考えるべきです。その場合、適性に応じた人事戦略を実行できなければ人材の不適切配置が生じることがあります。

　例えば、システム全体の設計を含めて担当してもらうつもりで採用したにも関わらず、設計経験がないエンジニアさんが採用された場合、お互いのニーズがアンマッチしてしまい、求められた能力と発揮できる能力が大きく乖離します。一般職でも人材の不適切配置は うつ病 の大きな原因となりますが、エンジニアのそれは専門性が高いため傍から見て非常にわかりにくいのが特徴です。

③-2　コードの不健全性

　身体であれば健康診断で現在の状況を定期的に確認しますが、コードに関しては携わる人以外が認識することはまずありえません。不健全なコードは有害以外の何物でもなく決して放置してはいけないものです。不健全なコードは「スコープが広い、ネストが深い、変数名が不適切、思考の過程をコメントとして残していない、逆に不要なコメントが多い、」　などと僕は考えます。

　これらの不健全なコードは、開発状況やリソースを無視したノルマを立てられたため、何とか間に合わせる、ということをくり返していくうちにまるでスパゲッティが絡まっていくかのように発生します。

これらの結果、「心理的な仕事の負担(量・質)」を増悪させてしまい、、「仕事のコントロール」ができなくなります。

④環境の問題

　例えばAWSやGsuiteなどのクラウドサービスが使用できなければ開発環境がかなり限定されてしまいます。エクセルしか使用できないという会社もまだまだたくさんあり、このような会社での開発は手段も限定されてしまいます。
　
分担に関しても開発チームにより境界領域を細かく設定しているのか開発手法はウォーターフローなのかアジャイルなのかなどもストレスの原因となりえます。

　これらは「心理的な仕事の負担(量・質)」、「職場環境」、「仕事のコントロール」、「技能の活用度」に影響します。

＜エンジニアの うつ病 の予兆＞

　特にエンジニアに特有の予兆はないかもしれません。抑うつ傾向、頭痛、説明のつかない痛み、倦怠感、出勤時間が乱れてきた、リアクションや表情が乏しい、イライラしているなど、一般的な うつ病 の症状・前駆症状です。

　ただし、一般職と比較して実際に会ってのコミュニケーションよりチャット等のツールを使うことが多いため、予兆に気が付きにくいという特徴があります。その場合はチャットのリアクション、返信までの速度などに現れることがあるため、普段との違いを意識する必要があります。

＜エンジニアの うつ病 を未然に防ぐには＞

　労働衛生の３管理に基づき対応します。

まずは作業環境管理です。開発環境に関しては、その選択（例えばクラウドは使用しないなど）に明確な意図があるかどうかを労務担当の立場より各関係者に調査します。その結果、特に明確な意図がなければある程度の柔軟性を持たせるのが良いかと考えます。明確な意図があり開発環境を変えることができなければ、人的リソースの確保に努めるべきです。次に作業管理です。職務範囲や組織からの期待値、目標を明確にしてください。その目標を達成するためにどのような仕様が必要かを明確にして不要な開発は控えましょう。ただし、今後開発する可能性が高いものはあらかじめ伝えておき、現時点のシステム完成像、未来の完成像を作ってください。また定期ミーティングで必ずコードの健全さを確認する時間をとってください。最後に健康管理です。定期的に 1on 1　のミーティングをすることをお勧めします。技術的な問題がわからなかったとしても、歩み寄る姿勢は人を安心させます。エンジニアさんに確認の上、希望された場合は技術者との面談も効果的と考えます。

　　また社内のみでの解決が困難であれば産業医に相談することが良いと思います。弊社はITに詳しいカスタマーサクセスチームがあるため気軽にお問い合わせいただけますと対応いたします。

　
次回からは事例を交え、上記をもっと堀下げていきたいと思います。