CLOSE

クラスメソッドのエンジニア採用戦略(全1記事)

2018.08.01

Brand Topics

PR

第一印象は信用しない、チーム全員で選考…クラスメソッドが実践する、常識破りの採用戦略

提供:クラスメソッド株式会社

2018年4月18日、クラウド・モバイル・ビッグデータに特化したコンサルティング等を手がけるクラスメソッド株式会社が、会社説明会「クラスメソッド流、エンジニアがいきいきと働ける職場と文化のつくり方」を開催しました。エンジニア採用を積極的に行う同社が、どのようにして人材育成を行っているのか? そのノウハウや考え方を明かします。後半パート「クラスメソッドのエンジニア採用戦略」に登壇したのは、マーケティング部長の嵩原將志氏。技術者の人手不足が深刻なIT業界で、いかにして効率的な採用活動を行っているのか? マーケティング的手法を用いた同社の採用ノウハウと、採用活動を行う上で大切にしていることを語りました。

クラスメソッドのエンジニア採用戦略

嵩原將志氏(以下、嵩原):では、「クラスメソッドのAWSエンジニア採用マニュアル」ということで発表いたします。副題は「現場の現場による現場のための採用」です。はじめに、自己紹介をさせていただきます。私は、嵩原と申します。

クラスメソッドでマーケティングの責任者を担当しております。入社して12年ほどです。

クラスメソッドのマーケティング活動は会社が小さかったころの名残が残っていて、採用活動もマーケティング部で行っています。今日のアジェンダですが、まず昨今のエンジニア採用事情をご紹介して、認識を揃えたいと思います。その後に我々の採用方針、採用活動についてご紹介していきたいと思います。

エンジニアの採用事情

では、まずは最初に昨今のエンジニア採用事情についてお話しします。3つ特徴をお話しすると、慢性的な人手不足、とくに技術者が不足しています。あとは技術者不足から来る賃金の上昇。さらに技術者にとって選択肢が増加しているのが現状です。

その背景をご紹介します。求人に関して公開されている調査資料によると、現在、IT系の職種の有効求人倍率は5.98倍と言われています。

これは調査元によって数字がぶれるので、7倍というところもあれば21倍と書いているところもあります。「さすがに21倍は嘘だろ」と思いますが、全体的に非常に高いです。

全体平均は2.36だそうです。なので倍以上、IT系の人材が足りないということです。チャートで表すと、この緑色の線がIT系の有効求人倍率で、その他の職種に関してはほかの色になっております。やはり1段、2段跳びぬけて求人倍率が高いのが読み取れます。

あとは、事業会社さんが技術者採用に非常に力を入れています。何年か前にSNSやエンジニアコミュニティなどで「SIerで働くかサービサーで働くか」といった議論があったと思いますが、事業会社さんも「ITが自分たちの競争力の源泉になる」ということをよくわかっているので、エンジニア採用を本気でやっています。

つまりなにが起きているのかと言うと、慢性的な技術者不足・技術者の賃金上昇・技術者にとっての選択肢の増加というのは、「技術者がとりあえずSIerや開発会社に就職を考える時代はもう終った」ということを示しています。エンジニアにはもう選択の自由があります。いろいろなところで仕事ができる。いろいろなところでITエンジニアは必要とされています。

クラスメソッドのエンジニア採用の特徴

そんな中、クラスメソッドのエンジニア採用の特徴をこれからご紹介したいと思います。まず、社長・部長に権限はありません。採用プロセスですが、全体的には10年ほどこのように進めています。

ですが、細かいところではさまざまな変化がありました。その中で言うと、人物像が明確になっていればプロセスで必要なこと・不要なことがわかってきますし、あとは採用事情の変化によっては慣習が有効でなくなることも多いわけです。

では、有効でない慣習についてどんなことをやめていったのか。

まずビジネスマナーのチェックをやめました。それから紙の履歴書・経歴書の提出廃止。その他、定めた人物像に対して関連性がわからない手続きや質問の一切合切を廃止しました。

ビジネスマナーチェックの廃止というのは、私が採用担当するようになる前の話です。我々も「一般的にちゃんとした会社」になりたかったので、当時の採用プロセスでは、SPI試験などをがんばって実施していました。

紙の履歴書・経歴書に関しては、やり取りに時間がかかってしまうし、正直面倒です。あと、文書保管のセキュリティ上のルールに則って見ても、受け取ったからには管理をしなければいけません。何年間かキャビネットに入れて保管しなければいけない。これはとても非効率的なので、これもナシにしました。

エンジニアが同席する実技試験を実施

逆に始めたことです。

まず現場のエンジニアが同席する実技試験を入れるようにしました。筆記試験をやってもらっていたことはありますが、少し内容が偏っていたんです。おそらく情報処理試験の抜粋などをやってもらっていたと思うのですが、それは知ってる人は解けるし、知らない人は意外と解けないものです。

そういうことではなくて、実際に手を動かしてもらう。最初はペアプロ(ペアプログラミング)からはじめたんですが、これがだんだん変化してチーム全員参加型の実技試験になりました。職種や部署によってテーマは変わりますが、基本的には事前に課題をお伝えして準備をしてもらい、みんなの前で実際にやってもらう、もしくは書いて来たソースコードの説明をしてもらう。そういった内容になっております。

これはすごく手間と時間もかかります。だいたい準備期間を1~2週間とってますし、チームの全員が参加するので、うちの場合は10人くらいのメンバーが面接に参加することも珍しくないです。多いときは20人くらい、リモートのメンバーもつなげて参加していたりします。

手間暇はかかりますが、チームの文化や大切にしたいことを再認識することができました。

もしみなさんの現場でも採用プロセスを検討されているようでしたら、ぜひやったほうがいい慣習だと思います。

現場の人間が全員OKしなければ採用しない

そして、ルールを見直しました。

まず、面接に参加した人全員の意見が尊重されて、揃わなければ採用しません。10人参加したら10人が「一緒に働きたい」という結論に至らなければ、採用になりません。

また、先ほどもご紹介したとおり、社長・部長の意向は一切通りません。社長・部長が採りたい人と現場のエンジニアが働きたい人というのは、やはりちょっとズレてしまうんです。例えば社長が「この人は営業とかプロマネの経験もあって良いじゃない」みたいな話をしたとしても、ほかのエンジニアのメンバーが「そんなに技術好きそうじゃないですよ」となったら、申し訳ないですが今回はご縁がなかった、ということになります。

なので、現場の認識が尊重されます。余談ですが、当然そういうふうにすると社長がムッとしていたりするんですが。

(会場笑)

それでも通りません。というわけで改めて、社長・部長に権限ナシ。大切なことなのでもう1回言います。

クラスメソッドの採用事情

続いて、クラスメソッドのエンジニア採用事情をご紹介したいと思います。今クラスメソッドは、ここ数年間の平均で、年間で30~40名ほどの社員が入社しています。

今年はさらにペースが上がっていて、恐らくこの1年間では、90名くらいの社員が新たに入って来ていることになります。

この中ですごく誇らしい数字としては、私が採用に関わってから辞めた人が、恐らく10人いるかいないか程度であるということです。定着率が非常に高いんですね。なので、いわゆる「足りない人を補うためにどんどん入れ替わって人を採りまくっている」という状態ではなくて、純粋に良い人が入って来ている、という状態です。

そして、入社する人材のほとんどは即戦力だったりします。我々は、新卒の人や未経験の人でもとりあえず採っちゃえ、という考え方はしていません。現場のメンバーが「一緒に働きたい」と言う人に入って来てもらうのでスキル的にしっかりしている人が入って来ています。

なので入社1ヵ月あれば、だいたいみんなAWS認定SAアソシエイトを取得していますし、AWS事業部のメンバーであれば、1年以内に日本語で取れる5つの資格をコンプリートしています。そして、英語でしか取れない2つの資格もぼちぼち合格している人がいるので、スキル的にはかなりレベルの高い人材が揃っています。

接点が多いほど採用率は上がる

続いて、採用に至る流入経路についてです。自社との接点が多い人ほど採用率は上がる傾向があります。

これは採用をやっている人であれば「へぇー」と思ってもらえると思いますが、我々のブログ経由で応募してきてくれた方の採用率は、およそ25パーセント程度です。4人応募してきたら、1人くらいは採用しています。

これのなにがすごいのかと言うと、検索流入やエージェントさんの紹介というのは、基本的に1~2パーセントくらいです。それに対して我々が25パーセント以上で、さらにそれが社員紹介になればまた確率が上がりますし、イベントに来た人であれば確率上がるし、会社説明会に来た人に関しても2人に1人くらいは採用しています。

ですので、本日会社説明会にいらっしゃっている方全員に応募していただけると、半分程度は入社いただけるのではないかという淡い期待も込めてこの話をしています。

マーケティングっぽい説明になりますが、接点が増えてナーチャリングされればされるほど、文化的に合っている人たちが応募してくるので、採用率は上がります。より採用の効率が上がっていく、ということになります。なので文化の発信がすごく重要になる。そのためにも我々はブログを一生懸命書いています。

つまり、我々は最小の工数でスキルの高いエンジニアを数多く採用できている、という傾向があります。

互いに納得して採用するための2つの問い

続いて、AWSエンジニアの採用マニュアルについてお話します。ここはすごく重要なところです。ただ採れればいいのかと言うとそういうことではありません。どうしたらお互いに納得して入社してもらえるのかがすごく重要です。

それには2つの問いがあります。

まず「人はなぜ転職をするのか」。当然ですが、転職には目的があります。そして、「転職者にお金以外のなにを提供できるのか」。これがすごく重要だと考えております。

転職を考える人の目的を満たすなにか、というのは、これはある意味でセールスポイントになると思います。なぜそのセールスポイントが重要なのかと言うと、冒頭でもお伝えしたように、求職者と企業の関係はもう変わったからです。とくにITエンジニアに関しては、求職者のほうがもう強いんです。みなさん選べますから。

なので企業の採用担当者としては、我々の仕事の環境を求職者の時間、言い換えれば人生で買っていただく、ということです。なんとなく「給料を上げる環境があるので働きませんか?」という態度ではもうダメなんですよ。

なので我々は、応募してくれる方が、その人生を投資するのに見合うものを提供できるかをすごく考えています。

求職者にとっての企業の価値を狩野モデルで考える

これはプロダクトデザインなどの話になってしまいますが、狩野モデルで考えるとこうなります。

ざっくり言うと、1番下の「当たり前」と書いている部分はあって当然な要素です。働いたら給料が出るとか有給休暇があるとか、それらは当然のことです。

そして、「一元的」というのはあればあるほどうれしい要素です。例えば仕事で使うマシンは、スペックが高ければ高いほど良いですよね。仕事スペースは広ければ広いほど良い。あとは周りにデキるエンジニアがいればいるほどうれしい、というものになります。

「魅力的」というのは、ここに来ないとなかなか得られないものはなんなのか、ということですね。おそらくこんなにがんばって「ブログ、ブログ」と言っている会社は僕らの会社くらいですし。

(会場笑)

あとはAWS re:Inventに34人も人を送り込むなんて会社も、僕らだけだと思います。

(会場笑)

ここは自信を持って、「僕たちがユニークな魅力を持ってる」と言い切れると思います。

社員の市場価値が上がれば、会社の市場価値も上がる

それらを整理すると、成長機会はすごくたくさんあります。ブログを書かなければいけませんし、かつ案件数は非常に多いです。まぁこれを「やだな」と思う人もいるかもしれないんですけど(笑)。

よその会社の1年間の経験に対して、我々の環境で働いていただいたら数年分の案件数、経験を積めると思います。なので同じ期間で多く経験値を貯めることができます。

さらに外部メディアへの出向、書籍の執筆など。今日、会場に来ているスタッフの中にも、書籍執筆の経験があるメンバーが何人もいます。あとはイベントの登壇ですね。Developers SummitとかJAWS-UGなど、そういったものに社員が出ても「情報が漏れるからダメです」なんてことは絶対に言いません。どんどん経験を積んで、自分の市場価値を上げてください、というのが我々のメッセージです。

社員1人1人の市場価値が上がっていれば、トータルとして会社の市場価値も上がるので。なので、どんどんやる方針です。

あと、比較的自由な仕事環境です。フレックスタイムとリモートワーク、在宅勤務なども自由に使うことができます。一応ルールとして「前の日までに言ってね」というのはありますが。「今日、宅配業者さんが荷物持って来るから在宅で良いですか?」みたいな、そんな理由も普通に通ります。それくらい働きやすいです。その人の環境に合わせて働き方を考えてもらって大丈夫です。幼稚園や保育園のお迎えでも、理由として通ります。

自社にセールスポイントはあるか?

こうしたことをマーケティング的に考えていくと、『リーン・スタートアップ』という本をご存知の方も多いと思いますが、その本の中で「MVP(Minimum Viable Product)」、「最小構成の製品」という定義が登場します。

リーン・スタートアップ

要するに、人が使うにあたって、必要最小限の機能を実装しているのがMVPです。

もう1つ、あまり使われていない用語として、「MMP(Minimum Marketable Product)」というのがあります。市場に出せる最小構成の製品、つまり同じようなカテゴライズのものと並べたときに、選んでもらえる要素がちゃんと盛り込まれてますか、と。まったく同じだったら、「最小構成です! MVPです!」と言っても、「いや、ほかであるから」となってしまったら選ばないですよね。

そうではなくて、「これを選ばないとその価値は得られないんだ」というものが採用や働く環境に盛り込まれているか、というのがすごく重要だと思っています。なので我々はそのように「マーケティングできるものなのか」とすごく考えています。

ということで、「セールスポイントはありますか?」と聞かれたら、「企業が『働きたい』と思ってもらえる仕事と環境を用意しなければいけない」というのが我々が考えている、今のところの結論になります。

学習する習慣はあるか?

では、採用活動をどのように行うかと言うと、まず定義するんです。どんな人と働きたいかを明確にします。

クラスメソッドの場合、みんなに伝えているのは「技術が好きである」ことと「自ら学習する習慣があること」と「実務でパフォーマンスが出せること」。この3つです。

まず「技術が好きであること」というのは、「好きこそものの上手なれ」というのはやはり真実です。好きなことは苦しくても、時間かかってもやれますよね。楽しいし。なのでこういったところが根本的に必要であると思っています。

続いて「自ら学習する習慣がある」こと。弊社では「学習エンジン」という言い方をしています。スキルが足りなくても、この習慣があればいずれ伸びていくので大丈夫だろう、と考えてます。

逆に今スキルが高くても、学習する習慣がない人はいずれ追い越されてしまいます。そのあたりはけっこうシビアに。2次面接で、みんなが「この人は学習してくれる人かな?」ということを感じながら会話しています。

これを勝手に「y=ax+b」の1次方程式で説明してみます。この説明をするたびにみんながポカーンとするんですが……。

「時間経過に対するスキルと成長のイメージ」ということで「y=ax+b」というのはおそらくみなさん、中学生のときに習う方程式だと思います。

僕らが重要視しているのは、「y=ax+b」のaです。傾き、成長率を大事にしたいと思っています。例えば面接をした日を0だとすると、bが高ければそれはそれで良いんですが、これはずっとではありませんし、市場・世界が変わっていけばだんだん下がっていきます。それよりは、成長できるなにかを持ってるか、そういう習慣を持ってるかが重要なんです。

大概の失敗しがちな採用・選考プロセスというのは、このbだけで判断してしまうことです。「今すごいから採ろう」みたいな、今マッチしているから採ったらいいんじゃないか、みたいなことを考えがちなんですが、それだとあまりうまくいきません。我々としては、我々と一緒に成長していける人がいいな、と思ってこういったことを考えています。

これを細々と説明するとこうなるんですけど……。

これは今日は飛ばします。

(会場笑)

あとは「実務でパフォーマンスを出せる」ということです。いくら「勉強します」と言っても、仕事でみんなと一緒に協調して仕事ができなければ困ってしまいます。なので、お願いしたものに関してはしっかり成果を出してもらう、ということはすごく重要です。

三原侑の「アマは和して勝つ、プロは勝って和す」という言葉がありますが、これは両方でも良いと思いますが、単に仲が良ければいい、文化的に合えばいいというものではないと思っています。この、ちゃんと成果出せるかというところは、みんなと一緒に働いていく上で必要最低限のことになると思っています。

応募してもらった機会は貴重である

続いて、採用技術についてです。我々は大きい会社ではありませんし、今のところは毎月のように何十名様もの応募があるとかそういう会社ではありません。応募いただいた機会はすごく貴重だと考えています。なので、どうしたら目の前の人を組織の一員として迎えられるか、ということを真剣に考えます。活躍する人として、そうした場を用意できるのか?

なので、そういったことをおうかがいするための質問や試験などをやっています。そして、その中で「できること」と「できそうなこと」と「やりたいこと」をきっちり整理して考えるんです。

例えば先ほど佐々木の話でもありましたが、「AWSをやりたいけど経験がない」というエンジニアがいて、AWS以外で経験があって得意なことで活躍できそうであれば、「じゃあそこからやりませんか?」と提案します。また、AWSの世界は幸いなことに非常に広いので、違う職種で入っても結局AWSをやっていただく可能性が高いです。今、AWSのサービスは100個くらいありますので、いろんなものをカバーしています。なので、そういったことを考えながら選考を進めています。

これはすこしおまけ的なところなんですが、AWSの世界は広いので、「インフラエンジニア歴何年」など、そうした安直なフィルターはかけていません。あとは先ほどの佐々木の説明とも重複しますが、サーバー・ネットワークの経験がないプログラマーでもうまく活躍する機会があります。

なので違う畑から飛び込んでくるというのは、そんなに我々にとっては大げさなことではありませんし、そもそも最初からAWSエンジニアだった人なんていないので。そこはもし興味があれば、ぜひお問い合わせいただければ、ということです。

母集団がなければ、待遇を良くしても応募してもらえない

続いて、マーケティング視点で採用を説明します。現場がどういった人材を求めているのか、どういった人と働きたいのかというのは、もうリサーチですね。ふだんの会話から我々、採用に関わるメンバーが、だんだん情報を絞っていくようなかたちでやっています。

あとは……過去に採用した人が入社後、どのような変化をチームにもたらしたのか、ということも考えています。ほかには、エンジニアが注目していることはなにかということも重要です。

その流れをマーケティングに考えると、これはマーケティングにおけるファネルですね。

母集団があって、その中から少しずつ我々に興味を持って応募してくれる、という段階があるわけです。

そこで重要なのは、「良い条件があれば来てくれるだろう」という思い込みです。それは確かにそうなんですが、そもそも我々に対して興味を持っている母集団が形成されていなければ、どれだけコンバージョンを上げても応募してもらえません。なので、その母集団形成がすごく重要です。

母集団形成のためには、我々で言うとオウンドメディアですね。『Developers.IO』だったり、SNSの活用など、あらゆる手段を講じて情報を出していきます。情報発信はすごく重要だと考えています。

もしかしたらほかの会社さんで、「それなりに良い職場のはずなんだけど応募が少ないのはなんでだろう?」という場合、それはおそらくみんな知らないからなんです。なので情報発信はすごく重要です。

例えば、もしかしたら読んだことある方もいらっしゃるかもしれませんが、「クラスメソッド株式会社について」というTogetterの記事があります。これは弊社代表の横田が夜中に突然、うちの会社の特徴を説明し始めたんです。それで「これを読んでエントリーを決意しました」みたいな声もいただいたりしています。

これも社長が突然呟き始めて、当時いたマーケの担当が「まとめときました!」みたいな感じでやったものです。このように、あらゆる手段を講じて情報を発信していく、ということをこだわっています。

ほかにはイベントです。勉強会や会社説明会など、そういったところで実際にフェイストゥフェイスで会う機会を作っています。そこでお互い知れることがあるのが、すごく大切です

第一印象は信用しない

それではまとめです。まず、選考ですごく重要にしているのは「第一印象を信用しない」ということです。とくに採用担当、1次面接に関わるメンバーに関しては、みんなに徹底してもらっています。

これは多くの採用の専門家がやってしまっているミスだと思っています。面接慣れしてくると「会って5分でわかる」とか「すぐわかります」って言いたくなってくるんですが、実際にわかったのは「5分で聞き出した情報がわかっただけ」で、5分でその人の人生はなんにもわからないですよね。

だから我々は、けっこう長い時間話をします。1時間はザラに話しますし、1時間半とか2時間ほど1次面接で話すこともザラにあります。それだけ聞いても、120分話しても、120分話した内容しかわからないんですよ。それは人生の何分の1ですか、と。

なので、「わからない」ということを前提にしてやっています。それでも判断はしなければいけないので、いつも「もしかしたら間違ったんじゃないか」ということをすごく考えながらやっています。我々が言うのも変ですが、謙虚な態度はすごく重要です。

あとは応募してくれてる人は人生かかっている、ということを忘れてはいけません。なのでそこはすごく謙虚にやるべきだと思います。

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

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

クラスメソッド株式会社

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 面倒な「営業の活動報告」を工夫したら起きた組織変革 報告数が5.5倍アップ、社員が自ら動き出すしかけ

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!