SES営業がスキルシートで確認すべき項目
SES営業がスキルシートを確認するときは、基本情報と希望条件を最新にし、技術名だけでなく使用場面、担当工程、役割、チーム規模、環境を案件経歴ごとにそろえます。
営業担当の方が見るべきなのは、見た目の整い方だけではありません。
提案先の案件条件と照合できる情報があり、その経験の根拠が案件経歴からたどれるかを確認することが重要です。
この記事では個人向けの転職書類ではなく、SES企業が提案前にスキルシートを作成・添削する実務に範囲を絞ります。
ファイル形式や保管方法など管理・共有の実務は、既存記事で整理しています。
スキルシートが提案材料として弱くなる理由
スキルシートが提案材料として弱くなるのは、情報が少ないからではなく、技術と案件経歴の関係が読み取れないためです。
技術名が並んでいても、どの案件で何に使い、どこまで担当したかが分からなければ、営業担当の方は提案理由を説明できません。
技術名だけでは経験内容を説明できない
スキル欄に言語やクラウド名だけを並べても、実務で使ったのか、学習したのか、環境に含まれていただけなのかを区別できません。
案件経歴側に使用場面がなければ、提案先から確認を受けたときに根拠を示せなくなります。
技術名は一覧だけで完結させず、該当する案件経歴へ結び付ける必要があります。
期間の空白と重複が説明なしで残る
案件期間に空白や重複があること自体を、直ちに誤りと決めつける必要はありません。
ただし説明がないまま残ると、記載漏れなのか、複数案件を並行したのか、期間を誤記したのかを営業担当の方も判断できません。
開始年月と終了年月を時系列で確認し、本人の説明と合う状態に整えます。
担当工程と役割が案件ごとに揃っていない
案件概要が詳しくても、担当工程と役割がなければ、本人がどこまで責任を持ったかは分かりません。
設計、実装、テスト、運用などの工程と、メンバー、リーダー、支援担当などの役割は別の情報です。
両方を案件ごとに記載すると、提案先が求める経験との一致点を説明しやすくなります。
営業が確認する情報の並び順
営業担当の方は、基本情報と希望条件、スキル要約、案件経歴の順に確認すると、最新性と根拠を行き来しやすくなります。
冒頭の要約だけで判断せず、案件経歴で裏付けられているかまで見ます。
基本情報と希望条件を最新にする
基本情報では、提出に必要な範囲の属性、現在の稼働状況、稼働開始、勤務地やリモートの希望を確認します。
希望単価や勤務条件などを記載する場合は、本人の現在の希望と一致しているかを提出前に確かめます。
過去の提案時に使った条件を残したままにせず、更新日と内容が対応している状態にします。
スキル要約と案件経歴を対応させる
スキル要約には、本人の経験の中心と強みを短くまとめます。
要約に書いた技術、工程、役割は、後ろの案件経歴で使用場面を確認できる必要があります。
案件経歴に存在しない内容が要約へ追加されている場合は、本人へ根拠を聞いて追記するか、要約から外します。
案件経歴を同じ粒度でそろえる
案件経歴は、期間、案件概要、担当業務、使用技術、担当工程、役割、チーム規模、環境を同じ順番で並べます。
古い案件だけ詳しく、新しい案件が一行だけという状態では、現在の経験を判断しにくくなります。
直近の案件ほど更新漏れが起きやすいため、終了予定や担当範囲の変化も含めて確認します。
案件経歴の時系列を添削する方法
案件経歴の時系列は、開始年月と終了年月を古い順または新しい順に統一し、空白と重複に説明が付くように添削します。
並び順を決めるだけでなく、期間と業務内容が本人の説明と一致しているかを確かめます。
開始年月と終了年月の表記をそろえる
期間は案件ごとに同じ形式で書き、開始だけ年月で終了だけ季節表現にするような混在を避けます。
参画中の案件は、終了年月を空欄にせず、継続中だと分かる表現を使います。
年月が分からない場合は推測で埋めず、本人が確認できる記録をもとに確定します。
空白期間の理由を本人へ確認する
案件と案件の間に空白がある場合は、書き漏れか、待機や学習などの期間かを本人へ確認します。
スキルシートへ理由を詳しく書くかどうかは提出先と自社方針によりますが、営業担当の方は説明できる状態にしておく必要があります。
空白を隠すために前後の案件期間を延ばすことは避けます。
重複期間の担当状況を分けて書く
期間が重なる場合は、複数案件を並行したのか、引き継ぎだけが重なったのかを本人へ確認します。
並行案件であれば、それぞれの担当範囲や稼働の関わり方を区別して書きます。
単純な誤記であれば期間を修正し、修正前の情報を別案件へ誤って引き継がないようにします。
稼働開始時期を提案前に確かめる考え方は、関連記事でも整理しています。
技術経験の書き方をそろえる方法
技術経験は、技術名、使用場面、担当した作業の組み合わせで書くと、案件条件と照合しやすくなります。
経験年数を根拠なく足すのではなく、案件経歴から説明できる内容へ整えます。
技術名と使用場面をセットで書く
言語、フレームワーク、データベース、クラウド、ツールは、実際に何へ使ったかを添えます。
同じ技術でも、実装で使ったのか、設定変更だけを担当したのか、既存環境を操作したのかで経験の内容は異なります。
使用場面が分からない場合は、本人へ具体的な作業を聞き、営業担当の方が想像で補わないようにします。
実務経験と学習経験を分ける
実務で使った技術と、研修や自己学習で触れた技術は、同じ実務経験として並べません。
学習経験を記載する場合は、実務経験ではないことが読み手に伝わる区分へ置きます。
この区別があると、営業担当の方は案件の必須条件と尚可条件へ当てはめる際に説明を誤りにくくなります。
表記の粒度を案件間で合わせる
ある案件では製品名まで書き、別の案件では「DB」「クラウド」だけにすると、経験を比較しにくくなります。
自社内で書く項目の粒度を決め、同じ種類の技術は同じ詳しさで記載します。
略称を使う場合も、同じシートの中で表記が揺れないように統一します。
担当工程と役割を具体化する方法
担当工程と役割は、案件全体の工程ではなく、本人の担当範囲として書きます。
チーム規模と環境も添えると、どの体制でどの責任を持った経験かを説明しやすくなります。
担当工程は本人が行った範囲に絞る
案件が要件定義から運用まで続いていても、本人が実装とテストだけを担当したなら、その範囲を記載します。
案件全体の工程を本人の経験として書くと、提案後の確認で説明が食い違います。
工程名だけで不足する場合は、作成した成果物や担当した作業を短く添えます。
役割とチーム規模を分けて書く
役割は本人の責任範囲、チーム規模は参加した体制を表す別の項目です。
チームに複数人いたことだけでリーダー経験とは言えないため、進捗管理、レビュー、顧客調整など実際に担った内容を確認します。
役職名がなくても、支援や取りまとめを担当した場合は作業内容として記載できます。
環境は使用したものだけを記載する
環境欄には、OS、データベース、クラウド、開発支援ツールなど、本人が案件で使用したものを記載します。
案件に存在していても本人が触れていない技術は、本人の経験として読まれない書き方へ分けます。
使用有無が曖昧な項目は本人へ確かめ、同じ案件の別資料から営業担当の方が転記しないようにします。
架空例で見る悪い書き方と良い書き方
悪い書き方と良い書き方の違いは、情報量ではなく、経験の根拠を案件経歴からたどれるかにあります。
以下は書き方を説明するための架空例であり、実在人物、実在案件、推奨条件、実績を示すものではありません。
悪い例は技術と担当範囲がつながらない
次の架空例では、技術名はありますが、使用場面、工程、役割、環境の関係が分かりません。
案件概要：業務システム開発
スキル：Java、AWS、SQL
担当：開発全般
役割：チームで対応
期間：春頃から
「開発全般」では本人の担当工程を特定できず、「チームで対応」では責任範囲を説明できません。
期間の表記も他の案件と時系列で比較できないため、本人への確認が必要です。
良い例は使用場面と根拠が対応する
次の架空例では、技術名を使った作業へ結び付け、担当工程と役割を分けています。
案件概要：社内向け申請APIの改修
担当業務：既存APIの機能追加とテスト
使用技術：Java（API実装）、SQL（データ確認）
担当工程：詳細設計、実装、単体テスト
役割：開発メンバー
チーム規模：複数名の開発チーム
環境：Linux、PostgreSQL、Git
期間：開始年月から終了年月まで同一形式で記載
この書き方なら、Javaをどの作業で使い、どの工程まで担当したかを案件経歴から説明できます。
実際のスキルシートでは、期間とチーム規模を本人が確認した事実へ置き換えます。
提出前に使える営業向けチェックリスト
提出前チェックでは、最新性と整合性、時系列、技術の根拠、担当範囲、誤記を順番に確認します。
次の表をそのまま確認項目として使い、確認できない内容は本人へ戻します。
| 確認区分 | チェック項目 | 完了の基準 |
|---|---|---|
| 基本情報 | 更新日が本文にある | どの時点の情報か分かる |
| 希望条件 | 稼働開始と勤務条件が最新である | 本人の現在の希望と一致する |
| スキル要約 | 要約の内容が案件経歴にある | 使用案件と作業内容を示せる |
| 案件期間 | 開始年月と終了年月の形式が揃う | 空白と重複の理由を説明できる |
| 担当業務 | 本人が行った作業が書かれている | 案件全体の説明と区別できる |
| 技術経験 | 技術名に使用場面がある | 実務経験と学習経験を区別できる |
| 担当工程 | 本人が担った工程だけがある | 成果物や作業内容と矛盾しない |
| 役割 | 責任範囲が具体的である | 役職名だけでなく実作業を説明できる |
| チーム規模 | 役割とは別に書かれている | 参加した体制を説明できる |
| 環境 | 本人が使ったものだけがある | 案件に存在しただけの技術と分けられる |
| 表記 | 同じ技術と工程の表記が揃う | 略称と正式名称が混在しない |
| 誤記 | 案件名と期間の転記ミスがない | 前回版からの更新箇所を確認済みである |
チェック欄を埋めること自体を目的にせず、提案先へ根拠を説明できるかを完了の基準にします。
営業担当の方が判断できない内容を見つけた時点が、本人へ確認を戻すタイミングです。
提出前確認と受信後の構造化を分ける
スキルシートの作成・添削は本人の経験を正しく伝える作業であり、受信後の構造化は異なる書式から同じ項目を取り出す作業です。
両方を分けて整えると、自社の提案品質を保ちながら、取引先ごとに異なるスキルシートも条件として扱えます。
営業担当の方は提出前に、技術経験、期間、担当工程、役割、環境の根拠を本人と確認します。
Dot Linkは受信したメール本文や添付から、スキル、単価、商流、稼働時期、勤務地などを構造化し、書かれていない情報は推測で補いません。
情報が揃った状態からヒアリングと提案を組み立てる考え方は、次の記事で詳しく解説しています。
メールを受信してから項目へ構造化する全体の流れは、次の記事で確認できます。
スキルシートは根拠を説明できる状態で提出する
スキルシートは、項目を埋めるだけでなく、記載内容の根拠を営業担当の方が案件経歴から説明できる状態で提出します。
基本情報と希望条件の最新性を確認し、技術、工程、役割、チーム規模、環境を案件ごとにそろえてください。
期間の空白や重複、要約と経歴の矛盾、実務経験と学習経験の混在を提出前チェックリストで確認します。
形式の異なるスキルシートを受信後に項目として整理したい場合は、Dot Linkでメールと添付の構造化を試してみてください。
スキルシートをDot Linkで構造化する
無料登録してメール連携する →よくある質問
スキルシートの提出前に迷いやすい本人確認、空白期間、技術経験の書き方を整理します。
いずれも営業担当の方が推測せず、案件経歴から根拠を説明できる状態を基準にします。
スキルシートは本人にどこまで確認すべきですか？
営業担当の方だけで確定できない内容は、提出前にすべて本人へ確認します。
特に稼働開始、希望条件、案件期間、使用技術、担当工程、役割は、古い版の転記や営業側の解釈で変わりやすいため、本人へは「この技術を使った案件はどれか」「実際に担当した工程はどこまでか」のように、記載の根拠を案件単位で聞きます。
表現の整理は営業担当の方が行えますが、経験の事実を追加したり期間を推測して補ったりすることは必ず避けてください。
案件経歴に空白期間がある場合は削除してよいですか？
空白期間を隠すために前後の案件を延ばしたり、期間欄から空白が見えないようにしたりすることは避けます。
まず本人へ案件の書き漏れ、待機、学習、休業など事実に合う理由を確認し、スキルシートへ理由をどこまで書くかは提出先と自社の方針に合わせます。
営業担当の方は質問を受けたときに空白期間の経緯を説明できる状態にし、空白が記載漏れなら案件経歴を追加し、意図した期間なら前後の年月と矛盾しないかを確認してください。
技術名を書くだけでは不十分ですか？
技術名だけでは実務経験の内容を判断できないため、案件経歴に使用場面と担当作業を添えます。
たとえば言語名だけでは、実装に使ったのか、既存コードを読んだのか、学習で触れただけなのかを区別できないため、案件ごとに「どの機能で使ったか」「どの工程で扱ったか」を本人へ確認し、スキル要約から該当経歴へたどれるようにします。
学習経験を載せる場合も実務経験と欄や表現を分け、提案先が経験の種類を誤読しない形へ整えてください。
参考情報
本記事のチェックリストは、SESスキルシートの公式様式を示すものではありません。
技術名だけを並べず、経験や実績と対応させてスキルを説明する考え方の参考として、IPAのITスキル標準を参照しています。
IPA「ITスキル標準（ITSS）」 — ITサービスに必要な能力を体系化し、人材育成や人材調達で使う共通の指標をまとめた公式情報です。
