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
3.1k
現場のエンジニアから見た採用担当との協働
こちらのイベントの登壇資料です
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
PicoRubyでLチカ
corocn
0
96
Kaigi on Rails 2024 - Rails APIモードのためのシンプルで効果的なCSRF対策 / kaigionrails-2024-csrf
corocn
11
6.9k
シリーズAをリファラル採用中心に走り抜ける / leaner-referral-engineer-2024
corocn
4
2.3k
捨てて加速するプロダクト開発 / sutete-speedup-product-development
corocn
3
720
リファラル採用にフルベットしてみた
corocn
3
3.9k
エンジニアとプロダクトマネージャーを兼任した1年間を振り返る / pdm-furikaeri
corocn
17
8.2k
育休のすゝめ #devsumi 2023
corocn
3
5.1k
GCPでRubyを動かしている話 / ruby on gcp
corocn
0
970
フルリモートワーカーのデスク選定 / how-to-select-remote-work-desk
corocn
1
650
Other Decks in Technology
See All in Technology
PostgreSQL で列データ”ファイル”を利用する ~Arrow/Parquet を統合したデータベースの作成~
kaigai
0
180
ローカルLLM基礎知識 / local LLM basics 2025
kishida
24
9.8k
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
9.7k
[続・営業向け 誰でも話せるOCI セールストーク] AWSよりOCIの優位性が分からない編(2025年11月21日開催)
oracle4engineer
PRO
1
140
GitHub を組織的に使いこなすために ソニーが実践した全社展開のプラクティス
sony
6
3.7k
Eight Engineering Unit 紹介資料
sansan33
PRO
0
5.6k
リアーキテクティングのその先へ 〜品質と開発生産性の壁を越えるプラットフォーム戦略〜 / architecture-con2025
visional_engineering_and_design
0
7.9k
個人から巡るAI疲れと組織としてできること - AI疲れをふっとばせ。エンジニアのAI疲れ治療法 ショートセッション -
kikuchikakeru
5
1.9k
DDD x Microservice Architecture : Findy Architecture Conf 2025
syobochim
13
5.9k
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
3.2k
今すぐGoogle Antigravityを触りましょう
rfdnxbro
0
220
【ASW21-02】STAMP/CAST分析における生成AIの支援 ~羽田空港航空機衝突事故を題材として (Support of Generative AI in STAMP/CAST Analysis - A Case Study Based on the Haneda Airport Aircraft Accident -)
hianraku9498
1
240
Featured
See All Featured
Balancing Empowerment & Direction
lara
5
760
BBQ
matthewcrist
89
9.9k
Designing for Performance
lara
610
69k
Site-Speed That Sticks
csswizardry
13
970
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.2k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
The Invisible Side of Design
smashingmag
302
51k
Build The Right Thing And Hit Your Dates
maggiecrowley
38
2.9k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.3k
How to Think Like a Performance Engineer
csswizardry
28
2.3k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.4k
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等で声かけてください - 採用メインだけど、採用以外の部分もたくさんある