SESスキルシートの書き方｜案件数が多い時の集約術と粒度

SES経験者のスキルシートが「書けない」理由

SESで長く働いてきたエンジニアがスキルシートで詰まるのは、単に案件が多いからではありません。案件1件ごとの詳細な書き方（担当フェーズ・規模・体制の粒度）を機械的に全案件に適用すると、10案件でA4換算15〜20ページを超え、要点以外は流し読みされやすくなるからです。案件1件ずつの詳細記法はスキルシートの案件詳細の書き方｜担当フェーズ・規模・体制の粒度で解説しているので、詳細に書くべき案件についてはそちらを参照してください。本記事では「詳細に書く案件」と「集約する案件」を分ける前提で、集約側の設計に絞って扱います。

案件数が招く3つの詰まりポイント

案件数が多いこと自体が問題なのではなく、以下の3つが同時に起きるのが実情です。

• 書類が長すぎて読まれない：エージェントの担当者や案件先の担当者は、書類選考段階でスキルシートに目を通す時間が限られています。エージェント実務では15ページを超えると冒頭以外は流し読みされやすい傾向があります

• 同じ技術・同じ役割の繰り返しが可視化される：SESで似た系統の案件を続けていた場合、案件を1件ずつ書くと「Java・SI・詳細設計」が10案件並ぶ書類になり、案件先の担当者に「同じことを続けていた」印象を残します

• 本当に見せたい案件が埋もれる：直近の高難易度案件やリードロールの案件が、5年前の運用保守案件と同じ粒度で並ぶと、読み手はどこに注目すべきか判断できません

汎用スキルシートの書き方は既存記事へ

スキルシートの全体書式（項目名、フォーマット、記入例）そのものはフリーランスエンジニアのスキルシートの書き方を徹底解説！記入例や今すぐ使えるフォーマットも紹介！で扱っています。スキルシートを一から作る段階の方はまずそちらで枠を決めてから、本記事の集約術を案件欄に適用してください。実績が少ない場合の書き方は実績が少ないフリーランスエンジニアでも通るスキルシートの書き方を参照します。SES時代の職務経歴書との使い分けは職務経歴書とスキルシートの違い｜フリーランスエンジニアの使い分けと書き方で整理しています。

集約と詳細記載を分ける判断フロー

まず、手持ちの案件を「詳細に書く案件」と「集約する案件」に分けます。分ける基準は経過年数ではなく、現在アピールしたいスキル・役割との距離で決めます。

分岐の判断軸

以下の4つのどれかに該当する案件は詳細に書き、それ以外は集約対象にします。

• 直近3〜5年に経験した案件（技術・体制がまだ現行の実務に近い）

• 現在アピールしたい技術スタックの主要経験を持つ案件

• リードロール・設計上流・PMなど、役割としてアピールしたい経験を含む案件

• 定量的な成果（性能改善◯%、コスト削減、ユーザー数など）を残せる案件

例外として、SES歴が10年を超え直近5年でも案件数が15を超える場合は、直近5年の中でも上記4基準に該当しないものは集約側に回す判断を検討してください。

直近何年で切るかの目安

直近何年で切るかはSES歴と案件数で変わります。以下は、フリーランス案件の書類選考で使われやすい実務上の目安です。

上表はフリーランス案件応募で使うスキルシートの実務目安で、応募先や職種・エージェントのフォーマットで前後します。「直近◯年」も固定ルールではなく、キャリアの節目（言語転向・上流工程への移行など）で区切ってもかまいません。

ミニFAQ

Q. 全案件を1件ずつ書き切ったスキルシートは、なぜ読まれにくいのですか？

書類選考では短時間で確認されることが多く、20ページを超える書類は冒頭数件と直近数件しか読まれない傾向があります。集約すれば読み手が「全体で何をやってきたか」を最初に把握してから詳細に入れるため、通過後の会話につながりやすくなります。

Q. 集約すると経験年数が短く見えませんか？

サマリー欄（職務要約）で通算年数と業界内訳を先に宣言すれば、集約しても経験年数の総量は伝わります。年数の伝え方はスキルシートの職務要約の書き方｜冒頭3行で読ませる型と職種別テンプレを参照してください。

集約の3つの軸｜業界・技術・役割で束ねる

集約は「案件を減らす」のではなく、複数の案件を1つの塊として書き直す作業です。塊を作る軸は3つあります。どれか1つで束ねてもいいですし、組み合わせてもかまいません。

業界軸で束ねる

同じ業界（金融、EC、公共、通信、製造など）の案件を1つの塊にまとめる書き方です。SESで同一業界の常駐が続いた場合に有効で、業界特化のドメイン知識を強みとして提示できます。

書き方の例：

「20XX年〜20XX年：金融系SIプロジェクトを3案件（メガバンク勘定系保守、証券会社の顧客管理刷新、ネット銀行のAPI基盤）で経験。いずれもJava/Oracle中心。3件を通じて金融ドメイン特有の障害対応フロー・システム間連携の設計勘所を蓄積」

技術軸で束ねる

同じ技術スタック（Java+Spring、C#+.NET、PHP+Laravelなど）の案件を集約する方法です。技術の熟練度をアピールしたい場合や、同じ言語で複数プロジェクトをまわしていた時期に向いています。

書き方の例：

「20XX年〜20XX年：Java/Spring Bootを中核とした受託開発を4案件担当。金融・製造・小売と業界は異なるが、REST API設計、Spring Security、JPA/Hibernateによるデータアクセス層構築を共通業務として実施」

役割軸で束ねる

担当した工程・役割（詳細設計、テスト、運用保守、開発リーダーなど）で束ねる方法です。工程の反復経験や、同じロールでの案件遍歴を強調したい場合に使います。工程名の粒度は募集要件の表現に合わせつつ、必要に応じてIPAの共通キャリア・スキルフレームワークの工程用語も参考にすると、案件先の担当者と齟齬なく読み合わせしやすくなります。

書き方の例：

「20XX年〜20XX年：SES常駐で運用保守フェーズを主に担当（5案件、通信・公共・製造）。障害一次対応、監視設定、月次リリース管理をローテーションで実施。うち2案件で運用改善提案（自動化スクリプト導入で対応時間を短縮）に関与」

束ねる時の注意点

軸を選ぶ時は、その塊を読んだ読み手が「あなたに何を頼めるか」を判断できるかを基準にしてください。3軸のどれで束ねても伝わらない場合は、集約せず個別案件として残す判断も選択肢に入ります。

ミニFAQ

Q. 業界と技術のどちらの軸で束ねるべきですか？

現在応募したい案件の募集要件に近い方を選びます。金融系の案件を狙うなら業界軸、Javaフリーランス案件を狙うなら技術軸で束ねる方が、応募先の担当者にとって関連情報が読みやすくなります。

集約テンプレート4パターン

集約の型を4つに分けて示します。手持ちの案件がどの型に当てはまるかで、書き方を選んでください。

型1：同一業界・複数案件を1行に束ねる

同じ業界で3〜5案件が続いた場合の書き方です。個別案件名は消し、業界内での担当領域と共通の技術スタックだけを残します。

補足として1〜2行で「金融ドメイン特有の要件（勘定系のバッチ制約、規制対応の変更管理など）に対応」といった注記を添えると、案件先の担当者が判断しやすくなります。

型2：同一技術スタックの案件を技術軸で集約

複数業界にわたって同じ技術スタックで働いていた期間を1つの塊にします。技術の総経験年数を明示するのがポイントです。

その下に「Laravelは5系〜10系までの経験あり」「マイグレーション・キュー処理・API設計を継続的に担当」など、技術の深さを示す一文を添えます。

型3：同一ロールの案件を役割軸で集約

同じロール（開発リーダー、テストリーダー、運用保守など）を複数案件で担っていた場合の書き方です。役割で軸を作ることで、リード経験の年数と対象規模を明示できます。

役割軸で集約する場合、リード業務での改善事例（レビュー観点の標準化、進捗可視化ツール導入など）を補足に1〜2行残すと、案件先が「頼める役割」を判断しやすくなります。

型4：短期・スポット案件は年ごとにまとめる

1〜3ヶ月の短期案件や、緊急対応で入った案件が複数ある場合は、年単位でまとめます。1件ずつ書くとかえって「継続性がない」印象を与えてしまうためです。

補足で「主要技術：Java/Python」「案件先の業界：金融・製造」など、束ねた案件群の共通項を示します。

集約時に落としてはいけない情報｜粒度の判断基準

集約は「削る」ではなく「束ねる」です。以下の3つは束ねても残してください。読み手が案件の重みを判断する材料になります。

期間の抜けを作らない

集約後もキャリア上の期間に抜けができないよう、月単位（または年単位）で連続性を保ちます。抜けがあると「その期間に何をしていたか」を面談で必ず聞かれます。ブランク期間がある場合は隠さず、別行で「20XX年〜20XX年：育児休業／自己学習期間」のように明記してください。

技術・体制の変化点は個別に残す

同じ塊の中でも、技術スタックが大きく変わった時期や、体制が変わった時期は塊の中で区別して書きます。

例：

「20XX年〜20XX年：金融系SIプロジェクトを3案件経験。前半2案件はJava/Oracle、後半1案件はJava/AWS/PostgreSQLへ移行。クラウド移行の経験含む」

上流経験・成果指標は個別に残す

要件定義・基本設計に関与した案件、定量成果（性能改善◯%、コスト削減、ユーザー規模など）を残せる案件は、集約塊の中でも1〜2行分の個別注記をつけます。上流経験の書き方はスキルシートの案件詳細の書き方｜担当フェーズ・規模・体制の粒度で解説しています。

ミニFAQ

Q. 契約上、案件先の会社名や案件名を書けない場合はどうしますか？

契約やNDAの内容によっては、案件先名や案件名の記載に制限があるため、「大手金融系」「メガバンク基幹系」など業界・役割ベースで匿名化して書くことが多くなります。最終的な開示可否は契約書やエージェントに確認してください。契約形態そのものの違いを確認したい場合の参考資料として、厚生労働省の労働者派遣事業関係業務取扱要領などが利用できます。

サマリー欄（職務要約）の使い方

集約したスキルシートは、サマリー欄で全体像を先に宣言してから詳細に入る構成にします。サマリーで通算年数・業界内訳・技術内訳を書いておけば、読み手が実力の総量を把握しやすくなります。

書き方の型：

「エンジニア歴◯年（うちSES◯年、フリーランス◯年）。金融系◯年、EC・SaaS系◯年、公共系◯年の経験あり。主要スタックはJava/Spring（◯年）、Python/Django（◯年）。直近3年は開発リーダーとして5〜10名規模のチームを担当」

サマリーの3行構造（役割・強み・実績）の作り方はスキルシートの職務要約の書き方｜冒頭3行で読ませる型と職種別テンプレで詳しく扱っているので、そちらを併用してください。単価アップにつなげる書き方はスキルシートで単価を上げる書き方｜評価される定量表現と実績の翻訳を参考にできます。

なお、主要スタックの経験を客観的な基準で示したい場合は、IPA（情報処理推進機構）のITSS＋（プラス）のようなスキル標準を参照して、担当した業務内容とのマッピングを補足に添える方法もあります。ITSS＋はデータサイエンス・IoT・セキュリティなど分野別のスキル項目が定義されているため、案件先に技術の広さと深さを伝える語彙として使えます。

SES歴別の集約アプローチ｜3ケース

自分がどのケースに近いかで、集約の重心を変えます。

ケース1：SES歴3〜5年で10案件以上

短期案件が多く、案件数が経験年数の割に多いパターンです。3〜5年で10案件を超える場合は、平均案件期間が短めだった、または短期案件・並行案件が多かった可能性があります。この場合、直近2〜3年の主力案件は詳細に書き、残りは型4（短期・スポット案件を年ごとにまとめる）で集約します。短期案件の理由（プロジェクト都合、スキルアップ狙いなど）を職務要約で1行触れておくと、案件先の担当者が意図を汲みやすくなります。

ケース2：SES歴10年以上で30案件以上

キャリアが長く、案件を全件書き切ると20ページを超えるケースです。直近3年を詳細、それ以前の7年以上を業界軸または技術軸で3〜4塊に束ねる構成が向いています。塊の中に「主要案件（1〜2件）は個別注記」を混ぜて、深さと広さの両方を伝える書き方が実務的です。

ケース3：直近フリーランス転身でSES時代の案件が中心

SES時代を丸ごと集約し、フリーランス転身後の案件だけ詳細に書くパターンです。SES時代の案件群は業界軸か技術軸で3〜5塊にまとめ、フリーランス転身後の1〜2案件を厚く書きます。SES→フリーランスの独立手順や書類の使い分けはSESエンジニアからフリーランスに転身する手順｜準備・契約・独立タイミングを徹底解説で扱っています。

面談で聞かれた時の答え方

集約した案件について面談で「もう少し詳しく教えてください」と聞かれた時に困らないよう、集約塊ごとに口頭補足用のメモを作っておきます。書類は圧縮、口頭で解凍するという設計です。つまり、書類では全体像を簡潔に示し、面談では代表案件と変化点を補足できる状態にしておきます。

準備しておく口頭補足の3項目

集約した各塊について、以下の3項目を頭に入れておきます。

• 代表案件を1〜2件：塊の中で最も深く関与した案件を、案件先の業界・規模・担当工程まで即答できるようにする

• 共通の技術トピックを1〜2つ：塊全体で繰り返し使った設計パターン、ハマったこと、改善した点を1つ話せる状態にする

• 役割の変化：塊の中でロールが変わった場合（メンバー→リーダーなど）は変化点を説明できるようにする

面談で使うフレーズ例

集約塊について聞かれた時の返答例：

「4案件を金融系SIとしてまとめて記載していますが、その中で最も長く関与したのは◯◯銀行の勘定系保守で、約1年半担当しました。他の3案件も金融系ですが、そのうち1件は上流の基本設計から入っています」

このように「まず塊の代表例を出す→次に例外・変化点を補足する」順で話すと、書類と口頭の情報を接続しやすくなります。面談で聞かれる質問全般については既存記事群を参照してください。

よくある失敗と対策

集約設計でつまずきやすい典型パターンを挙げます。

失敗1：全案件を1件ずつ書いてしまう

「案件を減らすと経歴が薄く見える」と考えて全案件を詳細に書いた結果、20ページ超えの読み流されがちなスキルシートになるパターンです。書類のページ数は経歴の厚みではなく、読み手に届く情報量で測ります。サマリーで通算年数を宣言し、詳細に書く案件を絞る方が、実質的な情報量は評価されやすくなる傾向があります。

失敗2：集約しすぎて技術・成果が不明になる

「20XX年〜20XX年：金融系SI 5案件」だけを書いて、技術も成果も塊の中に含めない書き方です。読み手は「金融系のJavaかもしれないし.NETかもしれない」と判断できず、判断保留になります。塊にする時は必ず「共通の技術スタック」「共通の役割」「共通の業界」のうち1つ以上を明示するのが最低ラインです。

失敗3：期間の抜け・重複を作る

集約する時に案件の期間を丸めすぎて、キャリア上の期間に穴が開いたり、複数の塊で期間が重なったりする失敗です。集約後は必ず期間だけ縦に並べて連続性を確認してください。並行案件（同時期に2つの契約）がある場合は、「並行」の注記を添えて重複を許容します。

失敗4：直近案件も同じ粒度で集約してしまう

「集約すべき」を全案件に適用し、直近の主力案件まで塊の中に埋めてしまうパターンです。直近3年（またはアピールしたい役割・技術を含む案件）は必ず個別詳細で残します。読み手が「今この人に何を頼めるか」を判断する材料は、直近の詳細案件にしかありません。

実践チェックリスト

スキルシート提出前に以下を確認してください。

• サマリー欄で通算年数・業界内訳・主要スタック・直近の役割を宣言している

• 詳細に書く案件が直近3〜5年に絞られている（4基準のいずれかに該当）

• 集約塊ごとに「期間・軸（業界/技術/役割）・案件数・共通スタック」の4項目が揃っている

• 集約塊の中に上流経験・定量成果がある場合は個別注記を1〜2行残している

• 期間の抜け・重複がない（連続性を目視確認）

• スキルシート全体のページ数が実務上の目安としてA4換算で6〜10ページ程度に収まっている（案件数や職種で前後。超える場合は直近案件の優先度を見直す）

• 案件先の名称は契約上開示できる範囲に絞っている（匿名化ルールを守っている）

• 集約塊ごとに口頭補足用のメモ（代表案件・共通技術・役割変化）を準備している

チェックが終わったら、実際の案件募集要件と自分のスキルシートを見比べる工程に進みます。フリコンのフリコンの案件検索から近い募集要件を数件確認し、自分の集約塊が要件と接続できているかを見ておくと、応募時の齟齬が減ります。

まとめ

SESスキルシートで案件数が多い時は、全案件を1件ずつ書くのではなく、集約と詳細を分けて設計するのが基本です。サマリーで通算年数と業界内訳を宣言し、直近3〜5年を詳細に書き、それ以前を業界・技術・役割の3軸で束ねます。集約塊にも技術・成果・期間の変化点を残しておけば、書類の情報量は落ちません。

次のステップとして、以下を進めてください。

• 手持ちの案件を「詳細に書く案件」と「集約対象」に分ける（4基準で判断）

• 集約対象を業界・技術・役割のどれかの軸で束ねる（4パターンから選ぶ）

• サマリー欄で通算年数・業界内訳・主要スタック・直近の役割を宣言する

• 集約塊ごとに口頭補足用のメモ（代表案件・共通技術・役割変化）を用意する

• フリコンの案件検索で近い募集要件を確認し、スキルシートとの接続を確認する

関連する書き方の記事も併用してください。汎用フォーマットはフリーランスエンジニアのスキルシートの書き方、サマリー欄の型はスキルシートの職務要約の書き方、案件詳細の粒度はスキルシートの案件詳細の書き方、SES→フリーランスの独立手順はSESエンジニアからフリーランスに転身する手順を参照してください。