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
10
5.6k
シリーズAをリファラル採用中心に走り抜ける / leaner-referral-engineer-2024
corocn
3
2k
捨てて加速するプロダクト開発 / sutete-speedup-product-development
corocn
3
670
リファラル採用にフルベットしてみた
corocn
3
3.8k
エンジニアとプロダクトマネージャーを兼任した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
Bazel for Ruby (RubyKaigi 2025)
p0deje
0
100
QA/SDETの現在と、これからの挑戦
imtnd
0
140
ガバクラのAWS長期継続割引 ~次の4/1に慌てないために~
hamijay_cloud
1
290
Road to Go Gem #rubykaigi
sue445
0
890
Mastraに入門してみた ~AWS CDKを添えて~
tsukuboshi
0
280
意思決定を支える検索体験を目指してやってきたこと
hinatades
PRO
0
220
彩の国で始めよう。おっさんエンジニアから共有したい、当たり前のことを当たり前にする技術
otsuki
0
150
生成AIによるCloud Native基盤構築の可能性と実践的ガードレールの敷設について
nwiizo
7
1k
AWSのマルチアカウント管理 ベストプラクティス最新版 2025 / Multi-Account management on AWS best practice 2025
ohmura
4
310
DETR手法の変遷と最新動向(CVPR2025)
tenten0727
2
1.4k
SmartHR プロダクトエンジニア求人ガイド_2025 / PdE job guide 2025
smarthr
0
130
Porting PicoRuby to Another Microcontroller: ESP32
yuuu
4
440
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
104
19k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Optimizing for Happiness
mojombo
377
70k
How to train your dragon (web standard)
notwaldorf
90
6k
Side Projects
sachag
452
42k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Git: the NoSQL Database
bkeepers
PRO
430
65k
For a Future-Friendly Web
brad_frost
176
9.7k
Unsuck your backbone
ammeep
670
57k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
32
5.4k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
9
760
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
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等で声かけてください - 採用メインだけど、採用以外の部分もたくさんある