エンジニアレジュメ ミキワメガイド
こんにちは！採用plus＋広報チームです。記念すべき初コンテンツです！
「エンジニア未経験人事のための、エンジニア採用の教科書」を目指して立ち上げたnoteですが、さて何を書こうかと早速悩みました…
そんな中ちょうど、お客様から「レジュメを見ても何書いてあるのか、どれくらい能力があるのか、自社の採用要件に合うのか分からない」という声を耳にしました。
確かにエンジニア未経験の人事担当者からしたら、エンジニアレジュメって正直、書いてあることの半分くらい意味が分からず、呪文に見えてくるのがあるあるだと思います（笑）
ということで記念すべき初回コンテンツは、エンジニア未経験の人事担当者でもレジュメを見てスキルを見極めることが出来るようになるため、レジュメのミキワメポイントを解説します！
是非ご覧ください！ご感想もお待ちしております！
※なお、文字情報やアウトプットの情報など情報量の少ない状態で判断する基準を示しています。実際には会って話してみないと判別できないことのほうが多いので、あくまでもスクリーニングという意識を持ってご覧頂けますと幸いです。
01. エンジニア全体の基準となるポイント
（a）スキル
まず開発スキルに関しては、あくまでレジュメ上での自己申告であるため、記載されているスキルのみで見極めるのは難しいです。
「プログラミング言語やフレームワークの名前＋経験〇年」（例：PHP、Laravel２年の経験あり）といった書き方をしている方が多く、この情報では的確な見極めは出来ません。
例えば、SIer（System Integrator：システムの受託開発を請け負う会社）などでJavaでのシステム開発プロジェクトに５年以上関わっていても、一行もJavaのコードがプログラミングできない人、といったケースも多々あります。
そのため、開発スキルは転職エージェントに伝えるための情報や、ダイレクトスカウトの検索条件用として割り切ることが大切です。組織で事前に基準値を決めて置いて、基準を満たしていない場合はNGにする、というのが良い使い方と言えます。
（b）実績
レジュメの見極めに際して最も重要な要素です。ここでの実績とは、「技術を使って何を成し遂げたか」を指します。
例えば、「PHPで２年以上の経験がある」という方は、２年間どんなことをPHP（およびその周辺技術）を使って成し遂げてきたのかを読み込んでみましょう。
例えば、「PHPで２年以上の経験がある」という方は、２年間どんなことをPHP（およびその周辺技術）を使って成し遂げてきたのかを読み込んでみましょう。
例）
・機能改修を行った
・フレームワークや言語のバージョンアップを行った
・自動テストの仕組みを導入した
・アーキテクチャーのアップデートを提案・実施した
・技術負債のリファクタリングを行った
・開発ベンダーをマネジメントしていた
上記のように、経験言語よりも１段階深い内容が実績として記載されているはずです。
「経験年数３年」と記載されていても、簡単な画面改修しかやったことがないエンジニアの場合もあります。反対に経験年数が１〜２年でも、ゴリゴリとコードを書いて長年の技術負債を減らしてくれる人もいます。
なお、あくまでも業務においての実績を確認しましょう。プライベートで最新技術をキャッチアップしているかという観点は、優れたエンジニアを判別する重要な要素の１つではありますが、マストで確認すべきは実績、つまり「技術をビジネスでどう使ったか」という点であることは押さえておきましょう。
ちなみに実績が具体的に書かれていないレジュメより、実績がわかる候補者から優先的にアプローチしていくほうが効果的です。
（c）職歴
職歴や転職年数は、あまり気にすべきポイントではありません。
「2〜3年いれば良いほう」というのが、昨今のITエンジニア転職市場です。おそらく今後ますます人材の流動化は盛んになってきます。従来だと「ジョブホッパー」と呼ばれるような方でも、２年間しっかりと活躍してくれれば万々歳、くらいの感覚で見ましょう。
また転職歴が短い方でも、単純な機能改修を担当するジュニアエンジニアという役割→最適なアーキテクチャーを考えたり、生産性向上にコミットするテックリード→エンジニア組織を経営と束ねるEMやCTO / VPoEなど、転職ごとに自己成長を実現している場合は見逃さないようにしましょう。
またはiOSエンジニア→Androidエンジニア→Flutterでクロスプラットフォーム開発など技術領域を広げていくパターンもよくあります。それぞれどのような背景で転職しているのかを仮説立てしながら読み解けると良いでしょう。
ただし「在籍期間が１年未満の退職が連続している」は例外です。なぜなら、どれだけ優秀なエンジニアでも新しい環境で成果を出すには半年近くかかるからです。１年未満で大した成果も残せないままジョブホップしている人は、今回も同じことを繰り返す可能性が高いかもしれません。
（d）年齢
基準を広く持ちましょう。 ビジネス職と同じく安直に「転職は35歳まで」とする求人も散見されますが、率直に言えばエンジニア採用において年齢フィルターは”ノイズ”になります。基本的にレジュメの見極め時点では年齢フィルターをかけず、まず会ってみることがオススメです。
昔は「エンジニア35歳定年説」という都市伝説が囁かれていましたが、2010年代前半でWeb業界で活躍していた若手エンジニアはすでに35歳以上がほとんど。エンジニアも高齢化が進んでいます。事業会社やWeb系ベンチャーなどでひとつの時代を築いた世代は40代を超えていることも多く、お任せするミッション次第では非常に愚直にコミットしてくれる世代でもあります。
特に経験が多いほど短納期/少数での大規模開発など、炎上した開発案件に関わっている方も多く、胆力はもちろん、突破力がある方もいらっしゃいます。立ち上げフェーズでの開発メンバーポジション等では、即戦力で活躍頂ける可能性も高いでしょう。
（e）年収
実は年齢より年収のほうが、実態の活躍度合いに近い場合がありますが、こちらも盲信は禁物です。そもそも給与は会社の業績や業界の基準値など環境要因にかなり引っ張られるからです。
見方としては、「これはちょっと怪しいかな？」というアラートのために見ておくのはあり。
例えば、同じような業種の他のエンジニアと比べて、経験年数・実績に大差がないのに異常に給与が高い・または異常に低い場合などは、「なにかあるかも？」という感覚を持つのが良いです。
（f）やりたいこと（希望するキャリア）
見極めポイントでは無いですが、エンジニアのキャリアとして臨んでいることが、自社（≒募集ポジション）で実現できるかを、事前情報としてインプットしておきましょう。
例えば、
・手持ちの技術をさらに深めていきたい
・未経験の技術領域にも挑戦していきたい
・組織やチームをよくしていきたい
・事業やプロダクトの成長にコミットしていきたい
といったことが挙げられます。
実績、スキルに加えて、本人がどんなキャリアを望んでいるか。このような点を具体的に記載している人が多いのが、エンジニアのレジュメの特徴です。
面談や面接の際にすり合わせが出来るよう、事前に目を通しマッチするかを見ておきましょう。
（g）働く環境
こちらも見極めポイントではないですが、業務委託や正社員、フルリモートやフルフレックスなどなど、実際に働く環境について希望している場合があります。
よく福利厚生の充実をアピールする企業がありますが、実際には福利厚生よりも「時間・場所の融通が効くのかといった実際の働き方」に関する面、「そして優秀なエンジニアと一緒に働けるか、一昔前の古びた開発ルールや技術ではなく、モダンな技術環境や文化、ルールで仕事ができるか」を大切にしているエンジニアが多いです。
こちらも、面接の際にすり合わせが出来るようにしておきましょう。
02. ステージ別でみるべきポイント
（a）ジュニア（参考年収350万～）
まず注意すべき点は、現段階での技術力に過度な期待をしないことです。その上で、以下のポイントに着目して判別しましょう。
<実務経験者の場合>
経験してきた実績の具体性を見極めます。
・どんな役割で
・どんな問題を解決するために
・どういう技術を使って
・どんな工夫をしてきたか
これらをレジュメから見極めます。逆に言えばこれらがきちんと書かれているエンジニアは、経験が浅くても会ってみるべきと判断できます。
<実務未経験の場合>
他職種からジョブチェンジの場合、レジュメや自己PR、Wantedlyのプロフィールなどで、文章のロジックが通っているか、エンジニアへの挑戦に戦略性があるか、流行りに流されているだけでないか等を見極めましょう。いわゆる「地頭」がエンジニアというロジカルな頭脳労働に耐えうるか、目的達成のために努力できそうかなど、自社内でエンジニアとして育成できるかを判断します。
これまでの学習時間やポートフォリオ、GitHub上でのリポジトリの数や中身、SNSやブログ記事などのアウトプットなどなど、努力の結晶は評価されるべきですが、実務経験が無いゆえに判断できる材料としては弱いです。
また、技術力が見えない場合には、最近気になっているアプリやサービスが何か、直近呼んだ技術本は何かなど、自己研鑽力や情報キャッチアップ力を確認するのも一つの手です。
（b）ミドル（参考年収600万～850万）
エンジニアとして課題解決してきた実績×今後のキャリアパスで判断します。
解決してきた課題の難易度や複雑性、工夫点や努力点など、ジュニア層よりも具体的なエンジニアリング経験にフォーカスします。「どのように課題解決してきたのか」「どのような考えで行動に移したのか」といった点を拾い上げましょう。
なお、解決課題の難易度や重要性については実務経験が無いと難しい部分なので、現場のエンジニア数名の意見も参考にすることが良いでしょう。
加えて、エンジニアとして今後どのような道を歩みたいと考えているかも重視しましょう。
・現場から少し距離を置いて、マネジメントにシフトチェンジしたい
・プロダクトの新機能開発よりは、開発環境・基盤の整備や生産性や開発体験の向上がやりたい
といったことが挙げられます。
自社が候補者の希望に対してどこまで柔軟性を持って対応できるかを判断することも大切です。
▼Tips
現場のエンジニアを巻き込んで採用するのがベストと言われますが、レジュメを丸投げしているだけではエンジニアも疲弊してしまいます。ですので、特に子の箇所にポイントを絞り「解決してきた課題の難易度や重要性、自社でも再現可能かどうか」に絞って意見を聞くようにすると、とても効果的です。
（c）シニア（参考年収850万～1,500万）
CTOやVPoE候補、テックリードクラスを指します。この人が来ることで、組織のどんな課題が解決できるという仮説がある？またそれは現メンバーも納得していることなのか？ という視点で考え、レジュメを見るようにしましょう。
大切なのは、技術力や経験がマッチしていても、自社で活躍させることができるのかです。
・受け入れる環境があるか
・新規採用ではなく、自社のメンバーを育成して充足することが出来ないか
・関わり方は柔軟に考えられないか（正社員／業務委託／技術顧問 など）
・コストや役割の問題で現メンバーとハレーションの危険性はないか。あればどう対処できそうか
といった、候補者側の情報よりも、自社との関わりを考える必要があるポジションです。
・環境が変わっても新しい課題を発見し解決してきた
・他職種を巻き込んで自らの手段に固執せずに課題解決を推進してきた
など、キャリアを積んでも新環境で自らをアップデートできる、してきた経験がレジュメから読み取れるとなお良いでしょう。
03. まとめ
いかがでしたか？
大切なのは、書かれていることを「要素別」また「レベル別」に、「重要ポイントを見定めて」見極めていくことです。
「エンジニアのレジュメを読んでもさっぱり理解できない」という方も、書かれていることを分解していけば、必ずミキワメのプロになることができます（勉強は必要ですが…）。
エンジニア採用の難易度と専門性はますます上がっておりますが、優秀なエンジニア採用の一助となれば幸いです。また、気になるテーマがあれば、是非コメントを待ちしております！
それでは、また次回の投稿をお楽しみに！
株式会社ワールドリード
採用plus＋事業部 広報担当
https://saiyo-plus.com/
<問い合わせ先>
TEL：03-5829-3660
MAIL：t.suga@worldlead.jp
担当：須賀