ITエンジニアの職務経歴書、GitHubと技術スタックの書き方

エンジニアの職務経歴書は、書く材料に困ることが少ない書類です。
関わったプロダクト名、使った言語、導入したライブラリを並べれば、枚数はすぐ埋まります。
困るのはそのあとで、読み返すと結局何ができる人なのかが自分でも読み取れない、という状態になりやすい書類でもあります。

この記事が扱うのは書類の中身です。
いつ着手するかという時期の話は職種を問わないため職務経歴書はいつ作ればよいかに、書いた内容を口頭で掘られたときの答え方はITエンジニアの面接は何を聞かれる？にまとめています。
3つは「いつ作るか」「何を書くか」「どう答えるか」で役割が分かれます。
履歴書との書き分けは履歴書と職務経歴書の違いとは？で扱っています。

エンジニアの経歴は職種名だけでは伝わらない

同じ職種名でも中身がそろわない

「バックエンドエンジニア」「インフラエンジニア」という肩書きは、担当した業務の範囲を示しません。
同じ肩書きでも、扱った言語、動かしていた基盤、担当した工程、チームの人数によって、日々やっていたことは変わります。

このため、職種名と在籍期間だけを並べた書類は、読み手の側で解釈の幅が大きくなります。
解釈の幅が広い書類は、都合よくは読まれません。
判断に必要な情報が無いとき、読み手は該当しない側に寄せて処理します。

読み手が必ずしもエンジニアとは限らない

書類が最初に通る場所は、採用担当者や人材紹介の担当者であることがあります。
技術の細かい判断ができる読み手に届く前に、要件と合っているかどうかの照合が入る形です。

照合で使われるのは、求人票に書かれた言葉と、書類に書かれた言葉の一致です。
同じものを指していても、表記が違えば照合されないことがあります。
技術的に正確であることと、照合されやすいことは別の話になります。

募集は領域を絞って出されている

経済産業省の試算では、IT人材の需要が中位から高位で伸びた場合、2030年に最大約79万人が不足するとされています（出典: 日本経済新聞）。
ただし不足はAI・クラウド・セキュリティといった先端領域に偏っており、基礎的な領域の供給はむしろ増えています（出典: コエテコキャンパス）。

不足の量が大きいことと、自分の書類が通ることは別です。
募集は領域を絞って出されるため、書類の側もどの領域の経験なのかが判別できる形になっている必要があります。
市場全体の状況はIT人材は不足している？にまとめています。

書き始める前に材料を3つに分ける

技術・工程・規模で棚卸しする

いきなり文章を書き始めると、覚えている順に並んで構造が崩れます。
先にやるのは、材料を3つの列に分けて書き出す作業です。

この3つがそろって初めて、経験の輪郭が決まります。
技術だけでは何をしたかが分からず、工程だけでは何で作ったかが分かりません。
規模が無いと、同じ工程名でも任されていた責任の重さが読み取れません。

会社単位ではなくプロジェクト単位で並べる

在籍した会社ごとにまとめると、複数の案件が1つの塊になり、どの技術がどの工程で使われたのかが混ざります。
プロジェクト単位で区切ると、技術と工程と規模の対応が保たれます。

在籍が長い会社では、担当が変わった時点で区切ります。
同じ会社の中で領域が変わっていること自体が、書類に載せる価値のある情報です。

求人票を1件開いてから書き出す

材料の書き出しは、求人票を1件開いた状態で行うと粒度がそろいます。
求人票の「求める経験」の欄が、どのくらいの細かさで書かれているかが基準になるためです。

求人側が「Go・gRPC・Kubernetes」という粒度で書いているなら、こちらも同じ粒度で書きます。
求人票のどこに何が書かれているかは求人票のどこを読むかにまとめています。

技術スタックの見せ方

一覧に並べるだけでは読み分けられない

技術名を横に並べただけのスキル欄は、量が多いほど読み分けができなくなります。
10年使ってきた言語と、1度の検証で触っただけのツールが、同じ行に同じ書式で並ぶためです。

読み手が知りたいのは、名前を知っているかどうかではありません。
その技術で何を、どのくらいの期間、どの工程まで担当したかです。
並べるだけの欄は、その手前で止まっています。

使用歴と直近で触れた時期を分ける

技術ごとに、通算の使用期間と、最後に業務で触れた時期を添えます。
この2つを分けると、いま手が動く技術と、以前は使っていた技術が区別できます。

ブランクのある技術を現役のものとして書くと、面接の段階で食い違いが出ます。
ブランクがあること自体は説明できる材料であり、触れずに進めた場合のほうが後の工程に影響します。

求人票に使われている表記に合わせる

同じものを指す表記が複数ある場合、求人票側の表記を採用します。
書類の側だけが独自の表記になっていると、照合の手間が増えます。

これは誇張ではなく、対応させる編集の作業です。
持っていない経験を書くという話ではありません。
求人ごとに全面的に書き直す必要もなく、共通の骨格を作ったうえで、前面に出す技術を入れ替える程度で足ります。

浅い技術には段階を添える

「触ったことがある」程度の技術を書くかどうかで迷ったときは、段階を添えて書きます。
業務で運用まで担当した、業務で実装した、検証環境で試した、学習として使った、という区分です。

段階が書かれていれば、読み手は必要な深さかどうかを自分で判断できます。
判断できる形で渡すことが書類の役割です。
資格の扱いも同じ考え方になり、判断材料はAWSなどの資格は転職で評価される？にまとめています。

担当した工程を項目に対応させる

プロジェクトごとに立場・工程・技術・結果を並べる

プロジェクトの記載は、概要を文章で書くより、決まった4項目に落とすほうが比較されやすくなります。
自分の立場（担当・リーダー・レビューする側）、担当した工程、使った技術、出た結果の4つです。

結果の欄は、数字が出せるものだけを書きます。
処理時間、障害の件数、リリースの頻度など、当時から測っていたものがあればそのまま使えます。
測っていないものを推定で書くと、面接で根拠を聞かれた時点で崩れます。

上流だけ・実装だけの経験も具体で書く

工程の一部しか担当していないことを、書類の弱点として扱う必要はありません。
募集の側も工程を区切って求めているためです。

要件定義と設計だけを担当していたなら、何を決める会議に出て、どこまでを文書にしたかを書きます。
実装だけを担当していたなら、渡された仕様の粒度と、実装で自分が判断した範囲を書きます。
担当していない工程を曖昧に含ませるより、境界を書くほうが読み手は扱いやすくなります。

運用・保守は担当範囲を書くと伝わる

運用の経験は「運用・保守を担当」とだけ書かれることが多く、そこから中身が読み取れません。
監視の仕組みを作ったのか、アラートを受けて一次対応をしていたのか、恒久対応の設計まで入っていたのかで、内容が変わります。

当番の体制、対応した障害の種類、再発防止をどこまで決めたかを書くと、範囲が伝わります。
社内SEとSIerでは同じ工程名でも読まれ方が変わるため、社内SEとSIer、転職の探し方はどう違う？もあわせて確認してください。

GitHubを添えるとき

見せるのは整理された数個で足りる

GitHubのアカウントを書類に添える場合、読み手が全部を見ることはありません。
開かれるのは、上から数個か、書類の中で名前を挙げたリポジトリです。

そのため、アカウント全体の見栄えを整えるより、見てほしい数個を指定するほうが効きます。
書類の側に「この2つを見てほしい」と書き、それぞれが何のためのコードかを1行添える形が、いちばん短く済みます。

コミット数の多さは論点になりにくい

コミットの数や日々の記録が採用の判断にどう使われるかを示す、出典の確認できる調査データは確認できていません。
当サイトで確認できるのは、求人票の応募要件に何が書かれているかまでです。

ただし、読み手が使える時間が限られていることは構造として決まっています。
数を増やしても、読まれる量が増えるわけではありません。
積み上げる方向より、指定する方向に労力を使うほうが、読み手の動きに合います。

READMEに前提を書いておく

コードだけが置かれたリポジトリは、何のために作られたものかが読み取れません。
READMEに、何を解決するものか、動かすのに何が要るか、どこが自分で判断した部分かを書いておくと、開いた側の理解が早くなります。

自分で判断した部分の記載は、面接で聞かれる内容と直接つながります。
技術面の質問では、選んだ理由と検討した代替案が掘られるためです。
答え方の型はITエンジニアの面接は何を聞かれる？で扱っています。

業務で書いたコードは載せない

在籍した会社の業務で書いたコードは、自分の判断で公開してよいものではありません。
就業規則や契約で扱いが定められているのが通常で、迷う場合は公開しないほうを選びます。

業務の内容を書類に書くこと自体は通常の記載ですが、成果物そのものを外に出すことは別の話です。
書類には範囲と役割を書き、コードは出さないという切り分けになります。

公開できるものが無い場合

公開できるリポジトリが無い状態は、珍しくありません。
業務でしか書いてこなかった場合、その状況自体が説明になります。

この場合は、書類の側で工程と技術と規模を厚く書きます。
一方、未経験から応募する場合は前提が変わり、作ったものが判断材料の中心になります。
難易度の見積もり方は文系・未経験からITエンジニアになれる？にまとめています。

書いた内容の使われ方はサービスの形で変わる

書類をどこまで作り込むかは、その書類がどこで読まれるかによって変わります。
当サイトが条件を整理しているITエンジニア向けサービスは57件で、利用の始まり方によって、書類が置かれる位置が違います。

会員登録型では書類が検索の対象になる

会員登録の時点で求人を見られるサービスでは、登録した経歴がそのまま企業側の検索の対象になります。
当サイトのデータでは、レバテックキャリア、レバテックダイレクト、社内SE転職ナビ、Tecgateエキスパート、AXIS Agentなどが登録型として記録されています。
いずれも全国が対応地域です。

検索される以上、言語名・基盤の名前・経験年数が書かれていないと候補に入りません。
技術名を省いた要約的な書き方は、この形では不利に働きます。
登録だけで進める使い方はITエンジニアは面談なしで転職活動できる？にまとめています。

経歴を登録して待つ形では記入量が効く

レバテックダイレクトは、企業が登録されたプロフィールを見て直接オファーを送る仕組みを持ちます。
この形では、書いた内容が届く連絡の量と中身にそのまま関わります。

連絡が来ないことを自分の市場価値と読み替える前に、記入量を見直すほうが先です。
仕組みはITエンジニアはスカウト型で転職できる？、記入する項目はスカウト型サービスのプロフィールの書き方で扱っています。

面談実施型では書類が会話の出発点になる

面談を伴うサービスでは、書類は読まれて終わるものではなく、質問の起点になります。
書いてある工程と技術に沿って、判断の理由が掘られる形です。

当サイトのデータでは、TechGo、ウズカレIT、明光キャリアパートナーズエンジニア転職、ユニゾンキャリア転職などが面談実施型として記録されています。
対象条件はサービスごとに違い、明光キャリアパートナーズエンジニア転職は「エンジニア経験者の方」を対象に明記しており、ユニゾンキャリア転職は東京・神奈川・埼玉・千葉を対応地域としています。
条件から外れているサービスでは紹介に進まないため、書類を整える前に対象かどうかを読んでおくほうが順序として早くなります。

まとめ

• 職種名と在籍期間だけの書類は解釈の幅が広く、判断材料が無いと該当しない側に寄せて読まれる
• 材料は技術・工程・規模の3列に分け、会社単位ではなくプロジェクト単位で並べ直す
• 技術スタックは通算の使用期間と最後に触れた時期を分け、浅いものには段階を添える
• 工程は立場・工程・技術・結果の4項目に落とし、担当していない範囲は境界を書く
• GitHubは全体を整えるより、見てほしい数個を指定するほうが読み手の動きに合う
• 業務で書いたコードは公開せず、書類には範囲と役割を書く
• 登録型では書類が検索の対象になり、面談実施型では質問の起点になる