クラウド、セキュリティ、インフラ領域で生きていく！

任される範囲の広がり方

フリーランス、業務委託向けのスキルシートの書き方

スキルシート（職務経歴書）をどう組み立てるか。読む側が数秒で選別する前提で、1ページ目に何をどの順で置き、案件ごとに何を書き、何を削るかを書く。

読む側は、どう読むか

読む側の事情

スキルシートを読むのは忙しい現場の責任者。

  • 複数の候補の中から、面談に呼ぶ人を短時間で選ぶ。
  • 材料はスキルシートと30分程度の面談だけ。
  • 期待はずれなら契約解除できても疲れるしコストがかかる。外したくない。

読み方は2段階。数秒で選別されて、OKならじっくり読まれる

  1. 数秒で選別する。エージェントや媒体から届く複数の候補のスキルシートをまずフィルタリングする。 スキルシート上から順に数秒で見て、面談に呼ぶ対象か、しっかり見るべき人かを選別する。 興味を持てなければそこで離脱する。
  2. 良さそうな人はしっかり見る。面談の前は質問を考えるために読む。面談の後は外したくないから最終確認として読み、違和感がないかを見る。
    • 説明が分かりやすいか。過去の案件の説明の分かりやすさや構成から、日本語のビジネス的なコミュニケーション能力を測る。
    • 短期間で離職する可能性がないか。過去の経歴から判断する。
    • 技術や役割を誇張していないか。誇張する傾向が全体的にないか。

だから、こう書く

  • 上から順に重要なことを置く。冒頭だけでこの人が何をする人かが5秒で分かる形にする。詳細はそこを通った人だけが読む。
  • 先頭は概要を短時間で把握できるように書き、案件別の詳細は正確に丁寧に記載する。

1ページ目に置くもの

考え方

  • 上から順に、相手が知りたいことを、認知負荷が低く短時間で分かる形にまとめる。
  • 相手が知りたいのは、いつからどのくらい使えるか、何をしてきた人か、何を任せられるか。
  • その中で自分の強みが伝わるようにする。強みは形容でなく、してきたことと数字で示す。
  • 案件ごとの詳細は1ページ目で一定の基準をクリアできた場合のみ読まれる。

項目ごとの考え方。分け方と並びは一例で、これに合わせる必要はない。

  1. 稼働の条件
    • いつから、どのくらい入れるか。
    • フルタイムでない場合は、相手が心配しそうなことを補足する。
      • 状況に応じて稼働時間は柔軟に対応する。
      • 日中のリアルタイムなやり取りは可能。
  2. 自己紹介
    • 数行で概要を書く。
      • これまでどんなことをしてきたか。
      • どんな役割に対応できるか。
  3. 対応できることと主な実績
  4. スキルセット
  5. 資格

具体例

上の並びで1ページ目を書くと、次のようになる。中身は架空のもの。

【稼働の条件】
- 2026年11月から週4日。
- 稼働日以外も日中はチャットに返信できます。

【自己紹介】
2016年から Web サービスのサーバーサイド開発、2020年からクラウド基盤の構築と運用を担当しています。
監視、可用性、セキュリティの改善を中心に、要件の整理から設計、構築、運用の引き継ぎまで一人で進められます。
5名前後の開発チームのリードも対応できます。

【対応できること】
- AWS のネットワークとコンテナ基盤の設計・構築
- Terraform による構成管理と CI/CD の整備
- 監視とアラートの設計、障害対応

【主な実績】
- リリース: 手作業だったリリースをパイプライン化し、リリース作業を40分から15分に短縮
- コスト: 使われていないリソースの整理とインスタンスの見直しで、AWS の月額費用を40%削減

【スキルセット】
AWS（VPC、ECS、RDS、CloudWatch）、Terraform、Docker、GitHub Actions、Datadog、Linux、Python、Go

【資格】
AWS Certified Solutions Architect - Professional
情報処理安全確保支援士

文章と列挙を分けると読む側の負荷が下がる。自己紹介は文章で概要を語り、列挙は箇条書きの欄に任せる。 欄に役割を持たせて重複させない。同じことを2つの欄で言わない。

案件ごとに書くこと

考え方

2ページ目からは職務経歴の表。案件は新しい順に全件を載せる。1案件に書くのは次の項目。

  • 期間、役割、体制。
  • 業務内容。何の案件で、何をしたか。
    • 案件のタイトルでどんな案件か伝わるようにする。
      • 何の事業の、どんな規模のシステムで、何をしたか。
    • 前提 → 何をした → 結果、の順で書く。元の状態が分からないと、何をしたかの重さが伝わらない。
    • 誇張しない。重さは形容でなく担当した工程の事実で示し、実績でない数字は書かない。役割の欄と業務内容がずれていると、誇張の疑いになる。
    • 略語と社内の言葉を使わない。読む相手は社外の人。
    • 説明の構成をどの案件でも揃える。案件ごとに書き方が違うと、構成から説明力を測られたときに弱い。

具体例

1案件分を書くと、次のようになる。中身は架空のもの。

家具のECサイト(月間100万PV)のAWS基盤の運用改善（リリース自動化、コスト削減）

期間      2024年4月 〜 2025年3月
役割      インフラ・SRE
体制      開発 12名、インフラ 2名

【業務内容】
家具を製造販売する企業の EC サイト（月間 100万 PV、開発は内製）で、AWS 基盤の運用改善を担当。
- 手作業だったリリース手順を GitHub Actions のパイプラインに置き換え、リリース作業を40分から15分に短縮
- ステージング環境を本番と同じ構成に揃え、リリース前の検証を定型化
- 使われていないリソースの棚卸しとインスタンスの見直しで、AWS の月額費用を25%削減
- 予算アラートを設定し、月次で費用の推移をチームに共有

【環境と技術】
AWS（ECS、RDS、CloudWatch）、Terraform、GitHub Actions、Datadog、Python

次に読む