Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの
Search
pospome
March 14, 2025
Programming
4
700
技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの
イベント "技術者からリーダーへの進化【サポーターズCoLab】" の登壇資料です。
https://supporterz-seminar.connpass.com/event/345341/
pospome
March 14, 2025
Tweet
Share
More Decks by pospome
See All by pospome
DMMプラットフォームにおけるTiDBの導入から運用まで
pospome
8
3.9k
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
10
5.7k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
42
18k
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
pospome
12
4.2k
組織全体で開発生産性に取り組むために 専門チームを作った話
pospome
2
1.9k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
750
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.7k
(再アップロード)Microservices & APIs
pospome
0
160
(再アップロード)Datastore/Go のデータ設計と struct の振る舞いについて
pospome
0
170
Other Decks in Programming
See All in Programming
オレを救った Cline を紹介する
codehex
16
15k
読もう! Android build ドキュメント
andpad
1
120
kintone開発を効率化するためにチームで試した施策とその結果を大放出!
oguemon
1
410
Drawing Heighway’s Dragon- Recursive Function Rewrite- From Imperative Style in Pascal 64 To Functional Style in Scala 3
philipschwarz
PRO
0
190
はじめてのIssueOps - GitHub Actionsで実現するコメント駆動オペレーション
tmknom
7
1.9k
バイセルでの AI を用いた開発の取り組み ~ Devin, Cursor の活用事例・知見共有 ~
umaidashi
0
140
Lambdaの監視、できてますか?Datadogを用いてLambdaを見守ろう
nealle
2
870
Ça bouge du côté des animations CSS !
goetter
2
170
機能が複雑化しても 頼りになる FactoryBotの話
tamikof
1
270
Generating OpenAPI schema from serializers throughout the Rails stack - Kyobashi.rb #5
envek
1
460
Generative AI for Beginners .NETの紹介
tomokusaba
1
140
Better Code Design in PHP
afilina
0
190
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
Speed Design
sergeychernyshev
28
830
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
52k
A designer walks into a library…
pauljervisheath
205
24k
The Cost Of JavaScript in 2023
addyosmani
47
7.5k
Building Your Own Lightsaber
phodgson
104
6.3k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Typedesign – Prime Four
hannesfritz
41
2.5k
Transcript
技術好きなエンジニアが “リーダーへの進化” によって 得たものと失ったもの @pospome
自己紹介 • 名前:pospome(ぽすぽめ) • 所属:株式会社カミナシ • 職種:VPoE • Xのアカウント:@pospome 2
本イベントのテーマと今日話すこと • pospomeの歩んできたキャリアにおける役割や視点の変化について お話しようと思います。 • キャリアパスは狙っていたものではない。 ◦ ただ、パスを歩む際に考えていることはあった 3
pospomeのキャリアパス 1. バックエンドエンジニア a. ソーシャルゲーム開発 b. ソーシャルゲームプラットフォーム開発 2. テックリード a.
認証基盤開発 3. アーキテクト/マネージャー a. 組織的な技術戦略の策定と推進 4. VPoE a. カミナシの開発組織を良い感じにする 4
注意点 • キャリアパスの話は生存バイアスが強いので参考程度に・・・。 5
pospomeのキャリアパス 1. バックエンドエンジニア a. ソーシャルゲーム開発 b. ソーシャルゲームプラットフォーム開発 2. テックリード a.
認証基盤開発 3. アーキテクト/マネージャー a. 組織的な技術戦略の策定と推進 4. VPoE a. カミナシの開発組織を良い感じにする 6
バックエンドエンジニア時代 • Webサービスの設計・開発・運用を担当する。 ◦ ハイトラフィック ◦ 大規模開発(マイクロサービス) • エンジニアとして強くなることのみを追い求めていた。 ◦
プライベートの時間もプログラミングをしたり、技術書を読んだり。 ◦ アプリケーションアーキテクチャを強みとすることに決めた。 • 「自分はエンジニアとして優秀になって、ずっと開発に携わっていく」 と考えていた。 ◦ 当時は “エンジニア35歳定年説” みたいなものがあり、 それに抗っていく気持ちがあった。 7
pospomeのキャリアパス 1. バックエンドエンジニア a. ソーシャルゲーム開発 b. ソーシャルゲームプラットフォーム開発 2. テックリード a.
認証基盤開発 3. アーキテクト/マネージャー a. 組織的な技術戦略の策定と推進 4. VPoE a. カミナシの開発組織を良い感じにする 8
テックリード時代 • ある日テックリードに任命された。 ◦ 嬉しかった。 • 業務に小さな変化があった。 ◦ ミーティングの増加(チームの窓口) ◦
ドキュメント作成の増加 ◦ 多少のピープルマネジメント & プロジェクトマネージメント ◦ チームの意思決定における権限と責任 ▪ 自分が決めることによる不安 • 結果的に開発作業に割ける時間が減った。 ◦ ゆーてエンジニアの延長線上なので、それでも楽しかった。 9
テックリード時代の挫折 • 今思うとこれが “技術者からリーダーへ” の転換点だった気がする。 • 自分の上位互換のエンジニアに出会う。 ◦ エンジニアの能力は数値化できず、優劣が付けづらい中で そう感じたので結構な衝撃だった。
10
テックリード時代の生存戦略 • 例のエンジニアと正面から勝負すると負ける。 どうすれば勝てるのだろうか? ◦ 当時のpospome は“勝ち負け” を気にする程度には エンジニアとしてのプライドが高かった。 ◦
生存戦略やキャリアパスではなく、自身のプライドを守るため。 11
テックリード時代の生存戦略 • 技術以外のこともできるようになろう。 正面から戦うことを避けて、総合力で戦う。 ◦ あくまでエンジニアとして総合力で戦う。 • 当時のpospomeが考えた “技術以外” とは?
◦ コミュニケーション ◦ ドキュメンテーション ◦ チームビルディング ◦ 採用 12
キャリアやポジションに対する不安 • 薄っすらとした不安 ◦ 1チームのテックリードでできることはたかが知れている。 ◦ テクノロジーのコモディティ化がすごい。 ▪ 下の世代がコスパよく階段を上がってくる。 13
キャリアの転換点 • 組織全体の技術戦略を考えて、実行するポジションに可能性を見出した。 ◦ 自身の技術力を活かしながらも、コミュニケーション、ドキュメンテー ション、組織づくりのスキルを伸ばせる。 ◦ 大きな組織を変えることができるエンジニア 14
pospomeのキャリアパス 1. バックエンドエンジニア a. ソーシャルゲーム開発 b. ソーシャルゲームプラットフォーム開発 2. テックリード a.
認証基盤開発 3. アーキテクト/マネージャー a. 組織的な技術戦略の策定と推進 4. VPoE a. カミナシの開発組織を良い感じにする 15
アーキテクト/マネージャー時代 • 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
pospomeのキャリアパス 1. バックエンドエンジニア a. ソーシャルゲーム開発 b. ソーシャルゲームプラットフォーム開発 2. テックリード a.
認証基盤開発 3. アーキテクト/マネージャー a. 組織的な技術戦略の策定と推進 4. VPoE a. カミナシの開発組織を良い感じにする 23
カミナシVPoE時代 • 自身の実力を確かめ、より市場価値のある人材を目指すために、 異なる環境で働くことに決めた。 ◦ 異なる役割(VPoE) ◦ 異なる業界(ノンデスクワーカー向けToBサービス) ◦ 異なるビジネスモデル(SaaS)
◦ 異なる組織規模(エンジニア30人規模) • エンジニアとしてのプライドやこだわりは影を潜めた。 ◦ 技術領域に強みがあることは変わりないけど、少し悲しい。 • 2024/10/1に入社して悪戦苦闘中です・・・。 24
カミナシのVPoEに求められるもの • 組織だけでなく、技術に関する意思決定もできなければいけない。 ◦ 良い組織は良い技術によってもたらされる(逆も然り)。 • カミナシの売上を上げること。 ◦ 開発組織の責任者として、どう利益を上げていくか。 ◦
視座が1つ高くなった。 • CTOとの棲み分け ◦ CTOはあくまで “技術を理解している経営者” VPoEは “開発組織の責任者” 25
最後に • 生存バイアスが強く、参考になるかは分からない。 • 強いエンジニアから逃げるためのキャリアパスだった気がする。 ◦ 言い換えると常に向上心や危機感を持っていた。 • マネージャーでもVPoEでも、 技術領域に強みを持っている点はとても役に立っている。
• エンジニアとしての最低限のプライドは持ち続けたい。 ◦ 影を潜めたけど・・・。 26
まとめ おわり 27