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
5
1.5k
技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの
イベント "技術者からリーダーへの進化【サポーターズ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
4.2k
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
10
5.8k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
41
19k
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
pospome
12
4.3k
組織全体で開発生産性に取り組むために 専門チームを作った話
pospome
2
2k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
810
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.8k
(再アップロード)Microservices & APIs
pospome
0
190
(再アップロード)Datastore/Go のデータ設計と struct の振る舞いについて
pospome
0
190
Other Decks in Programming
See All in Programming
Porting a visionOS App to Android XR
akkeylab
0
460
What Spring Developers Should Know About Jakarta EE
ivargrimstad
0
470
RailsGirls IZUMO スポンサーLT
16bitidol
0
180
AIと”コードの評価関数”を共有する / Share the "code evaluation function" with AI
euglena1215
1
160
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
3
760
イベントストーミング図からコードへの変換手順 / Procedure for Converting Event Storming Diagrams to Code
nrslib
2
810
Startups on Rails in Past, Present and Future–Irina Nazarova, RailsConf 2025
irinanazarova
0
100
なんとなくわかった気になるブロックテーマ入門/contents.nagoya 2025 6.28
chiilog
1
270
レベル1の開発生産性向上に取り組む − 日々の作業の効率化・自動化を通じた改善活動
kesoji
0
190
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
820
PHPで始める振る舞い駆動開発(Behaviour-Driven Development)
ohmori_yusuke
2
390
Railsアプリケーションと パフォーマンスチューニング ー 秒間5万リクエストの モバイルオーダーシステムを支える事例 ー Rubyセミナー 大阪
falcon8823
5
1.1k
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Producing Creativity
orderedlist
PRO
346
40k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Rails Girls Zürich Keynote
gr2m
95
14k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Scaling GitHub
holman
460
140k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
A Tale of Four Properties
chriscoyier
160
23k
How to Ace a Technical Interview
jacobian
278
23k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
950
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