見出し画像
Photo by wh_o_key

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

木村 直樹

注: 書き足りないところもあるので後日加筆すると思います。ご容赦ください。

2023-05-21にTwitterを賑わせたとある記事

2023年5月21日、次の記事が国内でエンジニアを中心にTwitterを賑わせました。

この記事にボクも関心を持ち、とても興味深くこの記事を拝見しました。

その上でTwitterでのこの記事への反応を追っていました。反応している多くはソフトウェアエンジニアと思われる方で、一部にはいわゆる非エンジニアと括られるプロダクトマネージャーやCEOをなさっている方も。

ボクにとってはTwitterでの一件を通じて、新たな学びが得られた気がしたので、こうして記事としてまとめてみようと思った次第です。

この記事で何が語られていたのか

ChatGTPに「https://note.com/joan_of_arc/n/ned510ca913c7 を要約して」と依頼してみました。

この記事は、エンジニアとして働いていた著者が過酷な職場環境と自身の苦悩について語っているものです。彼は様々な困難に直面し、職場での提案が度々拒否される状況や、コードの保守もできないと指摘された事から自信を失い、精神的な崩壊を経験しました。その結果、うつ病と診断され、結局は職場を離れることを余儀なくされました​1​​2​。

彼はこの経験からいくつかの教訓を引き出しています。その一つは、自分の能力に見合った会社や待遇の仕事に就くべきだということです。彼は自身の技術的な能力だけでなく、社内政治や信頼形成能力にも不足があったと感じました​3​。

また、自分の価値観や目的意識が合う会社に就職するべきだったとも語っています。彼は自身が重視する「コードの保守性・運用性」が彼の職場で必ずしも重視されていなかったと感じています。そのため、自分が重視する価値観と職場の価値観がズレていることが、彼の苦悩の一因だったと考えています​4​。

最後に、もっとコミュニケーションを取るべきだったと彼は反省しています。彼は価値観は人それぞれ違うと認識しており、そのために摩擦が生じることは避けられないと感じています。しかし、その摩擦を適切に管理するためには、お互いの価値観を理解するためにコミュニケーションをとることが重要だと認識しています​5​。

ChatGPT (model: gpt-4-browsing)

この要約を読んでいただくとわかるように、自称『雑魚エンジニア』の著者が『自社開発メガベンチャー』なる企業に就職してうつ状態になって休職の末に退職するまでのおよそ8ヶ月間を当事者目線で語っていて、著者自身が得た教訓を挙げています。

ボクが読んで感想として残ったのは、要約と同じで、この著者がなぜうつを患うまでになってしまったのかでした。

この記事の著者はどんな人物なのか

ちなみに、この記事の著者であるJoanOfArcさんはこちら。Twitterでは@Black_Jack_2021でつぶやいている様子。

このように2022年7月31日時点で転職を報告しているので、大学院はすでにご卒業され、他の企業をご経験されたのち、『自社開発メガベンチャー』にご入社されたようです。なので、インターンや新卒ではなく、ご入社される以前に少なからず社会経験を積み、データサイエンティスト(機械学習エンジニア?)として中途採用された様子です。

なぜバズったのか?

Twitterトレンドにはこの記事に関連するキーワードとして次が踊りました。

  • 雑魚エンジニア

  • 自社開発メガベンチャー

  • リファクタリング

この中で興味深いのが『リファクタリング』です。この著者が提案したリファクタリングが物議を醸し出しました。

リファクタリングとは

非エンジニアの方にとっては聞いたことのないもしくはよく理解していない言葉だと思います。

:リファクタリング（名詞）:外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変更させること。

:リファクタリング（動詞）:一連のリファクタリングを行って、外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること。

リファクタリングの定義

このように『リファクタリング』はただのソースコードの書き換えとは全くの別物です。重要なのは、ソフトウェアの既存の挙動は変えずにソースコードの品質を向上させるとことです。つまりソースコードを書き換えた結果、これまでと挙動が変わるようでは、それはもうリファクタリングではなくただのコード改変です。

書籍としてはMartin Fowlerの著作があまりにも有名です。


かく言うボクも、過去にこれの第1版を手に取り、これを読みたいがためにJavaを習得し、穴の開くほど何度も繰り返し読みました🤩プログラミングをこの本に教わったといっても過言ではありません。とてつもない影響を受けました。

だがしかし、このボクが書籍で学び実践を繰り返してきたこの「リファクタリング」ですが、件の記事への反応では少し様子がおかしい🤔と気づき始めました。

「初手リファクタリングは悪手」?

なぜ悪手だと考えているんでしょう🤔

具体的には、以下のようなツイートです。

「悪手」の反対意見

政治力と信頼残高

政治力や信頼残高が必要だと考えもあるようです。

こちらも具体的には、以下のようなツイートです。

「信頼残高」とは、スティーブン・R・コヴィーの『７つの習慣』にある言葉で、相手との信頼感／安心感の強弱を銀行口座の残高に例えたものです。

相手からの信頼が増す行為を「預け入れ」、相手の信頼を損ねる行為を「引き出し」として、相手の中にある信頼口座の残高を増やしていくことが大事だと説いています。なお、書籍によっては「信頼口座」「信頼貯金」ということもあります。

『7つの習慣』では、相手の中の信頼残高を増やすために、
- 相手を理解する
- 小さな気遣いと礼儀を大切にする
- 約束を守る
- 期待を明確にする
- 誠実さを示す
- 信頼残高から引き出してしまったら心から謝罪する

という6つのポイントを紹介しており、これらの行為を「預け入れ」、その逆の行為が「引き出し」と説明しています。また、こうした人間関係において大切なことを、コツコツと積み重ねていくことが大事だと説いています。

企業がユーザーの「信頼残高」を増やすためにできる、ただ一つのこととは？ | Web担当者Forum

日本でのリファクタリングへの誤解を憂う声も

気になったつぶやき

「リファクタリングすることで得られる価値」と「リファクタリングしないことで被る損失」があるという観点はとても重要ですね。


ここから何を学ぶか

うつは誰の身にも降りかかる身近な病気

うつはとても身近な精神疾患です。自分がうつに患うこともあれば、同僚がうつを患うことも現実的に起こり得ます。

今回この方の場合、転職されているのでそもそも大きなストレスを抱えている状況で、通常よりも精神疾患に罹りやすかったのではと推測されます。

ライフイベントにおけるストレスの大きさで「転職」は第11位に挙げられるほどです。

転職だけでなく、それに伴って並行して引越しされる方も少なくないですが、「引越し」も第36位に挙げられています。

このようにご自身の心境の変化や仕事・生活の変化でもメンタルの許容量は大きく影響を受けます。「オレは大丈夫」と思っている人ほど油断してうつに患う恐れがあるかもしれません。

入社半年で休職その後退職に至らしめた組織の失敗

この方を入社いただくためにどれほどの人が関わりコストが発生したことか。

もちろんその方を採用するための手数料や半年間の給与という直接的な金銭での損失は当然ながら、最低でもこれくらいの人の活動が徒労に終わっています。

  • 一連の採用活動

    • 採用担当、面接官、意思決定者

  • 入社手続き

    • 労務担当、MacBookを調達した情報システム担当

  • オンボーディング

    • チームメンバー

  • 給与の支払い

    • 経理担当

  • 休職・退職の手続き

    • 労務担当、MacBookを回収する情報システム担当

エンジニアでさえも『リファクタリング』に対する認識に違いがある

リファクタリングの定義に対する齟齬が同じソフトウェアエンジニアであってもいくつかの要因によって大きいことが浮き彫りになりました。

例えば、こんなことが起きることが予想されます。

Aさん「バックエンドのリファクタリングしますね」
Bさん「リファクタリングならいいよ🙆‍♂️」
…
Aさん「リファクタリングしました‼︎ レビューしてください🙏」
Bさん「はい、レビューします!!」
Bさん「…ん🤔あれ? リファクタリングだよね??」
Bさん「これだと修正前と挙動が変わりますけど😇」
Aさん「はい‼︎ このほうが効率的なのでw もちろん単体テストは修正してます」
Bさん「ん〜リファクタリングと機能修正が一つのコミットで読み辛いです😭」
Aさん「あ、はぁ…😶」
Bさん「え💦これが原因でE2Eテストが失敗してますけど」
Aさん「…すいません😞」

おいそれとリファクタリングできないソフトウェア開発現場が多い

ご自身の従事する(ないしは従事していた)開発現場では利害関係者と交渉して勝ち取らないとおいそれとリファクタリングができないことといった状況が透けて見える発言が多く見られました。

呼吸するようにリファクタリングできるのは希少でとても幸せなことなんですね。

これは組織的な要因とその組織との関わりの深さに大きく依存していると思われます。

  • チーム内にヒエラルキーが存在し、立場によって裁量がない

    • 新参者や下位のエンジニアの首根っこを上位者が掴んでいる

  • どんなに正論であっても提案者の信頼残高と根回しの有無で実現が左右される

  • SESやフリーランスとして順委任契約で主にワーカーとして開発に携わっているため、意思決定への関与と距離が遠い

  • そそそもリファクタリングする習慣が組織にない

  • 安全にリファクタリングできる環境が整っていない

    • 回帰テストなどQAが整っていない(=保証すべき品質が定まっていない)

こういった組織ではリファクタリングが正しい理解で認識されておらず、「新参者によるリファクタリングは、既存コードが破壊されるリスクが多分にある」という認識が強くあると伺えます。

改めて本来のリファクタリングの定義を確認しましょう。

:リファクタリング（名詞）:外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変更させること。

:リファクタリング（動詞）:一連のリファクタリングを行って、外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること。

リファクタリングの定義

ご覧いただけるように本来のリファクタリングは、外部から見た振る舞いの変更しないことを前提条件としているので、「既存コードが破壊されるリスク」を警戒している時点で、それは「リファクタリング」ではありません。

また書籍には「リファクタリングの第一歩」にこう記されています。

リファクタリングを行うとき、 最初にすることは常に同じです。 対象となるコードについてき ちんとしたテスト群を作り上げることです。 テストは不可欠です。

リファクタリングの第一歩 | 第1章 | リファクタリング(第2版)

つまり、テストによって品質保証できないのであれば、それも「リファクタリング」ではありませんし、改善したいコードに対するテストを設けることもリファクタリングの一部です。

ここまでを踏まえてもなお、リファクタリングするのに政治力や信頼残高って必要ですか??


この記事が気に入ったらサポートをしてみませんか？