スキルシートの書き方｜エンジニアの案件につながった項目と意識したこと

エンジニアのスキルシートの書き方で差がつくのは、項目の選び方ではありません。書く項目はどのスキルシートでもだいたい決まっていて、差が出るのは案件ごとの経歴に「習得スキル」と「意識したこと」まで書けているかどうかです。

僕は2009年に新卒でSIerに入り、2016年にフリーランスエンジニアとして独立しました。それからずっと、エージェントに出す経歴書（スキルシート）で案件を探してきました。途中からは案件ごとに「習得スキル」と「意識したこと」を書き足すようにしています。いまは.NETの業務系の現場で働いています。業務委託のエンジニアを受け入れる面談に、面談する側の一人として参加することもあります。

この記事ではスキルシートを書く側と読む側の両方の立場から、書く項目・書き方のルール・雛形をまとめます。

スキルシートを出す先のエージェント選びから考えたい方は、フリーランスエンジニアのエージェントの選び方も読んでみてください。

スキルシートに書く項目

スキルシートに書く項目は、個人情報・保有スキルの概要・案件ごとの経歴・自己PRの4つに分かれます。中心になるのは案件ごとの経歴で、スキルシートの大半はここが占めます。

僕がエージェントに出してきた経歴書には、次のような項目を書いていたはずです。

• 業務の概要
• 開発システム概要
• 開発規模
• 役割
• 言語
• 使用ツール
• OS

記憶で書いているので細かい抜けはあるかもしれません。ただ、一般的なスキルシートのテンプレートと比べても大きくは変わらない並びです。ここから順番に、何をどこまで書くかを見ていきます。

個人情報と保有スキルの概要

スキルシートの最初には、個人情報と保有スキルの概要を書きます。個人情報は、名前・年齢・最寄り駅・稼働できる時期くらいで十分です。

エージェント経由で現場に渡るスキルシートでは、名前をイニシャルにするなど個人情報を伏せた形で出されることが多いです。住所を番地まで書いたり、顔写真を貼ったりする必要は基本的にありません。どこまで載せるかは、登録するエージェントの書式に合わせるのが確実です。

保有スキルの概要は、スキルシートの「目次」のような役割を持つ欄です。言語・フレームワーク・データベース・経験した工程を、経験年数と一緒に一覧にします。

僕なら、言語はC#とVB.NETです。割合は半々くらいで、若干VB.NETのほうが多いかもしれません。作ってきたものはWindowsフォームアプリ・Webサイト・コンソールアプリなど、業務系システムがほとんどです。概要欄にはこの「何を作ってきたか」まで短く書いておくと、読む側が案件との相性を判断しやすくなります。

資格の欄もここに入ります。僕はIT系の資格を持っていません。基本情報と応用情報を受けたことはありますが、どちらも不合格でした。資格がなくても実務で困ったことはありませんが、取れるなら書ける資格があったほうがいいと思っています。資格の欄が空くぶん、経歴のほうで何ができるかを伝える必要があります。

案件ごとの業務の概要と開発システム

案件ごとの経歴は、「業務の概要」と「開発システム概要」から書き始めます。業務の概要は、そのシステムがどんな業務を支えているかです。開発システム概要は、そのシステムの形と自分が担当した範囲です。

書くときは、システム名や社名を出さずに種類で書きます。たとえば「〇〇社の△△システム」ではなく、「金融系の業務システム（帳票出力・データ連携）」のように書く形です。スキルシートは、エージェントから複数の会社に渡る書類です。前の現場の固有名詞は書かず、守秘義務を守っていることが伝わる書き方にしておくと安心です。

一方で、業界の種類まで伏せる必要はないとされています。「金融系」のような種類が書いてあれば、読む側は案件との業務の近さを判断できます。僕が2016年に最初の案件（信託銀行の業務システム）に受かったのも、業務に親和性があったからではないかと考えています。会社員時代に、生保や損保といった金融系の案件に携わっていたからです。

開発規模と役割

開発規模には、チームの人数と期間を書きます。システムの規模を示す数字（画面数・本数など）が出せるなら、それも添えます。

役割は、チームの中での立場と担当した工程です。「メンバー」「サブリーダー」「リーダー」といった立場に、「詳細設計〜結合テスト」のような工程を組み合わせて書きます。

ここで大事なのは、自分がやったこととチームがやったことを分けて書くことです。チームで要件定義をしていても、自分が関わったのが製造からなら「製造〜結合テスト」と書きます。盛った部分は、面談の深掘りの質問で聞かれやすいところです。

言語・使用ツール・OS

言語・使用ツール・OSは、案件ごとに使ったものをそのまま並べます。言語はバージョンまで書けると、読む側の判断材料が増えます。

使用ツールには、開発環境・バージョン管理・データベースの管理ツールなど一般に名前の知られた製品を書きます。一方で、現場独自のツールや社内の仕組みの名前は書きません。これも業務の概要と同じで、種類に置き換えます。

OSは、開発した環境と動かした環境のどちらも分かるように書きます。業務系ではWindowsのサーバーで動くシステムも多いので、ここが案件の条件と合うかを見る人もいます。

案件ごとの経歴は「習得スキル」と「意識したこと」まで書く

スキルシートの案件ごとの経歴には、やったことに加えて「習得スキル」と「意識したこと」まで書きます。僕が途中から書き足すようになった項目で、スキルシートの書き方で一番伝えたいのはここです。

やったことを並べるだけでは伝わらない

業務の概要・規模・役割・言語だけのスキルシートは、事実としては正しくても書いた人の中身が伝わりにくい書類です。同じ工程・同じ言語の経歴は、ほかの応募者のスキルシートにもたくさん並んでいます。

僕の経歴書も、最初は業務の概要からOSまでの項目だけでした。途中から、案件ごとに「習得スキル」と「意識したこと」を書き足すようにしています。

書き足したことで、面談で話す内容も変わりました。ただ業務の経歴を説明するだけでなく、その案件で自分が意識したことなどのプラスアルファを話すようになったのです。

年を重ねて経験が増えたこともあります。それでも話す内容を変えたことは、案件獲得のプラスになっていると僕は感じています。あくまで僕の実感です。

習得スキルの書き方

習得スキルには、その案件に入ってから新しく身についたことを書きます。言語やツールだけでなく、工程や業務の知識も習得スキルに入ります。

書き方の例を挙げます。

• 言語・技術：「〇〇（フレームワーク名）での画面開発を、この案件で初めて経験」
• 工程：「要件定義から実装まで一貫して担当」
• 業務知識：「〇〇業務の締め処理の流れ」
• 働き方：「AIを使った実装の効率化」

案件の数だけ書く場所があるので、1つの案件に2〜3行あれば十分です。どの案件でも同じことを書いているなら、それは「その案件で身についたこと」ではありません。もともと持っていたスキルです。保有スキルの概要のほうに移します。

意識したことの書き方

意識したことには、その案件で自分が気をつけていたこと・工夫したことを書きます。習得スキルが「何が身についたか」なら、意識したことは「どう仕事をしたか」です。

たとえば、次のような書き方があります。

• 「改修の前に影響範囲を洗い出してから手を入れた」
• 「ユーザーの要望をそのまま流さず、開発側が作りやすい形に言い直して伝えた」
• 「本番リリースの手順を事前に洗い出して、当日の作業を減らした」

2つめは、僕がいまの現場で大事にしていることです。いまの現場の一つでは発注する側の立場で仕事をしていて、ユーザーとベンダーの間に入ります。要望をただ横流しするのではなく、相手が仕事しやすいように翻訳することが大切だと感じています。

意識したことは、面談でそのまま話の種になります。スキルシートに書いてあると、面談する側から「ここはどういうことですか」と聞いてもらえるからです。面談での話し方はフリーランスエンジニアの面談対策にまとめています。

スキルシートと職務経歴書・履歴書の違い

スキルシートと職務経歴書・履歴書の違いは、「その案件に合うスキルがあるか」を伝えるために案件単位で細かく書く書類だという点です。履歴書は本人の基本情報を、職務経歴書は会社ごとの仕事と成果を伝える書類です。見る人も目的も少しずつ違います。

出す目的

スキルシートを出す目的は、案件を探している現場に「この人ならこの仕事を任せられそうか」を判断してもらうことです。フリーランスの場合はエージェントに登録するときに出して、エージェントが案件に合わせて現場へ渡す流れが一般的です。

職務経歴書と履歴書は、主に会社員として採用してもらうための書類です。長く働いてもらえるかや会社に合う人かといった点も見られます。

フリーランスの面談で決まるのは、雇用ではなく業務委託の契約を結ぶかどうかです。だからスキルシートでは、人柄や将来性よりも「いま何ができるか」が重く見られます。

書く中身の違い

書く中身の違いを表にまとめます。

僕はSIerに入社してから2016年に独立するまで、転職をしていません。だから職務経歴書を書いて転職活動をした経験はありません。書いてきたのはエージェントに出すスキルシートだけです。

SIerで働いている方なら、社内で案件ごとの経歴をまとめた書類を作ったことがあるかもしれません。書き方の感覚はそちらに近いものです。会社の中でプロジェクトにアサインされるときの経歴書を社外の人向けに書き直したもの。スキルシートはそう考えると分かりやすいです。

読みやすいスキルシートの基本ルール

読みやすいスキルシートの基本ルールは、「短く収める」「箇条書きで具体的に書く」「誤字脱字を残さない」の3つです。どれも当たり前に見えますが、書いた本人は意外と気づきにくいところです。

A4で1〜2枚に収める

スキルシートは、A4で1〜2枚に収めるのが目安です。面談する側は、限られた時間でスキルシートを読みます。長いスキルシートは、肝心な経歴にたどり着く前に読む集中が切れてしまいます。

とはいえ、経験が10年を超えると2枚では収まらないこともあります。そのときは古い案件ほど短くして、直近の案件と案件に近い経験を厚く書きます。すべての案件を同じ分量で書く必要はありません。

直近の案件を厚く書く理由は、もう1つあります。面談する側は、直近の経歴をよく見ているからです。これは後の「面談につながるスキルシートにするには」で詳しく書きます。

箇条書きで具体的に

案件ごとの経歴は、文章でつなげず箇条書きで書きます。1行に1つのことを書くと、読む側が必要なところだけ拾えます。

具体的に書くとは、形容詞ではなく中身で書くことです。

• 「大規模なシステムの開発に携わった」ではなく「チーム15名・期間1年の開発で、帳票出力の機能を担当」
• 「コミュニケーション力を活かした」ではなく「ユーザーとの打ち合わせに出て、要望を仕様書にまとめた」
• 「効率化に貢献した」ではなく「手作業で行っていた集計をバッチ処理にして自動化した」

例の数字は説明用の架空のものです。書くときは、自分の案件の実際の数字に置き換えてください。数字が分からないときは、無理に作らず「数名」「数か月」のように書くほうが安全です。

誤字脱字を残さない

誤字脱字は、出す前に必ずなくしておきます。1つの誤字で落ちることはないにしても、細かいところまで気が回らない人という印象につながります。

エンジニアのスキルシートで特に気をつけたいのは、技術用語の表記です。

• 大文字と小文字（「Javascript」「Github」のような書き方）
• 製品名やバージョンの書き間違い
• 同じ言葉の表記ゆれ（「データベース」と「DB」が混ざるなど）

「VB.NET」「C#」「.NET」のような言語名の書き方も、そろえておくと安心です。毎日使っている言語の名前の表記ミスは、特に目立ちやすいとされています。

面談につながるスキルシートにするには

面談につながるスキルシートにするには、面談する側が最初に見るところを押さえて案件に合わせて書き方を直すことです。面談する側の話は、僕が業務委託の面談に面談する側の一人として参加して感じていることです。どれも僕個人の見方で、どの現場でも同じ基準だとは限りません。

面談する側が最初に見るところ

面談する側としてスキルシートを読むとき、僕がまず見るのはスキルが現場に合っているかです。

合っていなくても、すぐに落とすわけではありません。スキルが少しずれていても、それでもいいと思える観点があれば大丈夫です。一般的には、言語は違っても同じ業務を長く経験しているといった点がそうした観点になりえます。スキルシートに「習得スキル」と「意識したこと」が書いてあると、その観点を見つけやすくなります。

もう1つ見ているのが、直近の経歴です。数か月で終わった案件ばかりが続いていると、正直なところ不安に感じます。

受ける側としても、同じ案件を何年も続けているほうが経歴書の見栄えが良いと感じてきました。僕のいまの金融系の案件は2020年から続いています。

短く終わった理由はスキルシートだけでは読み取れないので、事情があるなら一言添えておくのが一般的です。「プロジェクトの終了による」「当初から3か月の予定だった」のように、事実だけを短く書けば十分です。

案件に合わせて並べ替える

スキルシートは一度作って終わりではなく、応募する案件に合わせて直します。書いてある事実は変えずに、案件に近い経験が目に入りやすい順番にする直し方です。

直すところは主に3つです。

1. 保有スキルの概要で、案件で使う言語・工程を先に書く
2. 自己PRの最初の1〜2行を、案件に近い経験の話にする
3. 案件に近い経歴の「習得スキル」と「意識したこと」を厚くする

案件ごとの経歴そのものは、新しい順か古い順かの並びをそろえておきます。並びがばらばらだと、かえって読みにくくなるからです。

僕が最初のスキルシートを作ったのは2016年、会社に退職を伝えた後でした。最初の案件が決まった面談では、.NET系の開発経験が7年ほどあることと基本的に一人称で仕事を進められることを伝えています。スキルシートの自己PRも、案件に一番効く強みを1〜2個に絞って先頭に置くと伝わりやすくなります。

AIを使った経験を書く

いまのスキルシートには、AIを使った経験も書いておきたいところです。面談する側として、最近はAIの使い方も見ているからです。

見ているのは、AIの知識の量ではありません。コーディングだけでなく調査や資料作成まで、自分の仕事をどれだけAIに任せられるか考えながら働いているかです。そういう意識が見える人は「使える」と感じます。

エンジニアでも、AIをほとんど触ったことがない人はけっこういます。AIでコーディングした経験やエージェント型AIにゼロから任せて何かを作った経験をある程度話せるだけで、意外と半分より上にいく気がします。これは僕の感覚で、数字で確かめたものではありません。

スキルシートに書くなら、次のような形です。

• 習得スキルの欄：「対話型AIを使った実装の効率化」
• 意識したことの欄：「AIに渡す指示を、誰が見ても同じ成果物になる粒度で書いた」
• 自己PRの欄：個人でAIを使って作ったもの

僕は仕事では開発用のPCで対話型AIを使っていて、ソースを1から書くことはだいぶ減りました。個人ではエージェント型AIで、スケジュール把握とタスク整理・簡単な動画編集・コンテンツ生成の自動化の仕組みを作っています。業務のコードは外に出せなくても、個人で作ったものなら自己PRに書けます。

面談でAIの話をどう広げるかは、フリーランスエンジニアの面談対策のAIの章で書いています。

エージェントの推薦文・GitHubの使い方

スキルシートを補う材料として、エージェントの推薦文とGitHubがあります。どちらも、スキルシートだけでは伝わらない部分を補うものです。

エージェントによっては、スキルシートを現場に渡すときに担当者のコメントや推薦文を添えてくれます。自分では書きにくい人柄や働きぶりを、第三者の言葉で伝えてもらえる欄です。担当者との日頃のやり取りで自分の強みや希望を具体的に伝えておくと、推薦文に反映してもらいやすくなります。

GitHubは、公開できるコードがある人に向く方法です。業務系の現場では、業務のコードを外に出すことはまずできません。僕が経験した金融系の現場にも、PCからインターネットに接続できない環境がありました。業務のコードの代わりに、個人で作ったツールのリポジトリを載せる形になります。

公開しているコードがない場合は、スキルシートの経歴の書き方で伝える工夫をするのが一般的です。業務系の案件では、業務のコードを見せられないことは前提として読まれます。

スキルシートの雛形（項目だけ）

スキルシートの雛形は、ここまでの項目を上から並べれば作れます。エージェントから書式を渡されたときはそちらに合わせ、足りない項目だけを書き足すのが手堅いやり方です。

そのまま使える項目の並び

項目だけの雛形です。Excel・Wordのどちらで作っても構いません。

案件ごとの経歴を1つ書いた記入例も載せます。これは説明のために作った架空の一般的な例で、僕自身のスキルシートの中身ではありません。

使用ツールの欄は、実際に書くときは一般に名前の知られた製品名を書きます。書かないのは、現場独自のツールやシステムの名前です。

出す前に見直すこと

スキルシートを出す前に、次の点を見直します。

• 保有スキルの概要と、案件ごとの経歴の中身が食い違っていないか
• 案件ごとに「習得スキル」と「意識したこと」が1行以上あるか
• 前の現場のシステム名・社名・現場独自のツール名が残っていないか
• 盛って書いたところがないか（面談で深掘りされても答えられるか）
• AIを使った経験を、どこかに書いているか
• 技術用語の表記と、誤字脱字

最後の確認は、声に出して読むのがおすすめです。面談ではスキルシートを見ながら質問されるので、書いた内容を自分の言葉で説明できるかの確認にもなります。

スキルシートが整ったら、次は出す先のエージェント選びです。エージェントによって、扱う案件の分野や書式が違います。選び方はフリーランスエンジニアのエージェントの選び方にまとめています。まだ会社員でこれから独立する方は、フリーランスエンジニアの準備もあわせて読んでみてください。在籍中にやっておくことを書いています。