エンジニア採用の最前線、必要な人材を採用するための秘訣と実践方法をCTOや採用責任者が語る

2019年11月26日に開催されたFLEXY主催のCTOmeetupのテーマは「エンジニア採用の最前線」。
Sansan、メルカリ、アマゾン ウェブサービス ジャパン、LINEからCTOやエンジニア採用責任者をお招きして、「エンジニア採用」についてご登壇いただきました。

エンジニア採用に苦戦している企業が多い中、課題を解決する施策を求めて、多数ご来場いただきました。

<モデレーター>
●Sansan株式会社 執行役員 CTO 藤倉成太さん

<パネラー>
●株式会社メルカリ Engineer Hiring Manager エンジニア採用責任者 ひらいさだあきさん
●アマゾン ウェブ サービス ジャパン株式会社 技術統括本部長 執行役員 岡嵜禎さん
●LINE株式会社 Developer Relations室 Developer Successチーム マネージャー 兼 People Partner室 エンジニア採用チーム マネージャー 藤原聖さん

【目次】

CTO、技術責任者、採用責任者……エンジニア採用には多様な立場が携わる
– ご登壇者紹介

組織と採用プロセスの全体像
– エンジニア組織とエンジニア文化の作り方

– 時代やフェーズに応じた最良のミッション・バリューを突き詰めることが重要
– 大企業であっても最初からエンジニア組織の方針が決まっているわけではない

エンジニア採用力の強化
– 採用フローは各社で共通しているものの、手法は文化風土に応じて多種多様

– 人事と現場のエンジニアがどのように連携するのかが重要なポイント

採用広報
– 知名度や予算が無いスタートアップだからこそ持てる採用の強みがある

– 熱量と責任を持って誰かがメンバーを先導すれば成果は必ず表れる

選考基準(技術や人物面)
– 社内評価とリンクした採用プロセスでカルチャーフィットを公正にジャッジしたい

– 採用後のミスマッチを減らすため、相手に期待することを極力言語化する

組織づくり
– エンジニアの成長機会を積極的に作ることがモチベーション維持につながる


会場からの質疑応答
– まだネームバリューが無い企業の採用手法、草の根運動やファクトづくりで戦う

– 自社に合う人を探すことはもちろん、合わない人は確実に見送る覚悟も必要
– 責任のあるCTOや採用責任者というポジションになった背景とは?

CTO、技術責任者、採用責任者……エンジニア採用には多様な立場が携わる

Sansan 藤倉成太 モデレーター
Sansan株式会社 執行役員 CTO 藤倉成太さん

株式会社オージス総研でシリコンバレーに赴任し、現地ベンチャー企業との共同開発事業に携わる。帰国後は開発ツールなどの技術開発に従事する傍ら、金沢工業大学大学院工学研究科知的創造システム専攻を修了。2009年にSansan株式会社へ入社。現在はCTOとして、全社の技術戦略を指揮する。

藤倉成太さん(以下、藤倉):Sansan株式会社でCTOを務めている藤倉と申します。前職はSIerです。4年目の頃にシリコンバレーの子会社にアサインされ、現地で仕事をしていました。SIerはどうしても自分でプロダクトを作るという感覚を持ちづらかったことから、帰国後はSansanに入社。当初の肩書はただのエンジニアで、その後マネージャーを経てCTOに就任しました。本日はモデレーターを務めさせていただきます。よろしくお願いします。

ひらいさだあきさん(以下、ひらい):メルカリでエンジニア採用責任者を担っているひらいです。前職はGoodpatchという会社でCTOをしていて、エンジニア組織づくり、エンジニア向け評価制度の策定と運用、エンジニア採用、技術選定など幅広い領域でキャリアを積んでいました。
メルカリに入社したのは2018年の11月です。当初はモバイルチーム全体のエンジニアリングマネージャーでしたが、採用強化のため2019年7月に採用責任者に就任しました。

岡嵜禎さん(以下、岡嵜):アマゾン ウェブ サービス ジャパン技術統括責任者の岡嵜です。私も大手SIerの出身で、外資系ベンダーを経て現職です。日本の大手企業からスタートアップまで、幅広い顧客層を見ています。
若干毛色が特殊な会社かもしれませんが、アーキテクトや機械学習、データサイエンティストなど多様な人材がいますから、そういった人たちをどう集めているのかお伝えできればと思います。

藤原聖さん(以下、藤原):LINEの藤原です。前職はサイバーエージェントで、Androidエンジニアやエンジニアリングマネージャー、人事などの経験を経てLINEに入社しました。
現在はCTO直下のDeveloper Relations室の中にあるDeveloper Successチームのマネージャーを担っています。イベントや技術広報を担当している部署ですね。その部署に加えて、People Partner室、いわゆる人事部のエンジニア採用チームのマネージャーも兼任していて、LINEにおけるエンジニア採用は新卒、中途、採用広報まで含めて全て担当しています。あと個人的な活動として、FLEXYさん経由でエムスリーの技術顧問も務めています。

藤原聖さん LINE株式会社 Developer Relations室 Developer Successチーム マネージャー 兼 People Partner室 エンジニア採用チーム マネージャー 藤原聖さん
サイバーエージェントにてAndroidエンジニアとしてさまざまなサービスを立ち上げた後、エンジニアリングマネージャーとして中途エンジニアの採用や採用ブランディング、人事評価制度構築を担当。2018年8月、LINE株式会社に入社。同社の技術広報、エバンジェリスト活動を担うDeveloper Relationsチームにて社内外向けの勉強会、技術コミュニティのサポートなどに従事。2019年7月、社内の組織変更に伴いDeveloper Relations室Developer Successチームのマネージャーおよびエンジニア採用チームのマネージャーを兼任、エンジニアのサポートから採用広報、採用活動支援まで幅広い業務を担当。

組織と採用プロセスの全体像

エンジニア組織とエンジニア文化の作り方

藤倉:1部ではみなさんの組織や採用プロセスの全体像を掴めればと思います。まずは一般的なところで「エンジニア組織の作り方」をテーマに、みなさんのご経験や苦労した点などがあればお話しください。

藤原:私が所属しているDeveloper Relations室の活動は、社外の開発者に組織を魅力的に思っていただく、あるいは社内のエンジニアが働きやすい環境を作るといったことを含んでいます。その中で特にDeveloper Successチームのミッションは「エンジニアが自慢したくなる組織の実現」で、エンジニア組織の文化醸成の主体となっています。
例えば取り組みの一つとして、当社は入社したエンジニアに対して人事によるオリエンテーションを1日行っています。トレーニングのようなものですね。その最初のパートではCTOが直接「LINEのエンジニアカルチャー」を伝えます。

藤倉:なるほど。ほかの企業はどのような状態ですか?

岡嵜:エンジニア組織全体の方向性は私が決めるケースがありますが、我々が大事にしているのは「全員がリーダーである」という考え方です。ジェフ・ベゾスがトップダウンで指示をするのではなく、メンバー一人ひとりが会社の方向性を考えてドライブしていくのが特徴です。
ですから採用に関しても私が進めるというよりは、各チームのマネージャーがレスポンシビリティーを持って自分たちのチームを作っていくという傾向が強いですね。

ひらい:メルカリは今、エンジニア組織の文化を変えていかなければならないフェーズだと思っています。会社として Go Bold、All for One、Be a Proというバリューを強く掲げてここまで来たのですが、エンジニアの数が増え、海外からカルチャーの違うメンバーも増えている中では、異なった解釈ができるあいまいさがありました。今後エンジニア組織をスケールしていくため、今はエンジニアのプリンシプルやキャリアラダーなどを作ることで文化の明文化を進めているところです。

株式会社メルカリ Engineer Hiring Manager エンジニア採用責任者 ひらいさだあきさん
大学を卒業後、SIerに新卒入社。その後カカクコムに入社し、レストランのインターネット予約サービスの開発に携わる。2015年1月にGoodpatch(グッドパッチ)に入社、2015年12月にCTOに就任。 2018年11月にメルカリに入社。Mobileチーム全体のEngineering Manager等を経て、現在エンジニア採用責任者。

時代やフェーズに応じた最良のミッション・バリューを突き詰めることが重要

岡嵜:文化の言語化は流行っているんでしょうかね。例えば当社もOur Leadership Principlesというアマゾンの社員として推奨される行動14ヶ条というものがあります。LINEさんはいかがですか?

藤原:LINE STYLEという11ヶ条があります。

藤倉:うちもSansanのミッションやバリューを定めた「Sansanのカタチ」というものがありますね。
日本はこれまで暗黙の了解で社員が共通の方向を向くことができていたのですが、外資系企業の取り組みなどを見て、それだけに頼ってはいけないと学んでいる文脈はある気がしますね。

岡嵜:ちなみにバリューなどは作ったら変えていますか?

藤原:今年はVer.2.0になりましたね。項目が一気に増えました。

ひらい:マイナーチェンジしていますね。以前はBe professionalだったのをBe a Proにしたんです。英語圏の人から見ると、Be professionalは当たり前のことを言っているというか、子供っぽいニュアンスだったようなので。

藤倉:SansanはVer.5.0βですね(笑)。ミッションステートメントも結構変えたりしますよ。

岡嵜:時代に応じて変えていくことは重要なのかもしれませんよね。弊社には“Unless you know better ones.”というなんて言葉があります。今が最良だと思っていても、もっと良いものがあれば変えていこうというスタンスなんですよね。

アマゾン ウェブ サービス ジャパン株式会社技術統括本部長 執行役員 岡嵜禎さん
大手システムインテグレーター、外資ベンダー等のアーキテクト部隊の責任者を経て、現在は、AWS Japan(アマゾン ウェブ サービス ジャパン株式会社)の技術統括責任者として、エンタープライズ、インターネットサービス・スタートアップ、パートナーの技術部隊を統括。コンサルタントとしてのバックグランドも活用し、技術だけでなく経営視点で、クラウドや最新技術を適用していくための活動も推進している。

大企業であっても最初からエンジニア組織の方針が決まっているわけではない

藤倉:会場にはそもそもエンジニア組織の文化を醸成する初期段階のフェーズの方もいらっしゃるかと思います。そもそも誰が言い出して決めていくのかといった点はいかがでしょうか?

藤原:Developer Relations室は実は去年できたばかりなんですよ。草の根的な技術広報の発信やエンジニア組織の文化づくりを重要視する人たちがここ1~2年でタスクフォースを立ち上げ、必要性の合意が取れたので組織化したんです。
LINEはNHN Japan、ネイバージャパン、ライブドアが統合して生まれた会社ですから、最初から開発組織もエンジニアもいたんですよね。LINEというプロダクトが完成してから文化づくりが始まっています。

岡嵜:当社が掲げるOur Leadership Principlesはグローバル共通のものですが、組織ごとにTenetsと呼ばれるチーム方針を決めることができます。私が就任した4年半前もこれを作り上げるためにメンバー全員で1泊の合宿を実施し、自分たちが重要視する行動は何か、それをどう形にしていくべきなのかを徹底的に話し合いました。古典的な手法ですけどね。
その中で外部に技術情報を発信することがコアコンピテンシーであるということになり、率先してブログを書くことにしました。もちろんお金をかければできることですが、一番重要なのは全員が同じマインドセットを持つことです。1人ではなく10名、20名が週に1度記事を書けばそれだけですごい量になりますからね。うちはそういう形でカルチャーを醸成していきました。

ひらい:メルカリのプリンシプルやラダーは、CTOが声掛けをして作成がスタートしています。そしてメインとなるメンバーを募集し、集まった人たちでタスクフォースを組んで推進した形です。エンジニアがいつでも質問できる場を設けたり、全体会議を通して途中経過を共有するなど、基本的にはオープンチャンネルでやり取りを進めています。

藤倉:必要があってやる感じですよね。言語化されていないだけで、やらないと離職率が上がったり採用コストが高くなったりといった損失が出るロジックもあるはずです。 みなさん大企業で資金もたくさんありますが、確たるブランドがあるから文化醸成ができるというわけじゃありませんよね。手探りで試行錯誤しているのだと思いました。

エンジニア採用力の強化

採用フローは各社で共通しているものの、手法は文化風土に応じて多種多様

藤倉:次の議題は、今回のタイトルであるエンジニア採用です。事前にいただいている質問内容をもとにテーマを以下のようにまとめてみました。

一般的な採用プロセス
• 母集団形成
– 採用広報(認知獲得)
– 募集チャネル(エージェント、ダイレクト、リファラル、etc.)

• 選考
– エンジニアの協力獲得
– 選考基準と面接担当者の教育
– 魅力付け

• 承諾
給与オファー
承諾獲得

藤倉:このあたりについて、ざっくばらんに最近の取り組みや乗り越えてきた壁などがあればお伺いしたいと思います。

藤原:LINEは私がマネージャーになった2019年7月に採用方針を大きく変えて、ダイレクト中心のリファラルへと舵を切ったんです。
技術広報は先程言ったようにDeveloper Relations室が中心に活動して、選考は現場のマネージャー・エンジニアが担当します。人事は採用フローのマネジメントを担当しています。
選考フローは書類選考をパスしたら技術テストを受けてもらい、その後面接を最低2回行います。最後にリファレンスチェックを通れば内定です。

岡嵜:採用プロセス自体は他社と大きな違いはありません。特徴があるとすれば、技術だけではなく半分はカルチャーフィットも見ているという点でしょうか。また、最終面接は合議制です。偉い人が採りたいと言っても忖度はなく、面接官全員が同時に最終判断します。
あとは有名になったのがバーレイザーという制度です。これは部門外の人が必ずインタビュープロセスに入るというものです。エンジニア採用なら営業や人事の人が入ってきて、全く異なる観点から応募者をレビューします。利害関係がないので、「微妙だけど今忙しくて採りたいから通してしまえ」といったことがありません。基本的に、基準値の高い人を採用できるようなメカニズムを導入しています。

ひらい:当社の母集団形成のためのチャネルはエージェント、ダイレクト、リファラル、スカウトなどですね。最近の感覚としてはかなり外国籍の方の入社が多いので、採用のポイントは海外のエンジニアにどうアプローチしていくのかとです。海外に強いエージェントにサポートしてもらっていますし、海外のカンファレンスのスポンサーになったりもしています。海外カンファレンスの場合、イベントの登壇者や参加者に事前にLinkedlnでお声がけして、個別にミートアップもしていたりします。
選考プロセスは書類選考、ホームワーク式の技術課題、面接というパターンなのですが、ここは変えようとしています。最初にオンライン上でそこまで難易度の高くない課題でスクリーンして、さらにライブコーディングによって技術を見極められるようにする予定です。意図は応募者が使う時間や内定承諾までの期間を短くすることですね。ホームワーク式だとどうしても1週間はロスしますから。
あとは面接官の質を担保するという課題もあります。HRにはベーシックな面接官トレーニングの仕組みがあるので、エンジニア採用に特化したトレーニングを作ろうとしています。

人事と現場のエンジニアがどのように連携するのかが重要なポイント

藤倉:現場のエンジニアが自分たちのKPIとして採用を進め、オーナーシップを持つのが目指すべき姿ですよね。もちろん最初から完璧な形はないので、みなさんが現在の採用の形にいたるまでどのような変遷を辿ってきたのか聞いてみたいと思います。

藤原:7月に方針を変えたと言いましたが、6月までもそれなりに応募や紹介は多く、かなりの人数が選考プロセスに乗っていました。ただ、そのときは人事と現場のエンジニアが密に連携するといったことは正直できていなかったんです。私がエンジニア採用チームのマネージャーになった際にそれを強く感じ、チームの目標を「エンジニアフレンドリーな採用組織にする」と決め、より現場と一緒に採用を進めていくようにしました、特に母集団形成の部分などは、今はかなり寄り添った形に変わってきていますね。 ではどのようにしてエンジニア組織と連携したのかというと、具体的には情報をできるだけ共有するようにしました。やはりエンジニア組織はオープンな情報公開を好むんですよね。面接官トレーニングや人事マニュアルの資料を共有しましたし、エンジニア文化に合わせてミーティングのログなんかも全て残すようにしました。あとはコミュニケーションツールを統一するなど、全面的な整備も行いました。

岡嵜:当社にはピザ2枚ルールという考え方が根本にあります。2枚のピザでお腹が一杯になるくらい、つまり10名以下程度でチームを構成して、そこにフルレスポンシビリティを与えるということですね。それは採用や育成も例外ではありません。HRや採用チームは基本的にエンジニアチームと対になっていて、エンジニアチームのマネージャーと採用担当がタッグを組むんです。新卒系はもちろん別にまとめますが、個々の場合はブランディングから採用計画、魅力づけ、承諾獲得に至るまで現場の当事者が行うことになるので効果がありますよ。

ひらい:メルカリは採用人数などの目標を人事サイドが持ち、どこのチームに何人必要なのかといった部分をエンジニアリングマネージャーが算出します。採用プロセスの変更や採用の意思決定そのものはエンジニアサイドに権限があるのですが、プロダクト開発やピープルマネジメントがあるのでエンジニアリングマネージャーはかなり忙しいんですよね。私はEngineering Officeという横断組織に所属しているので、そこで採用活動のサポートをしています。大きいところではエンジニア採用プロセスの全体統一、小さいところではエンジニアに新しいポジションのジョブ・ディスプリプションを作成するためのヒアリングを行うといったこともしています。SREの役割だとか、GoやPHPの知識はどれくらい必要なのかといったことを聞くので、人事サイドではなかなか難しいんですよね。

藤倉:ありがとうございます。各社がどのような取り組みをしているのか、雰囲気が掴めたのではないでしょうか。

採用広報

知名度や予算が無いスタートアップだからこそ持てる採用の強みがある

藤倉:では2部を進めていきます。事前に70ほどの質問をいただいているので、それを僕なりにラベリングして採用広報、選考基準(技術や人物面)、組織づくりと3つの領域にまとめてみました。まず一番多かったのが採用広報についての質問です。

採用広報について
(事前に参加者から集まった質問)

•スタートアップのように採用に費用をかけられない場合にどのようにしたら良いか?
•エンジニア界隈での知名度が低く、露出を増やすなどしていきたい。採用ブランディングの戦略について、ヒントが欲しい。
•自社の技術者ブランディングなる物を意識しているか、している場合はどのようにそれを作り上げているか
•各社のブランディングで意識されている点があれば伺いたいです。
•採用広報活動としてはどんなことをしているのか。オリジナルの施策を考えなければならないのか。
•メディアの利用方法
•技術ブランディング、泥臭い話

藤倉:自社に知名度が無い、費用をかけられないといった状況における対応策が主に求められている回答ですね。いかがでしょうか?

藤原:当社は今年の7月頃からいろいろなことに取り組んで頑張ってはいるのですが、多数のチームが採用広報を行っている分、一貫したメッセージを出し続けるのが難しいんです。フットワーク軽く動くことができないのも課題ですね。スタートアップはここに強みがあるので、その点は羨ましいです。
いいなと思っている取り組みは、メルカリさんの「mercan」というオウンドメディアです。毎日記事を出し続けることがKPIだと伺っているのですが、うちもああいった活動を強化しなければと思っているところです。

ひらい:mercanは社内のことをみなさんに知っていただくメディアの一つになっているかなと思います。それとは別にエンジニアのテックブログもありますが、これらは特に大きな費用がかかるわけではありません。情報発信自体はスタートアップでも大手でもやっていけると思います。
それに最近はHRテック系のツールやサービスが増えてきていて、一定期間無料など安く使えますよね。新サービスをどんどん試せるのはスタートアップならではだと思いますよ。僕がGoodpatchに居た頃は自分が使いたいと思えばすぐに導入できる環境でしたしね。

熱量と責任を持って誰かがメンバーを先導すれば成果は必ず表れる

岡嵜:スタートアップが採用に費用をかけられないという問題については、ぜひAWSの最先端サービスを使ってください(笑)。
それは置いておいて真面目な話をすると、働きたい会社の条件は3つだと思っています。

1.社会貢献できること
2.自分がやりたいことをできる
3.自分が役に立てる場である

1の社会貢献についてはビジョンを愚直に伝えていくことが重要です。2のキーワードは「エンジニアの成長」ですね。例えば機械学習など、最先端のテクノロジーを扱っているということが効果を発揮するはずです。3つめが意外と盲点なのですが、自分がこの会社に入ったらこんなことに貢献できる、こんな働き方ができるというイメージが持てることは大切です。実際、我々の組織においても「自分が現場で活躍できるイメージが持てない」というフィードバックがあったんですよね。そこで現場のエンジニアの日々の活動が伝わるような取り組みも行っています。

藤倉:僕はここ1年広報やブランディングという観点で非常に苦労しました。うちは現在テックブログを毎日更新しているのですが、ここに至るまでがとにかく大変で。去年の9月にローンチして、テックブログに対する全責任を僕のチームが持ったんです。記事が足りなければ僕も書くし、書けなければお願いしてでも現場のエンジニアに書いてもらう。「このネタ出していいの?」という疑問などがあれば全て僕のチームが中継ぎして関係者や広報に確認してGOを出す。そういった取り組みによって、毎日記事を出せるようになったんです。
当初ブログのPVは1ヶ月で1000程度でしたが、今は月間3万以上です。誰か一人熱量を持って責任を持てば1年でなんとかなるということはお伝えしたいです。

藤原:うちは今リアルタイムでコンテンツ集めに苦労しているところです。

藤倉:書きたいけど書けないとか、忙しくて後回しになるといった状況もありますよね。そこは誰かが責任を持って集めないと厳しいです。

藤原:良い話を聞きました。ありがとうございます。

選考基準(技術や人物面)

社内評価とリンクした採用プロセスでカルチャーフィットを公正にジャッジしたい

藤倉:次は選考基準をテーマにしたいと思います。技術や人物、カルチャーフィットの見極め、採用基準の統一化といったことですね。

選考基準(技術や人物面)について
(事前に参加者から集まった質問)

• 仕事の進め方の上手い人を見極めるための採用面談の工夫って何かしていますか?
• 採用する上で、考慮している個人の特性事項は?(性格、経歴など)
• 採用時に相手のスキルを測る方法
• 評価制度がどのように行われているのか、技術面は人によって、評価基準が変わらないのか。
• プロジェクトで(チームで)行うシステム設計・コーディングができるかどうか見極める能力は面接で確認していたりしますか?
• 人材の採用基準としての技術力をどう推し量っているのか、また人となりとのバランスをどのように取っているのか
• エンジニア採用時の文化のフィットをどう判断するか?

藤原:入社後の評価制度としては、PレビューとCレビューの2つがあります。Pレビューは上司によるパフォーマンス評価。Cレビューは上司、部下、同僚を含めた360度評価のようなものです。自分が誰に評価されたい、この人を評価したいという情報をメンバーから集めて実施します。ちょうど今がCレビューの時期なので、私も30人ほどの評価を書かなければなりません。
このCレビューの評価の中には、LINE STYLEを体現しているかを測る項目がズラっと並んでいます。入社後にバリューに沿った評価を行っている点を踏まえると、やはり採用時、特に最終面談でももっとLINE STYLEに即したカルチャーフィットを見るべきなんですよね。バーレイザーなどの仕組みを採り入れたり、採用のプロセスの中で必ずヒアリングすべき項目を定めていかなければと感じています。

岡嵜:当社もLINEさんに近いですね。社内評価として職種ごとのケーパビリティとカルチャーフィットを見ています。技術面としてはアーキテクトやエンジニアリングなんかにはジョブレベリングガイドが規定されていますし、Our Leadership Principles を実践できているかを測る360度的な評価も採用しています。特定の人のバイアスがかかった評価にならないよう、フェアネスは重要視していますね。

採用後のミスマッチを減らすため、相手に期待することを極力言語化する

ひらい:メルカリは今作っているラダーを採用プロセスに組み込まなければと思っています。同様に今後採用に何をどのように適用しなければならないのかをリストアップ中です。
技術面をどう見極めるのかという部分だと、応募者がこなした技術課題の回答を採点して、例えばモバイルエンジニアの場合は2時間ほど長めの面談をしたりします。回答に対して合格ラインにはどういう答えを期待するのかをドキュメント化していたりもします。ただ全ポジションで共通して同じ取り組みをできているわけではないので、そこは僕がサポートしなければならない部分です。
あと気をつけているのは、最終面接の前にその人の前職の報酬を確認したり入社後のグレード、配属先のチームなどをマネージャーたちとあらかじめ細かく決めておくことですね。その人に対する期待をなるべく言語化し、入社後のミスマッチを減らすためです。とはいえ、メルカリも3ヶ月単位で状況が変わったりするので、それを見越したチーム配属をディスカッションするのは大変ですけどね。

藤倉:Sansanはもちろんバリューを評価するのですが、一方で活躍するメンバーには内省力が強いとかコンセプチュアルで抽象度の高い議論が得意とかいった、「Sansanのカタチ」には書いていない共通点があったりするんですよね。そういった要素を少しずつ言語化しています。

組織づくり

エンジニアの成長機会を積極的に作ることがモチベーション維持につながる

藤倉:最後のテーマは組織づくりです。質問を見るに採用における魅力づけや引きつけができていない、自分たちが魅力的な組織で働いているという自覚が欲しいといった気持ちがあるのかもしれないと思います。
いかがでしょうか?

組織づくり
(事前に参加者から集まった質問)

•エンジニアのモチベーションを保つために工夫していること
•エンジニアにとって魅力的に映る組織とは何か
•一番初めの組織づくりの取っ掛かりというか、ドライブの掛け方などもしコツがあれば教えて欲しいです。
•組織づくりは1日でできるものではないと思いますが、実際どの位の期間である程度完成しましたか?また採用に強い組織と現場エンジニアのパフォーマンス向上施策はリンクしていますか?
•離職を抑えるためにしていることについて。
•人材不足は続いているのでしょうか。また、人材をどのように育てているか知りたいです。

藤原:さきほどCレビューの話をしたのですが、部下がマネージャーを評価することもあるんですよね。だからマネージャー自身がメンバーをモチベートする方向を考えなければいけないという意味で上手く機能していると思います。逆に人事側はマネージャーをモチベートする仕組みをもっと整備していかなければなりません。
離職を抑える方法は僕も知りたいくらいですが、LINEは実は出戻りが多いんですよね。離職時もあまりネガティブな理由ではなかったり、温かく送り出すカルチャーが影響しているのだと思います。

岡嵜:エンジニアのモチベーションを保ち離職を抑えるという点では、やはり成長機会を作ることが重要だと思います。エンジニアは成長したいものだという考えが根底にあるんですよね。
成長には2種類あり、1つは自分がこの先も戦っていけるだけの技術スキルが身につくこと。もう1つは、お金や地位ですね。これも成長です。基本的には前者を重要視しているので、例えばアサインメントでチャレンジの機会を与えたり、新しい技術に触れる機会を作るといった取り組みができます。当社では去年からクォーターに1回、好きな技術を勉強する日を作っていますし、チームによってはさらに週に一日そういった時間を設けているところもあります。
あとはマインドとして、情報やナレッジは隠さずに絶対にシェアするようにという話もしています。お互いに高め合って成長していける環境を作るためです。そういうエンジニアに囲まれていろいろな情報をキャッチできれば、出ていくのがもったいない、ここでもっと成長できそうだと思えますから。そういう環境づくりが大事ですね。
もちろん辞めてもいいんですよ。ただ、辞めたときに「AWSで働いていたときが一番成長できた」と言ってもらえることを目指しています。

ひらい:うちもモチベーションアップのためにハックウィークというものを実施しました。エンジニアに1週間好きなことに取り組んでもらうというものです。なかなか面白かったですよ。例えばAndroidエンジニアがアプリのサンプルを作ったのですが、アプリをかざすとARになっていて、Macがあればそこにオーバーレイで「これくらい売れそうです」という価格が表示されるんです。社内にその動画を流したらかなり盛り上がっていました。岡嵜さんが言ったとおり、エンジニアがチャレンジして成長していける環境はすごく大事ですよね。

会場からの質疑応答

まだネームバリューが無い企業の採用手法、草の根運動やファクトづくりで戦う

藤倉:最後に会場からいただいた質問にいくつか答えていきたいと思います。投票数が一番多かったのが「ネームバリューが無い会社はどう戦えばいいのか」ですね。 それこそ僕がSansanに参入した11年前は社員数10数名で、僕は社員番号18番だったんですよ。しかも名刺管理のサービスですから、知ってもらっても大したインパクトはありません。もう気合でしたね。何百社というエージェントに全部説明して、少しでも「この会社、良いな」と思ってもらえたらこっちのものです。「そういえば」と思い出して紹介してもらえるように、片っ端から草の根運動をしたという感じでした。

藤原:僕が技術顧問で入っているエムスリーはこの1年間エンジニアブログで地道に技術広報をし続けていました。その結果、今はそれなりに採用の成果も上がっているようです。戦い方次第なのではないでしょうか。

ひらい:Goodpatchはデザイン会社としての知名度は高かったのですが、エンジニア組織としてのネームバリューはあまりありませんでした。GoodpatchはRubyを使っていたのでRubyKaigiのスポンサーになりました。もちろんスタートアップで費用は無いので一番安いランクです。スポンサーになっただけで人は来ませんから、スカウトメールにスポンサー活動のことを入れたりして、エンジニアを増やしていきたいんだとアピールしました。勝手に潜在層が顕在層になることはありませんから、ファクトを作り、それを届けたい人にどう届けるかという視点で採用活動をしていましたね。

自社に合う人を探すことはもちろん、合わない人は確実に見送る覚悟も必要

藤倉:「マインドセットが合わない人に対してどう対応すべきか?」というちょっとダークサイドな質問も上がっています。

ひらい:平行線になりそうなら辞めてもらったほうがお互いに幸せということは前提にありますね。ただその前段階として、メルカリならメルペイやUSなどいくつか違うチームがあるので、そこで活躍するチャンスがないかどうかはディスカッションします。

岡嵜:合わないと伝えるにしても上司が部下に一方的に言うのではなく、360度で行っている多角的な評価としてどういう行動が合っていないのかフィードバックを伝えることが重要だと思いますね。そこで変われるかどうかです。
Our Leadership Principlesには自己批判、自己反省ができるという要素も含まれているので、そもそもそれができない人はどんなにスキルがあってもそもそも採用しない、ということも大事ですね。

藤原:カルチャーやマインドが合わない人はやはり採用しないのが正解だと思います。

ひらい:短い面談でカルチャーフィットするエンジニアかどうかをどう判断するのかも当然重要ですが、どちらかと言えば合わない人は確実に落とすという意識も必要ですよね。合わない人を採用したときのハレーションや影響はすごく大きいので、迷ったら見送るべきです。

責任のあるCTOや採用責任者というポジションになった背景とは?

藤倉:最後に「いろいろいろいろ経緯はあると思うのですが、みなさんどうして今の会社のCTOになろうと思ったのですか?」という質問に答えたいと思います。現在の肩書としてCTOなのは僕だけなのですが(笑)、なぜ今のポジションに就こうと思ったのかですね。責任ある立場はプレッシャーも大きくて大変ですから。ひらいさんいかがですか?

ひらい:では私がGoodpatchのCTOになった経緯をお話しします。入社時は社員が50名ほどでした。プロダクトの開発のエンジニアとして入ったのはいいものの、これまでどうやって開発してきたのかわからないくらいのチームだったんですよ。社長が「これが欲しい」と言えば作ってリリースするくらいの感じで動いていました。なので開発のルールづくりやカンバン整理などをしていたら、そのうちエンジニアリングマネージャーになっていて。さらにプロダクトのエンジニアだけでなく全体を見てほしい、CTOに興味はありますかと言われ、やってみようということになった感じですね。

岡嵜:私は社会貢献ができる、自分がやりたいことをできる、自分が役に立てるという3つの要素が叶いそうだったからですね。あとはご存知の方もいらっしゃるでしょうが、私の前任者はソラコムの玉川さんです。辞めるときはアスキーでも大々的に報じられて、一体誰がこのポジションをやるんだという話になっていました。ここにチャレンジして生き残れたら、自分が成長できるだろうと思ったんですよね。それが一番大きいです。

藤原:大きな点は、前職のときから採用をすごく重要なものだと考えていたことですね。あとは、一人のエンジニアとして存在するよりも組織でより多くの仲間を得てミッションを達成した方が、社会に大きな影響を与えられるとも思っていました。人事と組織づくりに興味を持っていたんです。
その中でLINEからDeveloper Relations室に参画しないかとお話をいただいたのでジョインしました。入ってみると、良くも悪くも採用チームとエンジニアチームは縦割りでした。ここは僕が兼務マネージャーとして両者の橋渡しをしなければいけないと思っていたところ、実際に採用チームのマネージャーになってほしいと言われたので引き受けた感じですね。

藤倉:私はSansanに入社してしばらくしてから開発部長にならないかと言われましたが、コードを書いている方が楽しいし、マネージャーというガラではないなとは思ったんですよ。でも、僕はSansanを世界で戦える日本のソフトウェア会社にするつもりで入社していたので、その役に立てるならエンジニアでもマネージャーでもどちらでもいいなと思って。打診された瞬間に「やります」と答えました。その後CTOにならないかと言われたときも同じです。ガラではないけれど、必要なポジションだと思えたからやることにしました。客観的に求められている役割に自分が挑戦することで会社が前に進むなら、やる気になれるんだと思います。

写真右側から:
・ LINE株式会社 Developer Relations室 Developer Successチーム マネージャー 兼 People Partner室 エンジニア採用チーム マネージャー 藤原聖さん
・ 株式会社メルカリ Engineer Hiring Manager エンジニア採用責任者 ひらいさだあきさん
・ Sansan株式会社 執行役員 CTO 藤倉成太さん
・ アマゾン ウェブ サービス ジャパン株式会社 技術統括本部長 執行役員 岡嵜禎さん

この記事を書いた人
FLEXY編集部
FLEXY編集部
ハイスキルIT人材への案件紹介サービス
FLEXYメディアは、テックメディアとしてテクノロジーの推進に役立つコンテンツを提供しています。FLEXYメディアを運営するのは、ITに関連するプロシェアリングサービスを提供するFLEXY。経営課題をITで解決するためのCTOや技術顧問のご紹介、ハイスペックエンジニアやクリエイターと企業をマッチングしています。【FLEXYのサービス詳細】求人を募集している法人様向け/お仕事をしたいご登録希望の個人様向け

今のエンジニア組織に満足されていますか?

法人のみなさまへ。flexyでは技術組織の採用支援、組織作り(人事評価、パフォーマンスマネジメント)やアーキテクチャー設計アドバイスなどエンジニアのマネジメントや上流工程にお悩みの企業様とハイスキルなCTOの皆様やTechLeadの皆様の出会いを支援しております。

FLEXYでご案内できる業務委託案件

業務委託契約・開発案件(JavaScriptメイン)

テーマ FLEXY登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 4万円/日
必要スキル JavaScript・React
勤務地 東京都内/リモート含む
リモート

外部CTO、技術顧問

テーマ 技術アドバイザリーとして知見と経験を生かす
勤務日数 1日/週
報酬 10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京
リモート 相談可

業務委託契約・インフラエンジニア

テーマ FLEXY登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 5万円/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート 相談可

業務委託・フロントエンドエンジニア

テーマ FLEXY登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週1日〜
報酬 5万/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート リモートと常駐のMIXなど

人材紹介のCTO案件(非公開求人)

テーマ CTO、技術顧問案件はFLEXYに登録後、案件をコンサルタントからご紹介します
勤務日数 業務委託から人材紹介への移行
報酬 年収800万以上
必要スキル CTOとして活躍可能な方、エンジニア組織のマネージメント経験
勤務地 東京
リモート 最初は業務委託契約で週3日などご要望に合わせます

業務委託契約・サーバサイドエンジニア

テーマ FLEXY登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週2-3日
報酬 案件により異なります
必要スキル 案件により異なります
勤務地 東京都内
リモート 相談可能
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)