2021年8月30日
株式会社アルファドライブ 執行役員CTO
赤澤剛
2009年に株式会社ワークスアプリケーションズに入社、ERPパッケージソフトウェアの開発とプロダクトマネジメントに従事。2015年からはシンガポールにて技術基盤を担うR&D組織の拡大やアメリカ市場を中心とした海外拠点向けの機能開発を担当。
2018年よりLINE株式会社にて金融事業を担当、LINE Bank設立準備株式会社設立を経て、LINE Bankの勘定系システムを中心とする基幹システム構築プロジェクトを推進。
2020年5月よりAlphaDriveに参画、Incubation SuiteやNewsPicks Enterprise等、法人向けSaaSの開発に携わる。2021年1月より株式会社アルファドライブ執行役員CTO就任。
ユーザベースグループで企業内新規事業の創出支援、及びNewsPicksの法人向け事業 NewsPicks for Businessを手掛ける株式会社アルファドライブのCTO就任から5ヶ月、驚異のスピードでエンジニア採用の成果を挙げている赤澤剛さん。「ハイスキル人材の母集団形成ができない」という難易度の高い採用課題に向き合い、採用対象者へのアプローチを工夫し続けた結果、高いオファー承諾率を実現した。
赤澤さんはどのように採用改善に取り組み、どんな結論に行き着いたのか。エンジニアリング組織にかける思いを紐解きつつ、改善された採用方法とその成果に迫る。
やっぱり、優秀なエンジニアの母集団形成が一番のネックですね。ただ、これはうちに限った話ではなく、もう世界的な傾向だと思います。僕はこれまで中国やシンガポール、インドなどいろいろな国で採用を行ってきて、どこの国でも優秀なエンジニアの採用は激戦でした。
当社が所属するユーザベースグループはある程度エンジニアにも知られていますが、「株式会社アルファドライブ」は、エンジニアにとってはあんまり聞いたことのない会社だと思います。だから「エンジニアはうちの会社のことを知らない」という前提で、ファーストコンタクトでサービスや会社が面白そうだと認識してもらうことに苦労しています。
以前から「最初のタッチポイントさえつくれれば、魅力を伝えられるとおもうんだけどな」という思いはありました。
ここ最近はとくにプロダクトマネージャー(PdM)と、ウェブやアプリのフロントエンドエンジニアですね。よくあることですが、応募にきてくださる方のスキルセットと、我々の求める人物像が異なる場合が多いんですよ。
例えばPdMのポジションって一定の応募は来るんです。知名度が急速に広がりつつある職種だし、求人数も多い。でも僕らが想像する一緒に働きたいなと思うPdMの比率はそこまで高くない。
工数管理などプロジェクトマネジメント業務をメインにやっていたような人は、あくまでも僕らにとっては、求めるPdM像とはギャップがあることが多いです。
当社の求めるPdM像は、新しいプロダクトや機能を開発する際に担当事業の責任者とすり合わせながら課題発見もするし、どうしたら顧客の満足度が上がるかを設計する。デザイナーと一緒に粗々のUIを考えてもらうこともある。実際にお客さんとの商談にも出てもらって、機能を説明して、改善して欲しい点も聞いてくる。
そうやって、どういうふうに改善すれば相手は魅力を感じて買ってくださって、使ってくださるのか、当事者意識をもってともに考えていけるメンバーを採用したいと思っています。
そもそも職種名からこだわっています。例えばPdMの場合「サービス企画/プロダクトマネージャー」と書きます。どうしても「プロダクトマネージャー」とだけ書いてあると、想像とは違う方の履歴書も届いてしまう。そこを「サービス企画」、つまり「サービスプランナーという、すごく採用倍率の高い難しい職種のことなんだよ」と明記することで、伝わり方が変わってミスマッチを防げるといいなと思っています。
それからジョブディスクリプションの文面に、あえて砕けた言葉も交えます。「明日の自分を楽にするために今日仕組みをつくれる方」や、「優先度を明確に判断しながらも状況に応じて『仕方ないなぁ』という広い心で臨機応変に立ち回れる方」、「怠惰な方」など、採用の文面ではあまり使われないようなワードも自分自身の言葉として意図的に使うようにしています。
こういう言葉って、普段そう思ってない人が読んだら「この会社適当だな」と思って読み飛ばしてしまうかもしれません。だけど、普段からこういう考えを持って仕事をしている人からすれば、「これ俺のことじゃん! 俺へのメッセージだ!」と思って応募してきてくれるんですよ。自分たちの考え方に合う人だけに刺さればいい、そこが僕の狙いです。
正直ハイスキル人材の採用は狭い市場での奪い合いです。無理に採用の間口を広げてミスマッチになると、エンジニアも企業も不幸せになるだけ。だから、母集団形成でどんなに苦労しても、本当に合う人に来てもらいたいと思っています。
採用までのフェーズを「スカウト前」と「スカウト後」に分けて、それぞれのフェーズにおいてエンジニアへの訴求を最大化する努力をしました。まずは、スカウトメールの工夫です。うちがどんな会社かわからない人でも「この人なら、この会社に入るとか入らないとか関係なく、エンジニア人生の中で1時間くらい話してみても面白いかな」と思ってもらえるように、徹底的に文面にこだわりました。
正直、面談に来てくれる90%のエンジニアは弊社のことを知らない状態です。でもいろんな工夫をしているおかげか、「会社のことはよく知りません。でもあなたの書いていることに共感したから話をしてみたい」といって来てくれます。知っているから来てくれる、というわけではないんですよね。
一緒に働く人の空気感が伝わるように、普段社内のslackで使っているような表現をそのまま送っています。わざと「(笑)」とか、「www」とか書いたりします。結構口語で書くようにしていますね。
エンジニアの皆さんも当然わかっているんですよ。スカウトメールが一定のプロセスとして複数人に送られているケースが多いことを。それでもこのメールは企業からの一斉送信ではなく、あなたのことを知りたいひとりのエンジニアからのメッセージであることを伝えたい。
だから最低限、僕という生身の人間が、画面の向こう側にいるひとりのエンジニアのことを理解して書いているような文面、誠意をもって書いているんだなっていうことが伝わる文面になるようにしています。
ちなみに「ユーザベース」というグループ名はあえてタイトルに入れていません。入れたら開封率が上がることはわかっているんです。でも最初は、つくっているサービスへの共感や、スカウトを送った人の人柄への共感から始めないと、画面の向こうには届かない。
こういう言い方をするとエンジニアには嫌われてしまうかもしれないけれど、スカウトメールはラブレターです、企業からエンジニアへの。「なぜあなたにこのメールを送っているのかを分かってほしい」「僕は一度あなたと話をしたい」という真摯な気持ちを込めた。要は、早い段階で「好きです!」と伝えているわけです(笑)
ありましたね。お作法通りに書きすぎたと反省したこともありました。でもあるとき、自分が喋るときは文法通りの言葉を使ったりしないなと気づいて(笑)。一緒に働くチームはメールの文面ほど堅苦しい雰囲気ではないなら、もっと崩してもいいと思いました。
カジュアル面談と、その後のコーディング面接でそれぞれに特別な取り組みがあります。
まずカジュアル面談では、最初ちょっと雑談した後に「今日は本当にカジュアル面談だから、お菓子でも飲み物でもご自由にどうぞ! マジで面接じゃないんで」と、いきなり言います(笑)。僕もひとりのエンジニアなんで、カジュアル面談と聞いてきたのに、いきなり「あなたのやりたいことは?」とか面接っぽいこと聞かれたら、一瞬で心を閉ざしてしまうと思うんです(笑)。だから徹底的に、気軽に話せる雰囲気をつくることは気をつけています。
そして面談では、先に相手に質問することはしません。まず僕から、自己紹介と事業説明をします。カジュアル面談の目的は、目の前のエンジニアについて知ることではなく、自分たちのつくっているサービスを知ってもらうことですから。
で、1時間の面談が終わった後「またどこかで会ったら開発の話ししようぜ、バ~イ!」という感じでお別れします(笑)。もう、それでいいんですよ。徹底してカジュアル面談の姿勢を崩さないようにして、「エンジニアとしてこの人と話せて楽しかった!」と思ってもらえればそれでいい。優秀なエンジニアと知り合えて、話してくれたエンジニアの方が「悪い会社じゃなさそうだな」と思ってくれたら御の字。そこからすぐに採用転換なんてできすぎかなって思います(笑)。この空気感をつくることは、いつも気にしていますね。
カジュアル面談の後、選考に進みたいという方には1回面接して、その後2回コーディング面接をしています。具体的には、ペアコーディングの要素を持ったライブコーディングです。最初に10分くらい問題を読んでもらってから、しゃべりながら修正したり、いろんなパターンを考えてもらったりします。
あえてはっきしりした合否基準は設けていません。もちろん、どういうコードを書くかを見てスキルの判断はしています。でも僕が採用面接を通して見極めたいのは、「この人とだったら楽しくプロダクトをつくれる!」ということです。だからフランクな感じでお喋りしながら、わからないことがあれば一緒にネットで調べて解決する。その過程で、どんなところで壁にぶつかって、それをどんなロジックで解決するのか見えてきます。そこは結構見ているかもしれないですね。
ちょっと前なんですが、7月に入社してくれた方とコーディング面接を終えたとき、「今日は楽しかったです!」と言われて、僕はすごく嬉しかったんです。「一緒に開発を楽しみたい」という気持ちが相手にも伝わったと感じました。まあ、僕は「マジ? 俺も! よかった、おっつー!」なんて返しちゃったんですけどね(笑)
そうです。ただ、ここに固執しすぎると、判断基準がちょっと甘くなってしまうことがあるんですよ。だから僕は採用するかどうか最終判断で迷ったときに、いつも自分に「この人は自分のチーム“以外”でも活躍できるだろうか」と問いかけるようにしています。
それから「その人がいてくれることによって、僕がほかのことをできるようになるか。その結果、お客さまへの提供価値が増えるか」も大事。採用って、組織としてできることが増えるようにならないと、トータルで意味ないんじゃないかって思うんですよね。この人がいてくれたら、組織として新しいことをどんどんやっていけるか、っていう。
僕は採用を通して、優秀なエンジニアと出会いたいです。……というか大前提として、僕らがスカウトメールを送ったり、それを読んで連絡をくれたりする人ってみんなそもそもすごく優秀なんですよ。
エンジニア業界は広いようで狭いです。どの会社にいようとも優秀な人とはいつか何らかの形でクロスする。「あそこの面接を受けたけど、いい会社だった」と覚えていてもらえれば、いつか一緒に仕事ができるかもしれないし、お客様としてうちのサービスを選んでくれるかもしれません。
この先の人生で何かしらの付き合いを持つ価値があると思ってもらえれば、僕にとっては御の字です。だから、モニターの向こう側に息をしている生身の人間がいるっていうことを絶対に忘れちゃいけないと強く自分でも意識しています。
前職で海外で働いていた頃、5を超える国籍のメンバーをマネジメントしていたことがあるんです。
当時の僕はメンバーの強みよりもマイナス面を指摘することが多くて。「顧客のためなら」とメンバーにも、自分自身への厳しさと同様に厳しく接してしまっていました。顧客の期待に応えられるなら、自分たちが犠牲になる部分は仕方ないとさえ思っていた。
その結果、周囲から「赤澤さんのマネジメントはハードすぎる」と強い反発を受けてしまいました。
そんな中、当時のチームメンバーは諦めずに僕と向き合ってくれたんです。その時のメンバーの言葉が、自分にとって結構大きくて。わざわざ僕のところに来て、何度も「僕はあなたのことを尊敬しています。でも、今のやり方はよくない。赤澤さんのいいところが隠れてしまいますよ。絶対に直したほうがいい。もっと良くなるから」と真正面から言ってくれました。
その言葉を聞いて、自分のマネジメントのやり方を見直しました。マネージャーの役割は、メンバーのできている部分にフォーカスすることだと。「この機能すごいね! どうやってつくったの?」「この考え方、超いいじゃん!」と、一人ひとりのメンバーの強みを見つけて、徹底的に活かすことこそがリーダーの役割だと気づいたんです。
極端にいうと、納品期日を守るのが苦手なメンバーがいて、でも彼にはほかの誰も実現できないような機能が開発できるとする。その場合、その人に「納期を守れ!」というより、スケジュールに厳密性が求められるような開発は他のメンバーと分担して、その人が得意な開発に集中できる環境をつくってあげることが正解だと僕は思います。できることは共感して伸ばし合い、できないことはチームでやり方を模索して一緒に改善していく。この人たちだったら自分がいい影響を与えられるし、刺激をもらえるという関係性をメンバーで築いていきたい。
組織というのは、個人の強さを最大限に活かすフィールドであるべきです。
改めてですが、入社するかしないかというだけの関係は、僕が目指す理想な採用ではありません。よくあるのはカジュアル面談のあとに「これから面接に参加しますか?」と聞くんですけど、僕はあまり好きじゃないですね。落ち着いて返信したい派なので(笑)
入社してもらうことを採用のゴールにせず、エンジニアとしてだけでなく、友だちとして長く面白い関係をつくることが未来に繋がると思います。
株式会社アルファドライブ プロダクト開発エンジニアの求人はこちら
企画・取材・編集:王雨舟、石川香苗子
執筆:手塚裕之
撮影:Jin Qiuyu
関連記事
人気記事