社内向けプロダクトエンジニアだった僕の5年
僕のエンジニアとしてのキャリアは，社会人4年目で始まった．それまでの経験とは全く異なる分野への挑戦だった．
僕はそれまでプロダクト開発とは無縁の世界で働いていて，そこから縁あってソフトウェアエンジニアになっている．エンジニアとして初めて仕事を得たのは2019年の1月．そこから数えて丸5年間が経った．今現在は割と大きなプロダクトのバックエンドを担当している．
しかし，僕はほとんど社内向けプロダクトしか開発してこなかった．だから2022年に今の会社に転職したとき，仲の良いヘッドハンターを含む周りの方に「よく転職できたね．社内向けプロダクトしか開発してない経歴だと難しいと思った」と言われた．ああそうなのかやっぱりそうなのかと心の中で思った．
社内プロダクトの開発は一見地味に思えるかもしれないが，実際も地味だ．それは認める．でも，学べることは際限なくあるとも思っている．社内プロダクトだから学びが少ないと思っている人はきっと向き合ってる技術に対する問いが足りていないだけなのだ．
とはいっても，自分だってこのキャリアを不安に感じたことはあったので，どういうラーニングパスを踏んできたのかを共有することで誰かの何かの参考になったらいいなと筆をとっている．あ，自分のための備忘録でもある．
このブログは，僕と同じ様に途中からエンジニアになった人や，いまそれを考えている人，社内向けのプロダクトを開発している人を読者として想定する．最初からソフトウェアエンジニアとしてバリバリ自分のキャリアを築いてきた人には特に得るものはないかもしれないが許して欲しい．．
このブログで伝えたいメッセージはきっとこんな感じだ．
- 社内向けプロダクトだからだめということはない
- 何を学べるかは何を学ぼうとするか次第．自己研鑽は大事
タイトルにもある様に，このブログは僕のエンジニアとしての振り返りでもあるので，5年前の2019年から書き始めようと思う．
0年目（2018年）
ちなみに僕は新卒で入った会社を辞めてエンジニアになる前に目黒にあるLe Wagonというブートキャンプに行っている．9週間をかけてRuby, OOP, HTML, CSS, JavaScript, Ruby on Railsを学び最後にのアプリケーションを作るというもので，非常にためになった．そういったブートキャンプに通うことはおすすめだ．参加にあたって試験や面接があるものをお勧めする．参加者のやる気が違う．
1年目（2019年）
ブートキャンプが終わり，1ヶ月間の転職活動を経て，都内のベンチャー企業に迎え入れてもらうことになった．会社とプロダクトと技術面はこんな感じ：
| 項目 | 実際 |
|---|---|
| 会社フェーズ | 創業3期目 PMF前 |
| 組織フェーズ | 社員15人程度，開発組織4名（うち1名インターン） |
| 事業領域 | Fintech |
| 担当プロダクト | BtoB SaaS, 社内プロダクト |
| プロダクトフェーズ | PMF前（Paid Userが10社程度），分間数リクエスト |
| プロダクト概要 | |
|---|---|
| 言語 | Ruby on Rails，Python（ML） |
| インフラ | AWS EC2 |
| サービスアーキテクチャ | モノリス，バッチ |
| データベース | RDBMS |
| CI/CD | なし |
| Observability | なし |
ゼロからのスタート
右も左もわからずの状態からスタート．体系的に学ぶなんて余裕はなく，とにかく目の前で必要な知識をキャッチアップすることから始まった．幸いにもRailsに関してはブートキャンプで身につけた知識で戦えた．
対外向けのプロダクトとはいったものの，プロトタイプ段階でもあったから，社内向けプロダクトとその責任（影響の大きさ）はさほど変わらなかったと思っている．実際GAを見ても当時は1分に1セッションくるかどうかの世界で，GA見ながら「いま誰も見てないのでサーバー落としてリリースしましょうか」なんてことをやっていたものだ．
炊飯器なしでご飯を炊けるか
いい経験だったのは，この会社，GitHubを使わずオリジンをオンプレサーバーに持ってバージョン管理していたり，デプロイの際はソースコードをsftpでEC2に送り，EC2に入ってまずアプリケションサーバーを切って，asset:precompileした後アプリケーションサーバーを手動で起動し直すといった様な全般的な開発体験の古さだった．
わざわざ経験すべきとは思わないが，技術的に古風であることをそこまでネガティブに捉える必要はないと思っている．ツールを使えばやらなくても済むことをあえて覚えることができ，次の会社でツールをデバッグするときに良い勘所を持てる様になったと思う．炊飯器を使わずにご飯を炊く経験に似ている．この感覚はその後もすごい大事にしている．
一応言っておくが，ずっと古いのはもちろんダメだ．
とにかく仕事．傷跡を残す
当時の僕にはCI/CDなんてものは導入できなかったが（テストも無かった...），AJAXを導入してちょっとでもフロントだけで制御したり，テストをちゃんと書いたり，もちろん機能開発も一生懸命やった．途中から会社の鍵ももらえたので土日にオフィス行ったりしてとにかくコードを書いていたと思う．お金も無かったし．
自分がコードを書くことで対価がもらえるようになったことが純粋に嬉しかった感覚がある．
機械学習
ちなみに，ここまでのキャリアの中でこの職場で唯一機械学習を触った．リファクタリング程度だけどJupyter NotebookのPythonコードに触れた．Courseraでスタンフォードの有名な機械学習講座も修めた．
まあそうは言うものの，1社目は8ヶ月であっさり転職することになる．今度は規模感が3倍ほどのスタートアップに入る．
2〜4年目（2020〜2022）
さて，先ほどと同様に入社当時の概要をまとめると
| 会社概要 | |
|---|---|
| 会社フェーズ | 創業4期目 |
| 組織フェーズ | 社員50人程度，開発組織10名程度（正社員4名） |
| 事業領域 | HR |
| 担当プロダクト | 社内プロダクト（対外向けのプロダクトもあった） |
| プロダクトフェーズ | ユーザー数＝社員数 |
| プロダクト概要 | |
|---|---|
| 言語 | Ruby on Rails |
| インフラ | AWS EC2 |
| サービスアーキテクチャ | モノリス |
| データベース | RDBMS, Elasticsearch, Redis |
| CI/CD | CircleCI |
| Observability | Mackerel |
対外的に無料公開してるWebプロダクトもあったのだが，僕は社内向けプロダクトのチームに配属される．この会社の経験がなければ今の僕はなかったと断言できる．それくらい実に幅の広い経験をさせてもらうことができた．
僕にとって最初の学習機会はこの3つだったかなと思う：
- より複雑なRails
- CI/CD
- Elasticsearch・Redis
社内プロダクトとはいえプロダクトが大きく，より複雑なユースケースに応えるためアプリケーションも様々な技術的工夫が施されていた．プルリクを作るとテストが実行され，マージするだけでEC2へデプロイが走り出すCI/CDの体験も当時の僕にとっては新鮮だった．ドキュメント型のデータベースや，キャッシュの活用も初めてだった．
SPAとAPIサーバー
入社後数ヶ月して，フロントエンドをVueで分離するプロジェクトが始まったため，バックエンドとフロントエンドをREST APIをインターフェイスとして分離するアーキテクチャもここで初めて触れることになった．
アジャイルプラクティス
開発手法という面では，アジャイル開発にとても知見のある方のおかげで，スクラムやアジャイルプラクティスについてもしっかり考える機会に恵まれた．これについてはかなり恵まれたと思う．
データベース・データ分析
また，当時スロークエリが問題になっていたので，MySQLにおいての基本的なパフォーマンスチューニングや，RailsのORM（ActiveRecord）の構文を見直したりしていた．
その後，全社的にデータ分析が弱かったこともあり，データドリブンに戦術を立案できないかと思いデータ分析にそれなりの時間を費やすことになった．ETLというほどのパイプラインはないが，Redashを用いてデータ分析に必要なクエリ構文を一定身に付けたと思う．
エンドユーザー向けプロダクトとNuxt
入社して1年半，エンジニアになって2年が過ぎた頃，主に触っていたプロダクトの派生プロダクトとしてNuxtを使ったSPAの開発が始まった．主な実装はフロントエンドエンジニアの方が行ったが，当時プロダクト全体を見る立場にあったので相当程度キャッチアップするよう心がけた．インフラも全て自分たちで管理していたから，フロントエンドをホスティングするために必要なAWSの構成もここで経験する．
IaC
さらに，それまで手動管理していたインフラをTerraformに移行するプロジェクトに本格的に足を突っ込み，既存リソースの移行作業を行った．ディレクトリ構成も途中で大幅に変えたので，リソースを誤って消さないようにtfステートの管理（state rmやらimportやら）や移行を行ったのは保守という点では初めてと言っても良い重要な作業だった．個人的にはIaCは非常に好きな技術である．ちなみにその後AWS CDKもちょっと使わせてもらっていた．
EC2→ECSマイグレーション
個人的に楽しかったプロジェクトの一つがEC2からECSへの移行作業だった．CI/CDやインフラを変更しながら，プロダクトのダウンタイムを瞬断で済む程度に抑えつつほとんど問題なくリリースできたのでとても安心したし，一番自分が上手く進められた案件かもしれない．
Observability
その後はObservabilityに関与することになった．DatadogやNewRelicを検討し，導入作業を行った．今となって思えばObservabilityツールについてもTerraformで書けばよかった．
対外的なアウトプット
在籍中はエンジニアチームとして技術書展に小冊子を出したり，イベントで登壇したり，ブログを書いたりとアウトプットも多かったと思う．
個人開発
在籍中は自分の勉強を目的として個人開発もしていた．
Vue, API Gateway, Dynamoで簡単なサービスを作って社内の人に使ってもらったり，
Next.jsにも触れてサービス開発もしてみた．仕事で使うことはないと知りつつRustを勉強してみたり，WiresharkやRaspberryPiで遊んだりといった感じだった．役に立ったかと言われれば，結果的にとても役に立った．
CS基礎を体系的に学ぶ
在籍中は業務とは別に座学で以下の様な項目を勉強した
- コンピューターサイエンス（CS）基礎
- セキュリティ
- アルゴリズムとデータ構造
僕はエンジニアの仕事を始めるときにCSの知識がなくても良いと思っている派だ．とはいってもエンジニアの道を登っていくなかではどこかで必ず習得すべき知識になることは間違いない．入社した年（エンジニアの仕事を始めてから1年経った頃），CourseraでCS基礎講座を受講した．
そしてさらに翌年はセキュリティについて自分で勉強することにした．毎日何かしらセキュリティに関するツイートを続けてみたり，自分でRaspberryPiを買って簡単なハッキング手法を試してみたり．関連してZennでブログや本も書いた．
あとは大手SIerの社員がよく受けてるような資格もどんなもんか知っておこうと考えて，情報処理安全確保支援士（セキスペ）を取得した．
その翌年は再度CSに戻り，今度はアルゴリズムとデータ構造の勉強を始めた．結構大変だったが，Courseraで有名な「スタンフォード大学 Algorithm Specialization」全4講座を5ヶ月間かけて修了した．LeetCodeもそれなりに解いた（当時は転職するために解いていたわけではなかった）
Youtube
この会社に在籍している間に見たYoutubeのテック系の動画は300〜400本くらいあると思う．一時は1時間あった通勤時間に毎日見てた（朝弱いので行きは寝てた）こともある．
見ていたものは色々あるけれど，大体こんな感じに大別できる：
- 今使っている技術のもっと深い話
- 今全員が大前提として当たり前に使っている技術のもっと深い話
- 今使っていない技術の概要の話
- kubernetesの概要とか色々基本的なやつ
- C/C++におけるポインター
- Rustの歴史学べるやつ
- サイバーセキュリティに関連する手法の話
こうすることで，自分の知識の深さと広さをバランスよく拡大していける．深く理解することは”今”の自分に必要なことで，広く理解することは”将来”の自分の仕事のために必要だ．実際，広く勉強しておくことはポジションを変更してもらえる可能性や，時や新しいポジションができたときに異動できるチャンスを上げてくれる（実際このおかげで僕もTerraformやObservabilityを担当する仕事ができた）
ちなみに（英語について）
ちなみにここまで読まれた方は思うかもしれない「全部英語じゃねえかよ」．
すまないその通りだ．英語も勉強したんだ．Youtubeに関しては英語とプログラミングを同時に勉強するために見ていた側面もある．
帰国子女でもなく留学もしなかったのにどうやって英語を勉強しているのかというのは別のブログに書いたことがあるので気になったら読んでみてほしい．
4年目〜現在（2022〜）
さて，話は戻るが4年半が経った頃に次の会社に転職する．これが今働いているところだ．環境はこれまでと大きく変ったと思う．
| 会社概要 | |
|---|---|
| 会社フェーズ | 創業4期目 |
| 組織フェーズ | 社員1,000人程度，開発組織400名程度 |
| 事業領域 | 金融サービス |
| 担当プロダクト | BtoCアプリのバックエンド |
| プロダクトフェーズ | PMF後グロース，登録ユーザー4,000万 |
| プロダクト概要 | |
|---|---|
| 言語 | Kotlin, Java |
| インフラ | AWS, Terraform, kubernetes |
| サービスアーキテクチャ | マイクロサービス |
| データベース | RDBMS, Redis, DynamoDB, etc |
| CI/CD | Jenkins, ArgoCD, GitHub Actions |
| Observability | NewRelic, Graphana |
非連続な環境
これまでとは何もかも違う環境になった．モノリスからマイクロサービスになり，Duck typingから静的型言語に，ECSではなくk8sに，初めてのToCプロダクトに，トラフィックも大きく，コミュニケーションも日本語から英語に．とても良い転職だった．
入ってみてすごく実感したのだが，それまで学んでいたことにとても助けられたということだ．RustをやっていたおかげでJava/Kotlinを学ぶときのハードルは下がったし，フロントエンドからインフラまで前職で関与できたおかげで，他チームとのコミュニケーションや会話も問題なくできたと思う．もし前職も大きな会社でただサーバーサイドしか開発していなかったらこうは行かなかっただろう．
そう言った素地の上で，今は少し専門性を高めるタイミングなのだろう．この現場での学びはいつかまたまとめたいなとは思う．
ちなみに，いま一番苦労しているのはドメイン知識の理解である．主だったマイクロサービスが数十あるなかで多くのプロジェクトが並走するので，各ドメインロジックは頻繁に変わっていく．全体をそれなりに理解しながらプロジェクトを上手にリードできるようになるためにもキャッチアップが永遠に終わらない感覚である．また，ドメイン知識を追うあまり肝心な技術的なキャッチアップが疎かになってしまう時もあるから気をつけたいところだ...
これから
ここまでくるのも決して簡単とは言えなかったが（お金の面でも），今のところは本当に楽しい．しかし生成AIの登場やAGIによって「自分の書いたコードが動いた！」「プロダクトの要件をコードに落とす」という作業に喜びを感じるのはそろそろ気をつけたほうが良いだろう．数年以内には「課題を見つける」「アーキテクチャを考えること」ですらAIがアーリーマジョリティ領域に進出する気がする．もっと課題の抽象度，解決方法の抽象度をあげらがらコードを書いて，プロダクトコードがデリバリーするまでのラストワンマイルに責任を持てるようになっていきたい．
Discussion