scouty HR TECH LAB

HR TECH・AI企業であるscoutyが、オープンデータを分析して得られた知見や最先端のHR Tech事例を紹介していきます。

【イベントレポート】scouty ✕ Goodpatch Engineer MeetUp vol.2 〜エンジニア組織について〜

f:id:scouty:20180516101835j:plain

先日公開したイベントレポート「scouty ✕ Goodpatch Engineer MeetUp vol.1 〜プロダクト開発との関わり方〜」に続き、本記事ではイベントの後半セッション「エンジニア組織について」の一部を編集してご紹介します。

 

《プロフィール》

株式会社scouty リードエンジニア 伊藤 勝梧 (@showwin)

京都大学人工知能を専攻。クラウドソーシングにおける受注履歴からのワーカーのスキル判定を研究。2015年にAWS 認定ソリューションアーキテクトに認定。Cookpad, beBitでインターンシップの他、株式会社MMM サーバーサイドエンジニアを経験し、scoutyにジョイン。scoutyではインフラの構築からバックエンドの開発を中心に行っている。

 

株式会社グッドパッチ 執行役員 CTO & Vice President of Product ひらい さだあき

2015年1月にGoodpatch入社、2015年12月にCTOに就任。 これまではSIerJavaを使った開発やLinuxのインフラ構築などを経験し、前職の食べログではインターネット予約サービスの開発(Rails/JavaScript)にエンジニアとして携わりました。
Goodpatch入社後は、プロトタイピングツールProttのエンジニアリーダーとしてプロジェクトマネージメント、チームビルディング、プログラミング(Ruby/Rails/JavaScript)、パフォーマンスチューニングなどを行ってきました。CTOとしてエンジニアリング組織作り、エンジニアリング評価制度策定、技術選定、環境整備、エンジニア採用などを行っています。 現在はVice President of Product(プロダクト責任者)として、Prottのプロダクト開発を推進し、事業目標達成に向けて取り組んでいます。
プライベートではhtml5jというコミュニティのスタッフとして活動し、執筆/登壇活動を行っています。 フォントが好きで、FontLoversというFacebookグループを友人と立ち上げ、フォントに関するイベントなどを開催しています。好きなフォントは秀英体Optimaです。

 

株式会社グッドパッチ プロダクト&テクノロジー アドバイザリーボード メンバー 及川卓也

早稲田大学理工学部を卒業後、日本DECに就職。営業サポート、ソフトウエア開発、研究開発に従事し、1997年からはマイクロソフトWindows製品の開発に携わる。2006年以降は、GoogleにてWeb検索のプロダクトマネジメントChromeのエンジニアリングマネジメントなどを行う。その後、Incrementsを経て、独立。現在、企業へ技術戦略、製品戦略、組織づくりのアドバイスを行う。

技術系イベントなどで新しい技術に触れるのを趣味としており、登壇することも多い。Google Developers DayやDevelopers Summitデブサミ)、HTML5 Conferenceなどでの登壇が代表例。

ホラクラシーでもそうでない組織でも、個人のスペシャリティがあるということが大切


(及川さん)「エンジニアの組織について」というテーマでお話いただきたいのですが、まずはこちらのスライドをご説明いただけますか?

 

f:id:scouty:20180516102616p:plain



(伊藤)これは現在の開発チームの組織図です。scoutyは上下関係を作らないというホラクラシーな組織を作っています。大きい3つの丸のうち左側2つがWebの開発チームで、右側が機械学習チームです。Webの中でも、scouty appというのがクライアント企業が使うダッシュボードの開発、クローラーというのがSNS等をクロールしてきて情報を集めるシステムの開発プロジェクトで大きく分けて2つあります。その中にも丸がいっぱいありますが、これをロールと呼んでいます。例えばSREだったら、サイトが落ちないようにインフラ整備を行ったり、社内の機械学習エンジニアが分析するためにインフラ環境を準備するなど、インフラ側の責任を持っているロールです。ロールを持っている人はそれぞれの技術領域に責任を持つようにしています。組織によってはCTOが「この技術を使おう」と決めて、「開発チームはこれ使ってやってね」というようにトップダウンな決定をすることがありますが、ホラクラシー組織だと意思決定の権限は各自に割り振られています。

 

(及川さん)Goodpatchはどんな体制をとっていますか?

 


(ひらいさん)Goodpatchではホラクラシーにはしていないですね。Goodpatchにはプロトタイピングツール「Prott」のチームだけで20数人いて、関連部署との連携もあるので役割を分担しています。例えばProttのセールスやマーケティングにおいては、全社のマーケティング担当と協力するため、窓口を明確にする意図もあり責任者を決めて役割を分担する体制にしています。一方でGoodpatchのベルリンオフィスはホラクラシーな形を取っていますね。

 

(及川さん)ホラクラシー組織の問題としては、属人性が高くなってしまうということが挙げられます。例えば、そのロールの人が決定した技術選定やアプローチが正しかったかどうかが問題になる可能性、また人が入れ替わることで手法や扱う技術が変わる可能性がありますよね。これまでそのロールの人がAngularを使っていたが、後任の人はAngularではなくReactを採用するなどということも起こり得るかと思います。そういったリスクはどうやって解消されているんですか?

 

f:id:scouty:20180516102645j:plain


(伊藤)このスライドには書いていないんですが、メインロール以外に各ロールをバックアップする役割も存在しています。意思決定はメインロールの人が行うんですが、メインロールの人の意思決定のサポートや情報収集はバックアップの人が行います。また、意思決定に対しての意見は全メンバーが言いますし、全メンバーの意見を統合したうえでメインロールの人が最終的な意思決定権を持つという体制にしていますので、属人的ではなくチームの意思を反映した意思決定ができていると思っていますね。

 

(及川さん)複数のコンポーネントにまたがる意思決定はどうされていますか。

 

(伊藤)それぞれのメインロールには上下関係がないので、お互いに納得した上で意思決定してもらうようにしています。

 

(及川さん)ホラクラシーではないとおっしゃっていましたが、Goodpatchでは属人性の問題はありますか?

 

(ひらいさん)ホラクラシーではない体制においても、どのように属人性を排除していくかは大事なことだと思っています。例えばフロントエンドのチームは人数が多いのでチームでレビューする時間を取るようにしています。各人のスキルが均一ではないため、スキルが高い人にレビューが集中してしまうという問題が発生しがちなのですが、チームで集まってみんなでコードレビューすることで解決しています。また、不可の分散やナレッジ共有、ペアプロやモブプロなど複数人で一緒にプログラミングすることも問題解決のために試しているところです。

 

(及川さん)属人性からは少し脱線しますが、スクラムという体制は基本的にはメンバー全員がフルスタックで、どのタスクをどのメンバーが行ってもよいというのが理想の運用だと思います。でもscoutyのように役割が厳格に決められたり専門が決まっている場合はどのようにスクラムをうまく回しているのでしょうか?

 

(伊藤)普段の開発で必要なスキルは全員が必ず持っているという必要条件があります。現在のメンバーは全員がバックエンドの開発スキルは十分に持っていますね。その上で何かしらの分野で飛び抜けている人を採用するようにしています。
普段の開発の95%くらいは全メンバーが行えますが、残りの5%はその分野で飛び抜けていないとできないタスクです。そこには属人性を許容する、そうしないと技術的な優位差は出ないと思っています。

 

f:id:scouty:20180516102719j:plain


(ひらいさん)スクラムはその人がいなくても開発できるようにしていこうという考えがベースにあると思うんですけれど、Goodpatchはその点に関してはあまり意識していません。1個の芯を持っていて、その周辺技術を伸ばしていくような「T字型の人材」の育成を考えています。均一な能力を持つフルスタックも大事ですが、その人なりのスペシャリティがあるということはすごく大事だと思っていて、それを活かしていくようにしています。

 

(及川さん)個人のキャリアの志向性と組織としてのバランスをとっているということですね。

 

(ひらいさん)そうですね。個人でフルスタックになるというよりは、エンジニアチーム全体で良いポートフォリオが作れればいいと思っています。

 

現場のエンジニアが面接することで「自分の隣で働く人」を自ら決めることができる

 (及川さん)それでは次のテーマ「採用基準」「採用手法」についてGoodpatchからお聞きしてよろしいですか?

 

(ひらいさん)採用手法ではWantedlyをはじめいくつかのメディアを使っていてますし、エージェントにも依頼しつつ、最近ではリファラルの採用にも力を入れようとしているところです。また、先日scouty経由で一名内定承諾をいただけました。
カルチャーチェック、スキルチェックについては、スカウトを送った場合は最初に私がカジュアル面談を行い、候補者から選考に進む意思をいただけたら、そのあとは現場エンジニアとの面接を行います。スカウトする場合でもその他の手法でもステップは大きくは変わらないですね。

 

(及川さん)面接でスキル・カルチャーチェックするにあたって、何を聞くか、何を基準とするかを決めておかないと現場のエンジニアも困ると思うんですがそのあたりはどのように工夫されていますか?

 

(ひらいさん)面接を行うメンバーには面接官トレーニングを実施しています。トレーニングは人事が主体となって行っていて、どういった観点で見ていくのか、どういう質問をしていくのか、あるいはこういう質問はしてはいけない、ということをインプットしてから実際の面接に臨んでもらうようにしています。
現状の問題としては、採用目標が高くて大変だという難しさはあるんですが、scoutyという新しいツールを使ったり新しいメディアを使うという施策を行って打開しようとしていますね。一方で、面接官のトレーニングに時間がかかるので、面接担当者が偏り負荷が集中しやすいのは今後解決していきたい課題ですね。

 

(及川さん)scoutyはどうでしょうか。

 

(伊藤)候補者の母集団形成には、リファラルや自社でもscoutyを使っていますね。今週も機械学習エンジニアとWebエンジニア1名ずつがscouty経由で内定受託してくれました。エンジニアの人数は、1ヶ月に1名のペースで増えていますね。
スキルチェックやカルチャーチェックについては、最初にカジュアルな面談をして選考に進んでもらうかを候補者、scoutyともに相互に判断します。選考に進んでいただく場合は、3つのステップがあります。
Webのエンジニアの場合を例に挙げると、1つめのステップはスキルチェックとして問題を解いてもらいます。クラスの設計が綺麗にできるか、デザインパターンを知っているか、ちょっとしたアルゴリズムのテストなどを行い、Web開発に必要なスキルを網羅的に評価できるようにしています。2つめのステップは創業メンバーの3人と会食を行うカルチャーチェックです。3つめの最終選考では、ビジネス、コーポレートなどの全社員と一緒にランチなどの食事を行い、候補者の方と一緒に働くイメージが持てるかどうかを社員全員で判断しています。全員がそれぞれ意見を出して、一緒に働くことについて懸念があればオファーを出すことはしません。

現状の問題としては、いろいろな課題を課すことで様々な分野のスキルチェックを行いたい一方で、候補者側の負担が増えてしまうというジレンマがあります。短い時間で幅広いスキルをチェックをするための手法をいかにブラッシュアップしていくかということに今まさに挑戦しているところですね。


(及川さん)スキルチェックの課題は面接の時に提示してその場で解いてもらうんでしょうか。それとも事前に提出してもらうのでしょうか?

 

(伊藤)クラスの設計などじっくり考えないと解けないものは事前課題にしています。残りの課題は時間を設定して、面接の場で答えてもらい、いただいた答えに対してフィードバックをしたり、追加の質問をします。

 

(及川さん)Goodpatchはコーディングテストはされているんですか?

 

(ひらいさん)コーディングテストはまだ行っておらず、面接の中でスキルチェックを行っています。例えばフロントエンドだったら、JavaScriptの言語使用について質問したり、Reactを使ってる方にはどういった実装をしているか聞いたりしています。ネイティブのエンジニアの場合には、「こういった時にどう実装しますか」というような質問に加えて、実際にいくつかのアプリを見てもらい「あなただったらこれをどういう風に実装しますか」という質問をしていますね。

 

(及川さん)社内の協力体制についてもお聞きしましょう。社内のエンジニアに面談してもらったりリファラルで紹介してもらったりと、採用に関するコミットメントがかなり求められると思います。協力体制を整えるためにどのような工夫を行っていますか?

 

(ひらいさん)そもそも採用するエンジニアの方は、自分の隣で働くかもしれない人なんです。採用に協力してくれるエンジニアには「自分の隣で働く人が1回も会わずに決まってしまうのは嫌じゃないですか」というふうに話しています。面接を行うことで、候補者の方の人となりがわかりますし、自分の気になることを自分自身でチェックして納得したうえで一緒に働くことができます。

f:id:scouty:20180516102921j:plain


(伊藤)scoutyでもひらいさんがおっしゃったことと同じですね。自分たちで開発チームを作っていくんだっていう意思を持ってもらいたいと思っています。scoutyでは、面接だけでなくてscoutyを通して各エンジニアがスカウトメールを送ることで、候補者探しから手伝ってもらうようにしています。

 

ーーーーーーーーーーーーーー

 

イベントで紹介したその他のブログなどはTwitter上で #scouty_goodpatch_meetup と検索いただくとご覧いただけます。前半セッションのレポート記事「scouty ✕ Goodpatch Engineer MeetUp vol.1 〜プロダクト開発との関わり方〜」と併せて、自社のプロダクト開発や組織開発に活かしていただけたら幸いです。

 

scoutyでは今後もエンジニア向けイベント、採用担当者向けのイベントを開催してまいります。イベント告知はscoutyのconnpassページで行いますので、ご興味があればぜひご参加ください。

 

ポイントは「アウトプットの可視化」エウレカが新卒採用に成功した理由

f:id:scouty:20180502151943j:plain

《プロフィール》

梶原成親さん:
 株式会社エウレカCTO室責任者。新卒でNTT西日本に入社。楽天株式会社、株式会社リクルートライフスタイルを経て、2016年、株式会社エウレカに入社。CTO室責任者として、現在は、開発チームのチーム・ビルディング、モダンな情報システム担当、エンジニア採用、技術広報などエンジニアを支える環境作りに幅広く従事。

鈴木裕太朗さん:
株式会社エウレカ Pairs JP Androidエンジニア。明治大学理工学部情報科学科に在籍中の大学4年生(インタビュー当時)。scoutyを通じて2017年9月よりエウレカインターンとして入社し、2018年4月に新卒社員として正社員登用。Pairs JPの UI / UXの開発を行う。

ーーーーーーーーーーーーーー

scoutyを通して中途採用でエンジニアを採用するケースが多い中、株式会社エウレカではエンジニアの新卒採用に成功しました。今回の記事では株式会社エウレカでエンジニア採用を担当している梶原成親さんと、scoutyを通してインターン入社から正社員として登用された鈴木裕太朗さんにインタビューしました。

積極的にアウトプットしていく姿勢がエウレカにぴったりだった

ー 鈴木さんがエウレカさんからスカウトメールを受け取った時は学生だったと思うのですが、学生でも企業からのスカウトメールを受け取ることは多いですか?

(鈴木さん)採用サービスを通してスカウトメールが来ることはありますね。でも、scoutyを通して送られてきたエウレカからのスカウトメールは他のスカウトメールとは違って、自分が作ったアプリの中身を見てちゃんと評価してもらっていることが文面から伝わってきたんです。前々からエウレカのCTOである金子さんの話には共感していたし、イベントでお会いしたエウレカの社員の方とお話ししたこともあり、面白そうな会社だなと思っていたため話を聞いてみることにしました。

f:id:scouty:20180502152104j:plain

 

ー 梶原さんが鈴木さんをスカウトしたいと思ったポイントはどんなところでしたか?

(梶原さん)自ら発信しているスタンスがいいなと思いました。彼は、GitHubに自分が作ったAndroidアプリを公開していたんです。そのアプリを見てみて筋が良いと感じたこともありますが、何よりも自分で積極的にアウトプットしているところがエウレカのカルチャーにマッチしそうだなと思ってスカウトメールを送りました。

インターンシップの場合、まだ学生なので技術的にものすごく差がついているということは多くないので、エンジニアとしてのスタンスがアウトプットを重視するエウレカのスタンスとマッチしているかどうかを重要視しています。そういう意味では、scoutyのサービスは、アウトプットしている情報が可視化できるということがエウレカの採用方針にマッチしているんです。

 

ー 面談ではどんなことを話されたんですか?

(鈴木さん)自分が作ったアプリや過去のインターン経験について話しました。工夫したポイントや実装など、詳しく聞いていただけて、その場でフィードバックももらえたので、勉強になってすごく良い面談だと感じました。合計で3回の面接を経て、技術だけじゃなくて、エウレカの考え方、自分自身の考え方などについてじっくりと話をして、ここなら自分が成長できる環境だなと思えたので、インターンとして入社することに決めました。

 

(梶原さん)インターンの面談で注目しているのは成長意欲が強いかどうかですね。インターンしてもらうからには、成長できる環境を提供してあげたいという思いを強く持っています。もちろん私たちも時間をかけますので、キャリアプランを持っているか、ちゃんと目的を持ってインターンに参加してくれる方なのか、業務にちゃんとついて来てくれるのかをじっくり確認していきます。また、せっかくご縁があって一緒に時間を過ごす仲間なので、その先には相互の合意があれば新卒として歓迎したいという思いもあります。そういった背景もあり、エウレカのエンジニアのインターン合格率は16.7%という狭き門になっています。

 

ー 実際にインターンとして入社して、エウレカさんでの働く環境はどうでしたか? 

(鈴木さん)今までのインターンで関わっていたサービスよりも大規模な開発を行っていると感じています。過去のインターンではAndroidエンジニアが自分だけだったので、独学独流で開発を行っていました。もちろんそれはそれで成長できたのですが、今は先輩がいるので比較することで初めて「自分はまだまだ基礎が足りていない」ということがわかりました。また、自分で発信して動いていくというエウレカのスタイルが自分にすごく合っていますね。エウレカインターンシップでも発言することが自由な環境なので、発信していくことが好きな自分としては楽しいです。自分とスタンスが合う会社からスカウトがもらえたのは、今はとても良かったと感じています。


ー そこから正社員になったのは、やはりインターンとして働くうちにエウレカの魅力に気づいたからですか?

 (鈴木さん)そうですね。インターンとして働く中で、どういう風にプロジェクトが動いているのか、どんな開発スタイルなのかということを知ることができたので、正社員としてエウレカにジョインした時のイメージが沸いてきました。9月からインターンを始めたんですが、3ヶ月が過ぎた12月頃に正社員で働くことを考え始めましたね。
私の考えの中に「行動している人だけを信用する」というものがあります。エウレカにはエンジニアイベントへの登壇やブログ発信、個人プロジェクトを進めているなど行動を起こしている人が多くいます。そういった優秀なエンジニアがいるエウレカで働くことが成長に繋がると感じました。 

f:id:scouty:20180502152254j:plain

scoutyのメールを初めて見た時「これは何だ!」と驚きました 

ー scoutyのことはどのように知ったんですか?

(梶原さん)実は、過去にエウレカのエンジニアがscoutyからスカウトを受け取っていて、実際に送られてきたスカウトメールを見せてもらってscoutyを導入しようと決めました。
私自身もいろいろな採用サービスからスカウトメールを受けることがあったんですが、もっと情報を調べたらわかるのに、調べもせずテンプレートのような文章で送られてくるものが多くて、質が悪いなと思っていたんです。scoutyは「GitHubのこういうレポジトリを拝見してこう感じた、こういう点に興味を持った」と具体的に書いてあったので、初めて見た時に「これは何だ!」と驚きましたね(笑)。個人が発信しているアウトプットをちゃんと見てくれるサービスは面白いなと思い、その日のうちにサービスの内容を調べて導入を決めましたね。

 

—実際にscoutyのサービスを使ってみて、どんなところが良かったですか?

(梶原さん)一番良いのは、情報をギャザリングしてくれるところです。scoutyを使う以前からSNSの情報を検索してからスカウトをするようにしていたんですが、とても時間がかかっていました。その作業を自動化してくれているのはとても助かりますね。また、これはscoutyのシステムに関することではないですが、スカウトに関する疑問や改善ポイントに対してアドバイスをもらえるサポート体制も嬉しいですね。サービスを活用していく中で気づいた問題についても意見を伝えやすいですし、一緒になって最適な対応を考えてくれるんです。例えば、「スカウトメールの件名を効果的に変えたい」といった相談に対しても、「統計的には、こういう情報を入れるとスカウトの返信率が良くなる傾向がある」など明確に返してくれるんです。

 

f:id:scouty:20180502152436j:plain 

—スカウトメールを送るまでの流れについて教えていただけますか?

(梶原さん)スカウトメールを送るときには、まずCTO室でscouty上での検索条件を整えて、求めるエンジニアの母集団を抽出します。その後、現場エンジニアにそれぞれの候補者を見てもらい、特にマッチする候補者をピックアップしてもらいます。スカウトメールの細かい文章執筆はCTO室で担当していますが、実際の面談は現場エンジニアが担当するという流れです。ここはまだ試行錯誤ですが、せっかくスカウトしたのだからスカウトにきちんと責任を持つというか、「会いたい」と言ったエンジニア本人がきちんとお会いさせていただくというように一貫性を持たせるようにしています。現場と協働関係を築いて一緒になってやっていくのが大切だと感じますね。 

「発言は責務」エンジニアのアウトプットを推奨するエウレカの文化

エウレカではアウトプットを大切にされているように感じますが、それはなぜなんですか?

(梶原さん)エウレカには「発言は責務である」という行動規範があります。私自身も常々アウトプットが大事という話をよくしています。「アウトプットしよう!」と言うと、すごいエキスパートしかアウトプットできないと思うかもしれません。でも自分が持ってるノウハウの価値は、受け取った人が判断します。インターネットの世界にはいろいろなスキルレベルの人がいるんです。勉強し始めたエンジニアのアウトプットはエキスパートの方にとっては参考にならないかもしれない。でも、自分と同じくらいのスキルレベルの誰かの刺激にはなるはずです。インターネットを通じて誰かが誰かの課題を解決していく、こうやって世の中が良い方に進んでいくんだと思っています。

エウレカではLTイベントを毎月開催しています。エンジニアがアウトプットする機会はまだ多くないので、気軽にアウトプットできる場を作ろうと思いました。社内のエンジニアはそこでスピーカーとしてアウトプットを重ねています。

 

(鈴木さん)エウレカではインターンでも社員と同じように当事者意識と発言を求められます。インターンであっても発言が的を射ているようならば採用されることももちろんあります。例えば、インターン入社当初はプロジェクトの進め方は言葉でしか示されておらず、イメージしずらかったんです。それについて私が発言したら、デザイナーがモックを用意してからプロジェクトを進めるようになりました。イメージがつくようになって、手戻りが減り、結果として実装しやすくなりましたね。

もちろん、自分の意見が論理的ではないときには指摘されることがあります。それでも、“発言”を責務として、その発言をフラットに受け入れる環境がエウレカにはありますね。

 

エウレカさんで働くことの魅力を教えていただけますか?

(梶原さん)我々が開発・運営している「Pairs」は、日本をはじめアジア全体に健全なデーティングサービスの文化を広げ、ひとりでも多くの人が自分の望む人生を手に入れることができる社会をつくっていくことを目指す、社会性が高いサービスです。そのように、自分たちが生み出すサービスが、誰かの人生に与える影響力が大きいというのは魅力のひとつです。また、エンジニアに対する文化を、今まさにみんなでつくり上げているということですね。それに伴い、必要であれば制度もどんどん変えていけばいいと思っているし、今後はハッカソンをはじめもっとみんなで考えて、みんなで作っていくものをどんどん増やしていきたいですね!



【イベントレポート】scouty ✕ Goodpatch Engineer MeetUp vol.1 〜プロダクト開発との関わり方〜

f:id:scouty:20180426111936j:plain

2018年4月12日にscoutyとGoodpatchが「scouty ✕ Goodpatch Engineer MeetUp」を共催しました。

イベントでは「プロダクト開発へのエンジニアの関わり方」と「エンジニア組織について」という2つのテーマに沿って、scouty代表の島田 寛基、リードエンジニアの伊藤 勝梧、GoodpatchのCTOひらい さだあきさんによるトークセッションを行いました。また、モデレーターには両社と関わりがある及川卓也さんに務めていただきました。
本記事ではイベントの前半セッション「プロダクト開発へのエンジニアの関わり方」の一部について、編集を行いご紹介しています。

《プロフィール》

株式会社scouty 代表取締役 島田 寛基

2015年、京都大学で計算機科学の学士号を取得。大学時代にはグーグル(日本法人)でインターンシップのほか、Incubate Fundにてさまざまなスタートアップ企業でのテック面での支援を経験。2016年、イギリスのエディンバラ大学(The University of Edinburgh)大学院で修士号MSc in Artificial Intelligence」を取得。2016年、日本初のAIヘッドハンティングサービスを運営する株式会社scoutyを創業。

 

株式会社グッドパッチ 執行役員 CTO & Vice President of Product ひらい さだあき

2015年1月にGoodpatch入社、2015年12月にCTOに就任。 これまではSIerJavaを使った開発やLinuxのインフラ構築などを経験し、前職の食べログではインターネット予約サービスの開発(Rails/JavaScript)にエンジニアとして携わりました。

Goodpatch入社後は、プロトタイピングツールProttのエンジニアリーダーとしてプロジェクトマネージメント、チームビルディング、プログラミング(Ruby/Rails/JavaScript)、パフォーマンスチューニングなどを行ってきました。CTOとしてエンジニアリング組織作り、エンジニアリング評価制度策定、技術選定、環境整備、エンジニア採用などを行っています。 現在はVice President of Product(プロダクト責任者)として、Prottのプロダクト開発を推進し、事業目標達成に向けて取り組んでいます。

プライベートではhtml5jというコミュニティのスタッフとして活動し、執筆/登壇活動を行っています。 フォントが好きで、FontLoversというFacebookグループを友人と立ち上げ、フォントに関するイベントなどを開催しています。好きなフォントは秀英体Optimaです。

 

株式会社グッドパッチ プロダクト&テクノロジー アドバイザリーボード メンバー 及川卓也

早稲田大学理工学部を卒業後、日本DECに就職。営業サポート、ソフトウエア開発、研究開発に従事し、1997年からはマイクロソフトWindows製品の開発に携わる。2006年以降は、GoogleにてWeb検索のプロダクトマネジメントChromeのエンジニアリングマネジメントなどを行う。その後、Incrementsを経て、独立。現在、企業へ技術戦略、製品戦略、組織づくりのアドバイスを行う。
技術系イベントなどで新しい技術に触れるのを趣味としており、登壇することも多い。Google Developers DayやDevelopers Summitデブサミ)、HTML5 Conferenceなどでの登壇が代表例。

プロトタイピング前のユーザーインタビューで「その機能が本当に必要なのか」を検証

(及川さん)それでは1つ目のテーマの「プロダクト開発でのエンジニアの関わり方」について、このテーマを選んだ背景をお二人にお聞きしたいです。なぜこのテーマが良かったのか、あるいは自社にどういう課題があったりどういう取り組みをされているのかお話いただけますか。

 

(島田)昔のプロダクト開発は、ウォーターフォール型で仕様設計から単純に需要がおりてきてエンジニアが実装するという形だったのですが、最近はアジャイルの方法などが生まれています。クラフト開発において、仕様設計の部分にもエンジニアがディープに関わっていくといったやり方が主流になっていく潮流の中で、現在scoutyでは正式リリースに合わせて仕様設計のプロセスを見直して、社員全員を巻き込んで良いプロダクトを作るということを行っています。その際に使った手法や知見があったのでこういったテーマにしました。

 

(ひらいさん)Goodpatchにはデザインプロセスというものがあります。最初はUIデザイナーやUXデザイナーがユーザー体験から考え始めて、エンジニアがそれをどうやって作っていくかというプロセスがプロダクト開発の大きなテーマです。そのプロセスについてGoodpatchでは工夫しながらプロダクトの開発をしていますので、そういった点についてお話しさせていただきたいと思っています。

 

(及川さん)それでは「仕様」からスタートするのがいいですね。仕様って何を作るかがある程度決まった後にそれを細かく設計していくじゃないですか。そもそも、何を作るかという起点についてどのようにして決めていらっしゃるんですか?

 

(島田)scoutyには創業期の試作品みたいなものがあって、それを実際に運用していく中で色々な課題が見えてきました。「サービスとしてスケールしていくのか」とか「企業の採用担当者に継続して使ってもらえるのか」などですね。そういった課題が明確にあったので、それをどうやって解決してくかというところを考え、どういう仕様が良いのかを探していったという順番ですね。

 

(及川さん)課題ベースですでにサービスはできていて、ユーザーの不満だとか改善点にすべきものが見えてきたことで作るべきものがある程度決まっていたということですね。ひらいさんはどうですか?


 

(ひらいさん)新しい機能を作るときと、既存の機能を改修する時でちょっと変わってくるんですが、新しい機能を作る際には、元々フィードバックとかは無くて「こういう機能が必要じゃないか」ということを考えて作っていきます。
最初に「こういう機能が必要じゃないか」というアイデアが出てきた時には、まずはプロトタイピングをする手前でユーザーインタビューなどを行って、実際に何人かの声を聞いたりして「その機能が本当に必要なのか」と考えるところから始めます。

既存機能の改修の際は島田さんがおっしゃったようにフィードバックを基にしています。「使いにくい」「こういうのがあったほうが良い」みたいな声があるので、そういったところはユーザーインタビューやユーザーテストをしながら、どういう風に改修していくのかということを検討しています。

 

(及川さん)ユーザーインタビューって結構テクニックが必要だなと、私は経験からそう思っています。インセンティブとしてユーザーに謝礼を渡すと、出来るだけその会社のために何か考えようと思って自分が本当に思っていることとは違うことを答えてしまうんです。Goodpatchにはユーザーインタビュー時のテクニックはありますか?

 

(ひらいさん)Goodpatchが提供しているプロトタイピングツールの「Prott」は社内でも使っているので、毎週社内向けにユーザーインタビューをしています。インタビューする側はUXデザイナーやエンジニアが一緒に行います。どちらかというと「この辺が使いづらい」といった厳しい声が集まります。社内の人が必ずしもサービスのペルソナに合致するわけではないんですけれども、社内の人だとプロダクトに対して厳しい目で見てくれるので、そういった意見を集めた上で社外の人にもインタビューして両方の目線から確認しています。

 

(及川さん)まずは自分たちが作るものであるならば「本当に使うか」という観点で確認していくのが良いのかなと思いますね。scoutyの仕様設計については資料を使って説明していただけますか?

f:id:scouty:20180426113304p:plain

(島田)前提として、機能を作るときと製品そのものを作るときで仕様設計のプロセスは違います。このスライドは製品を作るプロセスだと思ってください。創業時には開発を行うのが私だけだったので、ユーザーインタビューを行う余裕はなく、とにかく思いついたものを作っていました。それだと市場の課題を把握したうえでの仕様にはならないため、後になってからリニューアルしてちゃんとしたプロセスで作り直すということをしました。

最初のプロセスとしてPRD(Product Requirements Document = 製品要求仕様書)を作ることから始めたんですが、ここが一番時間のかかるところでした。scoutyのサービスを実際に運用するのはクライアント企業の中でも人事担当者なのかエンジニアなのか、その場合にどういうところが大事なのか、というところを細かく決めていきました。
また、どういうソリューションになるかはわからないけれどとりあえず解決したい課題を書き出していきましたね。この段階では十分にユーザーインタビューを行いました。この一連の流れに数ヶ月ほどかかって、そこからPM(プロジェクトマネージャー)としてワイヤーフレームを手書きで作りました。

作ったワイヤーフレームをデザイナーに渡し、Adobe XDのようなツールでプロトタイプを作ります。この段階でスライド内に記載のある3と4をグルグル回すんですが、一度プロトタイプを作ったら社内で叩いて修正を出します。
scoutyでは、slackでチャンネルを作って、エンジニアもビジネスサイドの人間も含めて全員でとにかく2、30分触ってもらって思いついたことをコメントしてもらうようにしています。「こうしてほしい」という要望よりも「これが使いにくい」とか「これはなんのためにあるの?」みたいな指摘をもらうように意識付けしていますね。このタイミングでエンジニアからも鋭い指摘が出てくることが多くあります。考慮漏れがバンバン出てくるので、出てきた意見を基に作り直すし、これを繰り返します。だんだんと新しい意見が出なくなってくるので、これでいいなと思ったら一旦FIXします。

社内で意見出しを行っていると議論が巻き起こり、誰が言っていることが正しいのかが分からなくなったりします。そういうときは1でヒアリングしてたお客さんに再度ヒアリングしています。聞き方にも注意しています。「これどう思いますか?」と聞くよりも、「AとBどっちがいいか」などとちゃんと仮説を明確にして聞くということが大事かなと思いますね。その意見を反映したプロトタイプができたら「これって本当にお金を払って使いたいですか?」というようにさらにヒアリングしています。

 

この段階でようやく仕様がFIXします。ここまでは基本的に開発を進めないで、これが終わったら実際にマークアップをしていきます。UIについてもここで全部作り、適宜お客さんにヒアリングしていますね。ある意味では、この工程で出来ているものが最も仕様書に近く、それを基にエンジニアが作るというように開発を行っています。

 

f:id:scouty:20180426112235j:plain


(及川さん)ひらいさんはscoutyの仕様設計についてどう思いますか?

 

(ひらいさん)Goodpatchも近しい形で開発しています。似ているところがかなり多いなというふうに感じましたね。

 

(及川さん)Goodpatchってデザインスプリントをやってるじゃないですか。デザインスプリントは、Googleが開発した5日間でMVP(Minimum Viable Product)を作る手法なんですけれども、デザインスプリントとscoutyさんのやり方は若干違いますよね。

 

(ひらいさん)デザインスプリントの話をすると、デザインスプリントは元Google Venturesが提唱したプログラムで、基本的に5日間で構成されていて、「理解」「発散」「決定」「プロトタイピング」「検証」を行います。実施期間は5日間なんですけれども、準備には2週間くらいかかったりするので、1回のデザインスプリントをやるのに3週間から4週間かかります。
たった5日間なのでアプリケーションのすべての機能を検証することはできません。なので最初にデザインスプリントをするときは、作りたいアプリケーションのコアな部分に絞ります。そのコアな機能1つについて、ユーザーインタビューをしたりだとか、データ分析や競合の調査をしたり、要件定義をします。そのあとに発散を行います。ブレインストーミングのような形でアイデア出しなどを行って、ストーリーボードというどういったプロセスでユーザーがサービスを使っていくかというところを詰めていったりします。
2日目で発散させたところを3日目で収束させていきます。3日目ではどういった機能が必要なのかを絞っていってワイヤーフレームを作っていきます。4日目はデザイナーが一番大変な日になるんですが、1日でUIデザインとプロトタイプを作ります。そして5日目はそのプロトタイプを使って価値の検証を行う。これがデザインスプリントのプロセスです。

 

今お話したのはあくまでものづくりをする一歩手前だったりするんですよね。仕様もガチガチに決めるというわけではなくて、デザインスプリントを何回か繰り返していくことで機能をよりクリアにしていきます。また、このデザインスプリントを通じて認識を合わせていくということが一番大事だったりします。なので、デザインスプリントとは仕様を詰めていくものなんですが、それよりもメンバーの認識をしっかり合わせて一つの方向に向いていくということが一番大事だと思います。

全エンジニアがユーザーヒアリングを行うのがscoutyのプロダクト開発

f:id:scouty:20180426112402j:plain

(及川さん)それではユーザーテストの重要性と手法についてお話を伺いましょう。scoutyではどのようにやっているのか教えていただけますか?

 

(島田)ユーザーテストは、社内で生まれた仮説や議論の対立について聞いてみるという仮説検証や疑問解決の機会として活用しています。ユーザーテストがないとあたりをつけただけのプロダクト開発になってしまうので、とても重要だと思います。
scoutyのケースでいうと、ビジネスサイドがクライアントの元に訪問してサポートをすることが多くありますので、私もそこについていって実際にクライアントがプロダクトを使っている様子を観察して、用意してある質問を行っていきます。scoutyの社内では、クライアントがscoutyを運用するうえでどこに時間がかかってしまっているか議論をして意見が割れることもあったのですが、実際にユーザーテストを行った結果「ここは思ったよりも工数がかかっていない」「サービスのネックにはなっていない」ということがわかりました。

 

(及川さん)なるほど。ちなみに島田さんご自身はプロダクトマネージャーとしてプロダクト開発を主導していらっしゃると思うんですが、今日のテーマは「プロダクト開発へのエンジニアの関わり方」ですので、他のエンジニアの方がどのように関わっていらっしゃるかについてもお聞かせいただけますか?

 

(島田)いくつかあるのですが、例えば私以外にもエンジニアはクライアントの元に伺ってお話を聞くようにしています。エンジニア各々からもクライアントからのヒアリングを通したフィードバックをあげるようにしています。

 

(及川さん)エンジニアの中には客先に行きたくない、という人もいると思うんですがscoutyにはそういうエンジニアはいないんですか?

 

(島田)もちろんずっと通うことはしていませんが、必ず1回はクライアントのところに行くようにしていますね。scoutyにはサービスに関心があるエンジニアが多く、技術だけというよりはサービス・ビジネスに関心がある人の方がカルチャーフィットもしますね。

 

(及川さん)ありがとうございます。Goodpatchはどうですか?

 

(ひらいさん) Goodpatchも、エンジニアもユーザーインタビューに参加しています。私たちはデザインの会社ということもありエンジニアもデザインのことが好きで、UXを学びたいと思っていることが多いです。UXデザイナーがどうインタビューしているかなどを知りたい、また実際にユーザーがどう使っているか知りたいというモチベーションでユーザーインタビューに参加していますね。

 

(及川さん)それは、サーバサイドの方でもそうなんですか?

 

(ひらいさん)そうですね。UXに興味を持っている人は多いですし、パフォーマンスはサーバサイドエンジニアがチューニングする部分なので、実際にクライアントが使っている時に重そうな部分が見つかればユーザー視点を意識して改善する場合あります。そういった意味でも、実際にどうやって使っているかを見ることは重要だと考えています。具体的には、Goodpatch Blogにいくつかまとめています。


ユーザーインタビューは慣れていないと気をつけなくてはいけないことも多く、どのようにインタビューを行うと効果的なのか、どう進めると失敗してしまうのかということをナレッジを蓄積しています。また、ユーザーからのフィードバックはあくまでフィードバックなので、それを実際にプロダクトに反映させていくのかは別途判断するものだと考えています。
例えばProttにおいては「ラピッドプロトタイピング」という素早くプロトタイピングができてわかりやすいツールであるということが重要です。なのでユーザーから、他社のプロトタイピングツールである「Abobe XD」や「InVison」にはこの機能があるからProttにも欲しいと言われても、それがProttにあるべき機能なのかはまた別の話なんです。

バイアスを外すということが重要だと考えています。社内でユーザーインタビューを行うと、リテラシーが高く、プロトタイピングツールも使い慣れています。そういった社員にインタビューする時とクライアントにインタビューする時では前提が異なります。なので、社内だけでなくクライアントにインタビューすることが大事です。

 

f:id:scouty:20180426113003p:plain

あと、知りたいことについてですが、(スライドを見ながら)、この小さいところは知っていること、把握できている知らないこと、あとは把握できていない知っていること、把握できていない知らないことという様に分かれています。
クライアントが本当にほしいものは自分たちでは把握できていない知らないこともあるので、バイアスを外すことを大事にしています。

バイアスに気づくには、フィールドワークをおこなったりして、いろんな人がいることに気づくことが重要かと思います。インタビュー内容に自分でも答えてみたり、状況を設定して、自分が無意識にやっていることに気づく。例えば、コンビニに行く時にお財布を持っている人もいればiPhoneで支払いするのでお財布を持たない人もいます。この会場にいる人とご年配の方、若い方では行動が違うこともあるかと思います。

 

f:id:scouty:20180426112627j:plain

(及川さん)ありがとうございます。少し踏み込んだ質問なんですが本日参加されている方々の所属企業でもプロジェクトマネージャーが職種として存在しないということもあるかと思います。その体制で積極的にユーザーテストをしていこうと思った場合、デザインをGoodpatchに頼むようにユーザーテストも外部に頼むのがいいのか、社内で誰かに頼んだ方がいいのか、最初はどういう風に進めるといいと思いますか?

 

(ひらいさん)そうですね……Goodpatchに頼んでほしいなとは思います(笑)。ただ、自社でできることは多いと思いますよ。そもそもユーザーテストの必要性に気づいていない場合は外注するかどうかという発想にもならないはずです。ユーザーテストなどをやらないとプロダクトが良くならないと思っている人がいるなら、まずはユーザーテストに興味を持った人たちで始めていくのがよいかなと思います。ユーザーテストに関する記事や書籍が多くありますのでそのあたりを読んで、社内の人や自分の家族でも良いのでインタビューなど、何かできることがないか考えて始めていくのが良いかと思います。

 

ーーーーーーーーーーーーーー

 

紹介したその他のブログなどはTwitter上で #scouty_goodpatch_meetup と検索いただくとご覧いただけます。後半のセッション「エンジニア組織について」についても追ってレポートを公開いたします。

アウトプットの可視化で実現した、純粋な能力を基にした採用! Misocaのscoutyのスカウトメール執筆術

f:id:scouty:20180423114528j:plain

《プロフィール》

 濱口 美保さん:(写真右)
大学卒業後、転職エージェントにてキャリアコンサルタントとして求職者の転職支援に従事。その後、通信会社の採用担当を経て、社会保険労務士を取得し、Misocaにジョイン。Misocaでは、採用、制度設計、広報を担当している。

 

土屋 貴裕さん:(写真左)
大学院卒業後、大手自動車部品メーカー・SIerを経てMisocaにジョイン。Misocaでは主に受発注機能のサーバーサイド、フロントエンドの開発を担当する傍ら、採用のサポートを行っている。

 

株式会社Misoca:
Web上で簡単に請求書を作成し、郵送まで出来るクラウド型の請求書発行・管理サービス「Misoca」の開発・運営。
リモートワークを積極的に取り入れるなど、パフォーマンス重視の自由度の高い働き方を推奨している。
2016年に会計ソフト「弥生」のグループ会社となり、現在もスタートアップのスピード感を大切にしながら「取引のプラットフォーム」を実現すべく躍進中。

f:id:scouty:20180423114034j:plain

今回の記事では、scoutyを導入し、エンジニアの採用に成功した株式会社Misocaでエンジニア採用を担当している濱口美保さんと土屋貴裕さんに、スカウトメールを書くうえで気にしているポイントやscoutyの活用方法についてインタビューしました。

候補者のGitHubやブログなどを細かくを見ながら1件1件スカウトメールを書いている

ー Misocaさんでは普段どのようにscoutyを活用しているんですか?

(土屋さん)現在、週に5時間ほどscoutyに時間を割いてスカウトメールを執筆、送信しています。scouty上で候補者のGitHubやブログなどを細かくを見ながら1件1件スカウトメールを書いているので時間がかかりますが、月に30名くらいの候補者にスカウトメールを送信していますね。
運用体制としては、1人の担当者が候補者のピックアップからスカウトメール送信まで一貫してスカウト業務を行います。他の企業では候補者をピックアップする人とメールを執筆する人を分けていることもあるようですが、候補者をピックアップするときにはscouty上でかなり細部に渡ってその方の情報を見ているので、メールの執筆まで1人で完結した方が効率が良いと考えています。
scoutyにはGitHubやQiita、SNSやブログの情報がわかりやすくまとまっているので候補者のスキルも判断しやすいです。

(濱口さん)scoutyを通して最近Misocaにジョインしてくれたエンジニアは、scoutyでなければ採用できていなかったと思います。scouty上でGitHubなどのアウトプットをみたところ高いスキルを持っていると分かったのでスカウトメールを送ったのですが、やりとりをするうちに2年目のエンジニアだということがわかりました。年齢だけで合否を判断することはありませんが、他の求人媒体だと、年齢からある程度、業務での実務経験を推測して、スクリーニングしてから候補となる方を探すことが多いので、スキルのみに集中して見ることができるscoutyでなければ出会えなかった人材だなと思います。
彼はとても2年目だとは思えない能力をもっていました。社会人としては2年目だったのですが、学生時代にがっつりと開発をした経験があったので、エンジニアとしては6年くらいの経験がありました。面談で話をしてみると、エンジニアとしてのスキルのみならず、視野の広い思考性の持ち主で、非常に魅力的な人材でした。
scoutyを通すことで純粋に能力を基にした採用ができたという良い体験でした。

 

Misocaの文化に合わせた、ゆるくてリスペクトが伝わるメール

ー 時間をかけてスカウトメールを書かれているようですが、メールの執筆時に気をつけていることはありますか?

(土屋さん)全体のメール文章を通して、堅苦しくならないよう意識して書いています。Misocaの文化はゆるいので(笑)、そもそもガチガチに固いメールを要求するエンジニアの方とは文化が合わない可能性があると考えています。イメージでいえば、TwitterのDMくらいのゆるい感覚で書きますね。ゆるいと言っても、テキトーではなくて、候補者の方へのリスペクトの気持ちがちゃんと伝わるように執筆していますよ。
候補者の方の名前もTwitterなどのハンドルネームがあれば、本名ではなくハンドルネームを使うようにしています。Misocaの社内でもTwitterのハンドルネームをそのまま使っている人もいて、スカウトメールでもMisocaの文化に合わせて文章を書いています。私はほとんど本名で呼ばれていませんね(笑)あとは、転職活動をしなくても一度話してみたいということもメール内で伝えますね。

 

f:id:scouty:20180423114602j:plain 
ー 転職する気がない候補者とも面談するんですか?
(濱口さん)はい。実際に、転職を検討していないといおっしゃる方とも面談していますよ。転職の意志がないからといって面談や情報交換を拒むような文化はMisocaにはないですね。
技術力が高い人と話すことは単純に楽しいですし、Misocaの技術レベルや文化を知ってもらういい機会にもなります。現時点で転職する気がなくても、その方がキャリアの分岐点に差し掛かった時にMisocaのことを思い出していただけたら嬉しいですし、その方の周りの人たちにも、もしかしたらMisocaのことが伝わるかもしれない。そう考えて、面談を実施しています。直接的な採用活動というよりもブランディングの意味合いの方が強いですね。
手前味噌になりますが、Misocaには人としてもエンジニアとしても魅力的なメンバーが集まっているので、最初は転職する気持ちはなかった方が、面談や会社見学を通して、Misocaに共感してジョインするというケースもこれまでにあります。実際に今回scoutyを通して入社したエンジニアは、当初、転職の意志はなかったんです。最初は、代表の豊吉と私とで話をしたのですが、その後、会社見学にお誘いして遊びにきてもらいました。「社長と人事担当が話していることが真実なのか確かめにきてくださいよ」って(笑)。その後も何度か意見交換を重ねていくうちに、キャリア形成の場として弊社を選択してくれ、入社に至りました。
そういった実例もありますので、最初から転職の希望がなくてもまずはお話するようにしています。


ー scoutyを使ううえで大変なことはありますか?

(土屋さん)1通1通メールを書くのはやはり時間がかかりますね。1通10分くらいで書けることもあるのですが、候補者の方によってメールを書くために必要な時間も変わってきます。先日送信したスカウトメールは、1通書くのに30分くらいかけてしまいました。あと、書いたメールに返事がないと、少し悲しい気持ちにはなります。出来る限りメールの数を減らしたいので、候補者を選ぶ段階に力を入れていますね。ここが一番大変です。 技術的・文化的なフックが少なくて文章をひねりださざるを負えないのは、そもそものマッチ度が低いと考えるのが自然なので、Github、Qiita、TwitterFacebook、個人ブログなどのあらゆる情報を駆使して選定しています。
技術的な側面でいうと、弊社が採用している言語、フレームワーク、ツール周辺のライブラリに関してコントリビュートしている場合は、書きやすいですね。コミットの中身までちゃんと読んでます。
文化や働き方の側面でいうと、現在リモートワーカーだったり、地方で頑張っていたり、出身が現在のMisocaのオフィスが存在する愛知近隣、島根近隣だったりすると、書きやすいですね。最近の例で言うと、技術書典という技術系同人誌のイベントに私も含めて弊社から3サークル出展したんですが、そのような個人で参加したイベントにも触れたりします。
あと、実際の開発業務の隙間にスカウトメールを書こうとすると、使う頭の入れ替えで疲れちゃうので、今では「集中スカウトタイム」という時間を確保して、もうひとりのエンジニアと一緒にワイワイ書くようにしています。色んな視点がリアルタイムに共有できるので良いですし、さっと文面を見てもらうことができて「本当にこの文章で送って大丈夫だろうか」という不安が低減されるので捗ります。

 

エンジニアが強くなるために考えられた体制と、全社員がリモート勤務できる働きやすさ

ー Misocaさんのエンジニア採用の体制について教えていただけますか?

(濱口さん)採用にフルコミットしているのは私だけで、土屋は週に5時間、「ダイレクトリクルーティング担当」として活動しています。以前は、スカウトタイムを定期的に設けていて、私が「スカウトタイムだよー!」って声かけするとエンジニアのみんなが、オンライン・オフライン両方で集まってくれて、「この人いいね!」とか言いながらワイワイやっていたんです。でも、これらは全てプロジェクト外の活動で、みんなが善意で協力してくれてたもの。やはり担当者を決めたほうが良いよねということになり、現在はダイレクトリクルーティング担当のエンジニアとして土屋がメインで入ってくれています。
初回の面談や面接には、代表の豊吉が必ず入ると私が勝手に決めてまして(笑)、ほとんどのケースは豊吉と私とで実施します。1次選考の後に、技術面接を実施することが多いのですが、その担当エンジニアが5〜6人います。最終面接では、実際に一緒に働く人がどんな人で、どんなスキルの人かを候補者の方にも確認してほしいという思いがあり、1日名古屋にお越しいただいてペアプロやミニプロを実施することにしています(交通費支給です!)その担当が2名です。
scoutyのスカウト候補者のピックアップや、面接などを通してほとんどのエンジニアが何かしらの採用業務に関わっていますね。Misocaのメンバーは皆、採用はもちろん、どんな業務に対しても主体的に動いてスループットをあげることに協力的なのでとても良いチームだと感じています。

 

f:id:scouty:20180423155235j:plain

ー エンジニアチームは具体的にはどんな構成なんですか?

(濱口さん)エンジニアは社員で18人、外部で手伝ってくださっている方が2名の計20名です。基本的には何かしらの「プロジェクト」に属して仕事を進めます。プロジェクトは2週間で終わるものから2ヶ月間以上かかるものまであって、一部機能のリファクタリングのような小さいものから、新規機能実装でペルソナ作成から考えるような大きなものまで様々です。

(土屋さん)ロールも明確には決まっておらず、例えば私はサーバサイドのエンジニアなんですが、基本的にサーバサイドをやりつつ、フロントやインフラもやっています。また、エンジニア全員がスクラムマスターなども行えるようにしています。プロジェクト毎に責任者は決めていますが、実際には責任者が主導でやるのではなく各々意見を出しながらみんなで進めているのがMisocaの開発体制の特徴ですね。
プロジェクトも、会社側がアサインをするのではなく、次のプロジェクトの切り替わりの時に、「みんなどれやりたい?」と訊いて、エンジニアが希望を出してやりたいことをやっています。


(濱口さん)うちの代表の思いとして、「どこでも通用するエンジニアになって欲しい」というものがあります。エンジニアが強くなるためにどういう開発体制がいいのか、必要な制度があるかなどを常に考えて、早いスピードで改善を重ねているのも他社とは違うところかもしれません。


ー Misocaさんはリモート勤務をしている社員が多いんですよね?

(濱口さん)リモート勤務をしている社員が多いというよりも、全社員がリモート勤務可能なんです。居住地の関係でフルリモートで勤務しているのは22人の正社員のうちで8人くらいですね。普段出社している社員でも、雨や雪の日や、インフルエンザが流行っているときなどは出社しなかったりします。
全社員がリモートで勤務することができるのですが、「オフィス」という働く場所があるのでそこに集まっているという認識ですね。
「今日どこで働くのが一番パフォーマンスがいいか」を考えて自分で選択できるのがすごくいいです。

 

f:id:scouty:20180423114728j:plain

リモート勤務制度を運用する上で、回数制限があったり、事前申請が必要だったり、一部の人にしか認められていなかったり……となんらかの制限を設けている企業が一般的ですが、そうすると、リモート勤務している人はマイノリティーな存在になり、仕事を進めにくい状況が多々発生します。Misocaでは、リモート・非リモートでタスクを切り分けることはないですし、役割についても同様です。
リモート勤務制度がなければ、一緒に働けなかったであろう優秀なメンバーとワンチームで一緒に働けていることが嬉しいですね。

 

ありがとうございました!

 

f:id:scouty:20180423114842j:plain

【転職時行動の調査レポート】エンジニアはエンジニア以外の職種と比べて、圧倒的に“友達のつて”で転職活動する

scoutyのマーケティング担当の染谷です。HR TECH LABには初登場ですが、今後も色々と人事の方に役立つ情報を投稿していこうと思っております。

さて、scoutyでは、人工知能機械学習を活用してWeb上のオープンデータを分析することで、エンジニアのスキル・志向性の判定や、転職可能性の予測などを行っています。先日scoutyの転職可能性の予測精度をさらに高めるために、転職活動についてのアンケート調査をご協力いただける方を募って行いました。この調査結果が示唆に富んだものなので、HR TECH LABで紹介させていただきます。

特にエンジニア採用に関わっている人事担当の方には採用施策を考える上でヒントになるのではないかなと思っております。ぜひ、ご一読ください。

実施したアンケートの概要

まずは、今回行ったアンケート調査の概要をお伝えします。今回のアンケート調査は2017/12/27〜2018/2/9の期間にて、転職経験のある254名の方に回答していただきました。うち、エンジニアの方が117名、エンジニア以外の方が137名となっております。回答者の職種の内訳は下のグラフをご覧ください。

f:id:scouty:20180326181304p:plain


※グラフ内の数字は職種ごとの回答者の人数です。

このような皆様に以下のアンケート項目にご回答いただきました。

 

アンケート項目:

項目1:どのような手段で転職活動を行いましたか?(複数選択)

 ・ビズリーチなどの転職サイトに登録した

 ・エージェントに相談した

 ・友達の所属している会社に訪問した

 ・スカウトメールを受けとった(ヘッドハンティングを受けた)

 ・Wantedlyや企業の募集ページで自分から直接応募した

 ・友達に他社の人事担当者を紹介してもらった

 ・企業やエージェントの開催するイベントに行った

 

項目2:転職活動時にした(起こった)覚えがあることをすべてチェックしてください。(複数選択)

 ・Wantedlyを始めた

 ・Wantedlyのプロフィールを変更した

 ・Linkedinを始めた

 ・Linkedinのプロフィールを変更した

 ・Twitterを始めた

 ・Twitterのプロフィールを変更した

 ・キャリア関連のイベントに参加した

 ・興味のある会社のイベントに参加した

 ・新しいことを勉強するようになった

 ・GitHubにレポジトリを一気に上げた

 ・Qiitaの投稿数を増やした

 ・ブログの更新頻度を上げた

 ・ブログで、「転職活動中」ということを示す投稿を自分でした

 ・遅刻が増えた

 ・残業が増えた

 ・残業が減った

 ・リモートワークをする機会が増えた

 ・社内の友達との飲み会やランチの回数が増えた

 ・社外の友達との飲み会やランチの回数が増えた(面談先の企業の関係者は除く)

 ・Twitterでのツイート数が増加した

 ・SNSで、「転職活動中」「転職したい」「仕事辞めたい」「会社が辛い」といった投稿を自分でした

 ・SNSで、プロフィールか名前に転職活動をしていることを示す文字列を含めた

 ・Facebook上で、面接を受けた企業の人事と友達になった

 ・Facebook上で、エージェントの人と友達になった

 ・Facebookでの友達数が急増した

 ・社内のまわりの人が退職していった

 ・会社の業績や株価が下がったり、会社で不祥事が起こった

 

こちらのアンケート結果について、レポートしていきます。

調査結果①:エンジニアはエンジニア以外の職種と比べて、圧倒的に“友達のつて”で転職活動する

まずは一つ目の項目「どのような手段で転職活動を行いましたか?」の回答結果についてご紹介します。

f:id:scouty:20180326183234p:plain
こちらの回答結果を見るとエンジニアはエンジニア以外の職種と比べて、圧倒的に“友達のつて”で転職活動するといえます。グラフの赤枠で囲まれた箇所をご覧ください。転職活動の手段として「友達の所属している会社に訪問した」は、エンジニアの35.59%が実施しているのに比べ、エンジニア以外の職種では13.87%しか実施しておりません。また、「友達に人事担当者を紹介してもらった」はエンジニアの22.03%が実施しているのに比べ、エンジニア以外の職種では11.68%しか実施しておりません。つまり、エンジニアは、友達のつながりを利用して転職活動を実施する割合が、非エンジニアに比べて圧倒的に多いのです。その他の項目ではそれほど差がないことと比べると、歴然とした差が表れています。

この“友達のつて”で転職活動する層をもう少し細かく見ていきましょう。

f:id:scouty:20180326181408p:plain


こちらは、「友達の所属している会社に訪問した」、「友達に人事担当者を紹介してもらった」という“友達のつて”での転職活動を実施しているエンジニアの転職サイト(「ビズリーチなどの転職サイトに登録した」)・エージェント(「エージェントに相談した」)の登録状況をまとめたグラフです。

こちらを見ると転職サイトやエージェントを利用する層も一定数いるものの、”友達のつて”で転職活動を行う41.8%が転職サイトやエージェントといった従来型の転職サービスを利用していないことがわかります。エンジニア採用を行う人事の方からすると、このような層に対しては従来型の転職サイトやエージェントでアプローチができないのでアプローチの仕方を工夫する必要があると言えます。

調査結果②:SNS上の動きをチェックすれば、エンジニアの転職タイミングが見えてくる

続いて、二つ目の項目「転職活動時にした(起こった)覚えがあることをすべてチェックしてください。」の回答結果について見てみましょう。
こちらは項目が多いので、エンジニアの回答のみをご紹介します。

 

f:id:scouty:20180326182901p:plain
目立つのは、「Wantedlyのプロフィールを変更した」(38.14%)、「Wantedlyを始めた」(24.58%)、「Linkedinのプロフィールを変更した」(24.58%)といったSNS上での動きです。特にWantedlyやLinkedinといった転職活動の親和性の高いSNSを始めたり、プロフィールが更新された際は転職活動を始めた兆しになりそうです。

もし、今は転職活動をしていないものの、転職活動を始めたら採用したいと考えているエンジニアの候補者がいる場合は、その方のSNS上の動きをチェックすれば、転職タイミングが見えてくると言えそうです。SNSに関わる回答では、今紹介した項目ほど実施者は少ないものの、「SNSで、「転職活動中」「転職したい」「仕事辞めたい」「会社が辛い」といった投稿を自分でした」という行動を11.86%の方がされているというのも注目に値します。こちらも転職活動開始のサインとなり得ます。

また、「社内のまわりの人が退職していった」(34.75%)も、転職活動開始のシグナルとして活用できる可能性があります。とある会社から転職したエンジニアがいる場合は、その会社の他のエンジニアも転職を検討しているかもしれません。

その他で目立つのは「新しいことを勉強するようになった」(35.59%)、「興味のある会社のイベントに参加した」(27.97%)など、転職活動時のエンジニアは勉強やイベント参加に積極的になるのも特徴です。採用活動の一環としてすでに実施している企業も多いと思いますが、勉強会やイベントは転職活動をしているエンジニアに有効な施策と言えそうです。

まとめ:候補者のSNSの確認と、転職潜在層に向けた施策の実施が重要

ここまで、弊社の実施した転職前行動のアンケートの結果をレポートしてきました。
この調査結果の重要な結論は、エンジニアはエンジニア以外の職種と比べて、圧倒的に“友達のつて”で転職活動するということです。また、そのようなエンジニアの41.8%は転職サイトやエージェントを活用していないということも重要です。

この事実を踏まえると、転職サイトやエージェントを利用する、いわゆる転職顕在層のエンジニアに向けた施策の実施だけでなく、転職サイトやエージェントを利用していない転職潜在層のエンジニアに向けた施策も重要となります。転職潜在層のエンジニア向けの施策も、今すぐの転職を狙う施策はもちろんのこと、中長期的に採用に繋がる施策として、採用したいエンジニアと自社エンジニアとの関係性を作り、採用したいエンジニアが転職を考えた際に自社を頼ってもらえるようにするなど、自社の状況に応じていろんな施策を検討できそうです。
もし、採用したいエンジニアが自社のエンジニアと友達だった、もしくは友達になった場合は、その方のWantedlyやLinkedinなどのSNS上での活動を定期的にチェックすると転職活動のタイミングが見えてくる可能性があります。また、そのようなエンジニアを対象とした勉強会やイベントなどの実施も効果的と言えます。

「scouty」では、GitHubやQiitaなど様々なサイト上でアウトプットを行っているエンジニアをスキルで検索し、その方の転職可能性を確認した上で、自社へのスカウトをメールでお送りすることができます。メールをお送りできる対象は、転職サイトやエージェントへの登録有無を問わない転職潜在層(登録不要)なので、転職顕在層向けの施策はやっているけど転職潜在層向けの施策はまだという企業や、転職潜在層向け施策を強化したい企業には最適なサービスです。
ご興味があれば、こちら(
https://scouty.co.jp/recruiters )からサービス内容の確認や資料請求ができますので、ご覧ください。

 

以上、転職前行動のアンケート結果のレポートでした。皆さんのご参考になれば幸いです。今後もscouty HR TECH LAB では、エンジニア採用に関わる方にとって役に立つ情報を紹介していきますので、よろしくお願いします。

スカウトメールで出会った、今まで知らなかった魅力的な環境 〜サイバーエージェント アドテクスタジオ〜

f:id:scouty:20180305154559j:plain

《プロフィール》

高橋佳那さん(写真左):

 サイバーエージェント入社後、広告プロダクトの営業経験を経てアドテクスタジオ立ち上げから人事を担当。現在はエンジニアを中心とした採用を行っている。

 

阿部任史さん(写真右):

新卒でSIerのインフラエンジニアを経た後、株式会社Mynetに転職し、サーバーサイドエンジニアとしてソーシャルゲーム開発に従事する。その後scoutyを通じて株式会社サイバーエージェントへ入社。

 

サイバーエージェントアドテクスタジオ:

サイバーエージェントグループのデジタルマーケティング領域におけるプロダクト開発に特化したエンジニア組織。日々、小さなチーム/大きな裁量/独自の開発環境でエンジニア主導のプロダクト開発を行っている。シンガポールとUSに海外開発拠点を持つほか、多く大学の研究室との産学連携を積極的に行っている。

f:id:scouty:20180307181405p:plain

 

今回は、scoutyを通してエンジニアの採用に成功した株式会社サイバーエージェント アドテクスタジオのエンジニア採用担当である高橋佳那さんと、scoutyを通して送られたスカウトメールをきっかけにして入社された阿部任史さんにインタビューしました。

Goをどこで使っていたのかは知らなかったし、当時は選考を受けようとは思っていなかった

f:id:scouty:20180305154528j:plain

ー 実際にスカウトメールを受け取った時のことを教えていただけますか?

(阿部さん)これまでも採用サービスを通じてスカウトメールを受け取ることはあったのですがほとんど読んでいなかったです。しかし、scoutyを通して送られてきたアドテクスタジオのメールは自分用にパーソナライズされていたのでしっかり目を通しました。メールの冒頭で「本名が分からなかったのでGitHubの情報を元にして記載しています」というようなことが書いてあったので、他のメールとは違うなとすぐに感じましたね。
実はスカウトメールを開封したのは受信してから少し後になってからでした。そういえばスカウトメールが来ていたな、と思って読んでみたのですが、今思うと実際に転職活動を開始しようと思っていた直前に届いていたので、転職潜在層へのアプローチは出来ていたと思います。
スカウトメールの中では私が以前にやっていたScalaについて言及されていたんですが、メールを受け取った当時はScalaではなくGoをやっていたので「アドテクスタジオでGoを使っているところはありますか」と質問を返信してやりとりが始まり、選考を受けることになりました。

 

ー スカウトメールを受け取る前にはアドテクスタジオの選考を受けようと思っていたんですか?

(阿部さん)同じタイミングで他の企業の選考も受けていたんですが、当初アドテクスタジオは候補に入っていませんでした。他の企業は、転職サイトや企業サイトから応募しましたね。このようにヘッドハンティングされたのはアドテクスタジオだけでした。
アドテクスタジオについては、昔からブログや勉強会などを通じて知っていました。当時はScala関連で観測していたので、そのメージが強く、自分が興味のあったGoの企業とは考えていなかったです。ブログなどでサイバーエージェントでもGoを使っているという話を見たことはあったんですが、サイバーエージェントのサービスが多いこともあって具体的にどのプロダクトでGoを使っているのかは知らなかったです。

 

ー 「今まで知らなかったけど、こんな良い環境があったんだ」という職場を提案してあげることはscoutyがやっていきたいことなので阿部さんのケースは正にモデルケースですね

(阿部さん)私の場合は正にそうですね。
もちろんサイバーエージェントがどこでGoを使っているかはWebなどで調べれば分かるんですが、調べる手間をかけようとは思わなかったですね。世の中でGoを使っているところを自分でひたすら調べていくのは限度があるので、転職の際にも自分の観測範囲内でGoを使っている企業を見ていたという感じですね。

 

働く人間に対しての投資が大きいところがアドテクスタジオの魅力

f:id:scouty:20180305154535j:plainー アドテクスタジオの働く環境について教えていただけますか?

(高橋さん)アドテクスタジオはエンジニアのパフォーマンスの最大化を目指したオフィス設計がされています。気分を変えて仕事ができるソファースペースや集中

 

ルームがあるほか、部署専用のプレゼンテーションルームも設置しています。LT会や勉強会が多く開催されており、社員同士のコミュニケーションや技術共有の促進につながっています。他には2,000冊規模の技術書のライブラリーもあります。
制度として特徴的なのは、大学の研究室と同様に予算をもって少数メンバーにて技術研究を行う「ゼミ制度」や海外カンファレンスの参加などにも注力しています。ゼミ制度では、すぐに業務では活用できないような気になる技術にも手を出せるので中長期的なエンジニアとしてのスキルアップに活かすことができます。最近ですと、量子アルゴリズムやHCIの研究ゼミなどが新しくスタートしています。

 

(阿部さん)僕も勉強会が好きで、勉強会が頻繁に開かれているのは魅力でした。実は選考の中で一回勉強会に参加させていただいたんですが、それも入社を決めるポイントになりました。外部の著名な方が来て、トークをしてくれる機会が多いのも魅力ですね。
選考を受けるまで、僕の中ではサイバーエージェントというとキラキラしたイメージがあったんですが、アドテクスタジオはいい意味でキラキラしてないですし、一緒に働くエンジニアの方も話しやすいですね。開発環境もある程度自由に選べたり、裁量も大きく、手近なものが不自由なく使える環境ですし、働く人間に対しての投資が大きいなと感じました。

 

(高橋さん)勉強会といえば、実は阿部さんに連絡をとったきっかけも、勉強会に数多くご参加されているのはもちろんのこと、「社内ISUCONを開催した話」というブログを拝見したのが大きかったです。うちも技術が大好きなメンバーが多く、組織自体がこういったイベントの企画やそれを浸透させていくことに明るいので、マッチする部分があるかなと思いご連絡をさせていただきました。誰にスカウトを送るか、またどんな内容でメールを送るかは、すべて採用担当者とscoutyの担当の方とで1通1通文章を考えて送っています。

 

ー scoutyの魅力はどんなところだと感じていますか?

(阿部さん)僕個人の考えなんですが、仕事でつまらない思いをしている人って、プライベートではその鬱憤を晴らすように好きなコトをアウトプットしていることが多いと思っています。それを可視化して見つけられる、そして実際の業務に繋げられるというのはエンジニアにとっても嬉しいことだと思います。

 

(高橋さん)転職市場にいない人を見つけることができるところはscoutyにしかない画期的でいいところ。他にもダイレクトリクルーティングのサービスはありますが、サービスに登録しているのは少なくとも温度差はあれど転職に関心がある方なので、転職潜在層でしっかりアウトプットをしている人に巡り会えるのはscoutyの良いところだなと思っています。

 

ー ありがとうございました!

 

【イベントレポート】エンジニア採用成功術! 〜社内エンジニアの巻き込み方と、採用担当者に必要な技術知識〜

f:id:scouty:20180312153521j:plain

scoutyは2018年2月27日にエンジニア採用のノウハウ共有を目的としたイベント「TECH PLAY HR Meetup #2」( https://techplay.jp/event/659494?pw=t6BKIpHt )に共催スポンサーとして参加しました。イベントでは「エンジニア採用成功術!エンジニア採用における最適なコミュニケーションのあり方」というサブテーマに沿って、パネルディスカッション形式でエンジニア採用に携わる2名の採用担当者の方にお話を伺いました。

本記事ではイベントの中で紹介された「現場エンジニアを巻き込んだエンジニア採用の手法」について、編集を行いご紹介しています。

 

f:id:scouty:20180312153609j:plain

《プロフィール》

大月 英照さん(写真右):
Syn.ホールディングス株式会社
人財開発本部 採用・ビジネスパートナー部 部長
工学修士MOT)。学生時代にエンジニアとしてベンチャーを起業。その後エンジニアとして大手SIerにてシステム開発、PMを経験。 さらに大手人材紹介会社にてIT・Web業界向けの法人営業、テクニカルアドバイザーとして従事。 さらにHRとしてはメガベンチャーでエンジニアに特化した人事として採用や教育、広報を担当。途中ベンチャーでの役員経験を経て、現在はKDDIグループのSyn.ホールディングス株式会社にて、新卒採用、中途採用、新卒教育、技術広報、評価、組織開発、働き方改革労務管理ブランディング各種イベントの企画、実施等を行っている。

 

栗林 由季さん(写真左):
freee株式会社
リクルーティングマネージャー
情報通信関連の商社で営業としてキャリアをスタートし、2014年2月にfreeeに入社。社員数20名強の時代からリクルーターとしてfreeeの魅力について情報発信を行う。freeeテニス部部長。

 

エンジニアの協力を得るためには「情報の均一化」が不可欠

- それでは、エンジニア採用における社内エンジニアの巻き込み方というテーマでパネルディスカッションに移っていきましょう。ズバリ先に結論を聞いていきたいと思うんですけれど、社内エンジニアを巻き込む上で重要なところって具体的にどんなところだと思いますか?

 

(大月さん)

最初にちょっと自己紹介させていただくと、私はもともと大手のSIベンダーでエンジニアをしていて、次にリクルートエージェント(現リクルートキャリア)で人材紹介の営業を行い、その後DeNAという会社で技術系の採用やイベント、教育などエンジニアだけに特化したHRをやっていました。なので、HRの経験は実はDeNAと現職が中心なのですが、DeNAのエンジニアさんはとても素晴らしくて、巻き込むまでもなく自分達からやってくれることがすごく多かったので、実はあんまりそこ(エンジニアとのコミュニケーション)に関して苦労した経験とかどうやったらいいかとみたいなことはあんまりありませんでした。あと今の会社もとても協力的なので、そもそもの環境作りは比較的運がよかったところはあると思います。

 

それでも現職では苦労もあって、当初は面接官が自部門の採用じゃなかったりとか、なんで採用するのかわからないところで急に面接にアサインされていたりだとか、面接の研修をされていないとか、面接で何を聞いたらいいのかわからないとか、どこでジャッジしたらいいのかわからない、しかもそれを誰にも聞けないっていう状態が多かったんです。そうなってくると重要なところとしてはやはり情報量の均一化です。HRで持っている情報をどこまで開示していいかってわからないとこがあると思うんですけれども、しっかり必要な情報をタイムリー開示すると言うことが重要かなと思います。

 

- 情報っていうとHRではどんな具体的な情報がありますか?

 

(大月さん)

そうですね、HRの方だと当たり前に持っている該当部門の採用計画だとか、さらに関係のない部門の採用人数などもエンジニアの方にお伝えすると「それであそこ増やしたいんだね」というように納得感が出たりするんですね。それがない中で「ここの採用だけやります。◯◯人です」と伝えて協力させてしまうと辛いのかなと感じています。

 

前提条件というか、なんでやるかというところに疑問が絶対あるはずなので、なんで採用するのか、なんで自部門なのか、なんで自分が面接官なのかなどをしっかり伝えてあげることが大事です。あとはおまけで、HRでしか持っていないような情報を一つ伝えてあげると喜ばれますね。例えばバッティング情報とか、HRで当たり前の情報でも面接してもらうエンジニアの方には絶対新鮮な情報が多いです。

 

- エンジニアでも採用の情報をキャッチアップしていたり、どんどん採用がうまくなっていったりすることもありますよね

 

(大月さん)

そうですね、採用に全然興味ない人は意外といないと思っています。本当に嫌な人は一部いると思うんですけど、その時はさすがにアサインを変えればいいだけです。社内のエンジニア全員が採用するの嫌だっていうこと多分ないと思うんですよ。なのでやっぱり情報開示は大きな問題なので、情報の均一化を行ったことでエンジニアの方とも採用の話がかなりしやすくなりましたね。

 

f:id:scouty:20180312153651j:plain

 

- ありがとうございます。栗林さんも教えていただけますか

 

(栗林さん)

そうですね、私は社員20名くらいの時からfreeeにいるんです。今でこそ100億近い資金調達をしていたりFintech企業なんて言われてfreeeという会社を知っている方も多くなってきたかなと思ってるんですが、20名くらいの頃は雑居ビルに入っていて「freeeってなに?」っていう時代でした。

当時は本当に人が採れない状態があって、かなり苦しい採用だったと思います。エージェントに頼んでも紹介が上がってこないとか、いろんな採用媒体に募集を掲載しても全然応募がこないという状態が続いていました。現場のメンバーも採用の難しさを見て感じてきたと思っています。

待ってもだめなら探しに行くしかないということでダイレクトリクルーティングをはじめました。エンジニア、またエンジニアのみならずすべてのポジションでの採用もこちらから声をかけ入社に至るケースが多くあります。新しいチャレンジをしている採用チームを見てそして採用の難しさも知り現場のエンジニアも「自分たちも一緒に仲間探しをやろう」っていうように、メンバーの方からかなり自発的に動いてきてくれました。

 

その文化はどんどん人が増えても変わらず、昔からいるメンバーみんなが採用に協力的だという背中を見ることによって、freeeには今も優秀なメンバーは自分たちで採用するという文化があるのかなと思います。

 

ただ、必ず新しい情報のアップデートが必要です。「みんなで協力してやろうよとか頑張ろうよ」と言う気合と根性だけだとお互いの理解も深まりません。、数字ドリブンに「このぐらい面接数があるとこのぐらい人が採用できる」「リファーラルの採用決定率」など現場メンバーに伝えた上で採用の協力を得るようにしています。「大体月にこのくらいメンバーが協力すればどのくらい人が採用できる」というくらいまで伝えることでみんな闇雲に採用活動をすることなく協力的になってくれるのではないかと思っています。

あとやはり採用に関わっていただくことが、会社にとってどのくらい重要な事なのかもしっかり伝えていく必要がありますね。

 

f:id:scouty:20180312153723j:plain

 

社内エンジニアに聞くことで技術の知識も現場ニーズの理解も深まっていった

- エンジニア採用を行う上でエンジニアの知識、技術の知識はどこまで必要なのかということは終わりのない問いだと思います。それについてはどうお考えですか?

 

(大月さん)

そうですね、私の場合は元々コンピューターサイエンスを大学院で学んでいる事もあって、社内でも社外でも「エンジニア出身だからだいたいわかるでしょ?w」って言われるんですが、それは大きな間違いです。私がエンジニアをやっていたのはもう10年くらい前の話で、しかも典型的なSIerだったので、当時はRubyも触ったことはなかったですし、Perlも学生時代にちょっとやってた程度でWebの画面くらいしか作ったことはありませんでした。この部分は最近になって勉強しています。あ、でもここまで話しておいてあれなんですが、一方であまり技術スキルは必要ないかなと思っています。これはどの職種でも一緒です。経理担当者ではないので経理の知識も、法務担当者ではないので法務の知識もないのですが、採用はしますよね? それと同じで職種のヒアリングをした時にその候補者が何を言っているのかわかる程度あればいい。共通言語で話せるくらいのところまでは学ぶようにする。が私の答えです。ちなみにキーポイントは想像力と好奇心だと考えていて、この人たちは何に興味を持っているんだろう?とか私達採用担当者がまず想像して、それに興味を持つことが大切です。これはもはやエンジニアという職種に限らず全職種に対して必要かなと思ってます。

 

技術の知識の話に戻ると、学ぶのはキーワードだけでもいいと思っています。何がいまトレンドになっているかくらいはわりと知りやすいと思うんですよ。例えばQAの話がでたら面接でよく「Selenium」の話が出てました。最初は「何だろうこれ?」って思うんですが、わからないので、どんどん調べていくんです。でもWebで調べてわからなかったらエンジニアの方に聞きに行くと、皆さんは基本的に優しいので教えてくれるんですよ。そして、教えてくれたその単語もわからなくてまた調べて持って行くということを繰り返していくことでコミュニケーションが円滑になります。人事が知っておく知識、調べる行為はそのレベルでいいのかなと感じていますね。

 

f:id:scouty:20180312153803j:plain

 

(栗林さん)

私は開発の技術に関しては全然分からないです。ただ、freeeにいるエンジニアメンバーの強みやキャリア、こういう指向性があるということは知っていると思っています。候補者と誰が会えば一番いいんだろう、と考えた時に面談者を選出する必要がありますから、社内のメンバーのことを知るのは人事にとって必要なのではないでしょうか。なので技術判断というところはどうしても力を出すことはできないんですが、採用において面接からのストーリーを作ったり、適切なタイミングで連絡すること、そして未来のfreeeメンバーと長きに渡り関係性を築くことなどプロデューサーみたいな役割もしながら人事として力を発揮したいと思っています。

 

- 技術について全く知らないということは流石にないのかなと思っていまして、実際にはどのくらいの知識をお持ちなんですか?

 

(栗林さん)

うちで使っている言語だったり、フレームワークなどの技術について何を使っているかということまではわかります。
実はスカウトは私が打つんです。なので候補者がどういう経験をしてきたとか、そういうところはレジュメだったり、GitHubをみたりして大まかには分かります。ただやはり始めの頃はわからないことも多く、一緒にレジュメを見たりしながらどういうところが良い、どこがfreeeと合わないか等、エンジニアにガンガン質問していました。、エンジニアメンバーにフィードバックしてもらうことで、いまはfreeeの求めている開発者のスキルについてだいぶ理解が深まったのではないかと思います。

 

f:id:scouty:20180312153906j:plain

 

(大月さん)

私はすべての面接には入れないので、面接フィードバックのシートとかもよく見ることがあります。レジュメを見て、面接結果を見て、分からない言葉が出てくるんですが、分からないことは諦めないっていうこと、あと知ったかぶりをしないということが大切ですね。

 

- 知ったかぶりをしないということは大切ですね。栗林さんはいかがですか?

 

(栗林さん)

知ったかぶりはやらないですね。わからないことはストレートに分からないと言います。freeeの開発組織にどういう人が欲しいのかということ考える時にはうちのエンジニアと話すのが一番いいんじゃないかなと思います。欲しい人材はうちにいる人材だと思っているので、彼らを知ることでどういう人がエンジニアとして優秀なのか、どういう人をうちの会社が求めているのかというのを理解を深めていったのかなと感じています。

 

ーーーーーーーーーーーーーー

 

エンジニア採用において、現場のエンジニアとの協力体制を整える企業が増えています。実際にエンジニア採用に成功している企業の事例を基にして、エンジニア採用の体制づくりに取り組んでみてはいかがでしょうか。

scouty HR TECH LABでは今後もイベントのレポートや、オープンデータを基にした分析結果など採用担当者に有益な情報を紹介していきます!