ソフトウェアエンジニアとその近縁職と組織とその目的の狭間で保守性を叫ぶ。

aki426

はじめに

上記のnote記事を読みました。
実はこの記事を書く前にポエミーな応援記事を書いたのですが、Twitterを覗いたら想像以上に盛り上がっていたので、チキンな私はビビって一旦非公開にしちゃいました。
（ほとぼりが冷めたらまた公開しようかな）

そして再度書き始めたのがこの記事です。
Twitterでいくつか共感できるコメントを見かけたので、それらを含めてこの「問題」の解像度を上げる試みをしてみようかな、という主旨でやっていきたいと思います。
個人的な意見のまとめという側面もあります。
この「問題」について考えるための補助線として使っていただければ良いかなと思います。

元記事について

まず、元のnote記事への感想ですが、とても良い記事だと思いました。

鬱で苦しい最中に、ここまで自分の状況を言語化できるとは、客観性のある良いコードをお書きになりそうだなと思いました。
そして、（傲慢にも）私がこの方に声をかけることができるなら一言「あなたは何も間違っていないよ」と言いたいですね。
この程度のことは大なり小なり経験がある人の方が多いと思いますよ。

とはいえ、そもそもの置かれている状況が悪かったようにも思います。
元記事作者の方のプロフィールを簡単にまとめると次のようなものでした。

  • 20年10月~21年2月：機械学習エンジニアの長期インターンシップ参加

  • 21年3月？：経済系の大学院を卒業

  • 21年4月？：データサイエンティストとして金融機関へ就職

  • 22年年末？：機械学習エンジニアとして自社開発メガベンチャーへ転職

  • 23年5月？：退職

これだけ見ても結構な苦労が察せられる経歴なのですが、加えてこのような職歴であるにも関わらず自己認識が「エンジニア」であることが話をややこしくしているような気がします。
いわゆるソフトウェア開発のエンジニアと、データサイエンティストや機械学習エンジニアは（経験が無いので伝聞にすぎませんが）求められるものが
そもそも違うと思います。

ソフトウェアエンジニアとその近縁職

詳しい方がいらっしゃったらどうぞ詳しく訂正していただきたいところなのですが、各職種について私の雑な認識を書くとしたらこうでしょうか。

  • ソフトウェアエンジニア：ユーザの問題を解決するサービスの開発と継続的な成長が提供価値。目線はエンドユーザに向きがち。

  • データサイエンティスト：データ分析と結果から得られる有益な考察が提供価値。目線は経営層など社内に向きがち。

  • 機械学習エンジニア：問題を判定機で解けるように定式化し、MLを使って判定機を開発することが提供価値。提供先は内外いろいろだけど「AIでなんかやってよ」なケースに陥りがち。

これらの提供価値はラップしていることもあるかもしれませんが、していないことの方が多いようです。
また、これらの職種を採用したいと考えている組織や企業はそれぞれ全く別の問題を抱えており、それぞれ全く別の目的で採用しているように思います。

そして、元記事の作者は、noteに上がっている数個の記事を読む限り「ソフトウェアエンジニア」への志向が強いと思います。
少なくとも、コードの品質や長期的運用に心を砕くことができる性格のようです。
（※それは「細かい」というのとはまた違うと思います）
コードと計算機に対して真摯でありたいと思うことは、ソフトウェアエンジニアの適性の一つと私は思いますが、そういうものをお持ちのようです。
……私には、その真摯さは少し生真面目に過ぎるようにも思えたのですが、考えすぎでしょうか。
まあでも、真面目なのは良いことだと思います。

組織とその目的

そしてこれは実は当たり前のことなのですが、あらゆる組織や企業の目的は同じではありません。

一般的には、良いサービスを開発し、それを販売し、利益を得て、売り上げを立てることがIT企業だと認識されていますが、実は違います。
あまり深くツッコむのはオトナの事情で避けますが、例えば売り上げというか収益の立て方というのも色々あり、色々あるために企業が気にするステークホルダーというのも色々あることになります。

また、一般的には、良いサービスを長期に渡って顧客に提供し続け、サービスの価値を継続的に高め続け、競合に対する優位性を確保し続け、繁栄を目指すことがIT企業の目的だと認識されていますが、これも実は違います……。
これもオトナの事情で浅いツッコミにしておきますが、ステークホルダーの意向で企業の目的はガラっと変わりますし、そのスコープも長期ではなく中期だったり短期だったり、ごく短期だったり……します。

企業ですらそうなのですが、企業の中の組織はさらに複雑怪奇です。
どのような指示系統からどのような命令が降ってきていて、何を評価されて何を評価されないのか、評価されることになっているのに実は評価されないで胡麻化されるのか、予算はどうやって決裁されて執行されるのか、そもそも予算は使った方が良いのか使わない方が良いのか、使った方が良い場合は誰に使うべきなのか、などなど。

こういったことは社内で明言されている場合もあれば、そうでない場合もあり、「ワカってる人」は結構な割合で「そんなの当たり前だろ言わなくてもわかるだろ言わないもんだろ」と思っていますが、「ワカってない人」は「そんなのわからないだろ言えよ言わないとわからないだろ」と思っています。
私はこれは不幸な事故だと思いますが、意外といろいろなところで起こっている気がしますよ。
（組織の力学とか社内政治とか言われているものは、建て前である「企業理念」と本音である「本当の企業の目的」の間で理解できたり理解できなかったりする人々の間で起こる衝突とか摩擦のようなものだと思います。人間は全知全能ではないので、仕方がない面もあるのですが……）

そして、これもある程度仕方がないことなのかもしれませんが、新卒の方はこういった「オトナの世界」の力学についてほとんど無知です。
というか、私は無知でした。
ぜんぜんわかりませんでした。
ていうか、わかるようになったのは10年目くらいじゃないでしょうか。
新卒のころは「誰か教えてよ」と思うことすらできずに漠然とした「無知感」に悶々としていたのを覚えています。

状況的・性格的にそうなっても仕方ないこともあるよ

元記事の作者の方は、まだ働き始めて3年目ですのでこういったことに疎いのは致し方ないような気がします。
（もちろん新卒入社した瞬間「完全に理解」して組織の中を超速で泳げる人もいますが……再現性の無い特殊能力じゃないでしょうかね？）
特に、真面目にソフトウェアエンジニア的な問題意識や美意識を持ちながら、ソフトウェアエンジニアとしての価値提供を組織が求めていないことに後で気づき、そのミスマッチというか落差をどう解消したら良いのかわからず、苦しんでしまったのではないかな、と私は思っています。

元記事では「雑魚エンジニア」と自分を自虐的に自称されていますが、その自己認識こそがある意味すべての原因なのではないでしょうか。
私にはそう思えて仕方ありません。
つまり「誰もソフトウェアエンジニアを求めていなかった」ってことです。
ソフトウェアエンジニアをやりたいのに、ソフトウェアエンジニアとして採用されなかったのが、マズかったと言えばそうなのかな、と……。
技術力が足りなかったとか、職場の風土が悪かったとか、そういうこともあるのかもしれませんが、一番大きなボタンはそれで、そこを掛け違えてしまったからこそ鬱になったのでは？

まあ長々書きましたが、元記事の「得られた学び」の１～４を言い換えるとそんなところでしょうか。

世間の反応を紐解いてみる

ここからは、Twitter上で見かけた興味深い反応をザッピングしていきたいと思います。
引用されるのは嫌、という方は連絡ください。
すぐ消しますので。

一連の連ツイ、非常にうなづきが多いです。ほぼ同意です。
ホント、テスト書きましょうね。
ただ、その組織がそれを求めていないケース、というのが不幸にもあって、組織的にテストの無い低品質のコードが問題視されないこともあります。
それが良いことではないのは私も同意です。

余談ですが、元記事の作者の方は和田さんのこの記事を読まれると良いのではないでしょうかね。

きっと気に入ると思いますよ。

結局テストによってしか品質は確保できないのは当たり前の事実ですし、リファクタリングするならまずテストが必要だし、その前に仕様確認だし、さらにその前に要件確認なので、それらが無いなら全く最初から独力でもやっていく気概というのが修羅場には必要じゃないかな、と思います。
テスト文化圏で仕事したいですね。

つ、つよすぎる……。
とてもじゃないですが私には真似できません。
が、人生には腹を括ってこれくらいの図太さで問題にぶち当たってなぎ倒すことで初めて開く扉というのもあって、1回は開くことが必要と思います。

……リファクタリングとテストに関しては他の方も色々と言及されてましたが、Twitter上でも「テストがリファクタリングの前提である」という認識があるのか無いのかわからないコメントもあり、そこは「まずテスト書こうね」が合言葉というか、共通認識になると良いなと思いました。

これは「その会社がどのような成長フェーズにあって何を優先すべきと考えているか」と「コードの品質を重要視する風土が組織内にあるかどうか」の2つの要素があると思います。
「長期的な目線で品質を高めるべきフェーズ」で「コードの品質を重要視する風土がある」場合は信用構築も容易だしサポートも受けやすいと思います。
どちらも無い場合は、かなりつらい戦いになると思いますし「超立ち回る」か「転職」かどちらかを選ばざるを得なくなる気がします。

言及先のQiita記事、非常にうなづける話が満載です。
すでに動いてしまっている、つまり価値を生み出しているコードはクソでも黄金のクソだと思うんですよね。
それを上回る価値を提供できるか、自問自答しちゃいますね……。

ちょっと元記事の文脈からは外れますが、受託開発にはこういう力学が働きます。
顧客側の目的と受託側の目的がミスマッチを起こした結果、良いコードが書かれなくなってしまう「インセンティブ」が働きます。
結局こういうことがあるから内製化が進んでいるのだと思います。
あと、念のため断っておくと、あしゅりーさんはどちらかというと被害者なので強く生きてくださいとしか……。

CTOの立場からのご意見で、非常に慧眼と感じます。
なるほどトップはそういうクオリティコントロールを考えるのだなと気づかされました。
連ツイの
> まともな経営戦略がなければ、まともな技術戦略は立てられない。
という一言も刺さります……。

実はこれを目にして「やっぱりそういうもんなのかなぁ……」と思ってこの記事を書き始めました。
やっぱりMLエンジニアやデータサイエンティストとソフトウェアエンジニアでは成果と見なされる結果や時間的スコープが異なる気がするんですよね。
「そんなコード書いてたら後で困るでしょ！？」と思うことが「常識」かそうでないか、という溝は結構深いように思います。
経験談としてそう思います……。

MLの現場では無いですが、技術への理解が無いマネージャが有能なエンジニアを冷遇して……という話は近しい人間から聞いたことがあり、連ツイに書いてあることは業種を問わないのだなぁと思いました。
また、Pythonを毛嫌いする知人も似たようなことを言っていたので、いろんな意味でML界隈は今不幸な状況にあるのかもしれないですね。

結局、対話を怠ると全てが悪い方向に行ってしまうし、対話は双方向なものなので元記事の「先輩」に受け止める能力が無かったことも原因なのかな、と思います。
結局は技術力って単にコード書く能力だけではないので、いろいろやった上でのエンジニアリングなんですよね……。
総合格闘技なんですよ……いや、何でもありのサバイバルかな……武術的というか……。

「それ」

本当に酷いコードの開発を引き継いだ時、取れるのは「読み解きつつテスト書きながらリファクタリングする」か「ゼロ（要件定義）から書き直す」かですね。
私は場合によっては「ゼロから書き直す」もアリだと思います。
昨今の優秀なフレームワークを使っていても、全く手も足も出せないコードが生まれてしまうこともあります。

でも、そういうことがわからない「クソコードを見たらとにかくリファクタリングしなくちゃ！」ってほど甘ちゃんでも無いと思うのですよね、元記事の方は……。

これ、新人の教育にも使えるノウハウですよね。
すごく良い視点。
修正まではさておき、テストケースにまとめてPR出してもらえると超助かりますよね。

だから外野がなんやかや言うのも可哀そうな気もします。
メンターになってくれるような頼れる人が、社内と言わずプライベートなどでいるともう少し違ったのかもしれませんが……。

知的労働してる職種は特に「納得」が無いとストレスですぐに行くところまで行ってしまうので、対話できない上司はちょっと困りますね。
「心理的安全性」がなぜ叫ばれるかといえばそれが必要だからなんですけどね……。

政治的正しさは組織によって違うし、何なら時間によっても変わっていくのでケースバイケースなんですよね……。
で、Twitterはみんながみんな自分の経験を重ね合わせて判断してしまうので意見が割れる気がします（私含めて）。
でも結局はその場でよく確認して、対話して、アサインされたことをやりましょう、という話ですよね。
新人教育も仕事のうちですしね。

シニアになっていったらそういう視点も必要ですよね。
私も色々考えていますが、指標づくりや予測というのは組織の成熟度合にもよるので簡単ではないです。
ちゃんとやっていく上では必要なのですが、単にプロダクトの品質を確保する、ということのさらに1つ2つ上のレイヤーの話なので業界3年目の新人に求めるような話でも無いように思いますね。

結局コミュニケーションの問題だったと思うんですよね。
元記事の作者の方は勉強熱心な方ですし、例え現時点のレベルが低かったとしても育てる価値はありそうですし。
Slackでクソコード貼ったのが「先輩」の逆鱗に触れてしまったとか……？
私も同じ状況に置かれたら何していいかわからん自信あります。

妥協は必要ですよね。
妥協点は上げ続けたいですが、妥協しなければモノは完成しないし。
問題をコントロールできている、と感じられるだけの技術力を身に付けてからはメンタルも安定した経験があるので、まあバランスと地道な積み重ねなのかなと思います。

まあそういう面はありますよね。
めっちゃくちゃコーディングが早くて設計もエレガントだったら「おお、やってくれ」ってなりますけど、そうではない場合は……プロダクトの価値ももちろん上がらないわけですし……。
とはいえ、そこで新人を上手くコントロールするのも「先輩」の役割だったのでは？　と思ってしまいます。
元記事の方が実は手に負えない独善的な人格の人だったという可能性もあるにはありますが……。

とはいえ、気持ち悪さというのは「実際問題として良くないから感じる」わけで、リファクタリングまではしないまでもある程度テストケースで問題を検知可能な状態に閉じ込めておくような動きは必要かなと思います。
……結局すべきだったのはリファクタリングでは無くテストだった、っていう話の繰り返しになっちゃいますけど。

冷静な意見。
やっぱりお金もらってやっている以上良く考えて実行に移す必要はありますね。

まずメンターの立場で「先輩」はそういう指導をすべきだったのかもしれませんね。
これは自分が後輩を指導するにあたっても有益なので覚えておこう。
ソフトウェアエンジニアって本当に「説明」が必要な職種なんですよね……。

最後に

あえて結論めいたことはここには書きません。
だって、当事者がいる話だし、当事者にしかわからない話だし。
まとめてみても、いろいろと学びの多い「問題」だったなと思います。
自分も今の職場でどうやっていくか、考えさせられました。

とりあえず元記事の作者の方について言えば、一旦退職しちゃいましたけど、人生はこれからも続くわけですし、鬱病で苦しい状態にありながらエンジニアとしてやっていくための勉強は続けているようなのであまり無理せずやっていかれると良いのではと思います。
大丈夫、まだ若いんだから！
やり直しは効きますよ。

いいなと思ったら応援しよう！