エンジニアの職務経歴書｜Qiitaを読んでも通らない人が見落とす採用基準

この記事では、エンジニアの職務経歴書で採用担当者が確認している7つの判断基準と、技術スキル・実績の正しい書き方を解説します。Qiitaを参考にしても書類が通らない方が見落としがちなポイントを採用担当者視点から整理しています。

Qiitaには書いていない「採用担当者目線の現実」

採用担当者が職務経歴書を見る時間は平均30秒

転職活動中のエンジニアが職務経歴書の作成に1〜2週間かけることも珍しくありません。しかし採用担当者が最初の絞り込みで1通の書類に費やす時間は、平均30秒程度が実態です。このギャップを知らずに書くと、どれほど豊富な経験を持っていても伝わりません。

採用担当者は書類を「読む」のではなく、最初の30秒で「スキャン」して次の候補者に移ります。この行動パターンを前提に置くかどうかで、職務経歴書の設計思想が根本から変わります。

Qiitaのエンジニア向け職務経歴書記事は「何を書くか」の情報として優れています。しかし「採用担当者がどこから読むか」「何に引っかかって次に進むか」という読み手側の行動は、実際に採用をおこなった経験がないと見えてきません。

「技術スキルの羅列」が伝わらない構造的な理由

エンジニアの職務経歴書でよく見られる失敗が、スキルシートへの技術名の羅列です。「Python / AWS / Docker / Vue.js / React」と並べても、採用担当者には判断材料になりません。

採用担当者が職務経歴書を通じて確認したいのは「この人を採用したら何を任せられるか」という具体的なイメージです。技術名だけでは「どのレベルで使えるのか」「実際にどんな課題を解いてきたのか」が見えず、採用の判断ができません。

エンジニアの職務経歴書 基本構成と書き方

職務要約（キャリアサマリー）の役割

職務要約は書類の冒頭に配置する3〜5行のキャリア概要です。採用担当者がスキャン時に最初に目を止める場所であり、「この人は何者か」を10秒以内に伝えることが唯一の目的です。

職務要約で「自分がどういうエンジニアか」を先に定義することで、後続のプロジェクト歴が「その証拠」として機能する流れが生まれます。

職務経歴（プロジェクト歴）に書くべき5つの要素

各プロジェクトの記載は、採用担当者が「再現性」を判断するための材料です。以下の5要素をセットで記載することで、「何ができる人か」が明確に伝わります。

要素	記載内容の例
① 期間と規模	20XX年X月〜20XX年X月（X年Xヶ月）/ チームX名 / MAU XX万人
② プロジェクト概要	BtoB向けSaaSのバックエンドAPI開発・運用
③ 担当フェーズと役割	要件定義・設計・実装・レビュー / バックエンドリード
④ 使用技術	Python / FastAPI / PostgreSQL / AWS（EC2・RDS・Lambda）/ Docker
⑤ 成果・工夫点	APIレスポンス時間をX秒→X秒に改善（X%削減）/ 月次クレーム件数X件→X件に減少

成果は数値で示すことが原則ですが、数値化が難しい場合は「設計書ゼロから立ち上げた」「オンボーディング期間を半減させた」など、具体的な変化を言語化するだけでも伝わり方が大きく変わります。

スキルシート：「使った」と「使える」の違い

スキルシートの目的は「採用担当者が即座に判断できる情報を提供すること」です。技術名の羅列ではなく、習熟度と使い方のセットで記載してください。

記号	習熟度の基準
◎	業務の主軸として3年以上・設計・レビューまで対応可
○	実務で2年程度・機能実装を独力でこなせる
△	学習・小規模利用・補助的に触れた程度

「△だらけのスキルシート」はむしろ逆効果です。「浅く広く触れてきた人」という印象を与えます。採用担当者が「この人に任せられる」と感じる技術は◎または○に絞り、△は除外するか極力少なくすることをすすめます。

職務経歴書の作成に行き詰まりを感じる場合は、自動作成ツールで骨格を作ってから肉付けする方法も有効です。

採用担当者が重視する7つのチェックポイント

①成果を数値で語れているか

採用担当者が最も確認するのは「この人を採用したらどんな成果が出るか」の予測可能性です。数値のない実績は「何かやった」という事実を伝えるだけで、採用判断の材料になりません。

②技術選定の「なぜ」を書けているか

多くのエンジニアは「何を使ったか」しか書きません。しかし採用担当者、特に技術的バックグラウンドのあるエンジニアマネージャーが注目するのは「なぜその技術を選んだか」という思考プロセスです。この視点を持って書けている人は上位1割程度で、即戦力の証明になります。

③チームへの影響力が見えるか

個人の作業内容の羅列より、チームやプロジェクトへの貢献が見えると採用担当者の印象は大きく変わります。「何人チームの何をやったか」だけでなく、どのように貢献し、何が変わったかを書いてください。

④自走力の証拠があるか

採用担当者が「育てなくてもすぐ動ける人か」を判断するために確認するのが、業務外のアウトプットです。個人開発・OSS貢献・技術ブログ・Qiita記事などは、自走力と学習継続性の証拠として機能します。

記載する際は「何があるか」だけでなく「どんな規模か」を数値で示してください。

• Qiita記事15本（総LGTM数 2,000超・月間PV 8,000）
• 個人開発：Webサービス「○○」（GitHub Stars 120・月間MAU 1,200名）
• OSS：○○ライブラリへのPR（3件マージ済み）

⑤キャリアの一貫性と転職軸

複数回の転職履歴がある場合、採用担当者が確認するのは「転職回数の多さ」ではなく「軸の一貫性」です。職種や業界が変わっていても、「技術力の深化」「スケールの大きい課題への挑戦」など、転職理由に一本の軸があると評価が安定します。

職務経歴書に転職理由を書くスペースはありませんが、職務要約（キャリアサマリー）の中に「これまでの経験で培った強みと、次に挑みたいフィールド」を一文で入れるだけで、面接前から軸が伝わります。

⑥読みやすさとレイアウト

技術的に優れた経歴も、読みにくいレイアウトでは伝わりません。採用担当者は1日に数十通の書類を確認するため、視覚的なストレスのある書類はそれだけで評価が下がります。

• 分量の目安：経験5年未満はA4で1〜2枚、5年以上は2〜3枚
• プロジェクト記載は表形式が最も読みやすく、情報が整理されやすい
• 箇条書きを活用し、1段落に複数の事実を詰め込まない
• 誤字脱字はゼロが前提。提出前に必ず第三者視点で確認する

⑦「強みを一言で定義」できているか

冒頭の職務要約で「自分がどういうエンジニアか」を一言で定義できているかどうかで、書類全体の印象が大きく変わります。「フルスタックエンジニア」「マルチロール」のような汎用的な表現は使い古されており、採用担当者の記憶に残りません。

エンジニア職種別の書き方ポイント

SE（システムエンジニア）

SEの職務経歴書で採用担当者が特に確認するのは、上流工程（要件定義・基本設計）への関与度合いです。「開発・実装のみ担当」と「要件定義〜保守まで一貫担当」では求める役割が大きく異なるため、担当フェーズを明記することが最優先です。

• 担当フェーズを「要件定義・基本設計・詳細設計・実装・テスト・保守」のどこからどこまでか明記する
• システムの規模感をユーザー数・トランザクション数・データ量などで示す
• 顧客折衝・ベンダーコントロールの経験があれば明記する（PM候補として評価される）

プログラマ・開発エンジニア

開発エンジニアの職務経歴書では、「作ったものが社会にどう使われているか」を書けると評価が上がります。コードの品質や設計力は書類では直接伝わりにくいため、GitHubリポジトリへのリンクやQiitaアカウントを添えて、採用担当者が確認できる状態にすることが有効です。

• 「作ったもの」のユーザー数・MAU・売上貢献額などを記載
• チームの中での技術的な貢献（設計提案・ライブラリ選定・コードレビュー担当）を具体化する
• GitHubアカウントURLを記載する場合は、主要リポジトリのREADMEを整備してから添付する

PM・PL（プロジェクトマネージャー・リーダー）

PMやPLへのキャリアを目指す場合、あるいはその実績を証明したい場合は、数字だけでなく「困難な状況をどう乗り越えたか」のストーリーが採用担当者の印象を決定づけます。

GitHubとQiita記事を職務経歴書に活かす方法

エンジニアにとってGitHubとQiitaはスキルの実証ツールです。職務経歴書に記載することで、採用担当者が書類の記述を「確認」できる状態を作れます。

GitHubを職務経歴書に活かす3つのポイント

GitHubのURLを記載する際は「見せられる状態か」を先に確認してください。採用担当者がプロフィールを開いたとき、コントリビューション履歴が空白だったり、リポジトリにREADMEが存在しない場合、記載しないほうがプラスになることもあります。

• READMEを整備する：何を作ったか・使用技術・動作確認方法を3〜5行でまとめる
• ピン留めリポジトリを設定する：プロフィールページで採用担当者が最初に目にするリポジトリを6件まで選択できる
• スター数・フォーク数を意識する：社会的認知の指標として機能する。OSS貢献のマージ実績も記載の価値がある

Qiita記事の職務経歴書への活用法

Qiitaの記事実績は「技術的なアウトプット力」と「情報共有・ドキュメント化能力」の証明になります。記載する際は記事数だけでなく、LGTMの総数や代表記事のPVなど、読まれている実績を添えることで説得力が増します。

採用担当者が実際に記事を読むかどうかは重要ではありません。「読まれている記事がある＝技術的に信頼できる情報を発信できる人材」という印象を与えることが目的です。

職務経歴書の完成後に内容のブラッシュアップを求める場合は、有料の職務経歴書添削サービスの活用も選択肢の一つです。

まとめ

エンジニアの職務経歴書で採用担当者が確認する7つのポイントを振り返ります。

• ① 成果は必ず数値で示す（改善率・件数・MAUなど）
• ② 技術選定の「なぜ」を書く（比較検討・選定理由まで記載）
• ③ チームへの影響力を具体化する（レビュー・育成・改善提案）
• ④ 自走力の証拠を示す（個人開発・OSS・Qiita記事の数値付き実績）
• ⑤ キャリアの一貫性を職務要約に埋め込む
• ⑥ 読みやすいレイアウト（表・箇条書きで視覚的に整理）
• ⑦ 強みを一言で定義する（汎用的な表現を避ける）

Qiitaには「何を書くか」の情報が豊富に揃っています。しかし書類選考を通過するためには「採用担当者がどう読むか」という視点が不可欠です。技術スキルを持つエンジニアが書類で落ちるとしたら、多くの場合その差は「伝え方」にあります。

職務経歴書の作成をより効率的に進めたい場合は、職務経歴書の代行サービスを利用してプロに依頼する方法もあります。

エンジニアの職務経歴書に関するよくある質問

職務経歴書はA4何枚が適切ですか？

経験年数5年未満の場合は1〜2枚、5年以上は2〜3枚が目安です。採用担当者が30秒で全体像を把握できる分量に抑えることが重要で、「書けることをすべて書く」よりも「重要度の高い内容に絞って書く」が原則です。

技術スキルの経験年数はどう書けばいいですか？

単純な年数より「習熟度」と「使い方」のセットで書くほうが伝わります。「Python（4年・FastAPIでAPI開発、主軸言語）」のように、どのレベルでどう使ってきたかをセットで記載してください。採用担当者は「3年以上使った＝できる」とは判断しません。

未経験から転職する場合、書くことがないときは？

業務での開発経験がない場合は、個人開発・スクール・ハッカソン・OSS貢献などの学習成果をプロジェクト経歴と同じ形式で記載します。「期間・何を作ったか・使用技術・成果」のフォーマットで整理することで、採用担当者が評価できる情報になります。GitHubリポジトリやQiitaアカウントへのURLも必ず添えてください。