エンジニア募集要項を作ってみた
これまでのHappy Hiring !!
- 連載第1回では Happy Hiring !! がやろうとしていることをまとめました
- 連載第2回ではエンジニアの応募に繋がる募集要項を考えてみました
- 連載第3回では募集要項テンプレートを使って、開発チームにインタビューしました
- 連載第4回では改善したテンプレートをもとに開発チームに2回目のインタビューをしました
今回は募集要項の元となるインタビューは終わったので、実際に募集要項にまとめます。
インタビューではQAの羅列になっているため、タイトルと募集概要を加え、実際に募集要項を編集・作成します。
開発チームインタビューのふりかえり
タイトルと募集概要をまとめるにあたり、課題が多岐に渡っているため、ふりかえってみます。
現在の技術的な課題・問題(Tobe)
- 開発メンバーが1人なのでコードレビューなど開発体制がない
- 技術ドリブンでプロアクティブにサービスを改善できていない
- サービスのヘルシーチェックまで手が回っていない
現状の開発(Asis)
- サービス全般、PHP/Laravelスタックで統一されている
- とはいえ、レガシーな技術も多く、昨今の標準となっている技術もない
- Laravel 3.×系
- 継続的インテグレーション、継続的デプロイ、iOS/Android などネイティブ技術、Web API、キャッシュ戦略など
- 一方で標準となっている技術の採用も少しずつ出てきている
- 主なサービスドメインはエンジニア教育や研修
- ゼロからプロダクトを作ることもやっている
あなたにどのように解決して欲しいのか?(Howto)
- 1年かけて、サービスの改善が出来るレベルに成長して欲しい
- 開発経験が浅くても技術的な成長意欲があれば十分に活躍できる
- まずはPHP/Laravelの技術スタックを学ぶことからスタート
誰と解決するのか?(with Who)
- 開発経験は長い
- 誰かに言われたからやるという開発スタンスではない
- 技術が比較的好きなおじさん達
募集要項をつくってみる
ふりかえってみると、未整備なものが多く、大変そうな印象を受けます。
読者の皆さんなら、この募集要項のタイトルと概要をどのように作りますでしょうか?
(ぜひコメントなどで参加してもらえるとうれしいです!!)
私が成長経験としてエンジニアに感じてもらえそうだと考えたのは↓です。
- どのような開発体制、開発環境がよいのか、一緒に考えながら作れる
- 技術選定からはじめ、自身の学習成果をサービスの改善につなげられる
- アプリケーション開発だけでなくインフラやネイティブ化など、まさしくフルスタックに経験を積める
- 初期の技術スタックの学習コストを払えば、様々に活躍できる
- フレームワークのアプデやリファクタリングなども経験できる
- 少しづつでも技術をサービスの改善につなげよう、という意志がある
- ドメインがエンジニア寄りなので自然とドッグフーディングできる
この中でも、特にメッセージしたいのは、開発体制を一緒に作る、フルスタックに技術選定して、実装できる経験を積める、ということだと考えました。
というわけで、タイトル(40文字程度)と募集概要(200文字程度)を加えて、募集要項を作りました。
2人目の開発メンバーとして体制作りや技術選定→実装の経験を積みたい方募集!
募集概要
現在、1人で開発しているエンジニア向け研修サービスで、2人目の開発エンジニアを募集しています! コードレビューやスクラムの適用など、よりよい開発体制を一緒に考えながら、デプロイ方法や監視体制などのインフラ構築からアプリケーション開発、ネイティブ化まで一緒に学習しながら、技術を選定し、サービスに実装できるフェーズです。 自身のスキルとキャリアをフルスタックに広げたい方はぜひご応募ください!
あなたに何を解決してほしいのか
- 開発体制を作る
- 開発メンバーが1人のため、コードレビューを通じた品質検証はもちろん↓のようなことが出来ていません
- 改修のスピード、リズムがありません
- 今は実行結果しか見ておらず、可用性とか拡張性まで気を配れていません
- 技術ドリブンのサービス改善
- セールスチームからの要望ベースになってしまっているため、技術進化の恩恵をユーザーに提供できていません (開発の効率も含む)
- 例えば、受講ログの分析等を通じたテスト配信、学習スケジュール設定など
- サービスのヘルシーチェック (ログ監視など)
- 監視含めて外注しているので、予兆を把握できていません
- (今のところ障害は発生していません)
現在はどういうプロダクト/サービスを、どういう技術を使って開発しているのか?
- 具体的なプロダクトやサービスの内容
- 具体的な技術
あなたにどのように解決して欲しいのか?
- どのような方に
- 言われたことをやるのではなく、技術が好きで、面白がって開発したり、探求出来る方
- スキルはWebアプリケーションの開発やインフラ構築でも構わず、↑を重視しています
- どのようなスピードで、どのようなことを解決してほしいのか
- じっくり1年掛けて技術ドリブンのサービス改善ができるようになって欲しいです
- 大幅リニューアルというよりドキュメント整備など含め、1歩ずつ改善を積み重ねて欲しいです
- どのようなロードマップで進めるのか
誰と解決するのか?
- 技術が好きで、気さくな、開発経験年数が長い おじさん(30代) チーム
- 開発チーム全体のメンバーは3人
- 今回のポジションのエンジニア研修系サービスを開発している、皇居ラン部のおじさん1人
- コメディカル人材メディアやアプリをやっているおじさん2人
- 有給消化率がKPIです
- 受託ではなく、自社プロダクト/サービスで儲けることが好きです
まとめ
開発チームへのインタビューをもとに、タイトルと募集概要を含めた、募集要項を作成しました。
ちなみに、弊社の非エンジニアが同じポジションで、過去に募集要項を作っていますので、それと比較すると、大きく違っていることにお気づきになると思います。
なお、募集要項の修正からエンジニアとのレビューなどはGitHub上に残っていますので、ご興味のある方はご覧下さいませ。
では、次回、出来上がった募集要項を、どの募集チャネルで告知するのか、考えてみます!
来週もお楽しみに!! Happy Hiring !!
募集要項テンプレートを使って開発チームにインタビューしてみた -2-
これまでのHappy Hiring !!
- 連載第1回では Happy Hiring !! がやろうとしていることをまとめました
- 連載第2回ではエンジニアの応募に繋がる募集要項を考えてみました
- 連載第3回では募集要項テンプレートを使って、開発チームにインタビューしました
第3回で募集要項テンプレートに不足があり、具体的なスキルなど曖昧になってしまったので、テンプレートを見直し、改めてインタビューを実施することになりました。
今回はその見直したテンプレートをもとに、改めて開発チームにインタビューしたので、その模様をまとめました。
開発チームへのインタビュー準備
前回同様、テンプレートの改訂部分を開発チームに共有し、入力をお願いしていました。 テンプレート改訂
ただ、今回は開発チームの作業が混んでいたのか、事前に内容は更新されず、インタビュー当日を迎えました。
2回目の開発チームインタビュー!!
改訂した部分の質問から始め、その回答を聞いて、さらに深掘りする形式で進めました。
(インタビュアー:広瀬 [Q.]、インタビュイー:開発チーム [開発])
質問: 現在はどういうプロダクト/サービスを、どういう技術を使って開発しているのか? (Asis)
- Q. 具体的なプロダクトやサービスの内容を説明してもらってよいでしょうか?
- 開発 あ、、先に書いとけばよかった。。。うーん、どこから説明しよう
- Q. ちょっと時間が掛かりそうですね。。インタビュー後に追記してもらってよいですかね?
- 開発 スイマセン。。そうします
- (私の気付き)社外にサービス内容を説明する、というのは比較的、エンジニアにとっては関心外になるのかも知れません
- Q. 具体的に使っている技術はなんですか?
- (私の気付き)使用技術は必ずしも納得して使っている訳ではないので、深掘るかどうか、判断が必要です
- (私の気付き)判断基準として、ToBeで挙がった課題が技術寄りであれば、ここは大いに深掘りするとよさそうです
2回目のテンプレート不備。。と改善
判明した問題
将来(ToBe) と 現状(Asis) が揃ったので、候補者に具体的にどのようなスキルが必要で、どう解決していくのか、見えているはずが、、、、全く見えていません!!!! :scream: :scream:
このため、テンプレートに急造で質問を追加しました
質問の追加内容
- あなたにどのように解決して欲しいのか? (Howto)
Tobeで挙がった問題・課題に対して、一緒にどのように取り組んでほしいのか
この意図としては、どのような候補者に、どのようなスピート感で課題に取り組むのか質問することで、候補者の最低限必要なスキル、将来どのようなスキルや経験を得られるのか、が見えることを期待しました。
インタビューを再開
急造の質問をもとに、インタビューを再開しました。
質問: あなたにどのように解決して欲しいのか?
- Q. どんな候補者に?
- Q. 候補者はどのようなスピードで、何を解決できるようになっているのがよいですか?
- 開発 遅くても少しずつ1年かけて、一通りできるようになって欲しいですね
- Q. “一通り” とは、Tobeの課題だと、どんなものになりますかね?
- 開発 (課題を眺めてみて) そう考えると、Tobeで挙がってない課題がありますね。セールスチームからの要望解決が入ってないです
- Q. そのセールスの要望解決のことが、一通りになります?
- 開発 それと、"技術ドリブンのサービス" ですね
- Q. その2つを1年かけて出来るようになる、というのがゴールですね?
- 開発 ですね
- Q. では、どんな候補者に来てもらうと、1年でそこまで到達できますかね?
- Q. では、技術探究心がある候補者に入社してもらったとして、ゴールまでどんなロードマップを考えられますかね? 例えば、Laravelチュートリアルからはじめる、とか
- 開発 その辺は候補者のスキルレベルに寄りますね
- Q. その技術探究心があるという想定の中で、一番下の低いレベルから考えると、どうなります?
- 開発 となると、まずLaravelの開発環境を作るところから入って、チュートリアルをやって、というところからスタートですね
- Q. では、その次は?
- 開発 次は、、それまでのタスク消化状況を見ながら、テストを書く、ドキュメントを書く、というところを徐々にやりながら、機能改修を一緒にやって、と進めていくことになりそうです
- (私の気付き)テンプレートもこの順番で、ゴール->どんな候補者->ロードマップとすると、良さそう
ということで、ようやく、どんな候補者に、どのようにTobeの問題を解決して欲しいのか、が決まりました!
テンプレートの改善はまたやるとして、次に誰とやるのか、という質問に移ります。
質問: 誰と開発するのか?
- Q. 外部の人にチームを紹介すると、どんな感じになりますかね?
- Q. (なぜにエディタ。。。) 開発経験は豊富であると。あとはどんなおっさんなんですかね? そもそも何人とか
- 開発 そうそう、3人ですね。今回の募集対象となっているサービスの開発者が1人で、他は医療のコメディカル人材の紹介メディアと、アプリの開発をやっているのが2人
- Q. あざます。では、そのチームで重視していることとか、ポリシーみないなものとか、好きな言葉とかあります?
- 開発 有給消化率は高いw KPI持ってると言っていいかも知れません。
- 開発 あとは金を稼ぐ、というところですね
- Q. ほうほう。。金を稼ぐ、とは?
- 開発 やったこととか時間でお金が決める、という訳ではなくて、自社のプロダクト、サービスで儲けることで、自分たちの金を稼ぐ、という意識が明確である、ということですね。いわゆる受託や派遣ではない、と
- 開発 どんな技術を使うのか、というより、どうすればプロダクトやサービスが成長するのか、という観点を大事にしている、ということです
- Q. なるほど、技術より問題解決、ということですね。
- 開発 そうですね。とはいえ、問題解決とは別に、新しい技術とかテーマは好きですね。この技術、趣味開発で使ってみました、とか
- Q. ふむふむ。最近だと、どんなことに興味をもってます?
- 開発 世間並みですが、AIとかIoTとか。実際、AIはやってみようと計画中ですし、あとRasPiとかで工作は遊びでやってます
- Q. ふむふむ。。。あとは、何かありそうです?
- 開発 うーん、もう無いですね。これでいきましょう!
- Q. 了解です。では、これで進めます! このあと募集要項を実際、私が作るので、それをレビューしてもらう、というフローになるので、お願いしまっす
- 開発 OKです
- (私の気付き) 自己紹介が得意なエンジニアはあまりいないので、スムーズに引き出せるように、ちょっと質問を用意したほうが良さそう
開発チームに関する質問で、とにかく悩む場面が多かった印象です。
募集要項テンプレートでは、カジュアルな質問から真面目なものまで複数用意して、そこから選んでもらう、というのがマッチしそうです。
まとめ
- 見直した募集要項テンプレートをもとに、2回目のインタビューを実施しました
- 前回と同じく、インタビュー中、具体的な候補者像が出てこない、という事態になってしまったので、急遽、テンプレートにどのように解決してほしいのか、という質問を追加しました
- ようやく求めているスキルなど具体化できました
- 開発チームの自己紹介はエンジニアにとって苦手なようなので、質問を多く追加したほうが良さそうです
なお、今回のインタビューのログは アクティビティ にまとまっています。
では、次回はインタビュー結果をもとに、実際、募集要項を作ってみます!
また、余裕があれば、テンプレートの修正にも取り組みます。
来週もお楽しみに!!
Happy Hiring !!
募集要項テンプレートを使って開発チームにインタビューしてみた -1-
これまでの Happy Hiring !!
今回は第2回でまとめた募集要項テンプレートをもとに、実際に自社の開発チームにインタビューしたので、その模様をお届けします。
また、インタビューしてみると、募集要項テンプレートの問題点があったので、その改善内容もまとめています。
開発チームへのインタビュー準備
開発チームとインタビューでは 打合せ時間 = 開発時間の減少に繋がるため、出来る限り、時間を抑える必要があります。
このため、事前に募集要項テンプレートを開発チームに共有し、回答してもらいました。
開発チームの事前回答
開発チームの主力メンバーとチームリーダーにお願い、回答してもらいました。
- 主力メンバー :octocat: id:hitorigoe の回答内容
- チームリーダー :octocat: id:sep-mk の回答内容
事前調査をみた感想
インタビューをスムーズに進行させるため、事前にザッと回答内容を見てみました。
- 課題が多いため、抽象度の高い回答になっているなぁ
- ”サーバスペックの定期監視” のような掴みにくい表現もある
- 深掘りする必要がありそうなので、それぞれの回答に質問を2つ用意
- Q.これはどういうことを指しているのだろう?
- Q.これはなぜ問題なのか?
開発チームにインタビュー!!
hitorigoe と sep-mk の同席のもと、それぞれの回答内容を深掘りする質問を中心に、インタビューしました。
(インタビュアー:広瀬 [Q]、インタビュイー:開発チーム[開発])
質問:あなたに何を解決してほしいのか?
- サービスの品質チェック
- Q. これはどういうことですかね?
- 開発 これは募集対象のサービス開発体制が1人なので、実行結果を非エンジニアが見て、問題なければリリースになっているという状態を指してます
- Q. なぜ、これは問題になるんですかね?
- 開発 この状態だとコードレビューできず、たまたま今はOKでも、将来的なバグに繋がったり、可用性や拡張性などに配慮したコードになってるか不安なんです
- (私のメモ)新しいメンバーには、ゼロからコードレビュー体制を一緒に作って欲しい、ということが期待される
- 開発チームのクロス体制
- Q. 続いて、これも説明お願いします
- 開発 ↑にも関連しますが、病気など不足の事態で自分が長期離脱した場合、 :scream: なことになるので。。 ((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
- (私のメモ)新しいメンバーには、早く来て欲しい、、
- 技術ドリブンのサービス改善
- Q. 続いて、こちらはなんとなくわかりますが、説明もらってよいです?
- 開発 新しい技術をどんどん検証して、現在のサービス改善に繋がりそうであれば、提案・適用していく、ということが出来ていないんです
- Q. これが問題に挙がるのはどうしてでしょう?
- 開発 技術の進化に伴って、パフォーマンスが改善されたり、開発そのものを効率化し、その分、もっと機能拡張につなげたり、といった技術進化の恩恵をサービスのユーザーに提供できてないのが問題なんです
- 開発 例えば、機械学習、深層学習の技術で、例えば、受講ログをもとにテスト問題の配信や学習スケジュールの設定などに繋げる、などが考えられますね
- (私のメモ)新しいメンバーには、技術のキャッチアップと、それによりユーザー体験がどう改善するのか、そういったことが好きな人が合いそう
- サーバスペックの定期監視
- Q. 続いて、こちらは読んで分からなかったので詳しくお願いします!
- 開発 いま外部のデータセンター保守会社に監視をお願いしていて、ログ等のメトリクスを定期監視出来ていない状態なんです
- Q. ふむふむ。なぜ、これは問題になるのでしょう?
- 開発 これだと、問題が起きてから、後手に対応するということになってしまいます。幸い、大きなトラブルが起こったことはないんですが
- 開発 なので、自社でログなどの監視体制を作って、予兆を把握して、障害などの先回りをする、という状態にしたい、ということですね
- (私のメモ)新しいメンバーには、こういったインフラ寄りのログコレクションや結果を見える化する、ヘルシーチェックにも手を出してみたい人が良さそう
以上のようにまとめながら、優先度を決めようとしたところで、1時間近くになってきました。 実際のログ
また、インタビューしていると、課題がとても抽象度が高く、事前回答で挙がった現状の開発も抽象的になっています。
これでは応募者がみたときに、具体的なスキルや技術が抜けてしまって、手を動かして解決しているイメージが湧きません。。
インタビューを一旦終了 -> テンプレート見直し
現状の開発や開発チームに質問も残っていたのですが、掘り下げるのに時間が掛かるため、テンプレートを見直して、改めてインタビューを設定することになりました。。orz
将来の課題と現状との差分を取れば、具体的なスキルや技術が出てくると思ってましたが、見通しが甘かったようです。
何が問題だったのか
テンプレートの問題
挙がった問題や課題の抽象度に比例して、解決方法も抽象度が高くなってしまうため、Tobeに関する質問もしくはAsisの質問、どちらかを具体化する必要があります。
となると、Tobeの解決方法は候補者が具体化することであり、Asisを具体化するほうが良さそうです。
そこで修正したテンプレートが↓です。
- あなたに何を解決してほしいのか? (Tobe)
- 現在どういうプロダクト/サービスを、どういう技術を使って開発しているのか? (Asis)
- 誰と解決するのか? (with who)
改訂した 募集要項テンプレート
インタビュー時間の問題
やってみると、1時間はあっという間に終わります。
このため、時間が許す限り、オンラインで、開発チームが何を意図しているか読めば分かるところまで深掘りする必要があります。
とはいえ、はじめて開発チームにインタビューする場合、少なくとも1.5時間は想定したほうがよさそうです。
まとめ
- 募集要項テンプレートを使って、実際に自社の開発チームにインタビューしてみました
- 解決して欲しい課題が見える化されたものの、抽象度が高く、具体的なスキルや技術に言及できませんでした
- 一旦、インタビューを終了し、テンプレートを見直しました
- 現在どういうプロダクト/サービスを、どういう技術を使って開発しているのか?、という質問に変えてみました
では、これで2回目のインタビューをやってみます!
来週もお楽しみに!!
Happy Hiring !!
エンジニアの "応募" に繋がる募集要項とは
Happy Hiring !! とは (再掲)
ハッピーなエンジニア採用を! という意図で、エンジニア採用に関するノウハウを、自社採用を通じて、綴っていくというブログです。 大事なことなので二回言いました!
さて、今回は連載2回目、 エンジニアの “応募” に繋がる募集要項とは です。
エンジニア 募集要項のストーリー
募集要項をシンプルに考えると「こういうポジションを採用したいので、応募して欲しい」というストーリーを伝えるためにあります。
そこで重要になるのは、ポジションの詳細より、“なぜそのポジションが必要なのか” という見落としがちな部分です。
なぜ重要なのか、考えてみましょう。
- Q. なぜ、そのポジションが必要なのか?
- A. 開発上、○○○○○○という課題や問題があるため
この 2. の開発上の課題や問題こそが、エンジニアの応募動機に繋がります。
「その問題や課題は (自分なら解決できる) (自分なら解決できそうだ) (今は出来ないけど解決してみたい) から入社したい」という動機ですね。
そして、この動機が高まるほど、エンジニアが応募しようという行動に繋がります。
// 挙がった問題や課題の難易度と待遇条件は比例します
// 個人的には、今は出来ないけど解決してみたい、という応募動機が一番強いと思っています
なぜを明らかにするための募集要項テンプレート
では、"なぜ、そのポジションが必要なのか" を含めて、ストーリーにするテンプレートを考えてみました。
- あなたに何を解決してほしいのか?
- 現在どのように解決しているのか?
- 誰と解決するのか?
というわけで、一つ一つ眺めてみます。
あなたに何を解決してほしいのか?
この質問で明らかになるのは、現在のプロダクト / サービス / 開発チームが抱えている技術的な問題や課題です。
繰り返しになりますが、この問題や課題を明らかにすることによって、解決してやろう、という応募モチベーションに繋がります。
ここで重要になるのは、あれもこれもと細部の問題が出てくることがとても多いので、問題の粒度と照らし合わせて、問題を汎化する、募集ポジションを分ける、などが必要になります。
現在どのように解決しているのか?
↑がどちらか将来 (ToBe) を指すのに対して、ここは現状 (Asis) です。
ここで、重要なのは、現状の使用技術や開発環境など状況をオープンにすることです。
「"盛る" のはダメ、絶対」
ここで盛ると、入社ギャップに繋がり、お互いハッピーにならない可能性が高い上、早期退職となってしまい、企業の別れ方が悪いと炎上することもあります。
また、将来と現状のギャップが広がりすぎている、かけ離れていると、論理の飛躍に繋がりがちです。。
論理が飛躍すると、途端に、応募するモチベーションが失われる、というより、論理の破綻は何よりエンジニアのモチベーションを奪います。
将来と現状との乖離が広がりすぎているならば、将来もしくは現状の欄で、ロードマップは示したいところです。
誰と解決するのか?
見たままですが、誰とやるのか、を書くところです。
Whyに比べると、どちらか補足的なものになりますが、技術を使いこなして開発するのは “人” なので、Whyに挙がる問題と人の関連は強い、といえます。
ここで重要なのは、自社に著名なエンジニアがいない、とかでは無く、あくまで、開発チームがどんなチームなのか、です。
開発チームのミッションやバリューをまとめていればよいですが、開発メンバーの好きな言語やOSSや言葉を挙げるだけでも、どんな志向やどんなキャラが集まっているか伝わります。
個人的には、有名なエンジニア、バーン!! もよいですが、開発チームワイワイ!! の方がいい気がします。
また、現状は学習フェーズなのか、サバイバルモードなのか、将来、どんなチームを目指しているのか、チームの現状と将来もあると、より技術上の課題だけでない応募動機になりますね。
まとめ
- 募集要項には “なぜ、そのポジションが必要なのか?” が必要です
- そのWhy を掘り下げると、開発上の問題になり、それがエンジニアの応募動機に繋がります
- Why を含めて、募集要項をストーリーにするためのテンプレートを考えました
- あなたに何を解決してほしいのか?
- 現在、どのように解決しているのか?
- 誰と解決するのか?
今回の募集要項テンプレートは↓にまとめていますので、私はこれを使っている、こっちの方が伝わりやすいなどあれば、ぜひぜひプルリクエストもらえるとうれしいです!!
https://github.com/sezemiadmin/happy-hiring/blob/master/template/job_description.md
では、次回、この募集要項テンプレートをもとに、いよいよ自社の開発チームのインタビューに臨みます。
次回もお楽しみに!! Happy Hiring !!
"Happy Hiring !!" というブログをはじめます
Happy Hiring !! (ハッピーハイアリング) とは?
ハッピーなエンジニア採用を! という、そのまんまっぽい意図を込めてます。 エンジニア採用に取り組む、エンジニア出身ではない 採用担当の方や部門、企業を想定読者として、エンジニア採用に関わるノウハウを綴っていきます。
なぜ、やろうと思った?
非エンジニアの採用担当の方でエンジニア採用に取り組もうと思うと、とっても垣根が高く、募集要項一つ書くのに大変だったりします。(作った求人票をスコアリングする、みたいなサービス があるぐらいですから。。)
一部には、エンジニアが採用担当になる企業もありますが、とっても貴重な存在なので、やはり開発に専念し、役割分担として、非エンジニアの採用担当がそのままエンジニア採用を行うことが多いです。
例えば、テックな企業の採用担当でも、エンジニアリングの深い理解は求められますが、それでも実際の開発経験を求められることはありません。
(例) 採用担当の募集要項
問題になっていること
そこで起こることが、開発チームの意図を汲んだ募集要項を書けない、募集要項を書いても訴求が難しい、他のビジネス職と同じように選考出来ない、という問題が起こりがちです。
“実務的に言えば例えばエンジニア採用する時に人事にエンジニアがいないと、「エンジニアの採用の仕方がよくわかんないからエンジニアの人、手伝って」みたいな話が超あるあるです。”
引用元:人事はエンジニア観点でみると「楽しい」グリーCTOが人事責任者を兼務する理由を語る
そうなると、↑ の記事のように、CTOやVPがなることは稀としても、エンジニアや開発チームがコミットして採用する、もしくは丸投げするということもあるでしょう。
問題解決に繋がるかも知れないこと
私自身も非エンジニアですが、これまでの仕事柄、採用とエンジニアに近いところにいたため、これまでの私の経験や知識で、役に立つノウハウがあるかもと思ったのが動機です。
この “Happy Hiring!!” で目指していることは、ここで綴ったノウハウを通じて、これまでより垣根が下がり、どちらが偉いではなく、採用担当とエンジニアや開発チームが協働して、ハッピーなエンジニア採用につながればと考えています。
もし、ブログのノウハウを活かして、一緒に取り組んで欲しい、相談相手が欲しい、といった場合は、サポートメニュー考えたいと思っていますので、↓のSNSアカウントからお気軽にお問合せ下さい。
で、お前、誰よ
- 株式会社SEプラスで働いている広瀬というものです
- 過去に SEゼミ という学生向けの勉強会や開発イベントを3年開催していました
- 過去にSEプラスでエンジニア向け研修の企画や営業を10年やっていました
- 過去に新卒採用広告の会社で3年営業をやっていました
- 過去に自社エンジニア採用(中途)をやり、1名応募1名採用->現在も活躍中、というラッキーパンチを放ったことがあります
- 現在はSEゼミで開催したイベントが OSS Gate というコミュニティに繋がったため、そこで裏方? 雑用? みたいなことを楽しくやっています
- 現在、自社でセールスチーム向けのプロダクトをローンチすべく、絶賛開発中なのですが、そこでプロダクトオーナーをやってます
- 今回のサポート業で、その開発資金を得たいという欲求を持ってます
どんなことを書くの?
自分でも恥ずかしくなるような自己紹介をしたところで、肝心なことを思われると思います。
「おまえのそのノウハウ、本当に通用するの?」
当たり前ですが、スゴイ重要ですね。。。私もそう思います。
また普通のブログのように単発に何か思い出したこと、何かニュースや出来事に関連したことなど徒然と書いても、体系的にならず、実務には活かしにくくなってしまいます。
そこで、以下のことを考えました。
所属会社のSEプラスでこれから始めるエンジニア採用を題材にノウハウを綴る
採用の一連のプロセス、つまり募集->選考->入社、文化づくり的なものまで、そのプロセスごとにどう考え、どう実行し、どういう結果が得られ、そして次に向けて、どう ふりかえり したのかを綴れば、いい感じのノウハウになるのではと考えました。
これから書くこと = 採用プロセスごとのノウハウ
- エンジニアの “応募” に繋がる募集要項とは
- 開発チームへのインタビュー
- 募集要項 Job Descripton の書き起こし
- TRACTIONにちなんだ19のチャネルごとの訴求戦略
- モブプロLikeに、いい感じにスキルやマッチを測る選考方法
- ハッピー ハイアリング!!
- エンジニアが面白がる企業にする工夫
というわけで、ブログをスタートするとともに、SEプラスのエンジニア採用活動の始まりです!!
これから毎週更新するので、ぜひご期待くださいませ!! Happy Hiring!!!
