エンジニアリング経験のない方がエンジニア採用を担当する際に、困りごととしてよく出てくるテーマが、職務経歴書の読み方やスキルチェック方法、スカウト送信の方法です。そもそも、エンジニア用語がいまいちよくわかっていないので、どの候補者がどんなことができるのかがいまいちよく分からない。よく分からないが故に、社内のエンジニアに任せきりにしてしまい、お互いに効率が悪くなってしまっている。そんな話をよく聞きます。
そこでQiita Jobsでは、2021年6月25日に「職務経歴書の読み方と1ランク上のスカウト送信方法」というタイトルでセミナーを実施しました。これは、エンジニア採用を行うために知っておくべきエンジニアリングに関する知識をまとめた「職務経歴書の内容がスラスラ分かる！非エンジニアの採用担当に贈るエンジニア用語集」や、実際の職務経歴書、会話をもとに解説していったものです。
本記事では、こちらのセミナー内容についてレポートします。エンジニア採用の進め方や理解不足に悩まれている採用担当者は、ぜひご覧ください。
登壇者プロフィール
清野 隼史（きよの としふみ）
Increments株式会社
Qiita開発チーム リーダー
アルバイトを経て、2019年にエイチームに入社。Qiita Jobs開発グループでQiita Jobsの開発に携わる。2020年よりQiitaのプロダクトマネージャーに就任する。趣味はサウナ。
職務経歴書を読んでみよう（1枚目）
－－早速、サンプル職務経歴書を見ていきましょう。まず、活かせる経験・知識・技術として「PHP、Java、JavaScript」とあるのですが、この場合、JavaScriptはフロントエンドかバックエンドか、どちらの用途で使っているのでしょうか？
清野：これだけだと、なんとも言えないですね。JavaScriptって、ブラウザで動かせるプログラミング言語でもあるし、PHPやJavaのようにサーバの開発にも使えるので、フロントエンドかバックエンドかは、まだ分からないですね。
－－そう考えると、この候補者は少なくともバックエンドには強そう、と読めますね。次に、OSやDB（データベース）の部分について、人事が見るべきポイントはありますか？
清野：Linuxを使っているのであれば、いわゆる一般的なものは大体作れるだろうと読み取れます。また、ここではWindowsとも書かれているので、Windows特有のシステムも使えるのかな、と読むことができますね。ちなみにLinuxについては表記揺れでUnixと書かれていたり、他にもMac OSなどもありますが、本質的にはあまり変わらないと考えて良いでしょう。
－－DBでの表記を通じて、候補者は何をアピールしたいのでしょう？
清野：データベースも結構色々種類があるのですが、ここではSQL ServerとOracleということで、これらの製品は大規模システムによく使われるので、大きなデータベースを扱うシステムを担当していたのかな、と読み取れますね。
そこまで大きなシステムでないものだと、メジャーなものとしてMySQLやPostgreSQLなどが挙げられます。
－－少し観点を変えて、オンプレとクラウド、どちらの開発環境かを確認したい場合はどこを見れば良いのでしょうか？
清野：クラウド環境だと、AWSやGoogle Cloud、Azureといったワードが出てきたら、間違いなくその人はクラウド環境で開発をしていたことになります。逆にそこが出てきていなくて、DBが先ほど見たようなOracleやSQL Serverだと、クラウドに乗っていない可能性がありますね。
－－よく、テクニカルスキルの使用期間が求人要項でも定められていますが、そもそも年数とスキルって相関関係としてはどうなのでしょうか？
清野：少なくとも相関はあります。ただ、その傾きが標準的かというと、人によってまちまちです。期間だけで見極めるのは難しいところがあるかなと思います。
どちらかというと、期間ではなくてアウトプットの量の方が、技術が好きなのかどうかの判断軸としては良いかもしれません。技術が好きだからこそ、QiitaやGitHubなどでアウトプットしているし、休日も調べることに時間をかけているのかもしれません。
－－最後は自己PRですね。
清野：この辺りを読むと、Javascriptをフロントエンドで使っていたのかなというのが、なんとなく分かりますね。「クライアントから」と書いてあって、消去法にはなるのですが、さっきの言語でクライアントを作れるのってJavascriptしかないので、そのように読み取れます。
－－なるほど。もう一つ、「モノリシック」って何ですか？
清野：結構難しい概念なのですが、よくマイクロサービスの対比として使われます。モノリシックは、いわゆるサーバーに1つのアプリケーションを乗せて、そこで色々な機能を提供していくというものです。対してマイクロサービスは、小さなサービスを積み上げていって、サービス同士のコミュニケーションをとりながら大きなプロダクトを実現するものです。Amazonが最初に提示してやった組み方ですね。あれくらい大きくなってくると、一つのアプリをみんなで作っていくとバグが生まれやすくなってしまうので、小さい単位で運用保守ができるマイクロサービスの方が、ステーラブルになります。
職務経歴書を読んでみよう（2枚目）
－－もう1人、サンプル職務経歴書を見ていきましょう。この方、1番下の「チーム（10名）のリーダー」ということで、開発以外にもマネジメントをしていたということですね。よく「プロジェクトマネジメント」と「プロダクトマネジメント」があると思うのですが、この違いって何になるのでしょうか？
清野：よく出てくる話ですね。プロジェクトマネジメントって、スケジュール管理に近いものだと感じています。どこに誰がどのタイミングで開発していくのかをタスク管理していくイメージで、すでに期日と作るモノが決まっています。
対してプロダクトマネジメントは、そもそも“何を作っていくか”を考える仕事のイメージです。
－－例えばプロジェクトマネージャー（PM）やプロジェクトリーダー（PL）のスキルを見極める指標はいかがでしょうか？
清野：これはなかなか難しい話ですね。技術的な部分はコードなどのアウトプットである意味で分かりやすいと思うのですが、プロジェクトマネジメントって、アウトプットが見えにくいですよね。Qiitaやnoteなどでノウハウをアウトプットしている方がいたら、ぜひ読むようにしましょう。
－－そこで書かれていることで、いいなと思う観点は何になるでしょうか？
清野：プロジェクトって、大小さまざまなトラブルがあると思うんですよね。期日が間に合わないとか。そんな時にどういう選択をとったのか、意思決定やそのスピードなど、その人なりの考えや思考が記述されていると、スキルレベルもある程度わかると思います。
－－JavaとJavaScriptは分かるのですが、Bashって何ですか？
清野：Bashはシェルですね。シェルとは簡単に言うと、OSシステムにアクセスするためのものだとお考えください。Bashと書いてあると、インフラのサーバーへのアクセスとかもやっていたのかなと想像します。
－－なるほど。もう1つ、「アーキテクチャ」とも書いてあるのですが、これが書いてあるとどんなことを想起しますか？
清野：手元だけのコードだけではなく、俯瞰したシステム全体の仕組みなど、もう1個上のレイヤーも考えていたのかなとイメージします。
このように見ていくと、リーダー候補として考えられる候補者なのかなと読むことができますね。
感動するスカウト文面
－－次に、清野さんが実際に感動したスカウト文面をご紹介していきます。どういう文面が心を動かされるポイントになりますか？
清野：すごく自分のことを見てくれていると感じるところですね。オファーが来る時にエンジニアが気にすることの1つは、何で自分に声をかけてくれたのだろう、ということだと思います。
僕のことをしっかりと調べて知ってくれていて、且つその上で、僕の力が必要なんだよと記載されていると、そこに納得感があります。
－－文章量は、全体的にボリュームがあっても大丈夫なのでしょうか？
清野：そこは、僕は気にならなかったですね。そもそもエンジニアって、コードも含めるとものすごい量の文字と接しているので、抵抗のある方は少ないんじゃないかなと思います。もちろん、だからと言って周りくどく、だらだらと書かれていると誰でも嫌だと思うので、シンプルにポイントをまとめて書かれているものも良いですね。
－－なるほど。1つずつ分解していきましょうか。「企業が今どんな課題を持っているか」が記載されていて、次に、清野さんのどんな点が魅力的に映って必要な存在であると感じたのかをサマリーでまとめてくれており、さらにその下に詳細が書かれているような、しっかりとアウトプットを読んだ上でのスカウト文面になっていると、この辺りはどう感じるのでしょうか？
清野：シンプルにめちゃくちゃ嬉しいですね。そもそも何でアウトプットしているかというと、人に読んでもらうためで、人の役に立てるものを出せたらいいなと僕自身は思ってやっているので、学びにつながっているところも含めたこの文面は、すごく嬉しいなと思います。書いてくれているということは、僕の記事を読んでくれたということもわかります。
－－今お話しにもあったと思うのですが、採用担当として、エンジニアの文章をどういう観点で読むのが良いのでしょうか？
清野：よくあるのが「よくアウトプットされているんですね」という言葉なのですが、それって数字だけを見ているのかな、僕自身がどんなアウトプットを出しているのかについては興味がないのかな、と感じます。なので、少なくとも記事に対してどう思ったかという感想くらいは、書いてもらえると嬉しいと思います。
－－あとは、文章の下に会社のこともガッツリと書かれているものもあると思うのですが、ここは読むのでしょうか？
清野：会社のビジョンと、どんなプロダクトを作っているのかは、少なくともしっかりと見る気がします。この会社がどんなことを成し遂げようとしていて、それに対して一緒にやっていきましょうよと訴えかけられると、やはり惹かれますね。一方で僕に限ってお伝えすると、福利厚生や制度、会社がどこにあるかなどは読んでいないと思います。
－－先日Qiita Jobsでは、元P&Gの方をお呼びしてセミナーをやっていただいたのですが、その際に「WHOーWHATーHOW」に分解して考えるという話がありました。こちらの会社では、細かいHOWではなく先にWHATを出していることで、例え読了率が低かったとしても重要なポイントを先に出しているので、良い設計だなと感じますね。
※該当セミナーのレポートはこちら
人は転職で何を手に入れるのか？ 〜P&G流マーケティングで学ぶ採用成功のポイントセミナーレポート
シンプル＋具体性がポイント
今回は「職務経歴書の読み方と1ランク上のスカウト送信方法」というテーマで、実際の職務経歴書サンプルとスカウト文面をケーススタディとしたポイントを解説しました。職務経歴書については、各開発環境がどのような特色を持っているのかを理解した上で読むことで、候補者のエンジニアとしての属性が少しずつ見えてくるでしょう。またスカウト文面については、候補者のアウトプットをしっかりと読み、それに対する具体的な感想と、自社にジョインした場合の具体的な活かし方などをシンプルに分かりやすく説明することが、エンジニアの心を掴むポイントだと言えます。
取材／文：長岡 武司
