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
Takahiro Tsuchiya
July 30, 2024
Technology
7
3k
現場のエンジニアから見た採用担当との協働
こちらのイベントの登壇資料です
https://herp-user-community.connpass.com/event/324922/
Takahiro Tsuchiya
July 30, 2024
Tweet
Share
More Decks by Takahiro Tsuchiya
See All by Takahiro Tsuchiya
Kaigi on Rails 2024 - Rails APIモードのためのシンプルで効果的なCSRF対策 / kaigionrails-2024-csrf
corocn
9
5.4k
シリーズAをリファラル採用中心に走り抜ける / leaner-referral-engineer-2024
corocn
3
2k
捨てて加速するプロダクト開発 / sutete-speedup-product-development
corocn
3
670
リファラル採用にフルベットしてみた
corocn
3
3.7k
エンジニアとプロダクトマネージャーを兼任した1年間を振り返る / pdm-furikaeri
corocn
17
7.9k
育休のすゝめ #devsumi 2023
corocn
3
4.8k
GCPでRubyを動かしている話 / ruby on gcp
corocn
0
920
フルリモートワーカーのデスク選定 / how-to-select-remote-work-desk
corocn
1
610
Auth0イントロダクション / corocn_auth0_day_recap_in_osaka
corocn
1
1.1k
Other Decks in Technology
See All in Technology
モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実
kzkmaeda
0
110
20250326_管理ツールの権限管理で改善したこと
sasata299
1
390
AIエージェントキャッチアップと論文リサーチ
os1ma
6
1.2k
ルートユーザーの活用と管理を徹底的に深掘る
yuobayashi
6
730
DevinはクラウドエンジニアAIになれるのか!? 実践的なガードレール設計/devin-can-become-a-cloud-engineer-ai-practical-guardrail-design
tomoki10
3
1.4k
React Server Componentは 何を解決し何を解決しないのか / What do React Server Components solve, and what do they not solve?
kaminashi
6
1.2k
チームの性質によって変わる ADR との向き合い方と、生成 AI 時代のこれから / How to deal with ADR depends on the characteristics of the team
mh4gf
4
340
コンソールで学ぶ!AWS CodePipelineの機能とオプション
umekou
2
120
Engineering Managementのグローバルトレンド #emoasis / Engineering Management Global Trend
kyonmm
PRO
6
990
Riverpod & Riverpod Generatorを利用して状態管理部分の処理を書き換えてみる簡単な事例紹介
fumiyasac0921
0
110
Go製のマイグレーションツールの git-schemalex の紹介と運用方法
shinnosuke_kishida
1
410
初めてのPostgreSQLメジャーバージョンアップ
kkato1
0
440
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
462
33k
How STYLIGHT went responsive
nonsquared
99
5.4k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.1k
Designing for humans not robots
tammielis
251
25k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
Raft: Consensus for Rubyists
vanstee
137
6.9k
Designing Experiences People Love
moore
141
23k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
12
1.4k
Product Roadmaps are Hard
iamctodd
PRO
52
11k
Become a Pro
speakerdeck
PRO
27
5.2k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.2k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.6k
Transcript
現場のエンジニアから見た採用担当との協働 2024-07-30 株式会社Leaner Technologies / Takahiro Tsuchiya @corocn
自己紹介 今回はノリで本名顔出しで告知してもらいましたが、、 @corocn(ころちゃん、ころさん)と呼ばれています。 エンジニアです。 スタートアップでプロダクト開発や採用など色々やってます。 岐阜からリモートワークしています。 経歴 - 情報系大学 &
大学院卒 - 自動車部品メーカー - システム開発受託(SIer) - クラウド請求書 Misoca ← 本格的にエンジニア採用をはじめたのはここから - キャスター(採用媒体の開発、採用アシスタント( RPO)のお手伝い) - 現職: Leaner Technologies
昔の発表 - エンジニア採用をする上での基礎知識 - https://speakerdeck.com/corocn/recruting-engineer-basic - どう役割分担して開発してるか知ろう!という話をした - 技術に深入りしすぎちゃったので、今日はもっと前手の話をします
今日の話 - まず知っておきたいこと - ソフトウェア開発における人の増やし方 - 現場目線でHRに頼りたいこと - 現場主導のエンジニア採用を推進してきて思うこと -
現場の巻き込み方 - 採用活動を細く長く継続していくという視点
まず知っておきたいこと
スケールの戦略 - 自社がどんなビジネスモデルで - エンジニアはどう売上に寄与しているのか - どんなプロダクトを開発しているのか - どんな方針でプロダクトを拡張しようとしているか -
どんな方針で開発組織を大きくしようとしているのか - まずは大枠を知った上で、そこから派生する細かな技術情報は、必要になったらインプットで良い
toB SaaSビジネスの例 顧客 セールス プロダクト エンジニア 弊社のような toB向けプロダクトの例 セールスはそれぞれの顧客に対して独立して提案活動ができるので、比 較的スケールしやすい
エンジニアは 1個のプロダクトを複数人で触るので、独立して動きにくい = スケールに一工夫必要
人が増えても速くならない - 早い段階で人の増加による効果の頭打ちがくる - 実際に開発していてもチーム 8人程度で結構かつかつ感がある - チームの上限はピザ 2枚を囲める程度が目安と言われている
どうスケールさせるか - 基本的にはチームやプロダクトを分割してスケールに立ち向かうことになる - ここはCTOやVPoEが考えるトップダウンでの方針が色濃く出るところ - ぜひ自社のマネジメントレイヤーの方と会話してほしい (このへんが自分の言葉で説明できない人は特に)
人を増やしたくない気持ちの人もいる - 人増やして速度あがるんですか? いまのままでいいじゃないですか。 - 過度な組織の拡大で痛い目をみた経験がある - 中長期での事業目標を理解できてない - 少数精鋭はカッコイイ
- スケールさせないが許されない - 完全自己資本でやる分には全然許されそう - 一定の事業成長を約束して資金調達をしている - 拡大スピードを考慮しながらも、人を増やすことに向き合う覚悟が必要 - ということを改めて伝えることは大事
チーム分割で参考になりそうな本 - Team Topologies(通称ちいとぽ) - 組織設計の本なので HRの方にもおすすめ - 弊社も参考にしている -
ちいとぽを参考にしている会社をよくみかける - Timeeさんとか
HRに頼りたいこと
フラットな視点で見る - 完全に現場目線だと視野が狭くなりがち - 客観視する視点がほしい - 当事者だとどうしても俯瞰的に見るのが難しくなる(勿論できる人もいる) - たよりたい
例: コストをかける優先度が間違ってる - スカウトメールの文面 - 当事者なので、フルカスタム文面のスカウトは当然体験良く感じてしまう - 自分が送るときにもフルカスタムしないと成果が出ないのか(そうでもないはず) - 実際は顕在化しているかと会社の認知のほうが大きい
- 転職興味ないとき => ただの広告 - 転職タイミング => 有名なところからスカウトきたから話きいてみよ
例: 他社の露出に踊らされる - 他社がよく使ってる媒体だから採用できるだろう!という誤解 - 媒体主催のイベントで毎回この会社が登壇しているし、スカウトもめっちゃくる! - その媒体でめちゃくちゃ人が採用できているはず! - だから弊社も採用できるはず!
- 結局リファラルを軸とする会社が多い - 今日登壇する3社はおそらくそう - 次手で エージェント・自己応募あたり - リファラルから逃げないほうが最終的に幸せになれる
採用チャネル 私 元同僚: 一緒に働いたことがある SNS: 働いたことないけど、 SNSや勉強会でゆ るく繋がってた
巻き込み方
習熟度 - 全員が同じマインド・スキルセットを持っていると思わないこと - マネジメントと同じ - ある程度知識がある人は自由にやってもらったほうが成果は出る - 何もやったことないひとは手厚くサポートしたほうがいい -
エンジニアさんたち を巻き込むという考え方ではなく、 協力してくれる各個人という捉え方をしてほしい
認知を曲げない - 採用はどこまでいってもサブ業務になる - 採用は最優先といえど 1ヶ月160時間を採用に使っていいわけでない - エンジニアは基本的に「開発」がメインの業務になっている(それはそう)ので、そち らでチャレンジングな目標を抱えている -
言葉遊びで何もかも最優先にしてやることを詰め込みすぎない - 認知が曲がると気づかないうちにチームは疲弊する
得意領域で動いてもらう - 各メンバーの得意な関わり方を見つけよう - リファラル、アトラクト、技術選考、ブログ発信、イベント開催 - リーナーでは - リファラルに振り切ってる人(私)もいれば -
イベント企画が得意な人もいれば - Pittaでひたすらカジュ面するのが得意な人もいる - ストレス最小で続けられることが大事(継続は成果にもつながる) - 「得意なことで貢献してね」を伝えていく - 苦手を改善するのは諦める
まとめ - まず知っておきたいこと - まずはどうスケールさせるかの戦略を抑えてほしい - 現場目線でHRに頼りたいこと - 現場目線だと視野が狭くなるので一歩引いた視点で問いてほしい -
現場の巻き込み方 - 認知を曲げない - 得意をベースに細く長く継続できるように
調達力を強化して、 収益性を向上する。 調達DXクラウドシステム
「調達」って知ってます ?
「調達」とは、 企業の買い物。
企業の買い物 1000兆円 を科学する挑戦
見積 Sourcing 発注 Purchasing 見積作成 質疑応答 見積 比較検討 契約管理 商品選定
発注 検収 支払 Payment 分析 Analytics ⾒積 購買 ⾒積 / Sourcingプロセスを デジタル化できるクラウドプラットフォーム 発注 / Purchasingプロセスを デジタル化できるクラウドプラットフォーム
採用情報 - 現在社員数約60人 - 2人目のHRを探しています - 興味があればDM等で声かけてください - 採用メインだけど、採用以外の部分もたくさんある