この記事は [Atrae Engineers Advent Calendar 2024](https://adventar.org/calendars/10486) の10日目の記事です。 新卒入社して12年以上経ち、干支が一周回っていました🫨 自分は社会人歴 ≒ ソフトウェアエンジニア歴でもあるので、技術者としてのキャリアもそこそこ長くなってきていると言えるでしょう。 1年と少し前から [求人メディアGreen](https://www.green-japan.com/) という歴史あるサービスの開発に関わっています。新規サービスをゼロから開発する期間の方がそれまで圧倒的に長かったこともあり、さまざまな違いを感じながら楽しんでいます。今回詳しく触れるわけではありませんが、チームの中に様々なフェーズやバックグラウンドのエンジニアがいること、歴史 (そして、場所によっては複雑な仕様 笑) を読み解いていく面白さ、先人が整えてきてくれた環境や仕組みを享受できるありがたみなどが例えば挙げられます。 ※自分がジョインする前から現在までの数年間、どのようにGreen開発チームが歩んできたかについては、アドカレ初日の記事に hosakak さんが綴ってくれています。(私の尊敬する技術者の1人です) <iframe class="note-embed" src="https://note.com/embed/notes/n8039b6446a1b" style="border: 0; display: block; max-width: 99%; width: 494px; padding: 0px; margin: 10px 0px; position: static; visibility: visible;" height="240"></iframe><script async src="https://note.com/scripts/embed.js" charset="utf-8"></script> 前置き (?) が長くなりました。自分は、ひとりのエンジニアとしては恵まれた環境で働けています。しかし、技術者としての成長 ( "成長" にもいろんなベクトルがあるので、かなり抽象的なワードを使ってしまっていることを先に謝っておきます ) のためには、自身の置かれた環境に関わらず "当たり前" の基準を上げる努力を続けられるか？がキーになるのだと最近は特に感じています。 ## エンジニアの "配属ガチャ" は存在するのか？ ※一般的な "配属ガチャ" は「希望した部署に必ずしも入れない」みたいなニュアンスだと理解しています。今回使うのは、入った環境が恵まれているかどうか？のようなイメージです もちろん不確定要素は存在するので、”捉え方次第だが、一部存在する" が回答になるのだと思います。一緒に働くメンバーや開発するシステム、事業状況などがどこでも等しく揃っているわけはありません。そして、先述した "当たり前" 基準は、自身がもっとも濃密に関わる環境 (例: 同じチーム) によってある程度規定されてしまうことも致し方ないでしょう。極端な例ですが、プロスポーツ選手と一緒に練習するのと、趣味仲間でトレーニングするのとでは、鍛え方の上限や強度の捉え方が明らかに異なってきます。 特に新卒入社して初めてエンジニアをしますという人間 (自分もかつてそうでした) は良くも悪くも何も知らないためｗ、一緒に働いた人や環境に "当たり前" が大きく影響されるのは確かです。( だからこそ、受け入れるチームは、当人の基準を上げていけるような環境をデザインできるか？が重要になってくるのですよね。責任重大です... ) ここでは - 会社やサービスのビジョンには共感しているし、技術者として成長して貢献したい. もっとシステムを良くしていきたい - 技術者として強くなりたいし、基準 (レベル) を上げてくれとも言われてる. でもよくわからんし、今の環境でできるのか...? という人 (特にまだキャリアの浅い方に多いのでしょうか...?) が、所属する環境に引っ張られすぎず基準を上げるきっかけを作れないか？という視点で、そのHowの一例を書いてみます。 ※これで貢献がすぐできるようになるという話ではありません ## 外の世界を知る "外" というと勘違いを生むかもしれませんが、要は「自身の置かれた世界が当たり前ではない」という認知を得るための動きです。所属するチームのコードのみ日々読み書きし、同じチームの開発メンバーとのみコミュニケーションをし、それ以外特に何もしていない、という状態に仮になっているとしたら、結構効果があるんじゃないかと思います。 例えば、簡単なのは技術書を読むこと。非常にベタな方法ではありますが、良い技術書を選択すれば、ベストプラクティス・スタンダードとされていることが記載されており、システムを作っていく中での "常識" や "理想論" を得ることができます。もちろんシステムは生き物であるため、得た理想論にすぐ辿り着けないですしそれが唯一解なわけもないのですが、少なくともベンチマークとなる存在ができたり、考える時の引き出しになったりします。読むの苦手なら動画で学んでもよし、輪読会にしてもよし、です。 ![[IMG_1904.jpeg|360]] *最近読んでいるこの本はとてもいいです...* これまたありきたりですが、外部の勉強会に参加したりするのも良いですね。自分も過去に (というか今でも...😢) 経験がありますが、業務で触っている技術に関する勉強会に参加してみて全然内容がわからなかったりすると、なかなか悔しいものです。「他社の人はこれくらいのレベルは少なくともあるのか、自分・自社も追いつかなくては...」という気持ちになります ※話がそれますが、ちょうど先週末にチームの後輩に誘われ[ISUCON](https://isucon.net/)に出場したのですが、これまた学びと刺激と悔しさがあり良い機会でした。 自身の会社に複数のプロダクトが存在するのであれば、別のチームが開発しているコードを読んでみるのも良いでしょう。あそこのチームのあのシステムはよく出来ている、と評されているような場所があるならば、そこを選びましょう。歴史、技術課題、作っている人などが異なるので、日頃触れている環境と何かしら違いを感じられるはずですし、気になったらオーナーに聞ける可能性もあります。キャリア初期だとレベルの差分が判断できないことも正直あるとは思いますが、今自分が触っている以外のシステムや開発チームが同じ組織に存在すると手触り感持って感じるだけでも違うはずです。 ※もちろんOSSのコードでも良いと思います 方法は正直何でも良いのですが、とにかく少し "外" に出てみると、技術者としての自身や置かれた環境の現在地を意識するようになり、基準を変えるためのスタート地点に立てます。環境が恵まれていると把握したなら今以上にそれを活かして頑張ればいいし、そうでないなら改善・成長のとっかかりが見つかったと喜べばいいでしょう。 ## 手なりでやってない？と疑う (「手なり」ってなんとなく使ってたけど、調べてみたら麻雀用語なんですね ) どんなエンジニアでも開発をしていると必ず出くわしてしまうのが、システムの不具合というやつです。手なりになりやすい例の一つとして挙げてみます。自分ももちろん対応することはありますし、周りでも観測することの多い活動です。俯瞰した感想にはなりますが、取り組み方ひとつで地味に差がつく面白い例だと思っています。 不具合といってもいろんな切り口の内容があるので全て等しく扱えるかは分からないのですが、「さっさと逃れたい邪魔もの」と捉えている人は「システムを学ぶ機会」と認識を変えてみましょう。それが結果として "当たり前" のレベルを上げることにつながるはずです。 本来やりたかった開発がある中で突然飛び込んでくるものですし、時間の制約もあります。そもそもソフトウェアに価値を生み出すために開発しているわけなので、他に優先されるべきこともあるでしょう。ですが「学びの機会」と捉えて、不具合周辺のコードをじっくり読んで理解したり、「もっとこうなっていたらいいのに」と感じたりすることもまた重要です。ふだん同僚の若者に言っても伝わりきらないなと感じることも多いのですが 笑、コーディングの際に最も重要なのは書くことではなく読むことです。ゼロの状態からシステムを作る機会などそう多くなく、基本的には既存のシステムが積み上げてきた歴史を読み解きながらコードを追加したり修正したりしていくものです。そうした行動を将来レベル高くやっていくために複利で効いてくるのが、コードリーディングを通してシステムを理解すること・システムに意見を持つことではないでしょうか。 他者も関わってくる話にはなるので大きくは触れませんが、コードレビューも同じです。ただ承認を得るための通過儀礼のように捉えるか、議論を通して学びを得るための仕組みだと捉えるかで変わってきます。 短期で見たときのアウトプットが仮に同じでも、捉え方次第でプロセスの密度は大きく変わり長期で効いてくる。すぐに見えないからこそ、なかなか怖いものだなと自戒も込めてそう思います。 ## 閑話休題: 生成AIとエンジニア ChatGPTがローンチされてからもう2年経ったというニュースを先日見ました。開発を取り巻く環境は大きく変わり、ソフトウェアエンジニアというロールはこれから少しずつ姿を消していくのかもしれません (消えはせずとも必要な数は確実に減っていくでしょう)。 外の世界を知るために技術書を読むべきなどと書きましたが、その内容についても生成AIに聞けば教えてくれるようになっています。もちろん全てを体系的に整理してくれているわけではありませんが、少なくとも聞けば何か答を返してくれますよね。 "実現したいことを伝えれば、それをソースコードに落として実現してくれる" の範囲もどんどん広がっていきます。 そういった新たな知性が現れた時、その座を真っ先に奪われるかどうかも "当たり前" の基準の高低が関わってくるはずです。( 奪われるというよりは、他の職種、例えばプロダクトを企画する人が生み出すシステムアウトプットと比較した時に大きな違いが生み出せない・審美眼もない。だったらあんまり必要ないよね...となっていくイメージ ) 結局、高い水準でシステムを作る力があるかどうかや、こだわりや知的好奇心が強いかどうかなど、 "当たり前" の基準に尖りを持っていたほうが良いよな、という所感です。 ## 終わりに これまで書いてきたことを少しやったとて、基準がいきなり書き変わったり急にレベルが上がったりするものではありません。しかし、やらないとあまり前に進まないのも事実です - 当たり前の基準を漸進的に押し上げていく - 当たり前だと考えていることを当たり前に実行する これを一人のエンジニアとして、そしてエンジニアチームとして実現することが、長く価値を生み出し続けるシステムを開発していくために必要だと改めて思う近頃です。「良いシステムを作りたい」という思いだけではどうにもならず、その思いを実際に形にするためのOSやCPUも合わせて進化していかなくてはなりません。 今回は他者との協働ではなく個人でコントロールできることのみにフォーカスした内容にしましたし、レベルの高いことを書けたつもりも全くないのですが、それでも一事が万事ではあり、積み上がっていくと大きな違いになっていくはずです。なんだか内輪向けの内容になってしまった気もしますが、時間もなくなってきたのでこれで一旦締めようと思います。 ほんとうはもっと技術的なことを書きたかったのですがｗ、ちょっとタイミングが悪かったので、またいつか別の機会にすることにします。 ![[IMG_1666.jpeg|480]] *最後に意味もなく我が家の犬猫を貼ります*