【ゴールデンウィーク営業のお知らせ】 2024年4月27日(土)~2024年5月6日(月)の期間中、GWのため休業とさせていただきます。 ※4月30日(火)、5月1日(水)、2日(木)は通常営業いたします。 ※休業期間中にいただいた審査申請については、結果をお返しするために数営業日いただくことをご了承ください。

改善ポイントの宝庫!転職時に気にしたいITエンジニアのレジュメアンチパターン

2021-08-03 18:00

レジュメ(職務経歴書)のアンチパターン紹介のキャッチビジュアル

こんにちは!転職ドラフト審査チームです。

登録後、審査に通過した人のみが参加できる転職ドラフトで、私たち審査チームはレジュメのチェックとフィードバックを行っています。

日々、たくさんの方の審査を行っていくなかで、 「実力はありそうなのに書き方がもったいない!」 というケースが多々見られます。

「誰もが絶賛するレジュメはこれだ!」と言い切るのは難しいのですが、やりがちなアンチパターンには共通点があることも。
そのなかには、気づいていないだけでやってしまいがちなことも意外と多いのです。

審査に通過していない人も通過済みの人も、今後の指名額アップのために、この記事を読みながらご自身のレジュメを見直してみてはいかがでしょうか?

実力はいかに?プロジェクトサマリパターン

官公庁のリプレース案件です。
チーム規模:20名
役割:サブリーダーとして要件定義からテストまで
使用技術:Java
開発手法:ウォーターフォール

プロジェクトの概要だけが列挙されているパターン。

これだけでは「SIerでJavaを使ってたのかな?」程度しかわからず、具体的な実力は全く伝わりません。

このままだとレジュメというよりはちょっとリッチな履歴書状態です。

マネージャー経験が泣いてる…アイアムマネージャーパターン

50人規模のチームでマネージャーをしていました。
みんなをまとめ上げ、納期に間に合わせました。

マネジメント経験は高額指名や年収アップにつながりやすい経験です。

しかし、このままでは「マネージャーだった」事実と「プロジェクトの成功」しか伝わりません。正直、もったいない!

採用担当者が知りたいのは、 そのポジションで何を成し遂げたか、そのプロジェクトが上手くいった最大の要因とは何だったのか、そしてその要因に自分がどう関係したのか

いま一度プロジェクトについて、「あのときどうだったっけ?」と振り返ってみるとより良いレジュメになるはずです。

そのすごさが伝わらないフルスタックパターン

一人ですべての工程を担当していました。

「すべて自分でやりました。辛く苦しい経験も乗り越えられるので、任せてください!」
そんな気概が伝わってきますね。

確かに、一人で担当した経験はすごいですし、個人的にはこういう方は好きです!

ただし、採用担当者目線で見ると 「すべて」の中身がわからないことには評価のしようがありません
せっかくの経験。効率的にアピールするためにも、より詳しい記載が必要です。

がんばりだけは伝わるガッツパターン

納期直前までクライアントから仕様変更がかかり続けるも、なんとか納期に間に合わせることが出来ました。

プロジェクトが進んでからの仕様変更。しかも何度も。

そんな状況でもがんばれたのは、おそらくチームワークの良さやメンバーの信頼関係、そして本人の努力と根性だと思います。

「だからこそ、納期に間に合わせた成功体験をぜひもっと詳しく教えてほしい」
採用担当者もきっとそう思っているはずです。

簡潔さも大切に。ストーリーテラーパターン

弊社創業時からの案件です。私はxx年の夏に炎上していたこの案件に火消しとして参画しました。
当時のプロジェクトは退職者が続出する酷い有様で、ドキュメントもろくになく、毎日残業を強いられる苦しい日々でした。
〜中略〜
このプロジェクトをなんとか成し遂げることが出来ました。
今でもこのプロジェクトは私の中の大きな財産です。

短編小説を読んでいるような気持ちになり、つい共感してしまうこちらのパターン。

気持ちや技術面以外の状況描写が多くなりがちで、すべて読んでも「この人はPHPで受託開発を行っていて、JavaScriptはおそらく別の人が書いていたのかな?」くらいの情報しかわからない場合も。

レジュメである以上、 簡潔にまとめたり実力がわかる資料やエピソードを追記する 必要があります。

ただし、なかには性格の良さや読ませる文量力が伝わるケースもあるので、それはそれでありだと思います。

勉強になるけど…ディクショナリパターン

今回利用したのはRuby on Railsというwebフレームワークです。
このフレームワークはMVC(Model View Controller)アーキテクチャで構築されています。
言語はrubyです。
今回利用したバージョンは4系で、2013年にリリースされました。
Railsの理念として(以下略

利用した言語やツールについての説明が続くパターン。

参考になる情報もあり勉強になるのですが、採用担当者としては「技術説明よりもっとあなたのことが知りたい」と思っているはず。

もっと自信を持って!ネガティブパターン

gitを使うの初めてで、とても苦労しました。
モダンなJavaScriptを覚えるのにとても時間を要しました。

せっかくの成長がうまく伝わらないこのパターン。
謙遜しているのかもしれませんが、もっと自信を持って大丈夫です!

レジュメは自分をアピールする場。せっかく時間を使って書くなら、JavaScriptを使って どういう経験をして、何を成し遂げたかまで書いてみる と、あなたの魅力がぐっと伝わりやすくなりますよ!

書けない機密が多すぎる!シークレットパターン

詳しい内容は機密事項のため書けません。

業務上の機密事項をしっかりと守るのは大切です。

しかし、詳しく書けないとなると、残念ながら評価としてはプラスにもマイナスにもなりません。
詳しくかける他のプロジェクトがあれば、そちらを書いたほうが評価につながりやすい でしょう。

もし、機密事項の多い仕事がほとんどの場合は、アウトプットなどでアピールするのも一つの手段です。これまで学んだ知識や技術など、表に出せるものは積極的にGitHubやQiitaに残しておきましょう。

所属している企業に転職ドラフトの参加を知られることが気になる方は、この記事を参考に指名禁止企業などの設定をしてみてください。

転職ドラフトへの参加を知られたくない方が安心して参加するには?

アンチパターン改善のために意識したい5つのポイント

今回のアンチパターンを見ていくと、ほとんどは情報不足であることがわかります。

レジュメの情報を充実させていくためには、プロジェクトごとに以下の5ポイントを意識しながら書いていくのがおすすめです。

  1. プロジェクト概要
  2. どのような機能を
  3. どのような技術を用いて
  4. どのような工夫をして
  5. どのような成果を出したのか

プロジェクトの概要・技術・成果 はもちろんですが、そのプロジェクトを進めているとき どのような思考をしてどう動いたのか、その過程もしっかり記載 できると、より実力が伝わりやすくなりますよ。

※ 以下の記事もぜひ参考にしてみてください。

勘違いしてたかも?エンジニアの実力が伝わるレジュメの書き方6選

まとめ

ドキッとするパターンがあった方も、大丈夫そうな方も、この機会にレジュメを見直してみてはいかがでしょうか?

今回はアンチパターンとしていくつか例を上げましたが、これらが混ざっていても、結果的に実力がわかれば問題はありません。

アンチパターンを意識しすぎて思ったことを書けないのは本末転倒です。
まずは伝えたい思いの丈をたっぷり書いてから、アンチパターンなどのチェックなどを行い伝わるレジュメにアップデートしてくださいね。

ENTRY
pickup
interview

タグ一覧

年収診断 登録不要!30分で結果がわかる!
SIGN UPSIGN IN


転職ドラフトを友人や同僚に薦める可能性はどのくらいありますか?