コンテンツへスキップ

基盤の面白さに、10年かけて気づいた ―― SWEからSREへ転向します

基盤の面白さに、10年かけて気づいた ―― SWEからSREへ転向します のアイキャッチ
Contents

    はじめに

    6月から、ロールが SWE1 から SRE2 / Platform Engineer3 に変わります。

    この記事では、社内の事情や組織の話はしません。書きたいのは、約10年アプリ側でやってきた僕が、なぜ今このタイミングで基盤側に戻るのか。そして、自分のキャリアをどう捉えているか、です。先に白状しておくと、これは半分ポエムです。

    想定読者

    • アプリケーションを長くやってきて、信頼性や基盤の側に興味が出てきた人
    • 一度離れた領域に、もう一度戻ろうか迷っている人
    • マネジメントを経験して、また手を動かす側に回りたくなった人

    技術の how-to ではなく、キャリアの捉え方の話です。SRE や Platform Engineer という言葉を知らなくても読めるように書きました。

    最初は「基盤の人」だった

    意外に思われるかもしれませんが、僕のファーストキャリアは SIer のネットワークエンジニアです。

    やっていたのは、ネットワークの保守と運用、パブリッククラウドへの移行、それに初期のネットワーク設計(概要設計から詳細設計まで)。オンプレのサーバーラックと向き合い、ときにはデータセンターにも足を運びながら、その構成をクラウドへ移していく、そんな時期でした。期間としては非常に短かったので、胸を張って「やっていました」と言えるほどでもありません。

    そして当時の僕は、正直に言うと、基盤を提供するという仕事に面白みを感じられませんでした。

    今振り返ると、面白くなかったのではなく 面白さに気づけなかった が正しい。理由は二つあった気がします。

    一つは、インフラが「あって当たり前」の世界だということ。うまく動いていても誰も褒めてくれず、落ちたときだけ責められる。その非対称な厳しさの裏に何の価値があるのか、当時の僕には見えていませんでした。もう一つは、開発者自身がユーザーなのだと気づけていなかったこと。基盤を使い、その上でサービスをつくるのは開発者やエンジニアです。でも当時の僕は、目の前のパケットやサブネットマスクばかり見ていて、その先にいる「使う人」のことまで考えが及びませんでした。

    基盤は「縁の下」だと教わるけれど、縁の下の何が面白いのかは、縁の上に立ってみないとわからないものでした。

    そんなわけで、僕は基盤からアプリ側へ移ります。

    アプリ側を歩いた10年

    ソフトウェアエンジニアとしての10年超は、一つの場所に留まっていたわけではありません。基本はフルサイクル、フロントエンドからバックエンドまで横断して書くスタイルです。振り返ると、ずいぶんいろいろな場所を歩きました。

    2015年に、今いる freee へ移ります。最初に担当したのはデータ集約機能、銀行やクレジットカードの明細を取得する金融機関との API 連携でした。アメリカン・エキスプレスや三菱UFJ銀行、JCB といった大手との連携を、プロジェクトマネージャー兼プレイヤーとして回す。外部と仕様の認識をすり合わせながら、設計と実装を同時に進める。段取りと技術が地続きの仕事です。

    そこからは、金融子会社の freee finance lab へ。資金調達まわりのサービス、なかでも資金調達freee の立ち上げをリードしました。新規プロダクトをいくつも立ち上げる時期で、リリースのたびに SRE と並走し、Terraform でインフラをコード化(IaC)することもあった。並行して手がけたオファー型融資は、クローズも経験しています。

    ここから数年が、英語で仕事をしていた期間です。まずは、紙の証憑を仕訳データに変えるデータ化サービスのテックリード。チームはフィリピンの子会社を含む多国籍のメンバーで、設計の議論もコードレビューもドキュメントも英語。得意とは言えないけれど、やるしかない環境に身を置きました。

    続く税理士向けの顧問先管理から、ロールは EM4 になります。とはいえ基本はプレイングマネージャー。手は動かし続けましたが、コードを書く比重は下がり、その分マネジメントへ寄っていきました。顧問先管理は、新しく立ち上げると同時に、旧サービスを畳むフルリビルド。このときは開発者で日本人は僕だけでした(日本語を話せる海外メンバーもいましたが、基本は英語です)。そのまま従業員ポータルの立ち上げへと続きます。こちらはリード兼 EM。Web のチームを率いる日々でした(モバイルアプリのほうは、スポットでモバイルチームと協働した程度です)。振り返ると、EM としてはトータルで2年ほど働いたことになります。

    EM は、自分から手を挙げました。正直に言うと、EM は IC5 より進んでやりたがる人が少ない役回り、というイメージが当時はありました。今はそこまで煙たがられてもいない気もしますが。でも、一度もやらないまま「やりたくない」と言うのは違うよなと。食わず嫌いだけは避けたかったので、手を挙げることにしたのでした。

    やってみてわかったのは、EM が嫌だったわけではない、ということです。ただ、ピープルマネジメントよりも技術のマネジメントのほうが好きで、こちらのほうが長く続けられそうだった。人より技術に責任を持つ側が、自分には合っている。そもそも EM は役職ではなく役割です。上り下りの話ではなく、自分から確かめにいって確かめてきた、それだけのことでした。

    この「マネジメントから、また手を動かす側へ」という流れ、自分だけのものかと思っていたら、世界的にも語られているらしいと知りました。

    EMからICへ、キャリアは螺旋階段のように上がっていけるzenn.dev

    15年のキャリアで EM から IC に転身した、骨太な記事です。その中に、こんな一節があります。

    マネジメント側に立ち続けることだけが「前進」ではないという空気が、海外の一部で可視化されつつある

    EM → IC には構造的な壁があり、過去の経験の 掛け合わせ で勝負する、という指摘にも深くうなずきました。規模も背景も違うけれど、構造は同じだなと。

    IC に戻った直後、大きな揺さぶりが来ました。LLM が、コードを書く仕事を本格的に効率化しはじめたのです。アプリケーションのコードはこれからコモディティ化していく——そう感じたとき、自分のキャリアが正直こわくなり、改めて考え直しました。

    迷いはありました。一つの道は、流れの速い AI の側——エージェントの組み込みや、AI プロダクトそのものを作る側へ進むこと。正直、そちらにずいぶん心が傾いた時期もあります。

    もう一つの道が、最初に触れた基盤の世界でした。ソフトウェア開発がいくら効率化されても、その土台にあるハードウェアの世界や原則は、そう簡単には変わりません。変化の速いレイヤーの一段下には、ゆっくりとしか動かない地面がある。その地面に、もう一度ちゃんと向き合っておきたい——そう思うようになりました。それに、ここには下心もあります。ネットワークのように変わらないものを運用できる経験は、長い目で見ればキャリアにも効くはずだ、と。

    そして直近は、人事労務の統合基盤でアーキテクトをやっていました。gRPC API の再設計、サービスの責務分界、マスタデータの設計。「どこからどこまでを誰が持つか」という線を引く仕事です。気づけば、Datadog のダッシュボードを整えるなど、監視まわりにも関わっていました。

    この線引きをしていると、どうしても アプリの外 にぶつかります。レイテンシ、障害の伝播、スケールの限界。きれいに責務を切ったつもりでも、その下の足場が揺れれば全部揺れる。線を引けば引くほど、その線の下が気になっていきました。

    一周して、また基盤へ

    統合基盤で片足を戻していた僕は、6月から両足で基盤側に立ちます。SRE / Platform Engineer として、Kubernetes やサービスメッシュ、オートスケーリングといった、サービスの足場そのものを扱う領域へ。

    ここで冒頭の話が効いてきます。ファーストキャリアと、同じ「基盤を提供する」フロアに戻ってくる のです。

    ただし、同じ場所ではありません。10年前は面白さに気づけなかった縁の下に、今は別の高さから降りていく。アプリを10年作ったからこそ、基盤が揺れたときに上で何が起きるかが見える。責務分界を引いてきたからこそ、信頼性という線の引き方に興味が持てる。昔は退屈に見えた構成図が、今は「これが倒れたら誰が困るか」の地図に見える。

    立つ高さが変われば、同じ景色でも見え方が変わる。これはまさに螺旋階段です。

    「再設計」と言いかけて、やめた

    この転向を、最初は「キャリアの再設計」と呼ぼうとしていました。10年の遠回りを、戦略的な伏線回収みたいに語れたら格好いい。

    でも、やめました。きっかけはこの記事です。

    おい、夢を持たなくても良いぞ - じゃあ、おうちで学べる syu-m-5151.hatenablog.com

    nwiizo さんのこの記事に、「キャリアは設計できない」 という見出しがあります。読んだとき、ぐうの音も出ませんでした。

    ネットワークエンジニアだった頃の僕は、10年後に「やっぱり基盤が面白い」と言って戻ってくる未来なんて、1ミリも設計していません。EM をやったのも、ICに戻ったのも、その都度の好奇心と「これだけは嫌だ」の組み合わせで決めただけです。後から振り返ればひとつながりに見えるだけで、前を向いて引いた線ではない。

    「伏線回収」なんて綺麗な言葉は、後出しジャンケンでした。

    だから「再設計」はやめます。設計はできない。できるのは、歩いてきた道のりを 語り直す ことだけ。基盤 → アプリ → 基盤という回り道は、設計の成果ではなく、結果としてそうなった軌跡です。それでいいと思っています。

    持ち込めるもの、学び直すもの

    とはいえ、丸腰で戻るわけではありません。掛け合わせで勝負する、という話の続きです。

    状態
    gRPC API 再設計・責務分界の経験そのまま持ち込める。アプリと基盤の境界を引いてきた目線は強み
    障害時にアプリ側で何が起きるかの肌感持ち込める。上を知っている下の人は、たぶん貴重
    Kubernetes・サービスメッシュの深いところ学び直す。運用で触ってはきたが、設計者としてはこれから
    GitOps まわり運用してきたが、設計はこれから。盛らずに言えば「使ってきた」止まり

    何も無駄になっていない。一周したからこそ、最初のフロアで拾えなかったものを拾いにいけます。

    これから/同じ場所に立っている人へ

    10年後にどうなっていたいか、という問いには、正直まだうまく答えられません。設計できないと書いたばかりなので、なおさらです。

    代わりに決めているのは、nwiizo さんの記事から借りるなら 「何が嫌いか」 のほうです。基盤の面白さに気づけないまま、わかったふりで通り過ぎるのだけは、もうしたくない。それくらいの解像度で、当面はやっていこうと思っています。

    もし今、昔つまらなく見えた領域に戻ろうか迷っている人がいたら、伝えたいのはひとつ。領域がつまらなかったんじゃなくて、その時の自分の高さでは面白さが見えなかっただけかもしれない、ということです。同じ階段でも、一段のぼってから見下ろすと、景色はけっこう変わります。

    最後に

    というわけで、6月から SRE になります。一周回って、また基盤の人です。

    縁の下が面白いと、10年かけてやっと言えるようになりました。遅咲きですが、どうせ 焦って設計しても当たらないので、ちょうどいいのかもしれません。

    それでは、またね。

    footnote

    1. Software Engineer(ソフトウェアエンジニア)。アプリケーションのコードを書く技術職。

    2. Site Reliability Engineering。Google が提唱した、ソフトウェアエンジニアリングの手法で運用・信頼性の問題に取り組む考え方・職種。詳しくは Google SRE の公式資料

    3. Platform Engineering(プラットフォームエンジニアリング)。開発者が自律的に開発・デプロイできる社内基盤(Internal Developer Platform)を整え、開発体験と生産性を高める取り組み。Gartner は「2026年までに大規模ソフトウェア組織の80%がプラットフォームエンジニアリングチームを持つ」と予測している(2022年は45%。Gartner)。日本語の概説は Platform Engineering とは何か

    4. Engineering Manager(エンジニアリングマネージャー)。チームをまとめ、その成果に責任を持つ役割。

    5. Individual Contributor(個人コントリビューター)。マネージャーにならず、現場で手を動かす技術職。

    X Facebook B! Hatena