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

森本 大輝さんの軌跡: テックリードからEMへ転換する8年目の挑戦

個人の技術力を組織のアウトプットに変える設計者へ

  • #EM
  • #マネジメント
  • #チームトポロジー
  • #テックリード

エンジニア8年でたどり着いたテックリード

新卒でWeb系自社開発企業に入り、私はGo/Pythonでバックエンド開発を5年、テックリードとして3年、合計8年のキャリアを積んできました。マイクロサービスのアーキテクチャ設計、性能改善、SLO策定、技術選定。社内では「設計の人」として一定の評価を受けてきたと自負しています。

テックリードとしての3年間で、自分のチーム内では強い手応えがありました。レビューでメンバーのコードを伸ばし、技術選定で議論をまとめ、トラブル時はオンコール対応の先頭に立つ。「個人とチームの技術アウトプットを最大化する」という意味では、自分のスタイルが固まってきていました。

「個」では届かない領域に気づいた日

転機は、CTOから「エンジニアリングマネージャー(EM)を目指してほしい」と言われた1on1でした。事業が拡大し、エンジニア組織が3チーム30名規模に成長するなかで、テックリードを束ねるレイヤーが必要になっていました。

正直、迷いました。マネジメントは未経験で、評価面談・1on1・採用・育成・組織設計のどれも体系的に学んだことがない。何よりも、私自身が「コードを書かなくなる自分」をイメージできなかったのです。

引き受けると決めた瞬間から、私は「個人として強いエンジニア」を超えて、「組織のアウトプットを最大化する設計者」になるための学習を始めました。36歳、再びの初心者です。

SREと組織論の交差点

最初に取り組んだのは、自分の専門領域(SRE/プラットフォーム)と、組織論を架橋する読み方でした。

『SREの探求』と『SREワークブック』は、技術的な話以上に「エンジニアリング組織が信頼性とどう向き合うか」という文化論として読み直しました。エラーバジェット、トイル削減、ポストモーテム文化。これらはマネジメント施策そのものだと、初めて気づきました。

『SLO サービスレベル目標』では、SLOがエンジニア組織における「優先順位の合意装置」であることを学び、自社のロードマップ議論にそのまま持ち込みました。技術指標を経営の言葉に翻訳する役回りは、EMとして避けて通れません。

『LeanとDevOpsの科学』は、組織パフォーマンスを4つのキーメトリクスで測るという発想を、私のチーム運営の根幹に据えるきっかけになりました。

チームトポロジーが変えた組織観

私のキャリアでもっとも大きな衝撃を受けた一冊は『チームトポロジー』です。Stream-aligned、Platform、Enabling、Complicated-subsystemという4つのチームタイプ、3つのインタラクションモード(コラボレーション/X-as-a-Service/ファシリテーション)。

これまで「組織図はそのうちCTOが決める」と思っていた私が、「組織はソフトウェアアーキテクチャと同型である(逆コンウェイの法則)」を腹落ちさせた瞬間、急に組織設計が技術設計と地続きの仕事に見えてきました。自社のサービス分割と、チーム分割を並べてホワイトボードに書き出した日のことを、いまでも覚えています。

エンジニア組織を支える基礎教養

『Googleのソフトウェアエンジニアリング』は、評価制度・キャリアラダー・コードレビュー文化・大規模リファクタリング戦略まで含む、巨大組織のエンジニアリング実践記です。我々のような数十名規模の組織にすべては適用できませんが、原則を抽出して輸入する作業は半年かけてやりました。

マイクロサービスの組織的な側面は『マイクロサービスのプロダクションレディネス』で再整理しました。サービスごとのオーナーシップ、運用責任、ドキュメント、SLOの整備チェックリストは、チームを増やすときの離陸チェックリストとして使っています。

EMとして最初の半年で取り組んだこと

EM就任後の最初の仕事は、3チームのSLO整備と、Stream-aligned/Platformのチーム再編成でした。コードを書く時間は明らかに減りましたが、「チームのSLOを引き上げる」「Platformチームに認知負荷を吸収させる」という間接的な貢献によって、組織全体のデプロイ頻度が1.6倍、変更失敗率が半減しました。

メンバーの評価制度も、技術力だけでなくチームへの貢献を見える化する形に再設計し、エンジニア育成の軸を明文化しました。これは個人のスキル本ではなく、組織設計本を読んでいなければ書けなかった文書です。

マネジメント未経験のテックリードへ

「コードを書かなくなる自分」を恐れる気持ちは、私もよくわかります。ただ、組織のアウトプットを設計する仕事は、ソフトウェアアーキテクチャの仕事の延長にあります。コードを書かないのではなく、書くオブジェクトが「人と組織」になるだけです。

EM/CTOを目指すなら、SREやプラットフォーム領域の本を組織論として読み直す視点を、ぜひ手に入れてみてください。技術の人だからこそ書ける組織がある、と私は今、強く信じています。

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

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

30 秒で診断する