自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話

はじめに

　当記事を開いてくださりありがとうございます。私は表題の通り、私は一般にメガベンチャーと呼ばれる自社開発企業で機械学習エンジニアとして勤務しはじめてからわずか半年で、鬱を発症し退職することになったものです。この会社は待遇も良く、社風としても労働者思いのとても素晴らしい会社であったと私自身振り返って思います。
　そんな会社に運よく入社することができた私ですが、わずか半年で「鬱状態」と心療内科から診断を受け休職し、会社制度により退職することになりました。「え？そんなに素晴らしい環境なのにメンタル弱すぎでは？」と思われる方もいらっしゃることでしょう。返す言葉が全くありません。おっしゃる通りです。
　しかし同時に、「何故鬱になったの？」と思われる方もいらっしゃるのではないでしょうか。本記事ではこの点について鬱を発症した本人の目線から「どうしてそんなことが起きてしまったのか」という点について考察してみたいと思います。
　まず初めに注意書きですが、私は関わった方々のすべての視点を理解しているわけではなく、自分視点の主観的な理解しかお話しすることができません。その点まずご承知おき頂ければと思います。また、以下の文章には私が当時言われたとされる言葉が出てきますが、これらは100%厳密に記憶しているものではなく、あくまで私の記憶の限り記述したものとなりますのでご了承ください。

何故「鬱」になったのか

　さて本題です。私は何故鬱になったのでしょうか？当然社内の詳しい事情についてはお話しすることができないため、適度に抽象化して経緯を説明させていただければと思います（話を分かりやすくするため、時系列が正確になっていなかったりする部分もあります。あらかじめご了承いただけますと幸いです）。

入社直後：ワクワクと不安

　入社すると、まずキラキラのノートパソコンを渡されました。もちろん Mac Book Pro です。私はそれはまで Windows + WSL しか使ったことがなく、Mac Book Pro を使いこなせる自信も全くありませんでした。同期入社の機械学習エンジニアの方もすこぶる優秀です。入るや否や速攻で開発環境を立ち上げ、過去携わってきた案件や研究の内容、最先端の深層学習アルゴリズムの内容を楽しそうに話しています。私が手間取っていた開発環境の立ち上げも、一瞬で解決してくれて開発できるようにしてくれました。
　率直に言って「すごいところに来てしまったな」とそんな風に思いました。私は最先端の論文を追いかけるほど機械学習や数理最適化のアルゴリズムに詳しいわけでもなければ、Kubernetes, Terraform といったような煌びやかなインフラストラクチャ周りの深い知識があるわけでもないのです。
　私はとても不安な気持ちになりました。それでも「何かしら組織に役立たななければいけない。そんな気持ちで望もう！」と強く意気込み、全力で業務に取り掛かろうと思っていました。

プロジェクトアサイン

　ところで、もう一つ特筆すべきことがあります。なんと、どのプロジェクトに携わりたいか、選んでよいとまで言われたのです！私の前職ではデータサイエンティストとして勤務していたのですが、意志などとは関係なく降ってきたタスクをこなすことが要求されました。例えば「ファシリテーションの新人向け研修をやってくれ」などといった業務です。そういったことが当たり前だと思っていた私はまた感動してしまいました。そこで私は、前職での経験が一番近そうなプロジェクトを選択し、そのプロジェクトにアサインされることになりました。

プロジェクトアサイン直後

　さて、当然ですが私は仮にも機械学習エンジニアですからソースコードを共有されることになります。ワクワクと不安を抱えながら、github からソースコードをクローンして、読み始めました。すると「？」となりました。どうも全くソースコードの意味が分からないのです。その当時は「僕のコード読解力が足りないせいで読めないんだ…」と思い、かなり落ち込んでいました。しかし休職してからある本と出逢いました。それが以下の本になります。

この本を読んでみるとその理由がだんだんと分かるようになってきました。例えば、以下のような理由が挙げられます。

• データの定義が存在しない。（これはコードそれ自体の問題ではないですね。）

• SQLやPythonコードにほとんどコメントが見られない。

• 異様に長いデータフレーム操作が含まれる。

  • df.assign().merge().pipe().pivot().unpivot().assign().pipe()… のような。

• 適切な粒度による関数の切り出しが行われていない。

  • たとえば機械学習においては「学習データ作成」と「検証データ作成」の課程でほとんどの操作は共通化されるはずで、違う部分は教師データに対する操作のみだと期待される。

  • しかし、「学習データと検証データで何が違って何が同じか」を確認するのに毎回数百行のコードを読まないといけない。

• Pythonコードに docstring や型ヒントが一切ついておらず、どんな変数が入ることが期待されているのか、あるいはどんな変数がアウトプットとなることが期待されているのかさっぱりわからない。

  • プラスアルファでその関数の処理において必ずしも知る必要のない変数が含まれていたりする。

つまり私にとっては「なぜこんなことしているんだ…？と意図のよくわからないソースコード」だったのです。このソースコードが既にプロダクションデプロイされている、というそんな状況でした。

雑魚エンジニア、始動

　さて、私ことポンコツエンジニアも最初は「自らのコードリーディング能力が不足しているせいだ…」と思っていたのですが、ロバスト Python を読む前の段階においても「これはさすがにまずい…」と認識するようになりました。このままでは拡張性、保守性にあまりにも問題があると思っていたためです。少なくとも自分にはこのコードを保守できる自信がありませんでした。
　そこで、私は件のコードの責任者である先輩エンジニアの方にコードをリファクタリングすることを提案しました。すると先輩エンジニアはこういいました。

「このコードは既に十分に綺麗だから、（コメントは追加してもいいけど）リファクタリングする必要はない」

　…どうしよう。そんな気持ちが私の頭の中によぎりました。このままでは議論は完全に平行線です。私の部署は放任主義といった感じで、自分で主体的に動いて仕事を作っていくことが求められる部署でした。そのため、このままでは自分の提案を受け入れてもらうことができず、社内失業状態です。
　そこで、頭の至らない私にとって選択できる解決策はあまり思い浮かばず、「第三者に判定してもらおう」と思い、ソースコードの一部を私の部の slack に共有し「このコード、率直にどう思いますか？」とお伝えしました。

　すると「正直私はあまり触りたくはないですね…」というリプライが付きました。「（私が追加した）コメントがなかったら、何をやっているか本当にわからない」というリプライもつきました。どうも、私の所見と同じように感じる方もいらっしゃるようです。「ああ、やっぱりそうだよね。」と少し安心した気持ちで眺めていた私ですが、そこで件のコードの先輩エンジニアからこんなリプライが返ってきました。

「このコードは挙動が変わらないことを保証できなかったから、いじれなかっただけなんだ」

　あれ？前と言ってること違うくない？率直にそんな風に思いました（というかそれならそれでコメントぐらい自分で読んで書いておけよ、と思わなくもありませんが）。そこで、「私がこんな風にリファクタしたらきれいに、読みやすくなりませんか」と提案したところ、こんなご回答が。

「挙動が変わらないことだけを願います。というか、ただクラスに書き換えただけに見えるのですが。」

　どうやら「ソースコードを通じて意図を伝えることの必要性」や「読み手の認知負荷を引き下げる必要性」といった認識がこの先輩には存在しないようです。そこで「あれ、雑魚エンジニアの僕ではこの先輩の下ではもうやっていけないのでは…？」と率直に思いました。

　誤解を招きたくないので補足しておきたいのですが、この先輩エンジニアの方に責任を押し付けたいわけでは決してないです。この先輩エンジニアの方はそれこそアルゴリズムなどは最先端の論文を追いかけているほどゴリゴリにできる方でした。社内勉強会でも時折発表されていましたが、難しい内容をとても分かりやすくかみ砕いて説明することのできる方で率直にすごかったです。その点を強調しておきたいと思います。

初めての評価

　さて、そんなこんな色々と試行錯誤していた私ですが初めてマネージャー（件の先輩エンジニアとは別の方です）から四半期評価をされることになりました。そこでの評価はこんな感じ。

「今期はキャッチアップに時間を使っちゃってあまり何もできなかったね。もっと積極的に提案していってほしいな。評価は４段階中の下から２番目です」

確かに、表面上私がやったことはほぼゼロでした。それこそ「コメントを追加しただけ」だったのです。私は雑魚エンジニアでした。自分の中では一生懸命あの手この手で提案したりしていた（上述のソースコードのリファクタリングに以外にも、です）のですが、結局のところ私が変えられたのは「コメント」だけだったのです。

雑魚エンジニア、鬱へ

　こうした「自発的な提案」が求められる環境における「提案の拒否」が相次ぎ、私はどんどん心をむしばまれていきました。だんだん職場の方も心配するようにはなってくれたのですが、その時にはもう（自分でも気づかないうちに）かなり追い詰められた状態でした。
　ある日、マネージャーと面談をする機会があり「そっちのプロジェクトは大丈夫ですか」と聞かれたときに私は「率直に厳しいです。コメントもドキュメントもなくて何が書いてあるかわからないし…。」という話をしました。その時、マネージャーからお伝えいただいたのがこんなお言葉でした。

「あ、そういうコードを保守した経験ないんですね。別のプロジェクトにアサインすることもできるけど、その場合は個人で担当してもらうことになるけど大丈夫ですか？」

多分、この発言を機に私の心は崩壊したのだと思います。自分が「コードの保守もできない」雑魚エンジニアであることが問題だと指摘されたように私には感じられました。そして、その雑魚エンジニアには「個人でプロジェクトを回せるほどの自信」がもはや存在していなかったのです。

気が付くと、私はベッドから起き上がることもできず、具体的な自殺の方法を考える毎日を過ごしていました。「どう死ぬと楽に逝けるかな。」そんなことを毎日考えていました。そこまで来て、かなり色々な人（職場以外の家族など）から心配され、心療内科を受診し、「うつ状態」と診断を受けて休職することになりました。社内制度の関係で、休職は最大でも３カ月で、それを超えて復職できない場合「退職」となります。

　私自身、休職を経てうつの急性期に比べれば大分まともに動けるようにはなってきました。本を読んだり、プログラミングしたりできるようにもなってきました。ただ、サイレースという日本で最強の睡眠薬を処方されてもなお浅い断続的な眠りが続く状態なのです。そして薬の副作用か分からないのですが、毎日悪夢を見ます。そんな状況で日中も割と眠い状況が続いていたため、これは復職困難だと判断し、退職に至りました。

得られた学び

　この経験から何も学びを得ないのでは、「うつになっただけ」になってしまいます。それは本当にもったいないので、私自身何が学び足りえたかな、ということについて記述してみたいと思います。

1. 能力に見合った会社・待遇の仕事に就くべきだった

　率直に、自分の能力不足を痛感しました。それはもちろんプログラミングや機械学習アルゴリズムに対する専門性もそうですが、社内政治や意思決定を勝ち取るための信頼形成能力なども含めてです。そういった能力が足りなかったため、結果として信頼を得ることができず、何も変えることができませんでした。

2. 志向性が合う会社に行くべきだった

　自分が大切にしているもので自分より劣っている人の意見について、やはり無意識的にしろ意識的にしろ人は軽んじるものなのだな、と感じました。例えば、私でいえば「コードの保守性・運用性」を重視すべきと考えているため、コードの綺麗さや意図を伝えようとする努力に対して高い期待値を持っています。それが低い状態で運用されているのを見ると、修正したくなってしまってしょうがないのです。
　しかし、逆に先輩は「アルゴリズムによる課題解決」を重視されている方だったのです。私は先輩と比較すればアルゴリズムに対する理解度は圧倒的に下です。ほとんどないといっても過言ではありません。だからこそ、私の提案は「とるにたらないもの」としてしまったのかなと感じています。
　つまり何が言いたいかというと「重視するものが何か」ということについてもっと志向性を合わせないといけなかったのです。この志向性（目的意識・価値観）がズレているとうまく仕事がしづらくなるのかなと思いました。私が大切にしたいと思っていた拡張性や可読性は、少なくとも私がアサインされたプロジェクトにおいては期待するほど重視されていなかったわけです。（実際にプロダクションコードとして動いていたコードは前述のとおりです）。

3. もっとコミュニケーションをとるべきだった

　先ほど志向性が合う会社に行くべきだったと言及しましたが、とはいえ価値観は多かれ少なかれ人それぞれ違うものです。だから、こういう摩擦が発生することはどうしてもあるものだと認識しています。お互いの価値観を知るために、もっとコミュニケーションを取らないといけなかったんだろうなと思っています。最も、私が件の先輩エンジニアに「質問をしてもいいですか？」と聞くと

「少しだけならいいよ。」

と言われることが多く、コミュニケーションをなるべく抑えてしまったことも理由の一つだったのですが。傷つくこと覚悟でコミュニケーションを取りに行けばよかったなと思いました。

「君の提案には目的意識がない」

と言われたこともありました。その時の私の提案にはもちろん目的意識があったはずなのですが…。衝突することを恐れてコミュニケーションを深めることをやめてしまったのが反省点です。

4. 短期的な評価にこだわりすぎるべきでなかった

　予めこのポイントが今回私が学ぶことのできた最も大切なポイントであったということをお伝えできればなと思います。短期的な評価にこだわりすぎるべきではなかったなと思いました。どうしてかというと、短期的な評価は不確実性も多分に含まれており、必ずしも合理的になされているとは限られないためです。
　「結果がすべて」という言葉があります。私が叔父に言われ続けた言葉です。私自身この考え方を信念とすることに一定の合理性があるものと考えています。しかしこの言葉への認識を間違えると、自分ののど元に刺さりかねない諸刃の刃であるなとも、感じるようになりました。
　例えば、センター試験を例に挙げてみましょう。短期間の間に模試を何回か受けることもあるかと思いますが、点数が変動することって結構ありませんか？この点数の変動を「短期間において自分の能力が上がったり下がったり」したと考えることが合理的でしょうか？そう考えるよりも「たまたま発生した問題との相性によって点数が変動している」と考える方が私には自然なように感じられます。
　同じことが仕事の結果に対しても言えたりしませんか？ましてやセンター試験の例とは異なり、仕事の評価についてはそこまで厳格な点数の基準があるわけでもありません。そうである以上、たまたま成果を出したと認められたり、たまたま成果を出すことができなかったと認められることもあるはずです。その結果がもたらされたすべての要因を上司に考慮してもらうことなど、現実的には不可能なのです。実際上司は私の状況を理解していないからこそ、「もっと積極的に提案していってほしい」というフィードバックを返してきたのです。実際のところ私は提案自体は積極的に行っていたにも関わらず、です。
　誤解を招きたくないので再度強調させていただきますが、「上司の判断がおかしい」と言いたいのではありません。上司の立場からすれば限られたリソースでなるべく正当な判断が出せるよう、表層的な結果を根拠に評価することは合理的であると私は感じています。しかしながらあくまで結果や評価は常に納得性のある（＝自分の能力や努力を反映した）ものとは限らないから、短期的に部下の立場としてあまり傷つきすぎなくてもよいとお伝えしているのです。

5. 選球眼を養わねばならないということ

　このブログを書きながら、以下の本を偶然見つけ、読んでいました。

もしIT系に来られてメンタルを病んでしまいそうに思われている方にはぜひ一度手に取ってみてほしいと思っている本です。この本ではメンタルを病んでしまった方々の経験談がたくさん記述されています。色々な事例が登場しますが、私にとって最も印象的だったのは「気づいたときにはもう手遅れ」になる人が意外と多いんだな、ということでした。つまり「まだ大丈夫だ、いける」を繰り返すことがとても危ういということです。
　もちろん気合で乗り切れる場面もあるかもしれないので、それを一概に否定するわけではありません。ただ、その限界が訪れるのは大丈夫だ思った次の瞬間だったりするので、注意してほしいということです。
　野球の例えがどれくらいの人に通用するか自信がないですが、敢えて例えるなら、手元で急に曲がって自分に突っ込んでくるスライダーのようにイメージしていただけるとよいのかなと。「インコース！打てる！」と思って振ったボールが体に直撃するようなものです。とても痛いし、下手したら大怪我につながります。
　ある友人は私に「そんな際どいボール見送ったって最悪ストライク一つ取られるだけでしょ」といいました。その通りです。でも私にとってはその一球は「ここで打てなきゃ終わる！」という一球のように感じられていました。だからこそ振るしかなかったのです。しかしながら本当にその一球は自分にとって「ここで打てなきゃ終わる」ほどの大事な一球だったのでしょうか？大怪我のリスクを背負ってまで必要なリスクだったのでしょうか？もしかして「短期的な評価にこだわりすぎている」のではないでしょうか？

まとめ

　会社の方々にはせっかく雇ってくださったのに、まともに使えないエンジニアで申し訳ありませんでした。しかし、同じように悩むことになるエンジニアの方もいらっしゃるのではないかと思いますので、一人の失敗談として笑い話にでもしていただければ幸いです。このブログが、今辛いと感じながらも働いている誰かの人生を少しでも楽にすることができたらいいなと心から願っています。