キャリアモデル 読了 約 9 分

小林 竜介さんの軌跡: 15年のシニアエンジニアからアーキテクトへの転身

個人技の限界を超え、組織全体を設計するキャリアへの大きな転換点

  • #アーキテクト
  • #エンジニアリングマネージャー
  • #組織設計
  • #技術戦略
  • #キャリアチェンジ

経歴のスタート地点

小林竜介さんが新卒で入った大手SIerでは、Javaを使った金融系基幹システムの設計が最初の8年だった。要件定義書を読み、クラス設計を引き、性能試験まで通す——伝統的なアプリケーションエンジニアの王道を歩んだ。

8年目で転職したWeb系企業では、Pythonでの大規模Webサービスの開発に軸足を移した。最初の数年はバックエンドのいちエンジニアだったが、5年目以降は数百万ユーザー規模のサービスのリアーキテクチャを2回主導した。モノリスからモジュラーモノリスへの段階的分割、コアドメインのマイクロサービス化、共通基盤としての認証・通知・課金の切り出し。技術的な意思決定を一人で引き取れる、社内有数のシニアエンジニアになっていた。

最初のつまずき

40歳を前にして、彼は静かな違和感を抱えていた。技術判断の精度では誰にも負けない自負があった。一方で、自分のレビューが追いつかなければ品質が下がり、自分が設計した基盤を引き継げる人材が育っていない。「個人としての技術力」が組織のボトルネックになり始めていた。

もう一つの壁は、組織の話だった。CTOから「次のステップとしてEM/アーキテクトのどちらかを担ってほしい」と打診されたとき、彼は一瞬詰まった。技術選定や設計レビューは何百回もしてきたが、エンジニアのキャリアパスを設計したり、評価制度の文言を書いたり、チームトポロジーをゼロから引き直す経験は一度もなかった。

「自分は技術を判断する側であって、組織を設計する側ではない」という暗黙の前提が、ずっと彼の中にあった。けれど、その前提のままだと、15年積み上げた知見はその場で消えてしまう。誰かに引き継げる形にするには、組織の言語を学ぶ必要があった。

転機となった組織再編

転機は、会社全体の組織再編が始まった時期に訪れた。CTOの号令のもと、プロダクト軸の縦割りから「Stream-aligned / Platform / Enabling / Complicated-subsystem」というチームトポロジーへの移行が始まり、彼はPlatformチームの立ち上げリードに任命された。

最初の3ヶ月、彼は意図的に「設計」より「対話」に時間を割いた。社内のシニア・ジュニア合わせて30人以上と1on1を行い、技術的な不満と組織的な不満を分けて聞き取った。集まった声を構造化し、Platformチームのミッション・スコープ・サービス境界を一枚の図にまとめ、CTOと役員に提案した。

半年後、Platformチームは6名で発足し、社内向けの開発者ポータル、共通CI/CDテンプレート、認証基盤の3本柱を持つ形になった。1年が経つ頃には、Platformの利用度がプロダクトチームのリードタイム短縮に明確に効いていた。技術判断の感覚と、組織設計の言語が、彼の中で初めて一本につながった瞬間だった。

いま振り返る選書

組織設計の言語を手に入れた最大の一冊は『チームトポロジー』だ。4種のチームタイプとインタラクションパターンが、Platform立ち上げの設計図そのものになった。社内提案資料の8割は、この本の語彙で書かれている。

アーキテクチャの判断軸を整え直すために『ソフトウェアアーキテクチャの基礎』を再読した。ADR(Architecture Decision Records)を社内に導入したのもこの本がきっかけで、彼一人の頭の中にあった判断基準を、チームで共有可能な形に外出しできた。設計原則の言語化には『Clean Architecture』が長く効いていて、若手のレビューで使う共通語彙になっている。

マイクロサービスの運用観点では『Production-Ready Microservices』が現場の指針になった。SLOやオンコール体制を含めた「サービスを本番運用に乗せるとは何か」を網羅しており、Platformチームのチェックリストに反映した。さらに、システム全体を分散システムとして俯瞰する視座は『データ指向アプリケーションデザイン』が支えてくれた。

これから挑む人へ

小林さんはいま、Platformチームのリードとアーキテクトを兼務している。15年積み上げた技術判断の感覚は、いま「自分の手で書く」のではなく、「他のエンジニアの判断を引き上げる」ために使われている。

シニアエンジニアからアーキテクト/EMへの越境は、技術を捨てる旅ではない。むしろ、自分の技術知識を「他者が再利用できる形」に変換する旅だ。設計判断を頭の中に閉じ込めず、ADRに書く。良いコードを自分で書くより、レビューで一段上のコードを引き出す。チームの境界をデザインし、依存の重さを可視化する——どれも、技術の延長線上にある仕事だと彼は言う。

40代以降のエンジニアキャリアは、個人技を磨き続けるか、組織の生産性に賭けるかの分岐に立つ。後者を選ぶなら、技術書と組織論の本を半々で読み続けることが、最初の準備になるはずだ。

あなたに合う書籍を見つける

30 秒のキャリア診断で、次に読むべき本と職種ロードマップを提案します。

30 秒で診断する