スキルシートと職務経歴書の違い
| 比較項目 | スキルシート | 職務経歴書 |
|---|---|---|
| 用途 | 案件マッチング（SES・フリーランス） | 転職活動（正社員） |
| 読み手 | 技術責任者・PM | 人事・採用担当 |
| 技術詳細 | 非常に細かく（バージョンまで） | 概要レベル |
| 自己評価 | スキルレベルを段階評価 | 不要 |
| 個人情報 | 匿名（年齢・性別のみ） | 氏名・住所あり |
| 更新頻度 | 案件ごとにカスタマイズ | 転職活動時に更新 |
最も大きな違いは「読み手」だ。 職務経歴書は人事担当者が読むため、ビジネス成果やソフトスキルも重視される。 スキルシートは技術者が読むため、バージョン番号や具体的な実装内容が重視される。
スキルシートの基本構成
| セクション | 記載内容 | コツ |
|---|---|---|
| 基本情報 | 年齢、最寄駅、稼働可能日 | 匿名で記載（氏名は不要） |
| スキルサマリー | 得意領域を3〜5行で | 案件に合わせてカスタマイズ |
| 技術スキル一覧 | 言語・FW・DB・OS・ツール | 経験年数と自己評価レベルを併記 |
| プロジェクト経歴 | 参画期間、業界、チーム規模、担当、技術 | 新しい順に記載、直近を詳しく |
| 保有資格 | IT関連資格 | 取得年月を併記 |
スキルサマリーは「最初に読まれるセクション」であり、ここで興味を引けなければ詳細まで読まれない。 案件の求めるスキルに合わせて毎回カスタマイズすべきだ。
自己評価レベルの基準
スキルシートで最も迷うのが自己評価だ。 客観的な基準を設けることで、過大評価・過小評価を防げる。
| レベル | 基準 | 具体例（Reactの場合） |
|---|---|---|
| ★☆☆☆☆（入門） | チュートリアルを完了した程度 | Todoアプリを作ったことがある |
| ★★☆☆☆（初級） | サポートがあれば業務で使える | 既存コンポーネントの修正ができる |
| ★★★☆☆（中級） | 一人で機能実装ができる | 状態管理を含むSPAを設計・実装できる |
| ★★★★☆（上級） | 他者を指導でき、設計判断ができる | パフォーマンス最適化、テスト戦略の設計 |
| ★★★★★（エキスパート） | 組織の技術方針を決定できるレベル | React Nativeまで含めた技術選定 |
★3が「実務で戦力になれるレベル」の目安。 案件応募時に★3未満のスキルを主要スキルとして記載すると、参画後に期待とのギャップが生じるリスクがある。
逆に、全てのスキルを★4以上にするのも信頼性を損なう。 正直な自己評価ができるエンジニアの方が、クライアントからの信頼は高い。
プロジェクト経歴の記入例
| 項目 | 記入例 |
|---|---|
| 期間 | 2025年1月〜2025年12月（12ヶ月） |
| 業界 | 金融（ネット証券） |
| プロジェクト概要 | 証券取引プラットフォームのバックエンドAPI刷新 |
| チーム規模 | 10名（BE4、FE3、QA2、PM1） |
| 役割 | バックエンドエンジニア（サブリード） |
| 担当工程 | 設計、実装、コードレビュー、テスト |
| 技術 | Go 1.22, PostgreSQL 16, Redis, AWS ECS, Terraform |
| 担当内容 | 注文API・約定APIの設計と実装、レイテンシ改善（P99を200ms→50msに短縮） |
案件タイプ別のカスタマイズ戦略
同じスキルシートをすべての案件に出すのは効率が悪い。 案件の特性に応じて、強調するポイントを変えるべきだ。
| 案件タイプ | 強調すべきポイント | 弱めるポイント |
|---|---|---|
| 新規開発（スタートアップ） | 技術選定経験、0→1の実績、幅広い技術スタック | 大規模チームでの経験 |
| リプレイス・リファクタリング | レガシーからの移行実績、段階的移行の設計力 | 新技術のキャッチアップ速度 |
| 運用保守・改善 | 障害対応、パフォーマンス改善、監視設計 | 新機能開発のスピード |
| 大規模エンタープライズ | チーム規模、ドキュメンテーション、設計レビュー | 個人開発の成果 |
スキルシートのよくあるミスと改善
| ミス | なぜ問題か | 改善方法 |
|---|---|---|
| 自己評価が全て★4〜5 | 信頼性がなくなる | メインスキル以外は正直に★2〜3に |
| バージョンが曖昧 | 技術詳細がわからない | React 18, Next.js 14, Node.js 20のように明記 |
| 担当内容が「開発全般」 | 何をしたか伝わらない | 具体的な成果物と数値を記載 |
| 10年前のプロジェクトが詳細 | 現在のスキルが見えない | 直近3〜5年を中心に、古いものは要約 |
| 業界名が曖昧（「Webサービス」等） | どんなドメインか伝わらない | 「EC（アパレル）」「金融（証券）」のように具体化 |
スキルシート作成に使えるツール
| ツール | 特徴 | 向いている人 |
|---|---|---|
| Excel / Google Sheets | SES企業指定のフォーマットに対応しやすい | SES所属のエンジニア |
| Notion | テンプレート共有が容易、見た目も整えやすい | フリーランス |
| GitHub Pages + Markdown | 技術力のアピールにもなる | Web系フリーランス |
| Canva | デザイン性の高いスキルシートが作れる | デザインも兼務するエンジニア |
SES企業経由の場合は、企業が指定するExcelフォーマットを使うのが一般的だ。 フリーランスの場合は、NotionやGitHub Pagesで独自のスキルシートを作ると差別化になる。
面談につなげるためのテクニック
スキルシートの目的は「面談に呼ばれること」だ。 以下の点を意識すると、面談率が上がる。
・スキルサマリーに案件のキーワードを含める。「Go + マイクロサービス」の案件なら、サマリーにその経験を明記する ・直近のプロジェクトを最も詳しく書く。3年以上前のプロジェクトは2〜3行に要約 ・数値で成果を示す。「レスポンスタイム改善」ではなく「P99を200ms→50msに短縮」 ・技術スタックは案件で使う技術を上に配置する。読み手は上から順に読む
スキルシートは「案件の入り口」であり、これ1枚で面談に進めるかどうかが決まる。 技術的な正確性を保ちつつ、自分の強みが一目で伝わる構成を心がけよう。 あなたのスキルシートは、5秒で読み手の興味を引ける内容になっているだろうか。
フリーランス vs SES：スキルシートの違い
フリーランスとSES所属では、スキルシートの戦略が異なる。
SES所属の場合、営業担当がスキルシートをクライアントに提出する。 営業担当は技術に詳しくないケースが多いため、スキルシートの内容が「そのまま」クライアントに伝わる。 つまり、スキルシートの完成度がそのまま書類通過率に直結する。
フリーランスの場合、エージェント経由か直接営業かで戦略が変わる。 エージェント経由の場合はSESと同様にフォーマットに従う。 直接営業の場合は、Notionページやポートフォリオサイトの形式で自由にアピールできる。 独自フォーマットは差別化になるが、読み手の期待するフォーマットから外れすぎると逆効果だ。
スキルシート更新のタイミング
スキルシートは「プロジェクトが変わるたびに更新する」のが基本だ。 しかし、多くのエンジニアがプロジェクト終了後に更新を忘れ、次の案件探しの直前に慌てて書き直す。
おすすめの更新サイクルは以下の通りだ。
・プロジェクト参画時：使用技術、チーム規模、担当範囲をメモしておく ・プロジェクト中間（3ヶ月ごと）：成果や改善実績を数値とともにメモする ・プロジェクト終了時：上記のメモをもとにスキルシートを正式に更新する ・案件応募時：応募先の要件に合わせて強調ポイントを調整する
このサイクルを回すことで、「あのプロジェクトで何をやったっけ？」と思い出せない問題を防げる。 Brag Document（自慢ドキュメント）を併用すると、さらに効率的だ。
導入5ステップ
ステップ1: 基本情報とスキルサマリーの枠組みを作る
氏名は不要、年齢・最寄駅・稼働可能日のみ記載する。スキルサマリーは案件の要求技術を3〜5行で明記し、毎回カスタマイズする前提でテンプレート化する。
ステップ2: 技術スキル一覧を5段階で自己評価する
言語・FW・DB・OS・ツールを列挙し、各項目に経験年数と★1〜★5のレベルを付与する。★3は「一人で機能実装ができる」水準、主要スキル以外の過大評価は避ける。
ステップ3: プロジェクト経歴を新しい順に詳細化する
期間・業界・チーム規模・役割・担当工程・技術・成果の7項目を固定フォーマットで記載する。直近3〜5年を手厚く、古い案件は2〜3行に要約する。
ステップ4: 成果を数値で記述する
「レスポンス改善」ではなく「P99を200ms→50msに短縮」のように定量化する。チーム規模も「BE4・FE3・QA2・PM1」まで分解して記載する。
ステップ5: 案件タイプ別に強調ポイントを差し替える
新規開発案件では技術選定経験と0→1実績を、運用保守案件では障害対応と監視設計を冒頭に配置する。応募ごとにサマリーと技術順序を入れ替え、5秒で強みが伝わる構成に仕上げる。
よくある質問（FAQ）
Q. 職務経歴書とスキルシート、両方必要？
フリーランスやSES案件では両方必須です。職務経歴書で人物像を、スキルシートで技術詳細を示す役割分担。自社開発正社員転職では職務経歴書だけで完結することが大半です。
Q. 経験年数は盛ってよい？
絶対にNGです。面談やオファー後のリファレンスチェックで必ず露見し、信頼失墜＋業界内で悪評が広がるリスクもあります。経験年数は正直に書き、深さとアウトプットで価値を示す方向に寄せるべきです。
Q. 複数案件の経歴をどう整理する？
最新から降順、各案件1/2ページ程度で区切るのが標準です。各案件は「期間／役割／チーム構成／技術スタック／主な成果」の5項目を箇条書きで。成果は可能な限り数字（処理件数、改善率、ユーザー数など）で示します。
