ベンチャー企業に入社した機械学習エンジニアが半年で鬱になった話 108
鬱になる前に転職 部門より
5月20日に公開された「自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話」という記事が、Twitterなどのプログラマ界隈で盛り上がっているので共有したい（はてなブックマーク）。
記事を要約すると、氏はメガベンチャーと呼ばれる自社開発企業の機械学習エンジニアに転職、そこは待遇もよくプロジェクトも選べるなど自由主義な社風であったが、一方で放任主義であったという。入ったプロジェクトは前職（データサイエンティスト）の経験に近そうなPythonのプロジェクトであったが、ソースコードの品質が低く理解できず、またこのままでは問題があると思い、リファクタリングを提案するもチームメンバーには受け入れらず、結果として人事評価も低くなり、最終的にマネージャーからの「あ、そういうコードを保守した経験ないんですね」というコメントに耐えられなくなり、鬱になってしまったという。
これに対して、SNS上では「この人は悪くない。環境がダメだっただけ」「相性が合わなかったのでは」「コードの品質より短期的な売り上げを優先する職場だったのでは」「既存メンバーはリファクタリングする動機が無いのでこういうのは良いリファクタリングタイミングだ」といった擁護の声がある一方、「チームに入って初手リファクタリング提案は絶対ダメ」「入ったばかりの人は信頼ポイントを貯めてから提案すべき」「本番運用中のコードを変えようとしたら挙動が変わらないことだけを願いますと言われるのは当たり前」「品質が低いコードを保守するという仕事は普通にあるので元の品質が低くて直せないというのは普通にスキル不足」といった厳しい声、また「そもそもPythonで書いたコードに保守性なんてない」というどうしようもないツッコミも上がっている。スラド諸氏はどう考えるだろうか？
うーーん.. (スコア:2, 興味深い)
すでに言われていることも混ざってますが、記事を読んで思ったことをつらつらと、
1)仕事をする上での目標設定は与えない/チェックしない会社だったのか？
書かれていないから分からない。
もし課題を各自で設定しろというシステムで、自分でリファクタリングという目標を設定した、というならマネージャが止めないといけない。
そんな仕事を入社直後でそのソフトが作られた経緯も分からない、使われる状況の業務知識もない新人にさせちゃいけない。危険すぎる。
2)リファクタリングとテスト(自動化された)はセット
わかりにくい複雑なコードは負の遺産、それは間違いない。
ただしコードを変えるときは常にテストが付きまとうし、その工数はバカにならない。手動でやるならコード変更よりもテストのほうが工数が多いのはザラ。
記事見る限り自動化されたテストはなかったようだし、まず手をつけるべきはそこだったのかな。(でも後から自動化テスト作るってイバラの道だよね..)
3)リファクタリングってゼニになるん？
ゼニにはなる、ゼニにはなるんだが、ゼニにできる＆できないケースがあると思うし、コードのどこに保守性・運用性を持たせるかの考慮はけっこう大事。
具体的にはバージョンアップでよく変更する箇所(パラメータや画面の追加)とか、大きな移植を控えているとか(キレイなコードだったらコピペでいけるよね)。
でもこんなことは保守・運用を理解しないとね、入ってすぐの新人にはわからないと思う。かく言う自分も誰も中身を見ないモータードライバのコードをキレイにした前科ががが。
4)あなたの給料はどこから？
何回か転職を経験してきたけど、新しい会社で一番最初に気にするのは自分を評価するのは誰なのか？というところ。(割とこのへん曖昧な会社も...)
その誰かの工数を減らすことができれば、その人は他のもっと大事なことに時間を使えるようになるし、それはその人の先にいるユーザの満足につながる。
そういう意味で初手にリファクタリングを選んだのはスジが悪かったかな..。でも指摘する人はいなかったんだろうか。
5)あ、そういうコードを保守した経験ないんですね
入社半年の新人に何を口走っているんだ？
どうにも放任が過ぎるというか、他の新人はどうやってこの会社に馴染んでいるんだ？という疑問を感じた。
Re:うーーん.. (スコア:4, すばらしい洞察)
最後については中途なんだからおかしかないでしょ
それになかったんだね、てのはないなら仕方ないってフォローでもあるでしょ
フォローされるとプライドが傷つくとかなのか
実際やったことないことをやったことないんですねと言われてそこまで病まれるとなぁ
それも別の仕事に変わるかって言ってくれてんのに
ナイーブやなぁ
どうすりゃ良かったんよ人事の人は
そうですあなたが正しいですと言って入社半年のこの人の言う通りにするしかないわけ?
傷つきやすい人が大変なのはわかるけど、何かわかるように傷つきポイント示してくれんと地雷踏んじまうわ
しかしまじでわからん。
あーあの先輩と合わなかったですかね、ならいいんか？
Re:うーーん.. (スコア:1)
元コメです。この方中途だったんですね..、記事文面見て、てっきり新卒とばかり思っていました。
ちょろっと書いていますが自分は誰も中身なんて気にしないモジュールのリファクタリングでけっこうそれなりに時間を浪費した経験があります。
まあ当然ながらあんまり良い評価は受けなかったのですが、自分自身すこしそのときモヤモヤしたものを感じ、それもあってのコメントでした。
普通そうだと思うのですが、上長に黙って独自にプロジェクトを始めるなんてないです。「これをやります」と言ってOKをもらって開始します。
自分の感じたモヤモヤは「それじゃなんで開始時にOK出したんだ？」というものです。(今はまあ..あれのリファクタリングならそんなもんだろ、ですが)
一体この人はなにをマネージメントしてるんだろう、そういう感情だったと思います。
最後のヤツは中途＆言われてみれば、たしかにどうよ？ですが、コレ言ったマネージャさんって人事の人だったんでしょか？
人事の方なら納得します。技術的なことが分からないなりに精一杯良い提案をしてくれていると感じます。
が、採用面接ならともかく入社したあとの業務面談であれば、評価をするマネージャ格はエンジニア上がりだった可能性もあります。
私はエンジニア上がりのマネージャさんという理解でこの記事を解釈していました。
「じゃあどうすればよかったんだ？」という質問への私の回答は、「リファクタリングという目標設定の時点でマネージャが止めるべきだった」です。
単にこの方が突っ走っただけとか、自信満々で人の話を聞かなかったという可能性もあります。
マネージャが業務をよく把握してなかったとか、この方が実力不足だった面もあったのかもしれません。
自分が記事を読んで一番気になって、そしてコメントしたかったのは、集めた人員を管理して成果物を上げるべき立場のマネージャなら、もうちょっと何か出来たorすべきだったんじゃないか？ということでした。
以上、下っ端の愚痴でした；Ｄ
Re:うーーん.. (スコア:1)
上席のエンジニアあるいはエンジニア上がりの人、だったと思いますよ
ものすごく自由度の高い会社だったようだし、
PROJECTにはアサインされるけどその中で細かいGO確認なんかなかったんじゃないですか
#うちもそうだし。
面倒見の良くないプロジェクトに入ると仕事探してやってねって感じになる
この人の場合見つけて確認も取らずにやった仕事が評価低かった
評価者がフォローしようとして心折っちゃった
のかなと
ありていにいうなら「単にこの方が突っ走っただけとか、自信満々で人の話を聞かなかった」って話じゃないですか
入社直後なんだからそんなこともあろうかと面倒見てやれよと思わんでもないですが、
それって細かく管理するのと何が違うんよという気持ち
自由度の高さと裏腹なんではないかな
この会社は合わなかった に尽きるのかなと
Re: (スコア:0)
この人も書いてるけどコミュニケーション不足。
常に納期に追われる下請けなんか数十年単位でDOS自体から使いまわされて理解不能な利用ルールが色々ある汚いコードで回ってるけど、まわりに聞くからなんとかなる。
＃綺麗なソースコードできっちり書くのが理想だけど、現実的には動けばいいで回さざる得ない
お悔やみ申し上げる (スコア:2, すばらしい洞察)
エンジニアにとってソースコードは水みたいなもので、ヘドロの中でも元気なアメリカザリガニみたいな人もいるし、オオサンショウウオみたいな人もいるんだよな。
まあでも世の中の大半はヘドロみたいなソースコードだと思うから、アメリカザリガニになるしかないんだよな。
デジャブ?(関連ストーリー) (スコア:1)
前に見た話と似てる
データアナリストの職を得たが、エクセルでコピペする仕事しかできてない！私はどうすれば？ [it.srad.jp]
ソースコードとドキュメントを見てから決めよう (スコア:1)
百聞は一見にしかず。
Re: (スコア:0)
多分拙速主義的でドキュメントはない
Re:ソースコードとドキュメントを見てから決めよう (スコア:1)
呼ばれたかな
ソースコードの品質が低く理解できず (スコア:1)
理解できないソースコードの品質がわかるものなのだろうか？
ある一定レベルに達しているコードなら能力が不足しているから理解できなかった可能性もありそう。
どんなコードなのか見てみたい。
Re:ソースコードの品質が低く理解できず (スコア:1)
理解できないソースコードの品質がわかるものなのだろうか？
こういう問いが出てくる時点で、ソフトウェア品質の内部品質の理解が元ネタの雑魚エンジニア氏に遠く及ばないのは確定だね。
日本では珍しい事では無いが。
Re:ソースコードの品質が低く理解できず (スコア:1)
内品は日本では人気がないからねえ、このように
だからじゃないかな、日本の業界が遅れてると言われるとか
雑魚扱いされているとかの理由は
Re: (スコア:0)
品質が低いから理解できないというのも同感できない
Re:ソースコードの品質が低く理解できず (スコア:1)
俺に理解できないから品質の低いコードだと言ってるからなこのブログ
もちろん理解にしにくいコードだったんだろうが、
それを「品質が低い」「こうしたほうがいい」とかいきなり先輩に言ってたらそりゃ顰蹙買うよねっていう
それでも先輩も「動き変わらないならやっていいよ」と言ってくれてんだけどな
Re:ソースコードの品質が低く理解できず (スコア:2, 興味深い)
バージョン管理だけに実装に関するコメントを残すのはアンチパターンだよ。
長く続いてるシステム見たことない人は知らないかもしれないけど、途中でバージョン管理が変わることだってあるんだよ。
社内でSVN→Gitみたいなケースなら履歴も移行してもらえることも多いけど、特に会社間で担当が変わった場合とか、最終バージョンのソースだけが渡されて、履歴は失われることも多い。
ソースの説明は、ソースに残さないとダメなんだ。
Re: (スコア:0)
品質が悪くて挙動を把握しきれない、
という意味で言っているならそれはままあることですね。
まあ当人が「雑魚」と免責して語ってる以上
言語を操る能力は高くないのでしょう。
我がコードは我流。我流は無形。故に誰にも読めぬ (スコア:0)
「我がコードは我流。我流は無形。故に誰にも読めぬ。」は誰の言葉だったっけ。
＃元ネタは雲のジュウザだが
ソースコードの品質は見ればわかるからな。
それこそ「作った本人にすら説明できない／挙動が把握できない」
なんてのは典型的な糞コードの一つ。理解出来ないコードは改良も
デバッグもできないし、最低なコードだよ。
Re: (スコア:0)
そこかなぁ。
よくわかんないからリファクタリングしましょうとか初手で言われると、ヤバイ予感抱いてしまう。
「機械学習や数理最適化のアルゴリズムに詳しいわけでもない」ならなおのこと。
コードの綺麗さってのはマンガで言えば絵の綺麗さで、それは成功の必要条件でもないしもちろん十分条件でもないからなぁ。
いやもちろんきれいに越したことないけど。
ベンチャーなんで保守性とかなおさら優先度低いし。
Re:ソースコードの品質が低く理解できず (スコア:1)
Perlと比べればね。
IOCCC (スコア:1)
外国人のすごいプログラマーがいたのだが暇な時間にIOCCCのコードを楽しそうに読んでいたよ。
理解できないという時点で他人のプログラムを理解する能力が不足しているように思う。
# そういえば昔に書いた自分のコードが理解できないこともげふんげふん
機械学習エンジニアがpythonを使うだと? (スコア:1)
本物のプログラマならFORTRANで書くだろ。
それで出来ないならアセンブラを使うものだ。
# はっ、WebAssemblyってそのために(違います
Re: (スコア:0)
その話が掲載されていたbitを読んで大笑いしていました。
日本国内のベンチャーはだいたいベンチャーじゃない (スコア:1)
ベンチャー(管理職不在放任主義の零細企業という意味)
メガベンチャー（管理職不在放任主義の大企業という意味）
全然技術記事じゃない (スコア:1)
Zennじゃなくてnoteにでも書いてて欲しい。
Qiitaみたいにゴミ記事ばかりにされたらかなわん。
Re:全然技術記事じゃない (スコア:1)
Qiitaと同じでコードが1行も無くても誰でも投稿できるみんなの日記帳じゃないの?
スラド民理論 (スコア:0, すばらしい洞察)
ペンチャーに入ったやつが悪い(ｷﾘｯ
だろうが
ぺ？ (スコア:2, おもしろおかしい)
いやもちろん、わざわざペンチャー [google.com]に入った奴が悪いのは確かだけど
それを安全確認せずに操作するやつも悪いだろう？
で、何の話だっけ？
Re: (スコア:0)
メガベンチャーというからには社内に高プロ(年収1075万円以上)が沢山いそうなイメージがあるが、ブラック確定なんでは。
収入多くても潰れたらお終い。
Re: (スコア:0)
スラド民も Twitter 民も、コードを見ずに評価できんだろ
Re: (スコア:0)
どこの異世界のスラドの話だ？
そんな話は聞いたことがないぞ。
リファクタリングの必要性 (スコア:0)
これが諸氏もよく話題にする「よくわからないけど動いてるコード」ってやつか。
個人的にはこれが一番理由としてでかい。
「動いてるものをわざわざいじって動かなくなったらどうすんの？いじる必要ある？」みたいな。
そこに時間割くなら別のことしましょうという。
Re:リファクタリングの必要性 (スコア:3, 興味深い)
ぶっちゃけ、主体性の無いザコエンジニアさんなんだと思う。
環境なんて渡されたのをそのまま使うよりまず自分の使いやすい環境をベースに作業を始めてだんだんとそこの環境に近づけていけば良いのだし、ソースコードが読めないのが品質が悪いとか、何を甘えたことを言ってるのかと。いじる必要があるんだだから当然読む必要があるわけで、読めよ。
Re:リファクタリングの必要性 (スコア:2)
よくわからないけど、工場出荷検査では動いているコードを本番運用にぶっこむと、他のクエリの結果が印刷され・・・
Re: (スコア:0)
まあ、変更の容易さを担保せずに本番を絶対的正義として技術的な負債が積まれるままになると、変更しづらさでにっちもさっちもいかなくなることが多いけどね。
完全に塩漬けでいいならいいけど、運用されてるシステムってのは多少なりとも変更が発生するので。
Re: (スコア:0)
変更に時間がかかって無事脱落のパターン
Re: (スコア:0)
うーん、機械学習ベンチャーでもこんなレベルなのか。
挙動が変わらないのを運任せでお祈りするようなコードだから品質が低いと言われるんだが。
まあ、雑魚エンジニア氏もプロジェクト入る前にちょっとコード見せてもらうとか、
まずUnitTesTとCIを導入しましょうとか穏便なところから入って、静的解析やリファクタリングの話を持ち出せばよかったのにね。
気を取り直して次いこ、次。
Re:リファクタリングの必要性 (スコア:1)
記事を読むと、件の先輩エンジニアは天才肌の人で、第三者の視点で考える能力が欠如しているケースに感じますね。
同じ部内でそのコードが「正直私はあまり触りたくはないですね…」とか「（私が追加した）コメントがなかったら、何をやっているか本当にわからない」とか言われてることからも、この先輩個人か、その周囲の小さめのグループに関する話でしょうね。
Re: (スコア:0)
まあ、院まで行って論文たくさん書かなきゃいけなくなるとコードのメンテより論文のネタ、になるからね。
そのままの感覚で仕事してればそうもなるよね。つまるところ、他人は自分じゃないから、経験もそれに伴う考え方も違う。
経験を前向きに活かしてほしいものです。
Re: (スコア:0)
理解できないのに、どうしてリファクタリングできるのか。
単体テスト環境作ろうって提案するのが先な気がする。
Re: (スコア:0)
このままでは機械学習エンジニアがコードを理解できず機械学習の仕事を進められないので、「私」はいじる必要を感じたけど、その必要性について周りとうまく合意できなかったって感じかな。そもそも誰がリファクタリングするの？っていうリソースの問題もあるだろうし。ありもので何とかしろってのは仕事ではよくあること。
Re: (スコア:0, オフトピック)
違う違う。
いわゆる「よくわからないけど動いてるコード」ってのはプログラマ本人が理解できてないけど動いてるときに使う。
スリープ（待機命令＝待ち時間）入れたとこで挙動は変わらないはずなのになぜかスリープ入れると安定して動くとかそういうタイプ。
今回のはほかのプログラマが書いたコードが読めないってだけだから違う。
Re: (スコア:0)
君の方が違うよ。
ソース読んできなよ。
Re:リファクタリングの必要性 (スコア:4, 参考になる)
自分で書いたコードじゃない。
ソースコードをクローンして、読み始めました。すると「？」となりました。どうも全くソースコードの意味が分からないのです。その当時は「僕のコード読解力が足りないせいで読めないんだ…」と思い、かなり落ち込んでいました。しかし休職してからある本と出逢いました。それが以下の本になります。
私でいえば「コードの保守性・運用性(=長期的な課題解決)」を重視すべきと考えているため、コードの綺麗さや意図を伝えようとする努力に対して高い期待値を持っています。それが低い状態で運用されているのを見ると、修正したくなってしまってしょうがないのです。 しかし、逆に先輩は「アルゴリズムによる(目先の)課題解決」を重視されている方だったのです。
「最初は自分のせいだと思ってたけど、この本に出会って気づいた。悪いのは自分じゃない。ほかの奴らだ！」
よくいる意識高い系のお話しだよ。
Re: (スコア:0)
記事読んだけど何かまぁそんな立ち回りじゃそうなるよなっていう感じ
リスクベネフィットもろくに提案せず「キレイがいいからキレイにしましょう」じゃなぁ
キレイが良いと強く思ってりゃ最初からそんなコードにゃならんのよ
しかも強く断られたわけでもなく難色を示された程度で…
損で大したことできなかったらかと評価が低かったと。そらしゃーないでしょ。
挫折したことなかったのか
たまたま体調悪かったんかもしれんな
こういう記事を読み切れるモチベーション (スコア:0)
が自分には無かったんだが、読み切る人はやっぱり何らかの知見を得ようとしての事なんかな。
各章の見出しだけ見て、前回敗北者が次への挑戦と心の整理の為にしたためた文章、といい加減に解釈した。
珍しいものではなく自分が読む必要はなかろうと興味を失ってしまったが、興味を持って読む人はどのような琴線に触れてのことなのだろうな。
Re: (スコア:0)
そらお前さん、不幸な人間はいずれもそれぞれに不幸なものであると知るためよ。
そして明日の夜明けに新しい気持ちでビズリーチに駆け込むためよ。
Re: (スコア:0)
他山の石、というやつだよ。
Re: (スコア:0)
他人の不幸は蜜の味～
Re:一言で言えば「能力が低かった」だけ (スコア:1)
これ。
リファクタリングの必要性を粘り強く説明したり、デグレードへの対策を提案しなかっただけ。
そして勝手に諦めて勝手に病んで勝手に辞めたように見える。