エンジニアがメンタルをやらないための処方箋
エンジニアが労働災害になる場合のイメージはメンタルダウンである。工場のように工作機械がないから通勤災害を除けば、物理的に怪我をすることがほとんどない（実際は、インフラエンジニアはデータセンターでのラッキング作業などで怪我をすることもあるし、オフィスで転倒することだってある）。それよりは、10人いれば1-2人はメンタルダウンで長期療養しているか復職したか病状が進行形だったりする。
自分のメンタルのヒヤリハットは、いま思い出せば、あれは精神的にダメージを受けていたのではないかと思う案件や一歩間違うとメンタルも体力的にもやばいぞと気をつけていた案件を思い出す。
一度メンタルに罹患すると病気とお付き合いしながらの人生になるようだ。ようだとしか書けないのは、産業医や保健師から教えてもらったり、罹患していたエンジニアを部下に持った経験からの経験則からだからである。
ではどうしてメンタルダウンに罹患するのだろうか。自分の前者のケースで思い出すと、プロジェクトでのチーム内の人間関係だったような気がする。後者は完全に縦お直し案件での業務量過多である。
厚労省の調査結果がある。
アンケートによれば原因はダントツで62.6%『仕事の質・量』だという。続いて、仕事の失敗、人間関係なのだそうだ。
引用 厚生労働省 平成29年 労働安全衛生調査（実態調査） 結果の概況
自分の経験からメンタルやばい案件は原因の3つのうち、2つが一致していたから20年くらい実際の現場と変わっていないのだろう。
その点で、開発の現場で心理的安全性に注目され始めているのは良い兆しなのかもしれない。
年代別に見ると、40代は『仕事の質・量』と『対人関係』の度合いが一番高い。『対人関係』は30代と50代が同程度高いのは、多分理由が違う。30代は役割が高くなる年齢であり、50代は役割から外れていく年代だからだろう。
引用 同上
ストレスを感じる理由の選択肢の中で『会社の将来性』で30代と40代が高いのは昨今の早期退職や配置転換でリストラが身近なのか、事業に関わる業務が見えてきて、組織の事業の将来に希望が持てないからだろうか。
引用 同上
- 仕事の質
タスクに手をつける前に、タスクの見積もりをチームで行うことをしたい。チームでの見積もりの中で、次の項目を話す場を設けて、合意してから手をつける。
ー 制約条件
ー アウトプットの品質（仕様）
ー 完成状態（終わったと言える状態）
ー 成果物
ー 規模（プランニングポーカーでも理想時間でも良い） - 仕事の量
仕事の量は、抱えている仕事が見えていないから、他のタスクをやれないかと勝手な期待をされたり、自分で進行状況が理解できていないから手を出してしまったり、見積もりをしていないのに根拠なくやれるだろうと間違った判断をする。
ー カンバンでタスクを見えるようにする
ー リソースは1人1であることを認識する
ー 1日のうち正味で作業に充てられる時間を最大限にする（会議では進捗しない）
ー チームでタスクの優先順位をつける
ー カンバンのWIPは1以下にする
ー タスクを抱えているのに差し込みされそうになったら、どちらを優先するか判断させる - 対人関係
チームの価値観を醸成する。端的に言えば、タスクのアウトプットの質（仕様）を確保するためにどうしたらいいかをチームで考えることをチームの是とする。
ー 自分を扱って欲しい態度をメンバにとる
ー 自分はメンバと同じ性質ではない
ー タスクはモブでする
ー 泊まりの合宿をして一人ひとりの判断基準を見せ合う
ー 役わりが違うからこそ、困っていることを話す
3つ目の対人関係は、PMBOKのプロジェクトマネジメントでもアジャイル開発のシステム開発手法でも生産性を向上するツール＆テクニックでもない。一番エンジニアに近く、その人なりが出るマインドセットである。
逆に言えば、1つ目と2つ目は手法であるから教育すればどうにかなるが、３番目はそうは行かない。成功体験を与えないと後天的に性質として身につかない。
