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
Recruit
PRO
March 06, 2025
Technology
1
92
結果的にこうなった。から見える メカニズムのようなもの。
2025/2/19に開催したRecruit Tech Conference 2025の黒田の資料です
Recruit
PRO
March 06, 2025
Tweet
Share
More Decks by Recruit
See All by Recruit
Curiosity & Persistence
recruitengineers
PRO
2
32
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
35
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
2
35
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
0
38
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
recruitengineers
PRO
1
24
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
0
24
大規模プロダクトにおける フロントエンドモダナイズの取り組み紹介
recruitengineers
PRO
4
64
技術的ミスと深堀り
recruitengineers
PRO
3
50
『ホットペッパーグルメ』における マルチプラットフォーム化の歩み
recruitengineers
PRO
2
31
Other Decks in Technology
See All in Technology
20250304_赤煉瓦倉庫_DeepSeek_Deep_Dive
hiouchiy
2
130
完璧を捨てろ! “攻め”のQAがもたらすスピードと革新/20250306 Hiroki Hachisuka
shift_evolve
0
100
Log Analytics を使った実際の運用 - Sansan Data Hub での取り組み
sansantech
PRO
0
110
データベースの負荷を紐解く/untangle-the-database-load
emiki
2
550
プルリクエストレビューを終わらせるためのチーム体制 / The Team for Completing Pull Request Reviews
nekonenene
3
1.1k
AIエージェント開発のノウハウと課題
pharma_x_tech
9
4.8k
EMConf JP 2025 懇親会LT / EMConf JP 2025 social gathering
sugamasao
2
210
開発者体験を定量的に把握する手法と活用事例
ham0215
0
130
AWSではじめる Web APIテスト実践ガイド / A practical guide to testing Web APIs on AWS
yokawasa
8
780
プロダクト開発者目線での Entra ID 活用
sansantech
PRO
0
130
Amazon Athenaから利用時のGlueのIcebergテーブルのメンテナンスについて
nayuts
0
110
LINEギフトにおけるバックエンド開発
lycorptech_jp
PRO
0
430
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
137
6.8k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.5k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Designing for Performance
lara
605
68k
Designing Experiences People Love
moore
140
23k
Why Our Code Smells
bkeepers
PRO
336
57k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.2k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.2k
Optimizing for Happiness
mojombo
377
70k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Transcript
結果的にこうなった。から見える メカニズムのようなもの。 RECRUIT TECH CONFERENCE 2025 技術を活かし、技術と生きる~エンジニアはキャリアをどう描くか? 黒田 樹 株式会社リクルート プロダクトディベロップメント室 Vice
President
黒田 樹 ゲーム、バイク、車、システム開発 経歴 / Career SIerにて官公庁系の大規模開発のシステムアーキテクト として幾つかの開発を経てリクルートホールディングス に入社。様々なチームに対してスクラムやリーンスター トアップの導入支援、マイナー出資先の海外スタート アップのグロース支援を経て、リクルートテクノロジー
ズにて既存メディアや新規事業領域の開発マネジメント などに執行役員として従事。現在はリクルートにて開発 マネジメントやアプリケーション基盤開発やオフショア 開発を担当している。 趣味 / Hobbies プロダクトディベロップメント室 アプリケーションソリューションユニット Vice President
一般論 キャリアアンカー理論(山登り型) 自身のキャリアにおいて最も大切で譲れない価 値観や欲求を「アンカー(錨)」として認識 し、それを基に明確な目標を設定。山登りのよ うに、目指す頂上(キャリアゴール)を定め、 そこに向かって計画的に登っていく。キャリア アンカーは内面で不動であり、時間が経過して もほとんど変化しない。 計画的偶発性理論(川下り型)
キャリアの8割が予期せぬ偶然の出来事に よって決定されるとされている。川の流れの ように予測不可能な環境の中で、柔軟に対応 しながら進んでいくイメージ。明確なゴール を定めず、現在に焦点を置いてキャリアを考 える。 エンジニアと して頂点を 目指す
自分のポジショニング ここらへん キャリアアンカー(不変な大事にしていること)はありつつ、 将来については流れに身を任せているハイブリッド型 どーにかなるっしょー
川下り型的なノリが今の時代にあっている気がする 黒田のキャリア開始時点(2004年)に想像してたキャリア プログラマー システムエンジニア プロジェクトマネジャー Java SOA アーキテクト OSS 大規模プロジェクト
川下り型的なノリが今の時代にあっている気がする 黒田のキャリア開始時点(2004年)に想像してたキャリア プログラマー システムエンジニア プロジェクトマネジャー Java SOA アーキテクト HTML5 iOS/Android
新規事業オーナー アジャイル DevOps 機械学習 jQuery OSS LLM React クラウド 2025年に振り返った実際のキャリア 新規事業(PO)の道 マネジャーの道 事業会社へ道 エンジニアの道 この幅が不確実性 想定と全然違った。 ←決めきってしまうリスク 大規模プロジェクト
キャリア語りによって発生するミスリードについて 時系列的にキャリアの話をすると、どうしても山登り型風のストーリーになってしまう。そこで ミスリードが生まれる。帰納法的な話(結果的にAであった。振り返るとaやbをやっていた)を 演繹的に説明(aやbをするとAになる)してしまうような問題になる。しかし、それはイコール ではない。別にそれをトレースしてaとbをやったからといってAにはならない。 a b c A a
b c A aやってbやってcやるとAにな る。Aになるにはaとbとcをやる 必要がある。 結果的にAだった。振り返ってみると aとbとcをやってた。aとbとcをやっ ていることに意味がありそうだ。
キャリア語りによって発生するミスリードについて 時系列的にキャリアの話をすると、どうしても山登り型風のストーリーになってしまう。そこで ミスリードが生まれる。帰納法的な話(結果的にAであった。振り返るとaやbをやっていた)を 演繹的に説明(aやbをするとAになる)してしまうような問題になる。しかし、それはイコール ではない。別にそれをトレースしてaとbをやったからといってAにはならない。 a b c A a
b c A aやってbやってcやるとAにな る。Aになるにはaとbとcをやる 必要がある。 結果的にAだった。振り返ってみると aとbとcをやってた。aとbとcをやっ ていることに意味がありそうだ。
キャリアについて帰納法的に自分語りをしてみる ここでは、演繹的に説明されがちなキャリア語りを、そのバイアスに逆らって帰納法的に意味付 けしてみる。キャリアを構造的に捉えるために、アルゴリズムとして、リクルートOBの藤原さ んの理論を引用してみる。 100万人に1人の存在になる方法 藤原 和博 https://www.amazon.co.jp/dp/B0822FGPHK
100万人の1人の存在になる方法 - 藤原 和博氏 100万人に1人の存在になる方法 藤原 和博 https://www.amazon.co.jp/dp/B0822FGPHK 100万人中、1人というのは オリンピック選手と同等の希少性
100万人の1人の存在になる方法 - 藤原 和博氏 100万人に1人の存在になる方法 藤原 和博 https://www.amazon.co.jp/dp/B0822FGPHK
100万人の1人の存在になる方法 - 藤原 和博氏 100万人に1人の存在になる方法 藤原 和博 https://www.amazon.co.jp/dp/B0822FGPHK 100人中、1人になる希少性は 1万時間で到達できる見立て 例えば
1日6時間 * 240営業日/年で 7年
100万人の1人の存在になる方法 - 藤原 和博氏 100万人に1人の存在になる方法 藤原 和博 https://www.amazon.co.jp/dp/B0822FGPHK 1万時間の投資を3回やると100万人中の1人の希少性を論理的に作ることが可能 100万人と競争して1位になるのは無理ゲーでも、 100人中1位を3つなら現実感がまだ・・ある・・・かもしれない!!!
1万時間というマジックナンバーについて プログラマが知るべき97のこと 和田 卓人 (監修), Kevlin Henney (編集), 夏目 大
(翻訳) https://www.amazon.co.jp/dp/4873114799 1万時間の訓練 - Jon Jagger 「エキスパート」と呼ばれるだけの能力を身につけるには、一体、どのくらいの 量の訓練が必要なのでしょうか。それについては次のようなことが言われていま す。 • Peter Norvigは、何かでエキスパートになるには約1万時間の訓練が必要と 述べている。いわばこの1万時間というのが「マジックナンバー」というこ とになる。 • Mary Poppendieckも、著書「リーンソフトウェア開発と組織改革」の中で 「どんな専門的職業であれ、入念に計画された、集中的な訓練を最低 10,000時間積み重ねることとで専門家になると言う」と書いている。 専門的な技術や知識は、ゆっくりと徐々に身につくものです。1万時間が経過した 途端、急に身につく、というわけではありません。それでも、ともかく1万時間や る、ということが大切なのです。
キャリアについて帰納法的に自分語りをしてみる 1万時間という単位に意味がありそう。 1万時間で振り返ってみる。
1万時間による自分自身のキャリアの構造化 エンジニア 1万時間 新規事業 1万時間 マネジメント 1万時間
1万時間による自分自身のキャリアの構造化 エンジニア 1万時間 新規事業 1万時間 マネジメント 1万時間 ・大規模開発のエンジニア(BE/FE) ・大規模開発のプロジェクトリーダー ・大規模開発のアーキテクト キーワード 官公庁系、基幹システム、SOA、PMBoK、Java、Oracle、HiRDB、 Websphere、オフショア、PL/SQL、レガシー
1万時間による自分自身のキャリアの構造化 エンジニア 1万時間 新規事業 1万時間 マネジメント 1万時間 ・新規事業オーナー ・新規事業エンジニア ・エンジニアとして投資先デューデリジェンス/バリューアップ支援 キーワード iOS/Android、AWS、リーンスタートアップ、アジャイル、顧客開発、 グロースハック、カンバン、スクラム、仮説検証型
1万時間による自分自身のキャリアの構造化 エンジニア 1万時間 新規事業 1万時間 マネジメント 1万時間 ・グループマネジャー ・部長 ・リクルートテクノロジーズ(+いくつか)執行役員 ・リクルートVicePresident(現在) キーワード 採用、育成、評価、組織運営、事業価値とエンジニアリング、etc
1万時間のタイミング(偶然、流行る前にやっていた) エンジニア 1万時間 新規事業 1万時間 マネジメント 1万時間 エンジニア職ブーム 事業がわかるエンジニアみたい な文脈が話題にあがりだす エンジニアリングマネ ジャーやVPoEのような ロールが話題にあがりだす
世の中の流れ 自分の時間投資タイミング
1万時間タームの開始状態と結果 エンジニア 1万時間 新規事業 1万時間 マネジメント 1万時間 エンジニア職ブーム 事業がわかるエンジニア みたいな文脈が話題にあ がりだす 世の中 自分
・もともと大学で情報工学(C,Java,Perlある程度書ける) ・当時の新入社員同期でJava書ける人なし ・当時の配属先にJavaのエキスパートが不在 結果的に・・・ 難易度の高い技術的な仕事が沢山舞い込んできた。受動的に。 その後の1万時間の密度が濃くなった(気がする) 1/100になったかはわからないが・・・。
1万時間タームの開始状態と結果 エンジニア 1万時間 新規事業 1万時間 マネジメント 1万時間 エンジニア職ブーム 事業がわかるエンジニア みたいな文脈が話題にあ がりだす 世の中 自分
・リクルートに転職。社内に社員エンジニアがほぼいない時代 ・ビジネス的なことを考える社員エンジニアなんて更にいない 結果的に・・・・ 投資先の海外スタートアップの事業グロース支援によばれる等、 ビジネスxエンジニアみたいな面白そうな仕事が数多く舞い込んできた。受動的に。 そこでで得たアジャイルやリーンスタートアップ等の知見を登壇していったら、 デブサミベストスピーカー賞とれた(1/100にはなれた?)。コミュニティの知り合いも増えた。 色んなエンジニアイベントにスピーカーとしてよばれるようになった。 結果、1万時間の密度が高まった(気がする)。
1万時間タームの開始状態と結果 エンジニア 1万時間 新規事業 1万時間 マネジメント 1万時間 エンジニア職ブーム 事業がわかるエンジニア みたいな文脈が話題にあ がりだす 世の中 自分
・マネジャーやってみる?じゃー、やってみます。 ・社内においてそもそもエンジニア出身マネジャーが希少種 ・マネジメントをやりたくないというエンジニアが周囲に多い時代背景 ・自分は、事業 x エンジニア をやってきている ・エンジニア出身じゃないマネジャーよりも解像度が相対的に高い 結果的に・・・ 様々なマネジメント経験(進行中) 1/100になれるとよいなあ(希望)
帰納法的に見えてくるメカニズムのようなもの 周りよりも1ミリくらい ちょっとだけ知ってる。 ちょっとだけ出来る。 有識者。 有識者(実態は周囲か ら2ミリくらい上なだ け)扱いされだす。 この中ではいちばん出 来そうだからやらせてみ
るか〜 Help me! 有識者に相 談しよう 待ってるだけで勝手にケー ススタディが増える
帰納法的に見えてくるメカニズムのようなもの 自身の属する集合において、ちょっとだけ知ってる、ちょっとだけ出来る状態でスタートを切ると、 結果的に、そこに仕事や情報が集まる。自分で仕事を取りに行かないでも、仕事からやってくる。 こんなメカニズムがある気がして・・・・。スタンスは受け身なのに、なぜか成長出来る。 逆手にとると、スタートダッシュ(最初を最も能動的にすごす)して、最初に1ミリリードするのが 実はコスパがよいとも言える。このメカニズムのスイッチを意図的に押せるとも言える。 周りよりも1ミリくらい ちょっとだけ知ってる。 ちょっとだけ出来る。 有識者。
有識者(実態は周囲か ら2ミリくらい上なだ け)扱いされだす。 この中ではいちばん出 来そうだからやらせてみ るか〜 Help me! 有識者に相 談しよう 待ってるだけで勝手にケー ススタディが増える
まとめると ※当時はこんなこと考えていない hoge 1万時間 foo 1万時間 bar 1万時間 • 1万時間を投資する対象がニーズの先取りをしていた。 ◦ これは流石に計画できない。偶然。 ◦ とはいえ、いろいろなことに興味を持っていた。とりあえずやってみよう精神。
◦ 興味を持ったことをやりたいときにやれるパワーバランスを作っておく/認知しておく/利用するのは大事 ▪ 転職時にリクルートに社員エンジニアがいなかった(事業会社に行きやすいパワーバランス) ▪ エンジニア出身マネジャーが希少種だった(マネジャー任用されやすいパワーバランス) • 周囲に対するちょっとした優位性を持つことで仕事が流れてくるメカニズムを作る ◦ 1万時間で得たことを次の1万時間の優位初期値に利用する ▪ エンジニアだけど新規事業オーナーをするとか(1ミリリードで開始できる) ▪ エンジニア出身のマネジャーとか(1ミリリードで開始できる) ◦ 何事も初動を全力で行い、1ミリのリードを最短最速で作る。あとは受け身でも仕事が勝手にやって来る (可能性が高くなる)。そして全自動で有識者化していき、希少性が発生するかもしれない。
まとめると ※当時はこんなこと考えていない hoge 1万時間 foo 1万時間 bar 1万時間 • 1万時間を投資する対象がニーズの先取りをしていた。 ◦ これは流石に計画できない。偶然。 ◦ とはいえ、いろいろなことに興味を持っていた。とりあえずやってみよう精神。
◦ 興味を持ったことをやりたいときにやれるパワーバランスを作っておく/認知しておく/利用するのは大事 ▪ 転職時にリクルートに社員エンジニアがいなかった(事業会社に行きやすいパワーバランス) ▪ エンジニア出身マネジャーが希少種だった(マネジャー任用されやすいパワーバランス) • 周囲に対するちょっとした優位性を持つことで仕事が流れてくるメカニズムを作る ◦ 1万時間で得たことを次の1万時間の優位初期値に利用する ▪ エンジニアだけど新規事業オーナーをするとか(1ミリリードで開始できる) ▪ エンジニア出身のマネジャーとか(1ミリリードで開始できる) ◦ 何事も初動を全力で行い、1ミリのリードを最短最速で作る。あとは受け身でも仕事が勝手にやって来る (可能性が高くなる)。そして全自動で有識者化していき、希少性が発生するかもしれない。
さらにまとめると 演繹的にではなく帰納法的に、キャリアを振り返りました。 こうやってメタ的に自身のキャリアを振り返り、そこにあるメカニズムを理解し、 そこから今後のキャリアを見立てる。 というこの思考プロセス自体が変化に対応するために必要なのかもと改めて思いました。 ライフシフトという概念もあります。 いつ1万時間投資を始めても遅くはないと思います。 あくまで、私のキャリアの帰納法的分析結果ではありますが、何かの参考に少しでもなれば。