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
SSMRunbook作成の勘所_20241120
koichiotomo
3
160
Engineer Career Talk
lycorp_recruit_jp
0
190
TypeScriptの次なる大進化なるか!? 条件型を返り値とする関数の型推論
uhyo
2
1.7k
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
アジャイルチームがらしさを発揮するための目標づくり / Making the goal and enabling the team
kakehashi
3
130
個人でもIAM Identity Centerを使おう!(アクセス管理編)
ryder472
4
230
適材適所の技術選定 〜GraphQL・REST API・tRPC〜 / Optimal Technology Selection
kakehashi
1
690
Incident Response Practices: Waroom's Features and Future Challenges
rrreeeyyy
0
160
CysharpのOSS群から見るModern C#の現在地
neuecc
2
3.5k
プロダクト活用度で見えた真実 ホリゾンタルSaaSでの顧客解像度の高め方
tadaken3
0
180
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
chanyou0311
2
330
iOS/Androidで同じUI体験をネ イティブで作成する際に気をつ けたい落とし穴
fumiyasac0921
1
110
Featured
See All Featured
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.2k
Fireside Chat
paigeccino
34
3k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Writing Fast Ruby
sferik
627
61k
Gamification - CAS2011
davidbonilla
80
5k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
44
2.2k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Making Projects Easy
brettharned
115
5.9k
We Have a Design System, Now What?
morganepeng
50
7.2k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
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等で声かけてください - 採用メインだけど、採用以外の部分もたくさんある