これまでの振り返りも含めて
来週の面談等も鑑みて、問題ないようであれば現職を去る…ので自社開発もろもろを見て感じたことなど
結局我流から抜け出せない
エンジニアは市場価値と永遠に戦います。ゆえにVB.netやVB6の現場でよくあるカーゴカルトなプログラミングや、コードを書かない雑用業務を最も嫌います。今まで3社でしたがいずれも自社製品の開発が中心で、技術の開拓は(超選り好みした)一部のエンジニアに留まっている、というのが現実でした。新技術というのはそこには無く、巨大なビジネスロジックと条件分岐の塊によって生じた神クラスがあるだけ。
こんな状態なのでまともなクラス設計をしようものなら逆に怒られるので、一般的なエンジニアがよく書く「実装が必要ならインターフェイスを書いて、ここのドメインはこうあって・・・」というのは書いてもすぐrejectどころかcommit一つひとつを見て否定にはしるというわけですね。VBの現場では巨大なリポジトリクラスもどきはありましたが、それも全部SQLを手動で書いて定数(例えばCONST.HOGE[1]みたいな書き方、マジックナンバーのせいで何を指しているか分からない)を書いたりしました。現職でも同じようにマジックナンバーでHOGE[1]と書かざるを得ないだけでなく、phpで普通にmixinを使う(C#でもありましたが、こちらは最初からnew HOGE()のような書き方がされる、と思っている)ので、どの型が入っているか分からない等でバグが起きることさえありました。
正直、自社開発のベテランはいずれも地雷と呼んでも全然差し支えなく、特に転職や複数言語を扱えないようなメンバーがいたら速攻プロジェクトから外しても良い、採用しなくても良い、と思えるぐらいには設計力も実装力もないです。我流で身につけた技術で、リファクタリングも定期的にやらないままなので、いずれは会社の掃き溜めにでも追いやらないといけません。その労力も払えないと、会社の第一線にクソコードが生み出され続けます。会社も社員も幸せになれない。
マネジメントが客観性を欠いている
我流の問題点は迎合できる人とできない人であまりにも大きな差が出てしまい、人材が定着しないということに尽きますね。
現職ではなんちゃってスクラムでしたが、具体的な指南等は一切ないので全て手探りで、何らかの改善案を実行しようとしても全てベテランの判断で「できない」とされてしまってました。ぶっちゃけ、スクラムやウォーターフォールとかそういう技法よりもベテランの政治によってすべて決定されてしまうという時点で何もマネジメントできてないのでは？という懸念点しか残らず、メンバーが大体3年持たないという離職率の高さが全てを物語っていました。
マネジメント層はそれ相応の研修を受けたり勉強会を受けるのが必要であると思えるし、研修を通じて客観性のあるマネジメントができ、メンバーの士気向上はできるんだろうという期待はあるんですが、一番は他社からマネジメント専業の人を採ってくることなど客観性を直に持ってくることが会社や現場の成長にとっては必要になってくるんじゃないか、と最近では思っています。
自社だけでマネージャの育成をやろうとするとどうしても自社の価値観や手法にこだわってしまい、客観性を欠いたまま成長してしまうので、そういう意味では自社だけで固まる方がちょっとよろしくないという感覚が残っていますね。
若手の技術力はすなわち自らの血と汗をもって得た貴重な資源
ぼちぼちこの業界に入って8年近くと中堅になるので、それよりも全く下の世代アテではあるんですが、5年未満でOOPやTDDのような技術を持っているのは正直うらやましいです。しかも自ら勉強するだけではなく、PHPkaigiのような場所でLTだの登壇だのしていて成長しているわけですから、技術力もそれに比して上がってます。いわば自分磨きのために必死に努力してます。
とはいえ自社開発でもそういう現場はなくもないんですが、CircleCIで働いている方や日本のイケイケ系企業などで見かける程度で、本当に日本の自社開発でそういった高い技術力をもって成長している会社ってそこまでいないんじゃ？とは思ってます。Windows11が出た後も未だにVB6を触らないといけない現場もありそうと思えてしまうぐらいには、技術力は高くなっているどころか全体的に押し下げられているという肌感覚がそこにあります。正直もったいない。
なぜ品質の低いコードが生まれるのか
原因はそもそも経験の幅が狭いことになります。
若手に関しては「他の方法を知らないが、覚えることや変えることは可能」で、どちらかといえば今後コードの書き方等を指南していくことで柔軟に変わっていくだろうという未来がまだ見えています。ただ、現場の雰囲気や風潮などには敏感なので、そういったところでちょっとぎこちないところはあるんじゃないか、というのはありますね。
で、問題なのがベテランで、単に場数が少なかったり経験の幅が狭いと「この方法でやってきた！だから他の方法はいらない！」という理由で排斥行為へと安易に走ります。いわゆるVBのクソコードなんかは代表例で、「この方法でやってきたから大丈夫！」「既にこのやり方でやってきたから良い！」などと明らかに恥ずかしいであろう発言を何度も他人に対して投げつけてくる習性があります。
研修にそんなベテランの人が来て、新人は何も知らなくて、となればその会社はベテランの人が実質牛耳る悪魔城と化するってことですね。狭い知見で広い世界を語ろうとする上にそういった行為を咎めることもできないので、だんだんと技術力と人材を自ら手放してしまうことになります。人材を手放して、技術力を失って、客観的に良いコードの目線を失い、そうしてクソコードは生まれます。見積もりもガバガバなので営業力も「とりあえず取って来ればいいやｗ」と見積もりができないまま適当に案件採ってくるようになるので、納期が厳しいとかブラックとかでますます拍車が掛かりますね。南無。
転職はそんな絶望的状況に対する銀の弾丸か
違います。そもそもそんな状況を許す会社やメンバーが問題であって、転職はそんな状況からそもそも逃げるための手段として使ってはいけません。
大事なのは声が大きい特定の個人の発生を防ぐことであり、全員がお互い平等に話ができる状況でお互いが技術に関して話ができるという状態を保つこと。3社ともその制御ができておらず、ベテランと経営層が衝突したり、逆に癒着しすぎて現場が疲弊したりと新人が毎年必ず何人か離職する羽目になっているという現状を目の当たりにしてきました。
そもそも、マネジメントはエンジニアの駆動力が上がれば上がるほど重点的になっていき、最終的には技術力がなくても上手く現場を回せる人間や、どちらもできる人間のみが制御する、いわゆるエンジンとハンドルのような構造になっていくのが自然ですね。ベテランがエンジンもハンドルもこなすようになってしまえば、現場は振り回されるし、新人が振り落とされてしまいます。
転職をすると、そういった行動による改善や、ベテランになった際に自ら正していくことができない、という言わばハンドルがもがれた状態なので、自分から率先してやりたいという人は中々おすすめできません。ただ、心身に異常が出てきたり、モチベーション維持が難しいな、という方はハンドルを持たない方が幸せかもしれません。自分で責任を持たなければならないので。
マネージャの察知力は現場の察知力なんかよりもずっと弱い
いくら現場で働いてたとしても、マネージャが現場に関して何らかの事態が起こっていることに関しては現場よりもめちゃくちゃ把握するのが遅くなります。肌感覚が違いますし、実際リーダーやPMを経験した際にもそうでした。社員が辞める際、「あ、そうなんだ」としかならなかったり「え？やめちゃうの？」のような感覚になっている場合、もう現場に関して興味がないか、もしくは把握が全くできていない状態といっても過言ではないでしょう。大体マネージャのほとんどがこういった経験をしているんじゃないかって思ってます。実際、毎回「うーん、辞めちゃうのかぁ」のような感想でしたね。
ただ、現場に関して興味を持つだけではダメで、メンバーやステークホルダとの会話を大量に重ねて行って現場のことを初めて知るわけですから、そもそもマネージャの努力不足によってメンバーが離れて行ってるのは正直否定できません。メンバーのあらゆる行動に責任を持たないマネージャは、好奇心も関心もない。でも事実は事実なのでマネージャの責任で、これを対処しない会社も実際のところ問題です。
そういったマネージャの察知力は、言わばメンバーや現場への好奇心や慈善心なので、そういうのがなければ能力があってもマネージャは難しいのでは？とは言えます。むしろどっちかがあれば自ら現場を知った上でマネージメントしますしね。
コーティングを楽しみたい。 → VBはコーディング作業がつまらない。
新しいことをどんどん覚えたい。 → VBは新しいことは覚えられない。
自分のアイデアと創造性をコードで描いて届けたい。 → VBは型にはまったコピペコードを強制される。
サービスや製品の機能や仕様を考えて提案したい。 → VBは作業員が提案や着想はできない。
自分の技術とセンスを評価して貰いたい。 → VBは年功や多重請負での自分の階層位置が評価を決める。
合理的のためなら時には過去の慣習なんて捨てたい。 → VBは形式と過去の慣例が再重視。
実力に見あった高い給料を貰いたい。 → VBは高い給料は貰いにくい。人が二度とVBは書かない理由としては十分過ぎるだろう。
まあ、VBからphpに来たわけですが、これそのものは変わっていませんでした。