技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの

技術好きなエンジニアが “リーダーへの進化” によって得たものと失ったもの @pospome

自己紹介 • 名前：pospome（ぽすぽめ） • 所属：株式会社カミナシ • 職種：VPoE • Xのアカウント：@pospome 2

本イベントのテーマと今日話すこと • pospomeの歩んできたキャリアにおける役割や視点の変化についてお話しようと思います。 • キャリアパスは狙っていたものではない。 ◦ ただ、パスを歩む際に考えていることはあった 3

pospomeのキャリアパス 1. バックエンドエンジニア a. ソーシャルゲーム開発 b. ソーシャルゲームプラットフォーム開発 2. テックリード a.
認証基盤開発 3. アーキテクト/マネージャー a. 組織的な技術戦略の策定と推進 4. VPoE a. カミナシの開発組織を良い感じにする 4

注意点 • キャリアパスの話は生存バイアスが強いので参考程度に・・・。 5

バックエンドエンジニア時代 • Webサービスの設計・開発・運用を担当する。 ◦ ハイトラフィック ◦ 大規模開発（マイクロサービス） • エンジニアとして強くなることのみを追い求めていた。 ◦
プライベートの時間もプログラミングをしたり、技術書を読んだり。 ◦ アプリケーションアーキテクチャを強みとすることに決めた。 • 「自分はエンジニアとして優秀になって、ずっと開発に携わっていく」と考えていた。 ◦ 当時は “エンジニア35歳定年説” みたいなものがあり、それに抗っていく気持ちがあった。 7

テックリード時代 • ある日テックリードに任命された。 ◦ 嬉しかった。 • 業務に小さな変化があった。 ◦ ミーティングの増加（チームの窓口） ◦
ドキュメント作成の増加 ◦ 多少のピープルマネジメント & プロジェクトマネージメント ◦ チームの意思決定における権限と責任 ▪ 自分が決めることによる不安 • 結果的に開発作業に割ける時間が減った。 ◦ ゆーてエンジニアの延長線上なので、それでも楽しかった。 9

テックリード時代の挫折 • 今思うとこれが “技術者からリーダーへ” の転換点だった気がする。 • 自分の上位互換のエンジニアに出会う。 ◦ エンジニアの能力は数値化できず、優劣が付けづらい中でそう感じたので結構な衝撃だった。
10

テックリード時代の生存戦略 • 例のエンジニアと正面から勝負すると負ける。どうすれば勝てるのだろうか? ◦ 当時のpospome は“勝ち負け” を気にする程度にはエンジニアとしてのプライドが高かった。 ◦
生存戦略やキャリアパスではなく、自身のプライドを守るため。 11

テックリード時代の生存戦略 • 技術以外のこともできるようになろう。正面から戦うことを避けて、総合力で戦う。 ◦ あくまでエンジニアとして総合力で戦う。 • 当時のpospomeが考えた “技術以外” とは?
◦ コミュニケーション ◦ ドキュメンテーション ◦ チームビルディング ◦ 採用 12

キャリアやポジションに対する不安 • 薄っすらとした不安 ◦ 1チームのテックリードでできることはたかが知れている。 ◦ テクノロジーのコモディティ化がすごい。 ▪ 下の世代がコスパよく階段を上がってくる。 13

キャリアの転換点 • 組織全体の技術戦略を考えて、実行するポジションに可能性を見出した。 ◦ 自身の技術力を活かしながらも、コミュニケーション、ドキュメンテーション、組織づくりのスキルを伸ばせる。 ◦ 大きな組織を変えることができるエンジニア 14

アーキテクト/マネージャー時代 • DMM.comのプラットフォーム開発本部に入社する。 ◦ 120名のエンジニアが所属する組織のアーキテクト • プラットフォーム開発本部の技術戦略に責任を持つ。 ◦ PRD, Design
Docの導入 ◦ 共通コンテナプラットフォームの導入（プラットフォームエンジニアリングへの取り組み） ◦ 認証認可基盤の構築 ◦ SLI/SLO導入 ◦ 開発生産性の向上 16

アーキテクト/マネージャー時代 • マイクロサービスアーキテクトグループの設立 ◦ プラットフォームチーム ◦ SREチーム ◦ 認証チーム ◦
認可チーム ◦ Developer Productivity チーム • pospomeが考える戦略を実現するための実行部隊 ◦ この組織のマネージャーになった。 17

アーキテクト/マネージャー時代 • DMM時代の業務 ◦ テクノロジーマネージメント/プロダクトマネージメント ▪ 技術基盤のDesign Doc作成 ▪ 成果物レビュー
◦ プロジェクトマネージメント ▪ ロードマップ作成 ▪ 進捗管理 ◦ ピープルマネジメント ▪ 育成 ▪ 採用 ▪ 1on1 ▪ 評価 18

得られたもの • 抽象度の高い技術戦略への理解度は上がった。 ◦ プラットフォームエンジニアリング ◦ マイクロサービス ◦ Design Doc
• 大きな組織を動かすために何が必要か。 ◦ ドキュメンテーション & 説明会 ◦ トップダウン ◦ 信頼貯金 ◦ 話が分かる承認者 19

得られたもの • 視座の高さ ◦ 自分が使えるか?使いやすいか? -> みんなが使えるか? ◦ 最終的に目指したい世界 ▪
どういうCDを目指すのか? ▪ どういう運用モデルを目指すのか? • 需要があることを知った ◦ 組織に求められる働きはこれだった。 ▪ 組織を作ったり、動かしたりできる人材は強い。 ◦ エンジニアとしてのpospomeは求められていない。 ▪ それだけの価値を生み出せない。 20

失ったもの • 技術領域に閉じた活動ではあるが、楽しさは減った。 ◦ 開発作業をしなくなった（やっぱり自分で作っている方が楽しい）。 ◦ 一方である程度の楽しさはある。 • 技術に対する解像度が低くなった。 ◦
Goの新しい機能に詳しくない。 ◦ k8sの内部の仕組みに詳しくない。 ◦ 手を動かして得る知見を得られない。 21

過大評価と不安 • テクノロジーマネージメントを中心に色々できるようになった。 ◦ 技術領域を強みにしつつも、他もできる “T型” のスキルセット。 ◦ 自分って市場価値高いのでは? •
不安に感じることもあった。 ◦ DMMだからできるだけでは? ◦ これって自分の実力なんだろーか? ◦ 他の人も同じことできるのでは? 22

カミナシVPoE時代 • 自身の実力を確かめ、より市場価値のある人材を目指すために、異なる環境で働くことに決めた。 ◦ 異なる役割（VPoE） ◦ 異なる業界（ノンデスクワーカー向けToBサービス） ◦ 異なるビジネスモデル（SaaS）
◦ 異なる組織規模（エンジニア30人規模） • エンジニアとしてのプライドやこだわりは影を潜めた。 ◦ 技術領域に強みがあることは変わりないけど、少し悲しい。 • 2024/10/1に入社して悪戦苦闘中です・・・。 24

カミナシのVPoEに求められるもの • 組織だけでなく、技術に関する意思決定もできなければいけない。 ◦ 良い組織は良い技術によってもたらされる（逆も然り）。 • カミナシの売上を上げること。 ◦ 開発組織の責任者として、どう利益を上げていくか。 ◦
視座が1つ高くなった。 • CTOとの棲み分け ◦ CTOはあくまで “技術を理解している経営者” VPoEは “開発組織の責任者” 25

最後に • 生存バイアスが強く、参考になるかは分からない。 • 強いエンジニアから逃げるためのキャリアパスだった気がする。 ◦ 言い換えると常に向上心や危機感を持っていた。 • マネージャーでもVPoEでも、技術領域に強みを持っている点はとても役に立っている。
• エンジニアとしての最低限のプライドは持ち続けたい。 ◦ 影を潜めたけど・・・。 26

まとめおわり 27

技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの

技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの

pospome

More Decks by pospome

Other Decks in Programming

Featured

Transcript