以下の内容はhttps://ishikawa-pro.hatenablog.com/entry/2025/10/15/154212より取得しました。


新卒入社して6年ちょっと働いた会社を退職しました

2025年8月22日に、新卒の頃から在籍していた会社を退職しました。
2019年4月に新卒として入社して、6年と4ヶ月ほど在籍していました。
次の会社は決まっており、現在は約2ヶ月の有休消化中です。

退職理由としては、特に会社が嫌になったとかではなく、自身のスキルアップとキャリアアップのためです。
どんなことをやってきたかを多分どんどん忘れていくので、新卒からこれまでどんなことをやってきたか、ざっくり振り返りも書いておこうと思います。
極めて個人的な振り返りなので、最後まで読んでも得られるものはありません。

2019〜2021年8月

最初の半年は、結構古いサービスのバックエンドのちょっとした機能追加やリファクタリングとかをやっていました。
社内で Node.js を使い始めた頃に書かれたサーバーで、非同期処理が callback や Promise やco + generator など、色々入り乱れていて Node.js の歴史を感じながら開発していました。

半年が過ぎると、仮配属から本配属になり、自分は全然違うチームに異動となりました。
異動先では、新規サービスの立ち上げとかをやるチームに移動しました。
新規サービスの立ち上げと言っても、普通にゼロから作るのではなく、社内でマイクロサービスとして構築された headless CMS や認証・決済基盤などを利用して、新規サービスを開発するというのが、そのチームのミッションでした。
当時は、マイクロサービス側もできたばかりで、チームも新しくできたばかりという状態だったため、前例もほぼなく全て模索しながら開発するというような感じでした。
さらに、これからは TypeScript を採用していくという方針になったため、社内で詳しい人もいない中でTypeScript を学びながら、前例のない社内の共通基盤を利用しながら新規サービスを開発するということをやっていました。
最初は本当に大変でしたが、みんなで模索しつつ徐々に前例を作りながら開発パターンのようなものも出来始めていきました。
このような新規サービスの構築とか、大きめな機能追加のプロジェクトとかを2年半くらい点々とやっていました。

2021年9月

前述した社内のサービス開発基盤を使いながら新しいサービスや機能を開発するというやり方も、かなりパターンができてきました。一方で個人的には、毎回同じようなことばかりやっているなと感じるようになってきました。
また、当時 ISUCON にも1人で参加しており、前年と比べても良い結果ではなかったことから、技術的な伸び悩みを感じてきていました。
そこで転職を考えていたのですが、特にリファラルとかをしてもらえるようなエンジニアの知人もいなかったため、軽い気持ちで X にポストしてみました。

すると、なぜかプチバズってしまい、すぐに人事との面談が入りましたw (今でも昔 X でバズってましたよねってたまに声をかけられます)
面談では、上述しているようなことを人事とマネージャーに話して、もっとパフォーマンス改善や開発基盤の改善など、技術力を上げられるような仕事がしたいと言ったところ、チーム異動させてもらうことになりました。

異動後(2021年10月)

異動先は、数名のシニアエンジニアで構成されているチームで、開発基盤のパフォーマンス改善や社内の開発ツールキットのメンテナンスをしたり、場合によってはサービス開発に入って色々なサポートをしたりする、今で言う Enabling とか Platform Engineering と言われるチームに異動しました。
異動後は、これまでの経験を活かして、サービス開発チームの設計をレビューしたり、基盤側のメンテナーとしてコードレビューをしたり、パフォーマンス改善をしたり、たまにサービス開発に入ってサポートしたりしていました。
あとは、2年目くらいから DevOps にも興味が出始めて、k8s の本や分散システムなどのインフラ寄りの勉強もするようになりました。インフラがちょっと分かってくると、 CI/CD や k8sマニフェストなども自分で書いたりするようになり、自然と SRE との関わりが増えるようになりました。
当時は、CI/CD や環境構築も含めて、インフラ面はほぼ SRE に丸投げする文化だったのが、ここ数年はバックエンドエンジニアが自分でやるようになったので、少しは DevOps に貢献できたんじゃないかなと思っています。

当時読んで影響を受けた本

www.oreilly.co.jp

www.oreilly.co.jp

2022年

異動して数ヶ月した2022年2月ごろに、新卒の頃からお世話になっていた先輩社員が転職しました。
backend のリードエンジニアで、自分以外の人も頼りまくっていたので、個人的には大きな出来事でした。 先輩とは同じチームで働いていたこともあり、自分もいくつか引き継ぎをしたのですが、コードレビューの量が圧倒的に多くなって、最初の頃はどうやってレビューを捌きながら自分の仕事をやったらいいのか結構悩んでいました。
今振り返ると、当時は自分の「こうあるべき」というこだわりが強すぎていたなと思います。(コードの書き方とか設計とか)
そういう過度なこだわりは、一つ一つに細かく目を通しすぎてしまい、時間がいくらあっても足りないし、ゲートキーパーとしてみんなの障壁になってしまいます。
そして、自分の時間の足りなさや、ゲートキーパーとしてみんなの仕事の速度を落としてしまう申し訳無さなどから、あまり細かいところまでは見すぎないように意識するようになっていきました。
これは、単にレビューが雑になったということではなく、守るべき部分がどこなのか、どういうトレードオフ(デッドラインや既存システムとのしがらみなど)があってそういう設計になっているのか、などを加味して、どういう落とし所にするか考えるようになっていきました。

そういう開発や運用体制のあり方については、「システム運用アンチパターン」という本にすごく影響を受けました。
www.oreilly.co.jp

この年の自分の取り組みとしては、フロントエンドが Next.js を採用するにあたり、サーバーのホスティング場所をどうするかなどについて設計を進めていました。結果として、 Cloud Run を中心としたホスティング基盤を設計したり、 Cloud Run の revision 機能を活用した Preview Deploy 機能を構築しました。
このあたりを機に、k8s や Cloud なども積極的に触ったり、SRE と一緒に設計したりするようになりました。そして DevOps 方面に興味が向き始めていたんだろうなと思います。

cam-inc.co.jp developers.cyberagent.co.jp

あとは、Tilt というOSSのツールを使って、 local k8s cluster でローカル開発環境が構築できるように刷新 & 移行したりしていました。

tilt.dev

この移行も、アプリケーション開発者と k8s の距離をいかに縮められるかなどを意識して、設計を詰めて取り組みました。
特に影響を受けた Lyft の記事。 eng.lyft.com

この年は、そういった取り組みなどを評価していただき、半期に1度開催される社内のアワードでベストエンジニア賞を頂きました。

2023年

2023年は Platform Engineering との出会いの年でした。
当時、自分は backend エンジニアという職種だったのですが、backend のコードはあまり書いていないので若干違和感を感じていました。かといってサイト信頼性に責任を持つわけでもなかったので SRE でもないなと思っており、これは世の中的にはどういう仕事なんだろうと色々調べていたら Platform Engineering という言葉にたどり着きました。(当時、日本でも話題になり始めてたのもあり)
Platform Engineering という言葉を知ったときは、まさに自分がやっていることや、やりたいことはこれだなと感じました。

そして、自分の気持ち的に Platform Engineering が盛り上がっているタイミングで、 Platform Engineering Meetup の運営メンバーを募集しているのをたまたま見かけて、面識もない jacopen さんのツイートに飛び込んでいきました。

このおかげで、勉強会や Community の Slack などを通して Platform Engineering のトレンドを追えるようになりました。

仕事の方では、自分が入社してすぐにローンチされたサービスで、自分も色々開発に関わっていた思い出深いサービスが終了しました。サービスが終了しても、その裏側で動いているマイクロサービス群は内部プラットフォームとして生き続けているのですが、深く関わったサービスだったので感慨深いものがありました。

あとは、エンジニアの各職種のリーダーが集まって、半期に1回の頻度で技術組織の半年先や1~3年先の職種毎のロードマップを考えたりする合宿が、開催されるようになりました。
当時、ぼくはまだ合宿に参加する立場ではなかったのですが、 backend エンジニアとして事前に色々話し合って議論したり準備したりするのに加えてもらっていました。
この頃は、エンジニア組織としても数年がかりの大きなプロジェクトがひと段落し、この先どうしていきたいか?などのビジョンや方向性などを考える必要がありました。
当時の自分は、細かい技術的な問題など、目先の課題などについてしか考えることがありませんでした。そのため、もっと俯瞰的に考えたり、 backend 組織としてどういう課題に向き合っていくか、などについて考えるいい機会になりました。
この年の合宿で、 Polyrepo + Microservices という構成をやめて、 Monorepo + Modular Monolith に移行していくという決定もしました。
技術的な詳細は、会社の技術ブログでも解説しています。

developers.cyberagent.co.jp

当時読んで影響を受けた本

2024年

2024年は Platform Engineering に関する活動をたくさんしました。
仕事以外での活動でいうと、2月に Platform Engineering Meetup 運営メンバーとして Developers Summit に登壇させていただきました。

event.shoeisha.jp

次に、こちらも Platform Engineering Meetup 運営メンバーとして、 CodeZine にて記事を書きました。
運営メンバーでの連載だったのですが、自分は Internal Developer Platform について解説しました。
こういったメディアへの寄稿は初めてで、一度はやってみたいなと思っていたので、実現できてとても嬉しかったです。
codezine.jp

次に、 Platform Engineering Kaigi 2024 の実行委員をやりました。
やったこととしては、公式サイト開発チームのリーダとして、3名のチームでサイト構築をしました。
当時はまだ ClaudeCode などの優秀なコーディングエージェントもない時代だったので、得意でもないフロントエンドを頑張ってオーガニックコーディングで、セッション募集開始の前日の深夜まで開発したのもいい思い出です。

www.cnia.io

あとは、実行委員だけでなく、会社がカンファレンスのスポンサーをやっていた関係で、スポンサーブースの企画を考えたり、スポンサーセッションとして登壇もしました。
カンファレンス規模のイベントに一人で登壇するのはこれが初めてだったので、緊張しましたが、これもとても貴重な経験になりました。

speakerdeck.com

登壇系だと、AEON TECH HUB というAEONさんが主催してるイベントで、「大規模システムの効率的運用の裏側」というテーマでパネルディスカッションをしたりしました。
ぼくはアドリブが苦手なので、事前にもらったトークテーマをもとに、めちゃくちゃ準備して同僚にもチェックしてもらったりしてから挑みました笑 aeon.connpass.com

仕事面でも Platform Engineering に関する活動をたくさんしました。
2023年末か2024年の始めくらいに、 CTO からそろそろ Platform Engineering にも注力していきたいという話があり、3~4名くらいの規模で全員別業務と兼務で Platform Engineering のチームができました。
仕事内容的には今までとそこまで変わってない気がしますが、 Platform Engineering っぽいこととしては、ドキュメント整備などを頑張ってみたり試験的に Backstage を導入したりしました。あとは頻繁に社内で勉強会を開いたりして、社内でも Platform Engineering の勉強会とか、 Platform Engineering Team の取り組みとかを発信したりしていました。

2025年

2025年は、CTO が別の事業部へ異動するという大きな変化から始まりました。色々な面でお世話になっていたので、最初に聞いた時は本当にびっくりしました。
その影響もあってエンジニアの組織編成も色々と変わり、自分はエンジニアボードというエンジニアの各職種のリーダー1~2名程度で構成されるグループのメンバーに加わりました。(このグループで半期に1回の合宿に行ったり、毎週の定例で情報共有などをやっています)

あとは、エンジニア向けのAIツールの導入にかなり注力しました。
2025年の初めの方では、Claude 3.7 や o3 や Devin の登場など、コーディングエージェントの性能が大幅に上がり、世間ではとても盛り上がっていました。
一方で社内では GitHub Copilot によるコード補完くらいしか活用できておらず、他のツールなども検証してみたいけどどうしようか、という感じで誰もリードせずに止まっていました。
そこで、エンジニアボードという立場も利用して、自分が旗振りをしてAIエージェント系ツールの比較や検証などを進めていくようになりました。

結果として、 Devin と Cursor を会社として導入して、エンジニアが使えるように社内用のドキュメントやルールなどを整備しました。
この辺の意思決定を、今までだと CTO に頼っていたりしたのですが、自分の意思を持ってリードして進めることができたのも、個人的には成長を感じました。(もちろん周りのサポートがあってのことですが。)

Devin はかなり会社にフィットして活用できていたので、 Devin Meetup Tokyo というイベントでその辺りの発表もしました。

speakerdeck.com

自分が退職する直前には、かなりのエンジニアが Cursor を利用しており、Slack の Devin チャンネルでは色々なエンジニアが Devin に指示を出すようになっており、それなりに達成感がありました。

まとめ

こうして振り返ってみると、徐々にステップアップして行っている様が見えるのと、いいタイミングで貴重な機会を与えてくれた周りの人たちに感謝しかないなと思います。
6年でたくさんの経験を積ませていただいた会社や職場の人たちに感謝をしながら、次の職場でも頑張ろうと思います。




以上の内容はhttps://ishikawa-pro.hatenablog.com/entry/2025/10/15/154212より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14