891
909

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

エンジニアの職務経歴書 〜正しい魅力の伝え方〜

Last updated at Posted at 2023-01-22

はじめに

昨今の採用現場においてはソフトウェアエンジニアは売り手市場と言われ数年が経過していますが、2023年現在においても、デジタルトランスフォーメーションの加速により、これまでのIT企業の募集だけではなく、様々な企業がソフトウェアエンジニアを募集している状況にあると思います。

知り合いのリクルーターに話を聞くと、ここ最近米国のBigTech企業や、日本初のベンチャー企業のレイオフが目立ちますが、それはごく一部であり、多くの企業では引き続きソフトウェアエンジニアの需要は最も高く、この先10年以上はこの高い需要は続くだろうと言っていました。

image.png
引用元: 【2023年最新】厳選!エンジニア採用に強い15の採用媒体比較~最新市場動向や採用戦略も徹底解説 - type

私自身が就職した10年数年前は望んでソフトウェアエンジニアに就く人は理系出身のプログラミング趣向が強い人ばかりという印象でしたが、最近はいろんな分野からソフトウェアエンジニアに転職したり、これから転職を目指し勉強中という方を目にする機会が増えてきました。

需要の高さと、比較的ライフスタイルのバランスの取りやすいさ、スキルのポータビリティの高さなどにより、人気の高い職種になってくれることは個人的には嬉しく思っています。

私自身は現場のエンジニア採用担当として、通算100通以上の職務経歴書を拝見させて頂きました。
第一印象となる書類選考において、魅力的な職務経歴書と、残念ながら魅力を十分に表現できていない職務経歴書とあるなと感じています。

大きな要因となっているのは、世の中にあるテンプレートのイケてなさにあると思います。
「エンジニア 職務経歴書」と検索するといくつかテンプレートが出てきますが*、多くの方がこのテンプレートをそのまま使用してしまっているということだと思います。
そこで実際に何がダメなのか、どう書くといいのか、現場の採用担当は何を見ているのかをまとめてみました。

せっかくの転職活動。人生が大きく変わるかもしれないこの期間に、自分にあった会社を見つけていくためにも、自身の魅力を最大限正しく伝える職務経歴書の書き方を学んでいただければと思います。

2023/06/12 追記
「本当にエンジニアバブルは崩壊したのか? - Forkwell Press」によると、求人倍率は2023年5月のデータでは横ばい傾向にあるようです。
各社人経費にどれだけ掛けれるか、その意向は変わりつつあるのかもしれません。
より採用がシビアになってくることを予想すると、職務経歴書をしっかりと書き上げることもより重要になるかと思います。
image.png

対象となる方

基本的には2~5年実績を積んで新しいチャレンジをしたい方を対象としています。
ただ、これからソフトウェアエンジニアとして転職を目指している方も、エンジニア採用においてどういった観点が必要となるのか参考になると思います。

職務経歴書の書き方

ポイント1: やったことではなく、成し遂げたことを書く

まず、携わったプロジェクトの開発業務でやったこと、開発プロセスだけを記載している場合です。

社内向け業務システムの改修

  • 基本設計
  • 詳細設計
  • 実装
  • テスト

これでは、どんなチームで、どういった役割なのか、何を成し遂げたのか読み手からは想像できません。設計・開発・テストをすることはソフトウェアエンジニアであれば当然で、何の情報にもならないからです。

image.png

実績やトラブルについても、原因から解決アプローチや再発防止策と論理的に納得感を得られるよう文章に起こすと良いと思います。
(数が多すぎて文章にすると長すぎる場合は、具体的なアプローチだけを箇条書きだけにしておくなどはアリだと思います)

このような経歴を書く例として、

「賃貸物件検索サービスのiOSアプリ」
5名のチームのメンバーとして参加。
新規機能として、検索フォームに位置情報から近隣の物件を探す機能を担当。
位置情報を端末から取得するためのパーミッションの画面について、デザイナーと相談しながらiOSにおいて自然な画面遷移となるよう提案しながら勧めた。
また、歴史のあるアプリのため、レガシーな実装になっており、UnitTestもないコードだったためバグの検知が手動テストに頼っている状況だった。
そこで平行して一部のリファクタリングを実施。テスタブルな設計にし、UnitTestを導入したことでサービスの安定性を向上させた。これをきっかけにチームの中でもUnitTestを書いていく文化を根付かせることに繋がった。

このような感じで、ここは、読ませる人を実際に想像しながら、どんな課題にぶつかり、悩み、どう解決に向かったか、それで何が変わったのかを意識することが大切です。

(Additional)システムのパフォーマンス改善などは定量的な数値で表現する

パフォーマンス改善やリファクタリングは基礎技術ではなく、応用技術が必要になってきます。
そのため、こういった結果を残せるだけで高い技術力、洞察力、応用力を証明することができます。

  • ○○APIのレスポンスが遅く、キャッシュの最適化を行うことでパフォーマンス改善を行い、約30%の改善を行った。
  • BIツールの分析用クエリがスロークエリとなっており、DBサーバーの負荷が増加傾向にあった。インデックスを見直すことで30分かかっていたものが、1分ほどにすることができた。
  • 古いJavaで書かれたアプリをKotlinへコンバートを2年かけて段階的に行った。

しかしながら、いざ職務経歴書を書こうとしたときに、具体的な数値を書くことは覚えていないことが多く、難しいと思います。
自身にとって成果の出たものはブログを書くなり、何かしらで後から追えるようにすることが大切だと思います。

ポイント2: 正しい技術スタックの記載

とても基本的なことですが、結構書き込めてない方が多いです。
以下のような例です。

image.png

iOSエンジニアであれば、

  • 言語:Swift 5
  • アーキテクチャ:MVVM
  • ライブラリ:RxSwift、Alamofire、Nuke、Firebase(Crashlytics, RemoteConfig)、Quick/Nimble
  • 分析、Tracking:Firebase Analytics、Adjust
  • 広告:AdMob
  • データベース:Realm

Webフロントエンドエンジニアであれば、

  • 言語:JavaScript(ES 2020)
  • JSフレームワーク:React(v17)
  • CSSフレームワーク:material-ui
  • 分析:Google Analytics
  • ライブラリ:eslint、mocha、chai、babel、webpack

また、周辺ツールとして

  • ソース管理:GitHub
  • コミュニケーション:Slack
  • スケジュール:Outlook
  • ドキュメント:Confluence、Google Docs/SpreadSheet、miro
  • デザイン:Figma(デザイナーとのデザイン確認のみ)
  • その他:GCP BigQuery(ログ調査時に使用)、MySQL(不具合調査時に使用)

といった感じで、使っていたツールやサービスをできるだけ書きましょう。デザインツールなんかも編集はしなくても、使用したことがあることを補足として書くことで、経歴書を見る側としては、他の職種の人ともコラボレーションしながら仕事をしてきたことを想像することができます。

ポイント3: プログラミング言語の経験年数はあまり重要ではない

例えば、

  • Swift 3年(実装ができ、指導することが可能)
  • JavaScript 2年(基本的な実装が可能)
  • Java 1年(簡単な実装が可能)

こんな感じで言語の経験だけ書いているケースです。

image.png

ソフトウェアエンジニアにおいて、言語の経験年数は正直あまり関係ありません。一つの言語を長く書いていれば、近い領域の言語を学習するハードルは下がりますので、10年選手の方が3ヶ月新しい言語を学習した場合と、2年目の方の3ヶ月では言語に対する理解度は大きく違います。

ポイント4: 技術力と同等にコミュニケーション能力が重要であること

ソフトウェアエンジニアとは、プログラムを書く人ではないと私は思っています。エンジニアリングで課題を解決するのが役目です。
チームで開発する以上、コミュニケーション能力というのは実際の現場においてもかなり重要なスキルなのが事実です。(コミュニケーションは言葉での対話だけではなく、テキストやドキュメンテーションも含みます)

ブリリアントジャークという言葉があります。
Netflixのカルチャーにおいて、ドリームチームの説明にはこのように記載されています。

ドリームチームには、有能だが協調性がない、いわゆる「Brilliant Jerk」には居場所はありません。そういった人は素晴らしいチームワークを損なう要因となるからです。どれほど優秀な人材であっても、他人ときちんとしたコミュニケーションがとれなくてはいけません。能力の高い人同士がうまく協力して仕事をすれば、お互いの創造性や生産性が高まり、個人で働くより大きな成功をチームとして収めることができるのです。

どんなに優秀でも、チームに悪い影響を与える人は採用してはならないということで、私自身も採用において最も重要視しているものです。
逆にいうと、それだけコミュニケーションというのは重要なスキルであり、もし技術力以外にもアピールできることがあれば、それは大いなる武器となります。

ポイント5: できるだけアウトプットを用意する

基本的には会社の業務をしていると、外へ向けたアウトプットをする機会は多くはないと思います。
プライベートな時間を使って、アウトプットをすることは簡単なことではありません。
しかし、だからこそ他の候補者と差別化になります。

別に自らOSSライブラリを作ったり、有名OSSへコントリビュートするほどの必要はありません。
自分の実力がアピールできるコード、記事を公開して、リンクを経歴書に載せてみましょう。

そしてそれにも、どんなモチベーションで作ったものなのかを補足するだけで、素晴らしいアウトプットとなります。

おわりに

全体を通して大切なのは、読み手を意識することです。

スキルだけを並べても人間性は現れません。
あなたが何を感じ、何をしてきたかを伝えることができれば、人となりが現れ、"この人に合ってみたい" と思わせることができます。

自分の魅力をしっかりと伝えることで、自分に合った会社を見つけ、キャリアアップのお役に立てられたら幸いです。

補足1: 海外籍の方のレジュメ、もしくは外資系企業の採用に対して

海外だと日本のような職務経歴書とは形式が違って、フリーフォーマットが多いと思います。
そのため海外籍の方は別として頭を切り替えて見ることにしています。
海外籍の方の場合、スキルシートといった印象の方が強く、おそらくジョブ型雇用により役割が明確に分かれていることから、技術スタックは細かく書いていたり、改善の定量的な結果をしっかり書いてある印象で、コミュニケーションの部分はあまり書いていないことが多いです。
私自身が外資系企業の採用を担当したことがなく、日本企業と海外企業では求められる情報の解像度は変わってくると思いますので、外資系を望む場合はこの記事の内容が当てはまらない場合がありそうです。

補足2: 10年前後のキャリアを積まれている場合

「昔過ぎるのは覚えてない」というコメントを頂きました。10年前後、それ以上の実績を積まれてくると、経歴内容が多くなってくるのは当然ですので、昔の経歴は省略して記載していることは構わないと思います。
選考側としても書類選考や面接中でも昔のことを触れることは少ないです。
技術的な面においては古い技術は使われなくなることが多いですし、メンタル面でもその当時と今では考え方が変わっていることが多いかと思います。
なので技術においては直近の経歴を中心に記載しつつ、もし過去のエピソードの中でご自身のキャリアの重要な経験となったこと、今現在の自分を成す軸となった原体験、ロールモデルを見つけたことなど、自分を表現できる要素があれば、そこを面接で話せると良いと思います。

891
909
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
891
909

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?