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
2.8k
現場のエンジニアから見た採用担当との協働
こちらのイベントの登壇資料です
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
5
3.9k
シリーズAをリファラル採用中心に走り抜ける / leaner-referral-engineer-2024
corocn
3
1.8k
捨てて加速するプロダクト開発 / sutete-speedup-product-development
corocn
3
620
リファラル採用にフルベットしてみた
corocn
3
3.5k
エンジニアとプロダクトマネージャーを兼任した1年間を振り返る / pdm-furikaeri
corocn
17
7.6k
育休のすゝめ #devsumi 2023
corocn
3
4.6k
GCPでRubyを動かしている話 / ruby on gcp
corocn
0
890
フルリモートワーカーのデスク選定 / how-to-select-remote-work-desk
corocn
1
590
Auth0イントロダクション / corocn_auth0_day_recap_in_osaka
corocn
1
1k
Other Decks in Technology
See All in Technology
AIチャットボット開発への生成AI活用
ryomrt
0
170
適材適所の技術選定 〜GraphQL・REST API・tRPC〜 / Optimal Technology Selection
kakehashi
1
170
強いチームと開発生産性
onk
PRO
33
11k
Evangelismo técnico: ¿qué, cómo y por qué?
trishagee
0
360
Why does continuous profiling matter to developers? #appdevelopercon
salaboy
0
180
AGIについてChatGPTに聞いてみた
blueb
0
130
Terraform Stacks入門 #HashiTalks
msato
0
350
SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの取り組み~
takumiogawa
1
100
個人でもIAM Identity Centerを使おう!(アクセス管理編)
ryder472
3
200
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
6
670
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.6k
なぜ今 AI Agent なのか _近藤憲児
kenjikondobai
4
1.3k
Featured
See All Featured
Building an army of robots
kneath
302
43k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Testing 201, or: Great Expectations
jmmastey
38
7.1k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Designing for humans not robots
tammielis
250
25k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
44
2.2k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
410
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
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等で声かけてください - 採用メインだけど、採用以外の部分もたくさんある