エージェント登録や案件応募の際に「スキルシートを提出してください」と言われて、職務経歴書と何が違うのか分からないまま自己流で書いてしまう人は少なくありません。スキルシートは案件担当者が数十枚を短時間でさばく資料であり、書き方次第で選考の通過率が変わります。本記事では、職務経歴書との違いから具体的な記載項目、評価されやすい書き方までを整理します。
スキルシートと職務経歴書は目的が違う
まず前提として、スキルシートと職務経歴書は似ているようで役割が異なります。
職務経歴書は「この人物を採用してよいか」を判断するための資料です。人柄、志望動機との一貫性、キャリアの方向性など、定性的な要素を含めて評価されます。正社員採用の選考でよく使われる形式です。
一方でスキルシートは「この人を今回の案件にアサインできるか」を判断するための資料です。案件担当者やSES・フリーランスエージェントの営業担当は、クライアントから提示された要件（言語、フレームワーク、経験年数、役割など）とスキルシートの記載内容を突き合わせて、マッチするかどうかを機械的に確認します。読み手が数分〜十数分で判断できることが前提になっているため、情報の構造化と具体性が何より重視されます。
この違いを理解せずに、職務経歴書のような物語調の文章でスキルシートを書いてしまうと、必要な情報が拾いにくくなり、書類選考の段階で不利になることがあります。
スキルシートに記載する基本項目
フォーマットはエージェントや企業によって多少異なりますが、一般的に求められる項目は以下の通りです。
- 経験年数（総経験年数と、言語・技術ごとの経験年数）
- 使用言語・フレームワーク・ライブラリ
- データベース（種類、設計経験の有無、規模）
- インフラ・クラウド（AWS、GCP、Azureなどの利用サービス）
- 開発工程（要件定義〜運用保守のどこを担当したか）
- 役割（メンバー、リーダー、PM、アーキテクトなど）
- プロジェクト規模（チーム人数、開発期間、ユーザー規模など）
- 業種・業界（金融、EC、医療などドメイン知識の有無が分かる情報）
これらをプロジェクトごとに一覧化し、さらに全体のサマリーとして「得意な領域」「経験年数の合計」を冒頭にまとめておくと、担当者が最初の数十秒で全体像を把握しやすくなります。案件担当者は多忙なため、詳細を読み込む前に「候補として検討する価値があるか」をこの冒頭部分で判断していることが多いです。
「担当工程」の書き方が重視される理由
スキルシートの中でも特に見られているのが「担当工程」の記載です。単に「Java、Spring Boot、要件定義〜運用まで一通り経験」と書くだけでは、実際にどこまで深く関わったのかが伝わりません。
案件担当者が知りたいのは、次のようなことです。
- 要件定義であれば、要件をヒアリングする側だったのか、まとめる側だったのか
- 設計であれば、基本設計まで担当したのか、詳細設計・DB設計まで踏み込んだのか
- テストであれば、テスト設計を書いた側なのか、テストケースを実施しただけなのか
工程名を並べるだけでなく、「どのフェーズで、何を、どの粒度で担当したか」を一段掘り下げて書くことで、案件で求められる役割と実際の経験のズレを事前に減らすことができます。これは選考通過率だけでなく、稼働開始後のミスマッチを防ぐ意味でも重要です。
守秘義務に配慮した案件名・企業名の書き方
スキルシートには実際のプロジェクト経験を書く必要がありますが、多くの契約には守秘義務（NDA）の条項が含まれており、企業名やプロジェクト名、システムの詳細をそのまま記載できない場合があります。
一般的には、次のような書き方で配慮されています。
- 企業名を出さず「大手小売業のECサイト」「金融系企業の基幹システム」のように業種と規模感で表現する
- システム名や社外秘の仕様には触れず、技術要素と役割のみを記載する
- エンドクライアント名の記載可否が不明な場合は、事前に契約書やNDAの内容を確認する
どこまで開示してよいかは契約内容によって異なるため、迷う場合は自己判断せず、当時の契約書やNDAを確認するか、可能であれば元の契約先や現在所属するエージェントに確認することをおすすめします。判断に迷うケースでは、契約や法務の専門家に相談するのも一つの方法です。
よくある減点パターン
スキルシートでよく見られる、評価が下がりやすいパターンをいくつか挙げます。
技術要素の羅列だけで深さが伝わらない
「Java, Python, AWS, Docker, Kubernetes」のように単語を並べただけでは、それぞれをどの程度使えるのかが分かりません。経験年数や具体的な用途を添えることで、実態が伝わりやすくなります。
プロジェクトごとの粒度がバラバラ
あるプロジェクトは数行で詳細に書き、別のプロジェクトは一行で済ませているなど、記載の密度に差があると、担当者は「情報が少ない部分は経験が浅いのでは」と受け取ることがあります。すべてのプロジェクトで同じフォーマット・同じ粒度を意識すると読みやすくなります。
役割と規模が書かれていない
チームの人数や自分のポジションが分からないと、実際の裁量や難易度が判断できません。「5名チームのうち3名を率いるリーダー」のように具体的に書くことが望まれます。
最新の情報に更新されていない
古い案件のまま更新されていないスキルシートは、直近の経験や現在のスキルレベルが伝わりません。定期的に見直し、直近の案件を追記する習慣を持つとよいでしょう。
未経験領域を書くときの誠実な線引き
案件の幅を広げたいという理由から、経験の浅い技術を実務経験と同じように書いてしまうケースがあります。しかし、これは稼働開始後のミスマッチにつながりやすく、結果的に本人にとっても不利益になります。
誠実な書き方としては、次のような区別が有効です。
- 実務で担当した経験:プロジェクト名とともに記載し、役割・工程を明記する
- 個人学習・研修レベルの経験:「学習経験あり」「個人開発で使用」など、実務経験と明確に分けて記載する
- 触れた程度の経験:無理に書かず、面談で聞かれた際に正直に答える
実務経験と学習経験を混同させずに書くことは、選考時の印象を守るだけでなく、案件参画後の信頼関係にも関わります。分からないことを分からないと書く姿勢は、遠回りに見えて長期的にはプラスに働くことが多いです。
まとめ
スキルシートは職務経歴書とは異なり、案件担当者が短時間で適合性を判断するための資料です。経験年数や技術要素だけでなく、担当工程の深さ、役割、プロジェクト規模を具体的に書くことが評価につながります。守秘義務に関わる部分は自己判断せず契約内容を確認し、未経験領域は正直に区別して記載しましょう。まずは直近のプロジェクトを一つ選び、担当工程を細分化して書き直すところから始めてみてください。
