9月16日開催のcodeIq感謝祭に弊社スタッフも参加して参りました！
今回はこちらのセッションの内容レポートです！
今回も参加されたみなさんのTweetとともにお送りします！
エンジニア採用担当者が読みたくなる職務経歴書のポイントは？
エンジニアとしてのキャリアをわかりやすく、かつ効果的にアピールするためのポイントがわかるセッションが追加されました！ドワンゴの技術コミュニケーション室 室長の塩谷 啓さんが「採用担当者が読みたくてたまらなくなる職務経歴書を書くために絶対に外せない3つのポイント」を語ってくれます！必見です！
ドワンゴ塩谷さんの持ちネタ、こんにちは！から始まる絶対読みたくなる職務経歴書セッション始まった #codeiq39 pic.twitter.com/w8HdZDHBet
— 馬場美由紀@CodeIQ中の人 (@miyaq) September 16, 2017
☆登壇者プロフィール
株式会社ドワンゴ 技術コミュニケーション室 室長 塩谷 啓さん
2010年入社、別会社への転職を経て2014年再入社。「アニメロミックス」「N高等学校」「N予備校」などの開発チームにおいてリーダー、マネージャーを務める。現在は「技術コミュニケーション室」の室長に専念し、「エンジニアの生産性をあげる」というミッションを掲げ、教育・採用・環境整備などさまざまな取り組みを行っている。
エンジニア採用担当者が読みたくなる職務経歴書のポイントは？
というタイトルで始まった本セッション。
いきなり「読みたくなる職務経歴書はありません！」という出オチでした。
つまり、本セッションは塩谷さんが面接で実際に遭遇した、こういう書類はいけない！という『アンチパターン集』。
つまり「読む気が失せる職務経歴書とは？」が正しいタイトルとのことでした。
editページぶくまっちゃったので上げ直し。本日のスライドです。 #codeiq39 / “Three points to write resume that recruiters will want to read // Sp…” https://t.co/nnxmnxlDFO
— SHIOYA, Hiromu (@kwappa) September 16, 2017
こちらのスライドに詳細はあるはずですので、以下は内容をまとめることにします。
！ 駄目な書類パターン１： ファイルを１つずつ別々に送ってくる。
例：職務経歴書→word、履歴書→excel、推薦書→pdfなど。
これマズいっていうのを私は初めて知りました。みなさんやりがちじゃありませんか？
確かに、言われてみれば３つひとつひとつダウンロードして開くのって手間ですよね。どうせばーっと目を通したいのだから、pdfなんかに、ひとつにまとまっていたら見る方も楽ですよね。良いこと聞いた！次回から真似しよう！
！ 駄目な書類パターン２： 職務経歴書は新しい順に、具体的に。
例：職務経歴書がなぜか古い順。
例：DBや言語にバージョンが書いていない。
例：『開発』って具体的に何をしたのかが書いていない
採用担当者はやはり、最新の経歴を一番に見たいそうなので、それを冒頭に持ってくるのがセオリーだそうです。これは確かに当たり前ですね。
DBや言語のバージョンについて、これは個人的な経験なのですが、履歴書作成を転職のエージェントさんに依頼すると、こういうバージョンが抜けた職務経歴書が出来上がりますね。エージェントさんはそこまでエンジニア関係の知識がない人が多いのか、PHP、CSS、と書いて終わりという職務経歴書を作ってきます。それを『転職のプロが作ったのだから大丈夫だろう』とそのまま提出するとこういう指摘を受けるわけですね。
！ 駄目な書類パターン３： 職務経歴書にマクロを仕込む。
例：職務経歴書のexcelを開くと、マクロが立ち上がろうとする。
これ会場が爆笑したところです。怖すぎでしょ、その職務経歴書！
普通はこんなことにならないと思いますが、塩谷さんに来た職務経歴書には実際にあったそうです…
「採用担当者が読みたくてたまらなくなる職務経歴書を書くために絶対に外せない3つのポイント」 絵メモ1
職務経歴書にマクロ‥？！
つい書きがちなNGワード#codeiq39 pic.twitter.com/Ht3aEN6fv0— sakura@ (@818uuu) September 16, 2017
！ 駄目な書類パターン４： NGワード『サブリーダー経験があります』。
他には
例：『コミュニケーション能力があります！』
例：『長時間勤務で頑張ってきました』
これ、以外とやっちゃうアピールポイントなのではないでしょうか…
「『サブリーダー経験』は、何をしたのかわからない」というのがダメなポイントだそうです。上記の『開発とはなんぞや』と同じように、自分が組織の中でどのような役割を担って、どのような成果を出したのかをきちんと書きましょうと言うことですね。
また、興味深かったのが塩谷さんいわく、「エンジニアのコミュニケーション能力とは、隣の席の人とうまくやること」だそうです。もし、客先や他職種との交渉などのコミュニケーション能力をアピールしたいのであれば、そのことを具体的に書くべきだそうです。
それと聞いていて耳が痛かったのですが、『長時間稼働平気です』アピールですが、奴隷の根性アピールになるのでダメだそうです。むやみに残業して仕事をこなすのではなく、いかに時間内にスマートに仕事が出来たかをアピールする方が好まれるということですね。
でも現実に面接を受けていると、「残業も時期によっては多くなりますが大丈夫ですか？」という質問はかなり多くの会社で聞かれますので、ここは聞かれたときに口頭でアピールしたら良いと言うことなのでしょう。
！ 駄目な書類パターン５： ＪＡＶＡスクリプト
ＪＡＶＡサーブレット
ＪＡＶＡアプレット
ＪＡＶＡスクリプト
カタカナの上に全角っていうのがさらにポイント。会場はＪＡＶＡスクリプトのところで爆笑でした。
職務経歴書や履歴書は『エンジニアが読んで読みやすいもの』を心がけよということですね。全角英数はなんか気持ち悪いと感じる人は多いですし、『ＪＡＶＡスクリプト』ってもう…用語も正規表現を心がけましょう！
アンチ職務経歴書パターン
– SNSのアカウントで現職をdisってるのはNG
– 単語をちゃんと書いてない(JAVAサーブレット、JAVAアプレット、JAVAスクリプト
– アレコレやりたいと色々書くにも関わらず、GitHub等での活動がない#codeiq39— Yosuke FURUKAWA (@yosuke_furukawa) September 16, 2017
！ 駄目な書類パターン６： だめなＳＮＳが見える
例：検索するとSNSが出てきて、そこで会社の批判を行っている。
例：Githubのアカウントが半年何も稼働してない
例：ワナビーばかり書いてある
ここまで見られているのか！と胸がしめつけられる採用の現状。
SNSもお行儀良くということですね。会社批判は、「うちの会社に入ってきても同様にdisるんじゃないかな」と思われちゃいます。
ちなみにここで、会場内に「SNSやってない人～？」と質問を投げかけましたが、手が上がったのは数名！ほとんどの人がSNSをやっているということですね。エゴサーチ対策、気をつけましょう。
また、PR欄にワナビーを書くのは良いが、ワナビーだけ書いて勉強会や技術書を買って終わりにしているエンジニアは良くないそうです。エンジニアは休みの日にもコードを書かなければならない、というわけではなくが、Githubのアカウントがまるっきり活動無しはちょっといただけないとのこと。
Githubに上げるほどでもない勉強を細かくしている可能性もありそうですが、やはりアウトプットありきの業界なので、アウトプットを何かしらしていて欲しいということですね。私もこのブログを早く書き上げなければ！
https://twitter.com/llminatoll/status/908928830160617472
！ 要するに ！
エンジニアの採用面接であれば、『エンジニアが見て不快感を抱かない職務経歴書』作りがポイント、ということですね。
自分が面接官になったつもりで、書類を一通り見直してみる必要がありますね。
塩谷さんの最後のコメントは『大切なのは書類ではなくあなた自身。ウソをつかず、自信を持って』という言葉で締めくくられました。
私はまず、書類の前に自信が持てる経歴が欲しい！笑 がんばります！
書類はエンジニアが読むもの。#codeiq39 pic.twitter.com/70q4yb5YaT
— ぴすれ (@pslet) September 16, 2017
