エンジニアの心の健康とストレスについて - 考察と幾つかのidea -
この記事について
目的
- ストレスの相互理解による健康的な宇宙の創造
手段
- 手始めに、エンジニア(僕)が感じるストレスの分析
発展
- 他職種のストレス分析
序
デザイナーが一番ストレスに感じることとは何か。
僕らはこの質問に答えられるだろうか。
- 好きなデザインをさせてもらえない
- デザインの重要性を理解しない上司が多い
- 具体的な課題を設定せず「こんな感じで作って」といわれる
こんなものなのかな、とそれらしい想像をすることはできる。
自分が一番考えて作ったUI案ではなく、 適当に５分で作った案が採用しばしば採用される。 僕はそれが一番ストレスかな。 - by とある社内UIデザイナー
あの職種の人の一番のストレスってなんなんだろう。
こういうのって、想像はできても本人の言葉で聞く機会って意外とないよね。
という立ち位置からの話。
目次
- 裏切り発見モジュール
- まなざしの地獄
- エンジニア同士のよい関わり方
- エンジニア以外とのよい関わり方
1. 裏切り発見モジュール
進化心理学という学問での仮説に、 “心のモジュール性”という言葉がある。
心が特定の機能を果たすために 個別の生得的な構造を基盤に持ち、 それぞれが進化的に発達したという概念である。
つまり、心にもライブラリやモジュールがあるのではないか、という話だ。
ウェイソンの4枚カード問題
この問題を解くことができるだろうか。
論理的思考が得意な人にとってはさほど難しい問題ではないかもしれない。
では、この問題はどうか。
1問目の答え：A,7
2問目の答え：酒,17
実は、この問題は全く同じ論理の問題構造となっている。
にもかかわらず、2問目の正答率が圧倒的に高いという実験結果がある。
この結果を受けた仮説に、以下のようなものがある。
常識/倫理観や、ときには損得勘定が 高い論理的思考力を引き出すトリガーとなっているのではないか。
少々誇張してこれをわかりやすくいうと、
人間は、裏切りものを発見する際裏切り発見モジュールによって高い能力を発揮するのではないか。
というものだ。
この仮説が正であるとすると、人間は裏切りに対し高い”能力”を発揮するという。では、感情はどうか。
やはり強い感情を持つのだろうか。
エンジニアである僕らが強い感情を向けられるのって、いつのことだろうか。
会社におけるエンジニアの”裏切り”とは何か。
責務を放棄することなのか、バグを起こすことなのか。
そもそもエンジニアの責務って、一体なんなのだろうか。
2. まなざしの地獄
僕らの責務は、バグを起こさないことなのだろうか。
以下は、僕がよく経験する業務上関係三者の言い分だ。
先輩エンジニア
バグを起こすのはしょうがない。 次に繋げられれば問題ない。
事業部門担当者
なぜバグが無くならないんだ。 正常に動くのが当然のはずだろう。 あいつはダメなんじゃないか。
エンジニア本人
なぜバグを起こしてしまったんだろう。 なぜこうも責められるんだろう。 普段既存のバグを修正している成果は、 見られてもいないのだろうか。
この歪な関係の根源は、以下のような考え方の違いによるものだと僕は考える。
エンジニアの考え：
仕様通りに動くよう頑張ろう。 バグを起こさないように頑張ろう。 ついでに他のバグを直しておこう。
エンジニア以外の考え：
仕様通りに動くのは当然だと思う。 バグを出すエンジニアはダメそう。 余計なことをして工数を伸ばさないで。
さらに突き詰めていけば、
- 当然に期待されているもの
- 評価される(する)もの
の2点において双方にギャップがあると予想できる。 このギャップこそが双方にとってのdisコミュニケーションを生じさせているのではないだろうか。
当初の目的を振り返って、僕が本人の言葉でストレスの原因を語るのならば。
見て欲しいところは見てもらえない。 見逃して欲しいたった一つのバグで、 信頼が失われていくのが目に見える。
ということになる。
この状況を僕は"まなざしの地獄"と名付けたい。
僕らの責務は、バグを起こさないことなのだろうか。
バグが起きることは即ち、僕らの責任なのだろうか。
責任、という単語が出てきたところで、考察はここまでとする。
次章以降は僕の実体験に基づく経験談を話したい。
3. エンジニア同士のよい関わり方
エンジニア特有の文化に、コードレビューというものがある。
コードレビューとは？
誰かが書いたプログラムを、 チームみんなでレビューをすること。 僕のチームでは、 レビューを通らないプログラムは、 誰が書こうが原則リリースされない。
この文化は本当にいい文化である。
今一度、このコードレビューという文化が持つ機能を整理したい。
コードレビュー４機能
- コード品質の向上(維持)
- 業務の相互理解
- 責任の分散
- サービス(チーム)への帰属意識向上
1. コード品質の向上(維持)
コード品質の向上(維持)といっても、実はここにも二つの意味がある。
- コードそのものの品質向上
- チームとしてのコーディング力底上げ(均一化)
コードそのものの品質向上
これはいうまでもないが、汚いコード、次に改修をかける際に不具合を招きそうなコードは指摘を受ける。
汚いコードはリリースされない。
チームとしてのコーディング力底上げ(均一化)
指摘とリファクタリングを繰り返すことにより、"この場合はこう書いたほうがいいんだな"というチーム内認識が共有される。
時にはレビュアー同士で議論が巻き起こる。
何が良いコードで何が悪いコードなのか、各々が自身の考えを持つ時間が得られる。
これを繰り返すことによって、チームのコーディング力が底上げされ、ある程度均一化される。
大切にする思想は人それぞれにせよ、確固たる"こだわり"を持って書かれたコードは全ていいコードだ。
僕はそう考えている。
2. 業務の相互理解
チーム内でも、誰が何をやっているのかそこまで把握していない状況はよくあると思う。
朝会や日報報告をやっていたとしても、それが何のための機能なのか、どんな仕様なのかまでは知り得ない。
そこで便利なものがプログラミング言語だ。
エンジニア同士では、日本語で説明するよりも書いたプログラムを見せる方が話が早く終わることが多く、
コードを読めばある程度の仕様は把握できる。
ああ、この人はこういう機能を作っているのか、こういった仕様で、こういった目的のものなのか。
以上の情報共有作用があることによって、コードレビューをすることでエンジニア同士のコミュニケーション不足や不満(あいつ何やってんだ感)が解消される。
3. 責任の分散
この責任の分散こそ、コードレビュー4機能において最も重要な機能だと僕は考えている。
レビューをして、承認するということは即ち、コードの保証人になるということ。
これによって、バグがあっても、その責任は個人ではなくチームのものとなる。
バグを起きた時に、人を責めることも他人事でいることもできなくなるシステムだ。
何も、不具合や不祥事を起こして会社に不利益をもたらすことなどエンジニアだけの話ではない。
しかし、システム障害というものは非常にやっかいだ。
他の業種よりも遥かに、大きな欠損を引き起こしやすいと言える。
新卒のよくわかっていない段階でも現状のそれなりに仕事を任されるようになった段階でもその状況は変わらない。
僕自身も数時間分の欠損を出したことがあるし、その際は死にたくてたまらなかった。
その欠損をエンジニア個人の責任にするには日本におけるエンジニアの給与は安すぎるし、何よりそんな仕事をさせていると辞められてしまう。
互いに互いを守る手段、として互いに責任を保持する文化、とても効率的でやさしい機能だ。コードレビューは美しい。
4. サービス(チーム)への帰属意識向上
これもまた重要な機能である。
就活生にエンジニアというと、"言われたことをやるだけのやりがいがない仕事"だとか、”個人プレー”だとか思われることがあるが、決してそんなことはない。むしろその逆で、自分から業務の効率化や売り上げ増加に向けた企画を考え実行していくことが当然求められるし、個人よりもチームを重視して動くことの方が遥かに多い。
エンジニアのチーム作りに関しては様々な書籍が出ている。googleやマイクロソフト、アップル、はてな、クックパッドなどエンジニアの強い会社で培われてきたチームビルディングのノウハウはエンジニアならば誰もが興味を抱くものであり、そのあたりの本もよく売れている。実際僕も僕の上司も何冊かチームビルディングの本を読みいくつかのテクニックを実践している。
話をコードレビューに戻すが、責任の分散によって一人一人がサービスの広い範囲に責任を持つ構図ができることは先述した。 責任の分散がもたらすものは文字通りのものだけというわけではなく、チームへの帰属意識向上という側面がある。責任を持つということは、評価を得るということ。売上に大きく貢献した機能は、誤解を恐れずに言えばレビューを行った全員の手柄であるのが当然のことなのだ。
開発を進め、レビューを繰り返し、サービスのいたるところに自身の責任を置くことはすなわち、サービス全体を自分の仕事領域と意識させることである。サービスを愛しているか否かは別として、自分の仕事が何なのかはっきりと認識できることはモチベーションに大きく影響を与える。僕のチームではメインエンジニアはいない。一応組織的に僕がリーダー的な立場をとることもあるが、全員が全員メインエンジニアであると僕は正しく認識している。誰もが自分のサービスに責任をもち、自分のサービスを自身の評価と直結されることを認識している。
こんないいチームが作れているのは、コードレビューのおかげだと今はっきり感じている。
何かあったらみんなのせい、何もなければみんなの手柄
この意識を持ったチームを作ることこそ、エンジニア同士のよい関わり方である。
4. エンジニア以外とのよい関わり方
- "裏切り者"ではなく"共犯者"となる
- 互いの責務の線引きをはっきりする
- 要件のさらに前、要求定義をじっくりする
1. "裏切り者"ではなく"共犯者"となる
これはコードレビューにおける"責任の分散"にヒントを得た考え方だ。
最も効果的なやり方としては、エンジニアだけで要求定義、要件定義、リリース前テスト、リリース後テストをしないということである。
全ての段階でコンセンサスをじっくりとること。
"そんな感じでいいよ"というような曖昧な合意ではなく、"これでいきましょう"という強い合意を得ることが何よりも大切である。
要件漏れやテスト漏れがあればバグは起こる。
バグは、何をしても起きる時は起きる。
バグが起きた時に自身ばかり責められるのが嫌なのであれば、互いの責任となる状況を作るべきだ。
他人を責めるのではなく、共犯者と"ここがいけなかったね、次からはこうしよう"と話合えることの方が遥かに建設的な仕事と言える。
2. 互いの責務の線引きをはっきりする
ヤマアラシのジレンマという言葉を知っているだろうか。
寒さを感じているヤマアラシは、自身を守るトゲが邪魔をして他のヤマアラシと身体を温め合うことができない。
結局トゲが刺さらないギリギリの距離に近づくことしかできない。
という話である。
エンジニア以外との関わり方もこれに似たものがあって、
互いを突き放すでもなく、かつ近づきすぎない、ある程度の距離を保つことが重要と言える。
ここからここまでは私がやります、ここから先はあなたが。とあらかじめ互いの責任を明示すべきである。
相手がその責任を果たしていない場合は正当性をもって意見しよう。
代わりに自身が責任を果たせていない場合はなぜ果たせなかったのかを分析反省し、改善に向けての行動を素直に行おう。
馴れ合いも敵対も避け、ドライな関係を保つことが大切ということである。
要件の前に、要求定義をじっくりする。
エンジニア以外には、基本プログラムの話は通じない。
そのため、‘何がしたいか’等低次元から相互のことを理解することが重要である。
プログラムの動作については相手は知らないし、
必要としている機能やビジネスとしての動きについては相手の方が基本的に詳しい。
互いにリテラシーによる齟齬を避けるためには、何が欲しいのか、どうして欲しいのか、丁寧な要求定義が必要だ。
エンジニア以外とのよい関わり方
仲良くなって 仲良くなりすぎないで ある程度甘えて あまり甘やかさないで お互いを理解して
終
エンジニアといっても実際の業務内容や環境が幅広く、
僕が感じているストレスをエンジニア全員が抱えるストレス、と言い切ることはしたくない。
しかし、それなりの数のエンジニアが似たようなことを感じているのではないかと思う。
人間は欲求不満な生き物で、きっとどれだけ生活や自身や環境を改善してもないものねだりをしてしまうのだと思う。
けれども、今一緒に働いている人間がどういったことを不満に思っていて、それはどういった構造が原因となっているのか。
それを知るきっかけを作ることや、翻って自身について考えてみよう、とする姿勢はとても素敵なことに思う。
本投稿は"ストレスの相互理解による健康的な宇宙の創造"を目的にしていると冒頭に書いた通り、自分の辛さを理解してもらうことや、相手の辛さを理解しようと試みることによって、より働きやすく生きやすい世の中になっていってくれればいいと僕は思う。
労働なんてね、基本的に辛いもんだよ。みんながみんなね。
