スキルシートは「履歴書」ではなく「営業資料」だ
フリーランスSEのスキルシートを、多くの人が履歴書のように書いている。
やったこと・使ったツール・期間。それを時系列で並べるだけ。
でも実際に企業やエージェントが見るのは違う観点だ。「このSEを入れることで、うちの現場のどの問題が解決するか」。これが読み取れないスキルシートは、選考から外れやすい。
スキルシートは営業資料だ。自分の価値を、相手に伝わる形で書く必要がある。
よくある「もったいない」スキルシート
①業務内容が箇条書きで並んでいるだけ
・サーバー監視
・障害対応
・定期バックアップ
・手順書作成
何をやったかはわかる。でも「どのくらいの規模か」「どんな環境か」「どんな成果があったか」が一切見えない。
②ツール名の羅列で終わっている
使用ツール：JP1/IM、SCOM、SCCM、Paloalto
ツールを知っているのはわかる。でも「どの場面でどう使ったか」がない。JP1を使って何をしたのか、SCOMで何を監視していたのかが読めないと、相手は判断できない。
③担当範囲が「チームの一員として」で終わっている
自分が何をやったのかを、曖昧にしてしまうパターン。チームで動いていても、自分が担当したのは何かを具体的に書く必要がある。
上流案件を取りたいなら「設計経験」を前面に出す
インフラ系のフリーランスSEが上流案件に入るために必要なのは、設計経験の記述だ。
保守運用からのキャリアチェンジを目指す場合、過去に少しでも設計に関わったなら、そこを強調して書く価値がある。
書き方の例（Before）
・JP1を使ったジョブスケジューリング管理
書き方の例（After）
・JP1を用いたジョブネット設計・移行計画策定（既存バッチ200本の新環境移行）
・移行手順書作成・リハーサル実施・本番切替支援
同じ経験でも、書き方次第でまったく違うスキルシートになる。
具体的な数字を入れると信頼度が上がる
スキルシートで差がつくポイントの一つが「数字」だ。
- 規模感（サーバー何台・ユーザー何名・バッチ何本）
- 期間（何ヶ月のプロジェクト）
- 成果（障害対応時間を何割短縮・手順書を何本整備）
数字があると、相手がイメージしやすくなる。同じ「監視業務」でも「サーバー50台の監視」と「サーバー300台、24h/365d監視体制の構築・運用」では印象がまったく違う。
担当工程の書き方
スキルシートに「担当工程」の欄がある場合、正直に書くと同時に「どこまで踏み込んだか」を添えると伝わりやすい。
| 工程 | ただの記載 | 踏み込んだ記載 | |---|---|---| | 要件定義 | ○ | 顧客ヒアリング同席・要件一覧作成 | | 基本設計 | ○ | サーバー構成案3パターン提案・採用決定 | | 詳細設計 | ○ | 設計書（150ページ）の主担当 | | 移行設計 | ○ | 移行計画書・リハ計画・本番当日のリード |
主担当か補助かも書いておくと誠実さが伝わる。
スキルシートを更新するタイミング
フリーランスSEのスキルシートは「案件が終わったとき」に更新するのが鉄則だ。
時間が経つと細かい数字や成果を忘れる。案件終了直後に以下を記録しておく：
- プロジェクトの規模（サーバー台数・ユーザー数・期間）
- 自分の担当フェーズと主な作業
- 使ったツール・OS・ミドルウェア
- 印象に残った技術課題と対処
これをストックしておいて、スキルシートを書くときに組み合わせる。
自分の単価と市場ギャップを確認しておく
スキルシートを整備したら、自分の現在の単価が市場に合っているかも確認しておきたい。
スキルシートに書いてある情報（担当工程・スキル・経験年数・商流）を入力するだけで、市場単価の目安が出る。
交渉の根拠として使える。
まとめ
スキルシートで意識すること：
- 履歴書ではなく営業資料として書く（相手にどう役立つかを伝える）
- 数字を入れる（規模・期間・成果）
- 設計経験は前面に出す（上流案件を狙うなら必須）
- 担当範囲を明確に書く（チームの一員で終わらせない）
- 案件終了直後に記録する（時間が経つと忘れる）
スキルシートは一度書いたら終わりではなく、案件ごとに育てていくものだ。