2022-11-09

エンジニアとしてやっていく自信を失くした話

TL;DR

自分のエンジニアとしての成長スピードが最近ガクッと落ちた感じがあってなんとなく頭打ちしている感がある。エンジニア30歳定年説はこういうことなのかもしれないと思った。

詳細

自分は今年で25歳になる(一応まだ24歳だけど...)。シードのスタートアップと上場企業を経験して現職では見習いSREをさせてもらっています。スタートアップでは一人でコードを書いていたため誰かにレビューをしてもらう機会は無く、全部独学だった。前職では社内に自分以外のエンジニアがいたが、自分が所属していた部署が新規事業だったということもありあまり誰かと話したりすることなく大体一人でコードを書いていた。そんな中でよくないコードでたくさん実装したし、新しい技術をキャッチアップしないままとにかくコードを書いた。自分が他人と比較して実力が低く、成長スピードが遅いのはレビュワーや同僚がいないからだと思っていた。誰かにコードをレビューしてもらったり、教えてもらえる環境であれば自分は絶対にもっと速く成長できると信じて疑わなかったし、自力で調べながらある程度なんでも実装できるエンジニアになれると思っていた。しかし、転職して自分に初めて上司がついてコードレビューを頂き、自分と同年代のエンジニアに囲まれた環境で働いてその考えが間違っていたことに気がついた。結論、成長スピードは変わらなかった。同僚は全員自分より遥かにエンジニアとしても一人間としても優秀で「これが本物のエンジニアなのか」と毎日圧倒されている。自分なりに色々インプットして頑張ってみたもののどうにも追いつけず、それどころか実力差は開く一方だった。ここで初めて自分のエンジニアとしての人生はここで終わるのかもしれない、と恐怖を感じた。本当に、なんというか、手も足も出ないのだ。これまでRailsでちょこっとサービスを0から開発したり、バックエンドをTypeScript * DDDで開発したり、フロントをNext.jsで開発したり、ちょこっとAWSでリソースをいじったりとなんとなくWebアプリケーションエンジニアとしてやっていけるかなと思っていた矢先、その自信はあっけなく木っ端微塵に砕けた。なんというか、解決策が見えない。どれだけ頑張っても自分が目標としているエンジニア像にはなれないというハッキリとした感覚がある。毎日コードを書き書籍を読んだりしたが、歯がたたない。世の中の自分が目標とする最前線で戦われているエンジニアになれそうにないとハッキリわかったのが今。

こいつどれくらいの実力なんだ？と思われた方は

katsukiniwa.dev

github.com

こちらを覗いてなんとなく実力を感じ取って頂ければと :bow

どこにでもいるジュニアのエンジニアだと思います。今年でエンジニア4年目です。 TwitterでDM開いてるんで実力が気になる方はペアプロしましょう！疑似コードで何かソフトウェア書いたりsystem designの話とかしてみたいです！

結論

だから何か解決策があるという話ではない。エンジニアは実力社会であり、生存者バイアスのかかりやすい職種だと思っているので今一流として活躍されている方はそもそもこういった悩みにぶつかったことがないのだろうかと思ったりしている。もちろん似た悩みや課題にぶつかったとしても自分とは遥かに次元の違うレイヤーで戦っているのだろう。自分は本当に、なんというか、実力が足りない。どうにかして自分が憧れているエンジニアの方々に少しでも追いつけるよう頑張りたい。

2021-11-14

システム設計のまとめリポジトリ作ったとか師匠が欲しいとか色々

社会人1年目も終わろうかという感じなのでちょっと日曜日の余暇を利用して近況報告だったり最近感じた事なんかをダラダラ書いてみました。

awesome-software-design-jaというリポジトリを作りました

概要

システム設計やアーキテクチャの議論をする時に

QiitaのXXっていう記事読んどいて〜

とか

YY出版社のZZっていう本が良書だよ！

と、アドバイスをさせて頂くことが重なったので一念発起して自分がこれまでシステム設計やアーキテクチャを考える上で参考になった記事や書籍をまとめたリポジトリを作成しました。

github.com

作ってみた感想

Twitterで投稿した所、予想以上の反響を頂き素直に嬉しく思いました！
特に以前から作る構想があったわけではなく金曜日の仕事終わりにふと「作るか〜」というくらいの気持ちでザーッと挙げ連ねたという感じです。自分の持っている知識の割合がなんとなく可視化されて面白かったです。

サービスを開発する時に思うこと

いくつかのサービスの立ち上げを経験して、まず自分がエンジニアとして一人前にならないとどうにもならないな〜と痛感しました。作れるサービスって開発に携わるエンジニアの技術力によると思っていて。もちろん技術力が必須ではないサービス(コンサルとかD2Cとか)もありますよ。ただ自分がこれまで携わってきたサービスってエンジニアがまずコードを書いてサービスのPoCを作って、って感じでした。そうなるともうサービスをどれだけ質・スピードを高くしながら作れるかはエンジニアの技術力次第なんですよね・・・。1年前の自分よりは多少視野が広がったかもしれない、とは思いつつも根本的な部分では周りと比較してまるでダメだなと痛感しています。こればっかりは自分の実力・練習不足という他なく猛省しています。

ただ最近友人から「師匠がいないのも停滞している原因ではないか」という指摘を受けました。自分はエンジニア人生の大半を文字通り一人で過ごしてきました。レビューを受けたことはほとんどないですし、技術的な話も気軽にできる人は周りにほとんどいないです。まあ、これに関しては自分の社交性の低さとか徳の低さとかもっと他の部分に原因があるのは自覚していますw。ただ自分にはエンジニアの知り合いがいないので身近に師匠になってくださる方がいなく・・・。

とにかく師匠が欲しいです。自分のどこが具体的に駄目で、どう強くなるのが良いのか。もちろん本当に強い人は独学で強くなれるのは知っています。ただあれ、完全に生存者バイアスというか、再現性が皆無で一種のギフトだと思うんですよね・・・。もちろんその裏にはものすごい努力があるもの知ってはいるのですが、自分程度の実力だとそもそも自力で突破できる壁なんて全然ないんですよね。けどやるしかないのでなんとか根性で勉強はしているつもりですが、目標としている方々や活躍している同世代のエンジニアを見ると「本当に彼らに追いつけるのだろうか・・・」と心が折れそうになります。ウサギと亀の話ではないですが、現実のウサギはトップスピードのまま走り続けますし止まってはくれないです。亀の僕は差が広がっていくのをマザマザと見せつけられて終わる、みたいな感じです。師匠募集しています、っていって募集が来るわけないのは分かってるんですが、皆さんはどうやって師匠を見つけましたか？何卒迷えるエンジニアに１つアドバイスをください・・・。

さて、若干視点を変えて、サービスを開発する時って一人じゃ限界があります。となるとビジネスサイドの人間とやりとりをしてどうやったらリリースまでこぎつけられるか、という話し合いをします。戦略レベルの話ですね。技術選定だったり、アーキテクチャ議論だったり、採用の話だったり、納期だったり。ただ最近ライティングソフトウェアという本を読み始めて(まだ序章ですが)、戦略に対する認識が変わりました。

ライティングソフトウェアでは著者がザ・メソッドというプロジェクトを正しく進めるためのメソッドを提唱しています。そのザ・メソッドはシステムデザインとプロジェクトデザインから成り立ち、前者がシステム設計やアーキテクチャに関するデザインで後者がプロジェクトを進める上での原則をまとめたものです。そしてシステム構築においてシステムデザインよりもプロジェクトデザインの方がシステム構築の可否を握る割合が多いと主張しています(確かそんな主張だったはず・・・)。これは確かにそうだな〜と思いました。完璧なアーキを提唱・実行したところで無謀な納期、アテのない採用、足りない予算では勝てる戦も勝てません。ただそこらへんにも首を突っ込むとなると単なるプレーヤーとしてのエンジニアではなくCTOとして立ち振る舞う、ないし権限を委譲してもらう必要があり、それは一個人でできる範疇を大きく超えています。ただ、少しでも勝率を上げるためにはそういったエンジニアリング以外の部分の手綱も握った上で戦場に立つことが必要なのかな〜とか思いました。

最後に

タイトル考えるのが一番難しかったりしません？自分の場合書きたいことをテキトーにば〜っと書いて最後にタイトルを考えるので文章にピッタリのタイトルが思い浮かばないんですよね笑

2021-04-08

DDDで開発するにあたって

はじめに

自分はRailsでの小規模なアプリケーション(テーブル数が約40~50)の開発経験しかなかったため、新しい会社に入社してからDDDをキャッチアップするのに苦労している。しかし、最近になってようやくDDDの全体像が見えて来たので備忘録がてらどうやってここまで来たのかその道中を記しておこうと思う。

書籍一覧

自分がまず最初に読んだ本はこちら。

little-hands.booth.pm

DDDに関する基礎的な知識が体系的にまとまっていてとても参考になりました。DDDは登場する概念が多いのでまずは上記の書籍で全体感を把握すると良いのではないでしょうか？

次に自分が手に取ったのはこちら

www.shoeisha.co.jp

gihyo.jp

サンプルコードが大量に記載されているので、実際に自分の手を動かして理解する事が出来ました。この本のおかげでDDDに対する基礎知識の叩き台が出来上がりました。サンプルコードはC#ですが実装内容はシンプルなので何らかの静的型付き言語の経験があれば十分読み替えられると思います。自分はRuby以外にTypeScriptの経験しかなかったので写経する時はTypeScriptで行いました。

ちなみに写経してて最初につまづいたのがDIでした。Rubyはダックタイピングが採用されているのでinterfaceを使用して抽象に依存する、という概念を理解するのに時間がかかりました。こればっかりは何度も写経して自力で理解するしかないと思います。constructor DIを使用した場合は注入時に振る舞いが決まるというのは初心者には難しかったです。

この2冊を読んでから今現在、実践ドメイン駆動設計やエリック・エヴァンスのドメイン駆動設計を読み進めています。

www.shoeisha.co.jp

ちなみに今自分はドメインイベントの部分で詰まっています。何らかのコマンドが発生した時に別のコンテキストにその変更を通知する、というのは何となく理解できたのですが、いまいちIDDD_samplesを読んでも理解できないんですよね・・・。

その他参考になった記事

個人的に名人さんのQiita記事全般にお世話になりました笑

エンティティのconstructor自体もprivateにする手法は面白かったです。

qiita.com

あとこちらの記事のDDDを把握するのセクションは大変参考になりました。

qiita.com

思う事

DDDで、つまりドメイン駆動で開発していて痛感するのは開発対象となるサービスを正しく理解する事の難しさです。DDDは文字通りDomain Driven、つまりドメイン駆動で開発します。Rails時代はテーブル駆動でモデルを設計していましたがそうはいきません。ドメインモデル図の作成やユースケースの洗い出しを行って行ったり来たりしながら正確なドメインを作成していきます。ドメインを見間違える、つまり集約の定義や境界を間違えるとそのあとどれだけ緻密にコードを書こうとしても設計が根本から破綻してしまいます。最近自分はその事に気がついたのでこの本を読み進めています。

www.shoeisha.co.jp

まず正しいドメイン層を定義できるよう頑張ります。