paiza開発日誌

IT/Webエンジニア向け総合求人・学習サービス「paiza」(https://paiza.jp ギノ株式会社)の開発者が開発の事、プログラミングネタ、ITエンジニアの転職などについて書いています。

日本のエンジニア採用で、技術力が軽視される理由

f:id:paiza:20130918201254g:plain今回のpaiza開発日誌は片山がお送りします。

現在日本で転職をしようとすると、書類選考後面接、というのが一般的な選考プロセスで、エンジニアの採用でも同様のプロセスがとられている企業が殆どです。
 

しかしコードを書けるエンジニアを採用したいのであれば、まずコードが書けるかどうかを見極めて、そのあと面接したり履歴書を見たりする方が理にかなっていると思わないでしょうか。技術に自信がない人は違うかもしれませんが、エンジニア側としても喋りや書類などによるアピールよりも、技術力でアピールできた方が良いでしょう。

徐々に状況は変わってきていますが、考えてみると当たり前と思えるエンジニア採用時の技術力チェック・プログラミング面接という事がなぜいままであまり行われてこなかったのでしょうか。今回はその辺りについて考察してみます。

TwitterGoogleの採用選考は技術面中心

毎度シリコンバレーが比較対象になってしまいますが、海外の事例としてTwitterGoogleの採用選考の様子が書かれているブログがあるので紹介いたします。

Twitter 社採用面接受験記
 http://d.hatena.ne.jp/elm200/20110926/1316992422

相手は日本人とはいえ、面接のスタイルは完全にシリコンバレー式。「どうして Twitter に応募したのですか?」などというありがちな質問はそこそこで終わり、あとは数十分、ひたすら技術的な問題を浴びせかけられた(一人の面接に 30-40分をかけるのだ)。

私は合計8人(!)の面接官と本社で会った。シリコンバレー式の面接では、面接官は一度に一人しか出てこない。そして、30-40分の間、難しい技術的問題で候補者をギリギリに締め上げるのである。ある問題が提示され、それを解決する疑似コードをホワイトボードに書かせることが多かった。


◆[翻訳]Google の面接を受けてみた
 http://d.hatena.ne.jp/shiumachi/20090122/

合計8回の面接があった。最初の3つは電話越しで(電話面接)、残りの5つは現地での面接だった。リクルーターとの最初の面接はそれほど技術的じゃなかったけど、残りの7つの面接はとても技術的な話だった。

どこまでの技術レベルを求めるかは別にしても、ITエンジニアを採用するのであれば求職者としても、求人企業としても技術レベルをお互い確認してからのほうが合理的だし、納得感があります。雇用環境の違う日本と米国で単純比較はできませんが、面接の回数、会う人数は別としても、これらの事例はITエンジニアの採用として合理的な採用プロセスでしょう。

しかし翻って日本の採用事情を見てみると、どの職種でも定型の書類選考⇒面接という採用プロセスで、エンジニアの採用においても営業職や事務職などと同じこういったプロセスが用いられます。ごくたまに性格診断テストが入るぐらいというのが実情です。何故こういったことがが起きるのでしょうか。
※もちろん最近では一部の企業では技術力診断を自分たちで作って実施されていたり、面接の場で白板に書かせるようなところもありますが、まだ一部と言えます。

選考基準、選考プロセスが時代についてこれていない

原因1:履歴書、職務経歴書以外の選考ツールがない

採用選考というのは、企業にとって非常に重要なものであるものの、多くの候補者と面談を複数回繰り返す必要があり、時間と労力が必要になる作業です。そのため、会う前に履歴書、職務経歴書から読み取れる過去の実績をベースに、その人に会うかどうかを判断する事で、企業側の面接効率を上げようというのが書類選考の意義で、企業にとっては合理性のある行為です。

しかしエンジニアにの選考プロセスにおいてもそれが言えるでしょうか?全体像が全く見えないよう巨大プロジェクトで、仕様書ががっちり作られており、ひたすら部分的なコーディングする作業をやっていた実務経験5年と、一人で要件定義からインフラ環境構築、設計、開発、テスト、運用を行っていた実務経験3年では経験の質は全く違う内容です。

こういったことが書類上できちんと読み取れるように求職者が書けて、それを採用側も読み取れれば問題ないかもしれませんが、書く人によってフォーマットも違えば、同じ表記でも意味することが全く違うのが普通です。

私自身もエンジニア経験がありつつ、エンジニアの採用も長いですが、なかなか書類だけで的確に技術力を判断するのは難しいと痛感することが良くあります。

今時さすがに少なくなってきてはいますが、履歴書は手書きでなければ減点、印がまっすぐでないと減点、顔写真は証明写真でとったもの張り付けていないと減点(印刷はNG)など明らかに時代にそぐわない内容で選考されることもないわけではありません。(こういった事「履歴書の書き方」といって指南しているサイトなどもたくさんあります。。)これらは、履歴書、職務経歴書しか事前の選考ツールがなかった時代の名残です。

そんな細かい手書きがどうだ、という事に時間を割くならば、コードの一つでも張り付けてもらった方がよっぽど意味があるでしょう。

原因2:現場が求職者のコードを見ている暇がない

原因1とも関連する話ですが、履歴書、職務経歴書以外にコードの提出を義務づけたとしても、人事部ではコードの善し悪しを判断できないため、現場のエンジニアが採用にかり出される事に成ります。

より良い採用をするのであれば、現場のエンジニアも採用に加わった方が良いのですが、採用が必要な部門というのは、誰か辞めてしまい欠員補充なのか、仕事量が増えており現存メンバーだけでは仕事がまわしきれないための追加採用なのか、という状況が殆どのため、どちらにしろ現場は人手不足で忙殺されている状況のため、なかなか採用にまで手が回らない事が多いのが実情です。

採用する場合、1発1中で採用出来るという事はまず無く、通常一人の採用に10名程度の面接はするため、面接だけでも出席者数×1時間×10の工数が取られる事に成ります。またこれらの面接前に書類選考+コード選考をを行うと考えると、更に多くの時間が現場エンジニアから裂かれる事に成ります。

CTOが居て採用に時間を割けるのであれば、こういったフローも可能ですが、そういった体制が整っていない企業もまだ多いのではないでしょうか。そういった事情もあり、面接以外に事前のコード選考をするとなると、なかなか一歩が踏み出せない企業が多くなるのもうなずけます。
※ブログを書いていればurlを教えてくださいと事前に言われるのに、面接時にはブログについて何も言われないという経験はないでしょうか?これも上記と同じ事が起きていると推察されます。


原因3:エンジニアの役割がコストセンターからプロフィットセンターへ

これまでIT技術というと、コストセンター(売上計上がなく費用だけが計上される部門)である情報システム部が中心となり、外部ベンダーに発注をしてシステムを作るという事が中心でした。コストセンターは経営陣から見ると間接部門であり、売上があがらないため、評価対尺度はコストだけが対象になります。そうなると行きつく先はコストダウンしかなくなり、コストが小さければ良いという評価になり、部門の風土も必然的にいかに安く上げるかにしか興味が行かなくなります。

安く上げる事を考えると固定費として中にエンジニアを抱えるよりは、変動費として必要な時だけ利用できるよう外部のエンジニアに依頼するほうが良いという考え方になります。また競争力の源泉となるようなコアな技術であれば外に出してしまうと競争力がなくなってしまいますが、コストとしてみると、同じような仕事を繰り返ししている外部の専門家に頼んだ方が習熟度が高く、安上がりになります。これらの事からこれまでIT技術は「コスト重視の外注」という考え方になりがちでした。

しかし現在IT技術ははコストカットのための道具ではなく、利益の源泉としての捉えられ方のほうが強くなってきています。以前のように間接部門として情報システム部を置くのではなく、事業ごとに開発・製造機能を持つことで、事業特性に応じて意思決定も資源配置も迅速に行える体制とし、事業部の中にエンジニアがいる形が取られることが多くなりました。事業部は売上と費用を持つプロフィットセンターであるため、評価尺度も「売上 - 費用 = 利益」という軸になります。そうすると単純なコスト削減には意識は向かわなくなり、より攻めの姿勢へと変化します。

この傾向を裏付けるように、一般社団法人 電子情報技術産業協会が下記のような調査データを公表しています。

「ITを活用した経営に対する日米企業の相違分析」調査結果の公表について
● IT/情報システム投資:「極めて重要」が日本は約16%に対して米国では約75%
● IT予算が増える理由 :日本は「業務効率化、コスト削減」がトップ、米国は「製品・サービス開発」や「ビジネスモデル変革」と攻めの姿勢が顕著

投資というのは通常後のリターン(売上げ増、利益増)を期待して行うものであるため、コスト削減にしか目が向いていない場合、すぐにコスト削減できる事が判っているものにしか投資をしないという消極的な姿勢に成ります。このデータから、日本はIT投資をコスト削減手段として利用し、米国では新しい製品・サービス開発や、ビジネスモデルの変革という競争力の強化、新たなマーケットの開拓手段として利用している事が読み取れます。このデータでは、日本はまだコスト削減のとしてのIT投資ですが、この3年ぐらいで米国型に変わってきているのでないかと私は考えています。

この変化がエンジニアに何をもたらしたかというと、これまでエンジニアは守りのためのコストとみられていたものが、攻めのための競争力の源泉として見られるようになった点です。技術流出を防ぐために外注から内製へと切り替わり、高い技術力、高い専門性が求められるように変わってきています。

こういった変化に採用手法、プロセスがまだついてこれていないのがというのが実情でしょう。(ただこの1年でいえば、ポートフォリオによる転職サイトやソーシャルリクルーティングなど、新たな方法論も出てきています。)


エンジニアの置かれている環境変化のイメージ
f:id:paiza:20131130175041g:plain

今後ネット系企業は技術力中心の面接にシフトしていく

冒頭でも書いたように、すでに米国では技術力を見るための面接が中心に採用活動が行われていますが、日本でも今後この流れが中心になっていくと考えられます。

プログラミングのみ・面接なしで内定決める「コード採用」 サイバーエージェント
http://www.itmedia.co.jp/news/articles/1205/14/news062.html

グリー、エンジニア採用に新ツールGREE Programming Challenge」を導入
http://corp.gree.net/jp/ja/news/press/2012/0601-01.html

日本でもここに取り上げたようなプログラミング力を中心とした採用手法の導入も徐々に導入されています。また面接の場でホワイトボードにFizzbuzzを書かせる採用を行っているという話もよく聞きます。
 
今後採用企業としては、こういったプログラミング力を面接の中でどう見ていくか? 書類選考前の代わりにプログラミングテストを実施するのか?などを真剣に検討して行く必要が出てくるでしょう。またそれを実行するために、現場のエンジニアの時間をどう採用に回すかを考えなくてはいけなくなります。

また求職者サイドとしても、喋りやプレゼンテーションではなく、技術の面での実力が求められるようになるため、コピーアンドペーストや手ぐせのみのプログラミングではメッキがはがれてしまう可能性があり、より体系的に、そしてフレームワークの裏側でどのような処理が行われているかなどの、深いレベルでの理解が面接時にも求められるようになっていくと考えられます。

どうやって解決していくべきか

ここからは深夜の青汁CM的な展開になりますが、ここまで書いてきた転職時、採用時の課題を解決するためにコーディング転職サイトpaiza[パイザ]を立ち上げました。

エンジニアの採用なのにコードより先に書類を見るというのは合理的ではないですし、技術的な部分があまり問われないまま選考が進むことも、求職者、求人企業にとってミスマッチの原因となりえます。こういったことを少しでもなくし、技術がきちんと評価され、コードのにおいがする人が上層部、経営層に増えると、少なくとも炎上プロジェクトは少なくなるはずで、技術がわかっていない事によるロスはだいぶ減るはずです。
※現場を知りすぎている人が上に行くとイノベーションを起こしづらくなるというジレンマはあるとはいえ、Googleなどを見ているとそうとも限らないと思えます。

こういったミスマッチを無くし、より技術面にフォーカスした今の時代に求められている転職インフラとして作ったのがpaizaです。paizaでは幾つかのプログラミング問題が出題されていて、コードが書ければ、書類選考がなくなり、いきなり面談の日程調整に入れるようになっています。また「カジュアル面談」を選べば私服での面接となり、志望動機をいきなり聞かれる事もありません。言語はJava,C,C++,C#,PHP,Ruby,Python,Perlに対応しており、書いたコードは提出前にオンラインでテスト実行する事も可能になっています。

今後面接時にも白板等でのコーディングテストが実施されることもあると思いますので、その対策としても是非paiza(http://paiza.jp)を使ってみてください!


更に宣伝。paizaオンラインハッカソン!

本題と全く関係ありませんが、12月2日〜1月8日の期間限定で、オンラインで気軽に参加できるオンラインハッカソンも開催しています。こちらは、まだ転職する気がない方でも気軽に参加できて、人のコードを見て学べる場として設定しています。

オンラインハッカソン「paizaオンラインハッカソン(略してPOH![ポー!])」|http://paiza.jp/poh/ec-campaign/


プログラミング入門講座|paizaラーニング

PHP入門編Ruby入門編Python入門編Java入門編JavaScript入門編C言語入門編C#入門編アルゴリズム入門編