オファーが届くレジュメは、何をどう書くといいの？
企業から年収を明示したオファーが届く、ITエンジニアのためのスカウトサービス「moffers（モファーズ）」。
エンジニア特化型のレジュメ（職務経歴書）スタイルなので、これまでの開発経験や使用技術だけでなく、プライベートで作ったプロダクトもアピールでき、そして自分の希望年収ややりたいことも伝えられます。
ただ、登録するときに困りがちなのが「レジュメって、何をどのように書けばいいの？」ということ。
- 今よりプラスアルファの年収がもらえたら嬉しい。
- どうアピールすれば、自分の実力を年収に反映させられるかわからない。
でも、実は書き方ひとつで、オファーの年収提示額を上げたり、希望する業界や開発プロジェクトのオファーを受けたりできるんです！
ITエンジニアのためのレジュメノウハウを、moffersのキャリアアドバイザーアキコさん、moffersリナさんに、根掘り葉掘り聞き出してきました！
こんな感じでmoffersのレジュメを書いてみたんですけど……どうですか？
今までどんなことをしてきたのか、くわしく書いてあるので、とても良いと思います。ただ次のキャリアの具体的な話が少ないですね。
次の希望キャリアを明確にして、それを踏まえて活かせるキャリア・要素を選択するのがポイントです。
ポイント1：次の希望キャリアを明確にする
次のキャリア、ですか？
はい。たとえば、今後
- リーダーやマネジメントの経験を積みたいのか
- 業務やシステムのコンサルティングの方面へ進んでいきたいのか
- エンジニアとして技術力を上げていきたいのか
さらに、どのキャリアを希望しているのかがハッキリ書かれていると、企業側も判断しやすくなります。
マネジメント系に進みたいなら、今までの仕事経験の中からマネジメントに関わった部分を書く。
コンサル系に進みたいなら、「お客様が本当に解決したいことは何か」といった、一歩踏み込んだエッセンスを入れる。
技術系に進みたいなら、技術的なエッセンスをもう少し入れる。
いずれかに振り切ると評価が高いと思います。
そういう意味では、僕はエンジニアとして技術力を上げていきたいですね。
でも、『技術力を上げたい』だと『個人で勉強すればいいのに』って思われちゃいませんか？
それは伝え方や内容によりますね。企業の業務内容によっては、個人が自宅でできる範疇を超えているものも多くあります。
たとえば金融システムの開発なんて個人ではできませんよね。有償のシステムや技術もありますし。
なるほど。安心しました。
ポイント2：プロジェクトの大目的から書くべし
ほかに気になったのは、プロジェクトの大目的が書かれていないことですね。
大目的、ですか？
そもそも「そのプロジェクトはなんのためにやったのか？」という部分ですね。大目的が抜けているレジュメって結構多いんです。目的を明確に書くことによって、プロジェクトの進め方や優先順位の決め方、ゴール設定などが見えやすくなります。
ポイント3：過去の仕事内容は具体的に書くべし
過去やったことについては、かなり詳しく書いていただいていますね。いいと思います。あえて言うなら、もう少し具体的な要素があるとGOODですね。
例えば
- どのような業界？
- ユーザー数や平均アクセス数は？
- どんなシーンで使われる？
といったことです。「Webサイト制作」としか書かれていないレジュメも、わりと見かけるんです……。
▼過去に携わった業界・仕事内容は具体的に！
たしかに、Badパターンはあるあるですね。 エンジニアの方のせっかくの技術力を年収に反映させるためにも、moffers上でも「もう少し具体的に書くと、企業に評価してもらいやすいですよ」というアドバイスをフィードバックしています。
プロジェクト人数やサーバー台数といった規模感を定量的に書くと伝わりやすいと思います。特に人数については、プロジェクト全体と、ご自分の参加チームとを分けて記載するとGOODです。
「具体的なほうがいい」とはいっても、書きすぎちゃうとそれはそれでマズいですよね？
その通りです。企業から見て人気のあるレジュメは、定量的で文量が多すぎないものですね。
人事は一度にたくさんの人数をチェックするので、長すぎると読んでもらえないこともあるんです。
ひとつのプロジェクトあたり、パソコンの1画面以内におさまるぐらいを目安に書くといいと思います。ちょうど次のような文量です。
▼多すぎず、少なすぎない適量なレジュメ分量サンプル
ポイント4：技術用語に注意するべし
あかささんのレジュメは問題ないんですが、技術用語の使い方にも注意が必要です。 レジュメって、もちろん人事担当も見るんですけど、開発現場の人もチェックするので。技術用語の使い方は厳しくチェックされる方が多いです。
たしかに、僕も「JavaScript」が「JAVA Script」と書かれている記事とか見るとモヤッとしますね（笑）。
そうそう、その感覚です。
他にも、項目と内容があっていないと違和感がありますよね。
というのは？
「課題」という項目なのに、課題が書かれていないといったパターンです。
また、「やったこと」「できること」を分けて書くのも重要ですね。
細かいことのように思えますが、それだけでレジュメ不合格になる会社さんもあるんですよ。
ええーっ。そうなんですか。気をつけます！
ポイント5：やったことだけではなく、結果も書くべし
わりとあるんです……やったことだけが書いてあり、結果が書いていないレジュメ。
やったことだけしか書いてないとマイナスな印象です。「その結果、何がどうなったか？」まで書きましょう。
たとえば
- やったこと：テスト自動化のためのツールでテストを自動化し、開発にかかる時間を短縮した
- その結果：納期を●か月短縮した
というスタイルで書くのをおすすめします。
この点では、あかささんは問題ありませんでした。しっかり結果とセットで書けていますね。
逆に、結果しか書かれていないレジュメもたまにあります。
結果だけでなく、そうなった理由を書きましょう。リーダー・マネージャー志望の方なら、これは特に重要です。
やったこと → 結果 → それによって、どんないいことがあったのか
この一連の流れをワンセットにして、端的に書けていれば素晴らしいと思います。
ポイント6：定性的なものと定量的なものを分けて書くべし
結果を書く上でのポイントってありますか？
定性的なものと定量的なものを分けて書くのがポイントですね。
たとえば次のような書き方です。
事例1（2003年頃の想定）
▼定性的な事例
スマホの普及に伴い、自社のECサイトのスマホ対応アプリ化を推進した。社内にスマホアプリ開発経験者がおらず、iOS及びAndroidに対応したアプリ開発技術を独学で学び開発に従事した。本やWebで学ぶだけでなく、エンジニア主催の講演会や勉強会にも時間外に積極的に参加してUnityについての知見も習得した。
その結果、期日通りiOS、Androidそれぞれのアプリをリリースすることに成功した。リリース後の運用において、他社に先駆けてリリースしたことがプレスリリースとしても発表され、自社が「IT投資に盛んである」というブランド構築を実現できた。
▼定量的な事例
スマホの普及に伴い、自社のECサイトのスマホ対応アプリ化を推進した。アプリをリリースしたことで、PCを使わずスマホしか活用していない顧客の獲得を実現。月利用者数を4000人から5800人に増やすことに成功した。
また、弊社サイトの利用顧客は30代が40％と高く、対して20代が20％と低かった。この20代顧客獲得についても、スマホアプリのリリースを通して比率を30代と同等程度の35．7％まで向上することに成功した。
事例2
▼定性的な事例
製造業向け物流・在庫管理システム開発に従事をしていた。社内の人員不足や納期が迫っていることなどを踏まえ、アプリケーション部分だけでなくDB周りまでの全体の開発・マネジメントに従事した。
アプリケーションからDBまでを一貫して技術的・業務的にマネジメントすることで、エンジニア間での認識齟齬を防ぎ、スピーディーに開発を行うことができた。結果的に納期までにシステム開発をすることに成功した。
▼定量的な事例
製造業向け物流・在庫管理システム開発に従事をしていた。プロジェクトの都合もありエンジニア数が足りない中でメンバーの業務過多が発生していた。リーダーとして現状のプロジェクトの状況やマンパワーを整理し、チーム間で仕様や開発進行状況の共有が的確に行われないため、手戻りが多く発生していると感じた。
そこで、他チームリーダーと連携し、進行状況共有のシートを共通化した。
また、リーダー・サブリーダーレベルでの定例会議の頻度を2週間に1回1時間実施から、1週間に1回30分実施に変更し、密な情報連携を行える様にした。その結果、業務が効率化され、メンバーの残業時間を15％削減、期日内のシステムリリースも実現できた。
同じ事例でも、定性的に書くか定量的に書くかでこんなに違いが出るんですね！
参考になります。
ポイント7：未経験の分野を狙うには、作ったものを載せるべし
近年、AIやロボット技術が盛り上がってきていて、未経験だけど仕事にしたいという方もいらっしゃいますね。
未経験の分野であってもオファーされるコツってあるんですか？
はい、ありますよ。
単に「勉強しています」だけだと見込みは薄いですが、「勉強しています＋作りました」というように、意欲とアウトプットの両方がセットで書かれていれば、可能性はあると思います。
作ったものっていうのは、個人で作ったアプリやWebサービスですかね。
そういったものは、moffersの入力欄のどこでアピールすればいいんですか？
こちらの画面でアピール内容を「業務」か「プライベート」か選べるので、「プライベート」に設定していただき、ものづくりに対する情熱をアピールしてください！
ここでは、技術コミュニティでの活動や、登壇履歴などをアピールしていただくのもよいと思います。
また、GitHubやQiitaのURLを記入できる欄もあります。特にGitHubをチェックされている企業さんが多いですね。
自分のアウトプットを見た上で、企業から声をかけてもらえると、エンジニアとしても嬉しいんですよね！
さらに、もう1ポイント！
- なぜ、それをしたいのか
- その技術に関わることで何を実現したいのか
も合わせて書くと、評価が高いと思います。
ポイント8：QCD等のフレームワークを取り入れるべし
最後にもうひと押し「ここに手を入れれば、もっとレジュメのクオリティーが上がるのに」というポイントがあったら教えてほしいです。
はい！お教えしましょう。
QCDや5W1Hなどのフレームワークを取り入れて書くと評価が高いです。
こういったフレームワークが使える人なのかどうか、というのは見られています。
というのも、先ほどもお話しした通り、レジュメは人事だけじゃなく現場の人も見るんですよね。
「QCDのCが抜けてる。コスト意識ないよね。だからプロマネできないよね」ですとか。
なるほど。僕も、一度書いたレジュメ内容をQCDで整理し直そうと思います！
◆QCDとは
- Quality（品質）
- Cost（費用）
- Delivery（納期）
これら3つの要素をまとめた、主に製造業において設計・生産時に重視されるポイントのこと。
◆5W1Hとは
- いつ（When）
- どこで（Where）
- だれが（Who）
- なにを（What）
- なぜ（Why）
- どのように（How）
これら6つの要素をまとめた、情報伝達のポイントのこと。
総括して、あかささんのレジュメを直すとしたらどこ？
- 次の希望キャリアを明確に意識して書く
- プロジェクトの大目的を入れる
- なんのシステムかがもう少し具体的な目安があるとGOOD
- QCDのフレームワークを取り入れるとよりGOOD
あかささん、アドバイスを受けてどうですか？
自分の経験やアピールしたいポイントなどを書く機会はなかなかないので、実際に転職アドバイザーからアドバイスをいただけるのはありがたいですね。
あと、Web上でのフィードバックが丁寧で、優しい印象を持ちました！
アドバイスも具体的でわかりやすかったです。
よかったです！フィードバックにはこだわっているんです。質ももちろんですけど、特にこだわっているのはトーンですね。
指摘するにしても「こうしてください」ではなく「このように書くとよりよくなりますよ」というトーンで伝えるようにしています。
そうなんです。moffersのキャリアアドバイザーは「ビシバシ指摘する」というよりかは「よりよいレジュメになるようにお手伝いをしている」んですよね。
フィードバックの総評・入力不備は、moffersログイン後のダッシュボードの一番上に表示されます。プロジェクト詳細は、プロジェクトごとにアドバイスしていますよ。
【おまけのQ&A】フィードバックはみんなしてもらえるの？
moffersって、すべてのユーザーのレジュメに目を通してアドバイスしているんですか？
はい、そうですよ！ キャリアアドバイザーのチームを配置して、万全の体制でレビューしています。
フィードバック後は、みなさんのレジュメのクオリティーが目に見えて向上します。それがとても嬉しいですね。
【PR】あなたの本当の評価がわかる！年収確約サービス「moffers」
登録した詳細な経験・スキル情報に基づき、企業が「年収」を明示した形でスカウトを行う、ITエンジニアのための転職サービス「moffers」がオープンしました！
あなたの本当の評価がわかる「moffers」に登録してみませんか？
■プロジェクト概要（目的・人数・体制など）
▽プロジェクト概要
金融系顧客の既存業務システムの改修、新機能の追加の短期プロジェクト
▽プロジェクト目的
既存システムとユーザ業務が乖離していたために、業務に沿うようにシステム改修が必要であった。また、システムを用いたユーザ業務の中で、データの確認作業の負荷が特に高く、データをグラフ化するなどでユーザの業務負担を軽減する必要があった。
例）一見しただけでデータが変化している/していない、数値が大きい/小さいなどが分かるようにする。
▽顧客からの要望
ユーザが多用するシステムのために、FW型の開発ではなくユーザと密にコミュニケーションがとれるアジャイル型の開発で、柔軟に対応を進めてほしいと顧客からの要望があった。
▽チーム体制
オンショア1名、オフショア1名で、オン側はユーザとのコミュニケーションよりの作業、オフショアは実作業よりの分担。
■プロジェクトにおける自身の役割
▽役割
ユーザコミュニケーション、関連システム＆関連チームとの調整。設計〜開発〜テストと一連の全作業、＋オフ側の成果物のレビューなど。
▽工程
基本設計、詳細設計、開発、テスト、リリース、各種調整など一通り全て担当。※有識者のサポートあり。
■当時の背景/抱えていた課題等
▽知らないことばかり、分からないことばかりの状態でのスタート
・新チームにアサイン後すぐのプロジェクト
・新チームで担当しているシステム知識、業務知識の不足
・主として使用されている言語がVBAで未経験の言語 etc
▽ユーザの要望との認識齟齬
・作成した画面のレイアウトや表示形式が、ユーザのイメージと異なる場合に出戻りが発生すると予測した
■課題に対して自身が発揮したバリュー及び成果
▽キャッチアップのスピードと一歩踏み込んだ知識の獲得
短期のプロジェクトだったため、業務外でのインプット（参考書、資格etc）、過去の類似案件や類似対応をもとに、早い段階で必要最低限の知識を身につけることができた。また、その際に出た疑問点、不明点などは、既存の設計書やソースをもとに、自ら調査を実施した後に有識者にQAすることで、システム的にも業務的にも一歩踏み込んだ知識を身につけることができた。
▽作業の前倒しによる＋αの顧客要望対応
上記のキャッチアップを元に前倒しで作業することができていたため顧客の要望を追加で引き出し、期間内に対応することができた。作業途中で今回のスコープ外の既存のシステムでの問題点を発見し、調査を実施、改修方針や対応方法を立て顧客に提案、その後、顧客からの追加開発の承認を得ることができた。
▽成果物をベースにした顧客コミュニケーション
早い段階で動くモノ、見せれるモノ（簡単なモックetc）を作成し、それをベースにユーザとコミュニケーションを取ることで、お互いの認識の齟齬を減らすことができたこと。予想していた出戻りもほとんどなかったこと。
■総括
顧客とのコミュニケーションの取り方としてお伺いベースではなく、提案ベースのコミュニケーションをする事を心掛けていたために案件を主導すること。簡単なモックや画面イメージなど「動くモノ、見えるモノ」をもとに、お互いの認識をすり合わせることはよくあるが、加えていくつかのパターンで顧客に提案することで、顧客側でも最終成果物のイメージがつきやすくなること。上記は今後のプロジェクトの進め方として参考になった。