スキルシートの書き方は？ITエンジニアの7項目と例文

エージェントから届いたExcelを開いたまま、どこまで書けばいいのか決めきれず、提出が後ろへずれていく。独立して間もない時期に起きやすい詰まり方です。

受託とSESで7年の実務があっても、経験業務欄が「大手金融系システム」の一行で終わっていれば読み手は判断できません。工程欄が「開発担当」なら、設計から任せられるかも伝わりません。

見られているのは経歴の豪華さではなく、読み手が判断できる形になっているかです。

手を入れる順番は決まっています。工程欄を公的な区分の言葉に直すこと、冒頭200字の要約を作ること。この2つを先に片づければ、書類の状態は変わります。社名も案件名も出せない案件の書き換え方は、後半で扱います。

今日のうちに直せるのは、どちらからでしょうか。

基本の7項目と並び順はどうするか

記入欄は7つです。基本情報、職務要約、稼働条件、保有技術、資格、経験業務一覧、自己PR。

エージェント配布のExcelでは5ブロックにまとまっていることが多く、職務要約と稼働条件が独立した欄になっていないだけです。本記事では、記入欄として7項目に分けて扱います。

並び順は、読み手が判断する順に合わせます。配られたExcelの欄順を動かせない場合もありますが、各欄の中身の濃さは自分で決められます。

項目	書く内容	その位置に置く理由
基本情報	氏名（提出用はイニシャル）、年齢、最寄り駅、最終学歴	読み手が最初に属性と通勤圏を確認する
職務要約	経験年数、得意な工程、主な技術を200字程度	案件企業へ要約が転記される起点になる
稼働条件	稼働開始日、週の稼働日数、リモートと常駐の可否	条件が合わないと技術を読む前に外れる
保有技術	言語、フレームワーク、DB、クラウド、OS、ツール	照合の入口になる欄
資格	情報処理技術者試験、クラウドの認定資格など	技術欄の裏づけとして読まれる
経験業務一覧	案件ごとの記入要素（内訳は後述）	書類選考の判断がここで決まる
自己PR	強み、得意な工程、直近の技術、稼働条件	判断材料が出たあとに読ませる

稼働条件は、開始日と週の稼働日数だけでは足りません。月間稼働時間の目安と精算幅（下限と上限）、常駐の可否、商流と再委託の可否まで入れると、照合の往復が減ります。

NDAの範囲で出せる公開物があれば、URLを添えます。GitHub、技術ブログ、OSSへの貢献などです。

希望単価はシート本体に書かず、担当者にヒアリングやフォームで伝えるのが通例です。企業へ回る版に単価を残さないためです。

言語化する業務要素は職業情報で裏が取れる

何を書けばいいか迷ったときは、公的な職業情報を下敷きにできます。厚生労働省の職業情報提供サイト（job tag）には、職業ごとのページがあります。

システムエンジニア（Webサービス開発）のページには、次の内容が並びます。

• 「どんな仕事？」の仕事の流れ: 要件定義、基本設計、詳細設計、単体テスト、結合テスト、総合テスト、導入、保守
• 「どんな仕事？」内の「よく使う道具、機材、情報技術等」: OS（Linux）、データベース（MySQL）、クラウドサービス（AWS）など
• 別セクション「しごと能力プロフィール」のスキル: プログラミング、要件分析（仕様作成）の順で高いスコアが並ぶ

出典：厚生労働省 job tag システムエンジニア（Webサービス開発）

プログラミングの次に要件分析（仕様作成）が来る並びは、技術名だけでなく要件定義の経験を前に出す理由になります。工程、技術、能力の3方向から当てると、空いている欄が浮かびます。多いのは「導入」と「保守」です。

枚数とファイル形式の目安

分量の目安は、本記事ではA4で1枚から3枚に置きます。直近の3件から5件を厚く、それ以前は1行に圧縮し、案件数が多ければ3枚を超えても構いません。無理に収めて工程と役割を削るほうが損です。

提出形式はエージェントの指定が最優先で、指定がなければ編集可能な形式を主、PDFを副に用意します。担当者は受け取ったシートに社名のマスキングや体裁調整を入れて案件企業へ回すため、Excelでの提出を指定する場面があります。

原本は、届いたExcelのまま持ちます。ファイル名は「イニシャル＋スキルシート＋年月」のように、受け取る側が探せる形にそろえます。

下書きから完成までの書き方の流れ

白紙から出せるファイルにするには、順番があります。欄の上から埋めようとすると職務要約で止まるので、材料を集めてから要約を作ります。

要約は最後に書きます。本章で扱うのは、棚卸し、案件単位への分解、冒頭サマリの3段階です。工程と技術の書き方は次章で扱います。

経歴の棚卸しと案件単位への分解

最初の作業は、経歴を案件ごとに割り直すことです。在籍企業の単位では、中身の違う仕事が1行に潰れます。案件単位に割り直すと、行数は在籍した会社の数より増えます。

棚卸しのときに手元へ集めておくと書きやすい材料があります。

• 稼働時期が分かるもの（勤務表、請求書、稼働報告書）
• 自分が書いた成果物の種類（設計書、テスト仕様書、手順書）
• チームの人数と自分の立ち位置が思い出せるメモや議事録
• 使った技術のバージョンが分かる記録

同じ在籍期間でも、中身は別の仕事です。「大手金融系システム 2019年4月〜2021年3月」の2年が、新規開発の8カ月と、リリース後の改修の16カ月に割れることもあります。

経験業務一覧は1案件1行で書く

シートの7項目とは別に、経験業務一覧の1行をどう構成するかを決めます。入れる要素は、期間、業種、システム種別、規模、工程、技術、役割です。

新規開発の案件と既存改修の案件を、1件ずつ埋めた例を置きます。数値は本記事の作例なので、自分の記録の数値に差し替えてください。

記入要素	新規開発の案件（記入例）	既存改修の案件（記入例）
期間	2022年4月〜2023年3月（12カ月）	2023年4月〜2024年9月（18カ月）
業種	流通（小売）	金融（銀行）
システム種別	会員管理システムの新規構築	勘定系周辺システムの改修
規模	5名チーム（サーバーサイド2名）	8名チーム（改修要望の担当2名）
工程	要件定義、基本設計、詳細設計、実装、単体テスト（結合テストは仕様書レビュー）	影響範囲の調査、詳細設計、実装、単体テスト、回帰テスト
技術	Java、Spring Boot、PostgreSQL、AWS（EC2・RDS）	Java、Struts、Oracle、Linux
役割	会員登録APIの設計と実装、設計レビュー担当	改修要望の見積りと影響調査、単体テスト仕様の作成

この表を1行の文章に戻すと、書き換えの前後がはっきりします。

• 書き換え前: 大手金融系システム（2023年4月〜2024年9月）開発担当
• 書き換え後: 金融（銀行）向け勘定系周辺システムの改修（2023年4月〜2024年9月、8名チーム）。影響範囲の調査から詳細設計、実装、単体テスト、回帰テストを担当。Java、Struts、Oracle

固有名詞は1つも増えていません。期間から役割まで1行で追えれば、読み手はその行で判断できます。

冒頭サマリは200字で転記されやすくする

工程と技術を埋めたら、最後に冒頭の職務要約を書きます。先に書こうとすると抽象的になるので、材料がそろってから作ります。

冒頭の要約が、そのまま案件企業への紹介文に使われる場面を想定しておくと無駄がありません。担当者によって扱いは違うので、転記しやすい形にしておいて損はありません。

職務要約の例（つなげて1段落にします）

• Webシステムの受託開発とSESで7年、サーバーサイドの設計と実装を中心に担当してきました
• Javaでの業務システム開発が主で、基本設計から単体テストまでを主担当として進めました
• 直近はAWS上の構成設計と構築にも参加し、EC2とRDSを使った環境を担当しています
• 要件定義からの参加を希望しており、週◯日の稼働が可能です

「◯」は、自分の記録から拾った数値を入れる箇所です。思い出せない数値は空欄のままにして、面談で答えられる範囲だけを書きます。

技術スタックと担当工程の書き方

照合の入口は保有技術、判断の決め手は経験業務一覧の工程記述です。この2つの粒度で、紹介される案件の幅が変わります。技術は区分ごとに、工程は工程名ごとに書き分けます。

技術は区分ごとに年数と使い方を添える

保有技術の欄は、区分を立ててから中身を入れます。区分がないと、読み手は要件の言葉を探すのに時間がかかります。

区分	書き方の例
言語	Java（7年、Spring Bootでの新規開発と既存改修）
フレームワーク	Spring Boot（4年）、Struts（2年、既存改修のみ）
データベース	PostgreSQL（5年、テーブル設計とSQLチューニング）、Oracle（2年、既存改修）
クラウド	AWS（1年、EC2・RDS・S3の構成設計と構築を1案件）
OS	Linux（CentOS、Amazon Linuxでの運用コマンド操作）
ツール	Git、Jenkins、JIRA、Redmine

規模を書けるなら、担当したテーブル数、処理したバッチの件数、チームの人数のように、自分の担当範囲で説明できる数値に限ります。システム全体の非公開の指標は入れません。

実務と学習の区別も、この欄でつけます。まだ案件で使っていない技術は「学習中」「資格取得のみ」と添えれば、面談の技術質問で苦しくなりません。

工程名は公的な区分に合わせる

工程欄で損をしやすいのは、自己流の言葉です。エージェント配布のExcelでは、要件定義から運用・保守までが列として並んでいることが多く、その列名に合わせるのが最短です。先に見たjob tagの工程名も、ほぼ同じ並びでした。

IPAの共通フレーム2013は、関係する人々が「同じ言葉を話す」ことを目的に作られた枠組みです。

原文の言葉では「構想から開発、運用、保守、廃棄に至るまでのライフサイクル」が対象で、作業項目や役割を包括的に規定したものと説明されています。出典：IPA 共通フレーム2013（SEC BOOKS書籍案内）

「開発担当」の一語では、ライフサイクルのどこを担ったのかが決まりません。工程名は、下の表をそのまま使えば足ります。

原文が示すライフサイクルの5区分	スキルシートに書く工程名（本記事での対応づけ）
構想	企画、要件定義
開発	基本設計、詳細設計、実装、単体テスト、結合テスト、総合テスト
運用	運用、監視、障害対応
保守	保守、既存改修、回帰テスト
廃棄	システム移行、撤去（スキルシートで書く場面は少ない）

進行管理やプロジェクトマネジメントは、このライフサイクルとは別の軸です。工程欄には入れず、役割欄に書きます。

配られたExcelで工程が列になっていて、●主担当と○一部担当を付ける形式なら、凡例に従って記号で埋めます。どこを決めたかは、備考列か役割欄に文章で足します。

開発担当では何が伝わらないのか

「開発担当」の4文字では、担当した工程の範囲と、自分がどこを決めたかが伝わりません。

よくある書き方	判断できる書き方
開発担当	基本設計・詳細設計・実装・単体テストを主担当（結合テストは仕様書レビューのみ）
Javaでの開発	Javaで会員管理APIの設計と実装、5名チームで設計レビューを担当
テストも実施	単体テストの仕様書作成と実施、結合テストは他社ベンダーとの連携部分を担当
AWSを少し	AWSでEC2・RDS・S3の構成設計と構築を担当、運用は引き継ぎ

書き分けの軸は「誰と何人で、自分はどこを決めたか」です。チーム人数と決定範囲が1行入るだけで、設計から入れる人かどうかが読み取れます。

習熟度も「得意」「ある程度」と書くより、「独力で遂行できる範囲」「指導や既存実装を参照しながら担当」と記述に落とすほうが誤解がありません。

社名を出さずに案件を書く方法

エージェント経由のスキルシートは、契約に明文の禁止があるかどうかに関わらず、企業名やサービス名を書かないのが原則です。シートは担当者を通じて他の企業へ渡るため、他社の顧客名が載っていること自体が嫌われます。

固有名詞は、業種、事業規模、システム種別、自分の役割の4要素に分解すれば、伏せたまま情報量を保てます。

固有名詞を4要素に分解する

「大手金融系システム」の一行も、分解すれば書ける情報が残っています。

要素	書き換えの作り方	例
業種	公開されている産業分類の言葉に寄せる	金融（銀行）、保険、小売
事業規模	従業員数や拠点数の規模帯で表す	従業員数千人規模、全国数十拠点
システム種別	一般名詞で機能を言う	勘定系周辺システム、会員管理システム、在庫管理システム
自分の役割	工程と立ち位置で言う	8名チームのサーバーサイド担当、設計レビュー担当

4要素を組み直すと、「金融（銀行）向け勘定系周辺システムの改修、8名チームでサーバーサイドの設計と実装を担当」という1行になります。

置き換え語の作り方

置き換え語に推測が1つ混ざると、書類そのものが疑われます。確認できる事実の抽象度を1段上げるところで手を止めてください。

• 企業名を出せないとき: 業種＋規模帯に置き換える（例: 大手通信キャリア→通信、従業員数千人規模）
• サービス名を出せないとき: 機能の一般名詞に置き換える（例: ◯◯Pay→決済アプリのバックエンド）
• 規模を出せないとき: 自分が見た範囲の数値に限る（例: 担当テーブル数、バッチ処理件数、チーム人数）
• 期間を細かく出せないとき: 年月まででそろえる（例: 2023年4月〜2024年9月）

独立前の案件は、手元の秘密保持誓約書や就業規則で開示を禁じられている対象を先に確認します。判断が割れる表現だけ、担当者に案を見せて提出先に出せるか相談すれば足ります。

自己PR欄の書き方と例文

自己PRは、技術欄と経験業務欄を読んだあとの読み手に向けて書きます。ここで人柄を語り始めると、照合の流れが切れます。入れるのは、強み、得意な工程、直近の技術、稼働条件の4点です。長さは3文から5文で足ります。

型に沿って4点を並べる

4点の順番は、読み手が判断に使う順です。強みで何ができる人かを示し、得意な工程で任せられる範囲、直近の技術で今の手触り、稼働条件で参画の形を示します。

役割名で迷うなら、公的な定義を借りられます。IPAのデジタルスキル標準は、DX推進の人材を6つの類型に分けています。

ソフトウェアエンジニアは「システムやソフトウェアの設計・実装・運用を担う役割」と定義されています。出典：IPA DX推進スキル標準（DSS-P）

自己PRの1文目を「設計から運用まで担うサーバーサイドエンジニア」と置けば、公的な定義と同じ輪郭で読まれます。

サーバーサイド中心の例文

• Javaでの業務システム開発を7年経験し、基本設計から単体テストまでを独力で進められます
• 要件のあいまいな部分を設計前に洗い出す進め方が得意で、設計レビューで出た指摘は次の工程に持ち越さず全件反映してきました
• 直近はSpring Bootでの新規開発と、PostgreSQLのSQLチューニングを担当しています
• 週◯日、リモート中心での稼働を希望します

「コミュニケーションが得意」は、読み手には何も残りません。「要件のあいまいな部分を設計前に洗い出す」まで落とせば、どの工程で使える人かが読めます。強みは、作業名で書くものです。

既存改修が中心のときの例文

新規開発の実績が薄いなら、調査力と回帰テストで勝負します。仕様書がそろっていない現場を回してきた経験は、改修案件では新規開発の実績より強く読まれます。

調べ方も工程名で書きます。影響範囲の調査、改修箇所の詳細設計、回帰テストの設計まで分けると、任せられる範囲が読めます。

既存改修の例文

• 稼働中システムの改修を中心に7年、影響範囲の調査から単体テストまでを担当してきました
• 仕様書がそろっていない環境での調査と、改修後の回帰テストの設計が得意です
• 直近はJavaとOracleの既存システムで、月◯件の改修要望を処理しています
• 常駐と週3日のリモートのどちらにも対応できます

出典のない成果数値や、他社の記事で見た改善率をそのまま入れるのは避けます。受賞や認定、監修といった権威づけの言葉も、裏づけがないなら書きません。

提出前チェックと案件ごとの出し分け

書き上がったら、提出前に見る場所が決まっています。読み手が止まるのは、工程の粒度と期間の抜けの2カ所です。今日のうちに直せるものから並べます。

提出前に見る6項目

• 期間の連続: 経験業務一覧に期間の抜けがないか。書ける要素が少ない案件も、期間と業種だけで1行残す
• 工程の粒度: 「開発担当」のような一語が残っていないか。工程名に置き換える
• 表記ゆれ: 「Java」「java」「JAVA」、「AWS」「Amazon Web Services」が混在していないか
• 技術年数: 各技術の年数が、その技術を使った案件期間の合計を超えていないか（合計ではなく個別で見る）
• 形式とファイル名: エージェントの指定形式で出したか。イニシャルと年月がファイル名に入っているか
• 固有名詞と個人情報: 開示が禁じられている社名やサービス名、住所の番地や電話番号が残っていないか

技術年数は、足し算で合わせないことが大事です。1案件で言語、フレームワーク、DB、クラウドを並行して使うので、技術ごとの年数を合計すれば経歴年数を超えます。

原本と提出用は、書き分けます。自分の管理用はフルネームで持っていても、提出用は氏名をイニシャルに、住所は最寄り駅までに落とします。

原本1つと差し替え2カ所の二層管理

案件ごとに一から書き直す必要はありません。原本を1つ持ち、応募先ごとに差し替える箇所を2カ所に限ると回せます。

• 保有技術欄の区分内の並び順（クラウド寄りの案件ならAWSを先頭へ）
• 職務要約と自己PRの文面（改修中心の案件なら調査と回帰テストの話に替える）

経験業務一覧の行は動かしません。新しい案件が上の逆時系列が慣行で、読み手はここで直近性と期間の連続を見ています。推したい案件は、工程と役割の記述を厚くして目立たせます。

原本は、案件が終わるたびに追記します。終わった直後なら技術のバージョンや工程の範囲を思い出せますが、半年後には細部が消えます。

複数のエージェントに預ける場合も、原本は1つにまとめて管理します。同じ案件に2社から提案が入ると、提出先も担当者も調整がつかず見送りになるため、提案前に案件名か企業の特徴を担当者に確認して重複を避けます。

まとめ

手元のExcelを開いて、工程欄の「開発担当」を工程名に置き換えるところから始められます。

今週中に提出するなら、工程欄の直しと冒頭200字のサマリ作成の2つに絞るのが現実的です。技術欄の表記ゆれとファイル名は、そのあとで間に合います。

直したファイルは、登録しているエージェントに並び順と自己PRだけ差し替えて出してみてください。まだ1社なら、同じ原本のまま2社目に出せます。提案の前に、案件が重なっていないかだけ担当者に確認します。

書類の状態が変わったかどうかは、提出してから見えてきます。

よくある質問

希望単価はスキルシートに書くべきですか？

シート本体には書かず、担当者へのヒアリングや登録フォームで伝えるのが通例です。シートは担当者を通じて案件企業へ渡るため、単価を残すと交渉の前提が先に固定されます。希望額と最低ラインは、口頭やメールで担当者に数字で伝えておけば足ります。

案件が2〜3件しかない場合、経験業務一覧はどう埋めますか？

件数ではなく1件あたりの情報量で見せます。期間、業種、システム種別、規模、工程、技術、役割の各要素を1件ずつ埋め、担当工程は要件定義、詳細設計、実装、単体テストのように分けて書きます。長期の案件は担当フェーズごとに行を分けると、行数と判断材料の両方が増えます。

エージェント指定のExcelとPDFは、どちらで提出しますか？

指定があればその形式が最優先です。指定がなければ編集可能な形式を主、PDFを副に用意します。担当者が社名のマスキングや体裁調整をして案件企業へ回すため、PDFだけ送ると編集可能な版の再送を依頼されることがあります。

履歴書や職務経歴書とは何が違いますか？

履歴書は学歴や職歴の事実、職務経歴書は在籍企業ごとの業務、スキルシートは案件ごとの技術と担当工程を照合するための書類です。エージェントは案件の要件とスキルシートを突き合わせるため、技術名の粒度と工程の記述が中心になります。

ブランク期間がある場合はどう書けばいいですか？

期間を空けずに1行残します。その間にしていたこと（学習、資格取得、他分野での就業、療養など）を事実のまま短く書けば足ります。案件で使っていない技術は「学習中」「資格取得のみ」と添えて、実務と区別してください。

参考文献・出典

• IPA DX推進スキル標準（DSS-P）
• IPA 共通フレーム2013（SEC BOOKS書籍案内）
• 厚生労働省 job tag システムエンジニア（Webサービス開発）

最終更新: 2026-10-22です。引用データはIPAのDX推進スキル標準（デジタルスキル標準ver2.0の公開に伴い2026年4月16日に更新）に基づきます。

共通フレーム2013と、厚生労働省job tagの職業情報（2026-10-22取得）にも基づきます。

この記事を読んだ方におすすめ