スマートキャンプで業務委託でエンジニアをしている佐藤です。BOXILの開発を1年3ヶ月前から、沖縄からフルリモートでやっています。
皆さんは、毎日楽しくお仕事できていますか？ エンジニアという職業は労働時間やストレスが多く、IT業界は他の業界と比べて精神疾患にかかりやすいと言われています。
私はもともと自己否定ばかりしてしまう思考の癖があることに加えて、7年前に起業に失敗してメンタルを壊してしまったことをいまだに引きずっていて、日々悩みながら生活をしています。
スマートキャンプは、過労とは無縁で、メンバー間のサポートもよく、これ以上ないくらい私に合った職場です。それでも自分の心の問題で不安になったり、絶望感に襲われたりすることがあります。今回はそうなるたびに書き綴ったメモを、開発中にネガティブな気持ちにならないための技術としてまとめようと思います。
メンタルが強くないエンジニアはこんな気持ちになる
皆さんは、開発中に以下のようなネガティブな気持ちになったことはありませんか？
- ひとつのタスクに時間をかけすぎている。この程度のことをなぜ解決できない？と自分を責める。
- リファクタできるかやってみます！と言って2時間ほど作業をしたが、思ったよりもコードが複雑で何もできずに時間を無駄にした。
- プロジェクトにライブラリを導入するための技術調査で、調査の終盤でプロジェクトでの要件を満たせないことがわかった。せっかく時間をもらったのに何も残せなかった。
ほかにも、開発中に
- 仕様の考慮漏れが見つかって血の気が引いた。自分はぜんぜん貢献できていないと思った。
- 朝起きたときから気分が憂うつ。昨日の夜にレビューを依頼したコードは批判されるに違いない。
- レビューで指摘してもらったコードをうまく書き直すことができない。自分の技術力のなさを見せたくないので、冷や汗を書きながら作業をしている。
とか、開発中以外でも、
- 人に頼むのは遠慮するところがあるなぁ。実装方針の相談や、コードレビューの依頼とか。
- 自分の話をするのが苦手。誰も自分の話なんか興味ないのになぁと思う。
- せっかく1 on 1をしてもらったのに、本当の自分の悩みを知られたら変に思われるんじゃないかと思って緊張してしまった。
など、私は頻繁にネガティブな気持ちになります。
ネガティブな気持ちになった原因を分類してみる
上記のリストを眺めてみると、ネガティブな気持ちは以下の3つに分類することができそうでした。
- スピード（タスクが遅れていること）に対しての不安
- 品質（実装内容）に対しての不安
- コミュニケーションに対しての不安
コードをすばやくきれいに書けて人柄も優れていれば、理想のエンジニアと言うことができると思います。それができないときにネガティブな気持ち、すなわち不安になるようです。
具体的には以下のようなものがあります。
a. スピード（タスクが遅れていること）に対しての不安
- タスクに時間がかかり過ぎている
- 作業が遅いと思われているに違いない
b. 品質（実装内容）に対しての不安
- 考慮漏れがあるかもしれない
- うまく実装できなくて情けない、恥ずかしい
- 不具合が出るのが心配
c. コミュニケーションに対しての不安
- 自分が担当の仕事でメンバーに迷惑をかけたくない
- 困っていてもメンバーに頼ることができない
- ありのままの自分を出せていない
ネガティブな気持ちにならないための技
「a. スピード（タスクが遅れていること）に対しての不安」への技
まず、「スピードに対する不安」に対処する技を紹介します。
進捗をつぶやきまくる
簡単なタスクなのに時間がかかり過ぎていると思われないようにするためには、進捗をつぶやきまくる技が有効です。Slackで想定と違ったこと、辛いこと、時間がかかっていること、はまっていることなどを1日に何度もつぶやきます。助けてもらうことやアドバイスをもらうことが目的ではないので、文章はまとまっていなくてもいいです。「実は難しいタスクだった」ということがアピールできればOKです。
メンタルが強くない人は自分で自分の作業を「遅い！」と責める思考になることが多いです。本当の目的は他のメンバーに大変さアピールすることではなく、自分で自分に「そういうこともあるよ、仕方ないよ」と言い聞かせることだったりします。
Slackのチャンネルは、自分専用の分報（times_xxx）を使うのが一般的ですが、自己主張が苦手な人は自分のチャンネルを開設するのに抵抗があるかと思います。なので、チームのチャンネルがあると気が楽です。BOXIL開発チームでは、「#boxil_dev_心」というチャンネルがあります。
以下、Slackの実例です。
原因が見積もり失敗にある場合、プランニングを重視する
タスクに時間がかかってしまった原因が、実際にコードを見てみると作業項目が見積もりよりも多かったということはよくあると思います。
その場合は、タスクに着手する前のプランニングをしっかりやるようにします。BOXIL開発ではスクラム開発の手法を取り入れているので、この記事でのプランニングとはスプリントプランニングを意味しますが、ウォーターフォールでは「内部設計」のフェーズに相当します。
プランニングで具体的な実装を考える文化がない場合は、チームリーダーに「事前に〇〇さんと実装方針を確認させてください」と言うようにするといいでしょう。メンバーの誰かとプランニングをしておくと、実装中に困ったことがあったら相談しやすいというメリットもあります。
さらに、プランニング後に追加作業が発覚した場合、プランニング時に作った細かなタスクの一覧に、「[追加] タスク名」のようにそれがわかるように項目を追加しておきます。自分の技術不足のために遅れたのではないことを示すことで、自分を守ることにつながります。
「b. 品質（実装内容）に対しての不安」への技
次に、「品質に対しての不安」に対処する技を紹介します。
実装方針を決めておく
品質に不安を抱えないために、ここでも事前のプランニングが重要になってきます。実装方法が見えていないときや複数考えられるときもちろん、そうでないときも、タスクに取り掛かる前にチームメンバーと実装方針を決めておくといいです。
そうすれば、もっとよいやり方があるんじゃないかという不安をずっと抱えたまま作業することや、うまく実装できなくて情けない思いをしたりすることがなくなります。
実装方針のプランニングは、複数人で実際のコードを見ながら、誰が書いても同じようなコードになるレベルまで話すのが望ましいです。
設計好きなメンバーに設計を相談する
チームメンバーのなかで、設計の話が好きな人がいればチャンスです！ たとえ忙しそうだったり、別のタスクの担当だったとしても、隙をみて話しかけてみるといいです。設計の話は、その人にとっては息抜きみたいなものです。
PRにコメントを書く
実装後に不安に思っていることはとりあえず全部PRに書いておくと、実装がイマイチだったとしても「ちゃんと考えている」ことをアピールをすることができます。PRの本文に「確認してほしいこと」という項目を作ったり、PRのFiles changedのコードに実装について考えたことをメモします。
メンタルが強くない人は自分に自信がないため、「バカだと思われなくない」と考える傾向があります。PRでは先手を打っておきましょう。
「c. コミュニケーションに対しての不安」への技
最後に、「c. コミュニケーションに対しての不安」に対処する技を紹介します。
ランチに誘う
困っていてもメンバーに頼ることができない、ありのままの自分を出してコミュニケーションが取れないと感じる場合は、仕事外でのコミュニケーションが不足しているからかもしれません。
普段からランチに誘ったり、仕事で助けてもらったお礼にお酒をごちそうしたりするなど 、仕事以外でのカジュアルなコミュニケーションを増やすといいです。
私のようにフルリモートのエンジニアだったら難しいところがあり、課題に感じているところなのですが、業務時間内で雑談時間を作るなどの工夫しています。
まとめ
メンタルを強くするためには、今回のようなテクニック的なものだけでなく、マインドフルネス瞑想や心理学などでネガティブな感情に対処できるようになることが重要だとは考えています。それはそれでやりつつ、今回は仕事における工夫で不安をなくすテクニックをまとめてみました。
もともとメンタルが強くない、もしくは何らかの原因で一時的にメンタルが弱っているエンジニアの方が、少しでも仕事をしやすくなれば幸いです。
