📄
ITフリーランスエンジニア必見！案件獲得を左右するスキルシートの書き方ガイド
特に経験を重視されるのがフリーランス
フリーランスエンジニアが案件を獲得する際に一般的に最初に重要になるのがスキルシートです。企業側は正社員採用と比較してより即戦力を求める傾向にあるため、今回お願いする案件と似たような経験があるかを重視する傾向にあります。そしてその経験を記載したものがスキルシートになります。
スキルシートは特にフォーマットが決まっている訳ではなく自由に書ける都合上、読み手にとって必要な情報が伝わるものと伝わらないものが存在します。
今回はスキルシートを使ってフリーランス専門エージェントとして案件とのマッチングをしたり、ソフトウェア開発の現場の方からのフィードバックを頂いてきた経験から、より効果的なスキルシートとは何かをまとめてみます。
スキルシートを誰がどういう理由で読むのか
スキルシートはソフトウェアと同じように利用者の課題が解決できるように書くことが重要になってきます。
- 利用者 - どんな人が読むのか
- 課題 - 読んだ人が解決したい課題は何か
多くのフリーランスエンジニアのかたに当てはまる状況をもとに想定するとこういった場合が多くなります。
- 利用者 - 開発リーダーやエンジニアリングマネージャー
- 課題 - 特定の案件にマッチして活躍が見込めそうなプロフェッショナルなのかを知りたい
これを想像して読み手に必要なことが伝わるように書くのがポイントになります。
スキルシートを書くときのテクニック
最新の経歴から順番に書く
スキルシートを開いた時に最初に見えるのがファイルの一番上部です。なのでWebページと同じように上から順に見ていきます。そして一番重視するのが最新の経験となり、例えば20年前に使った言語の今では古いバージョンの経験などがあっても読み手が重視することはありませんので、ある程度省略しても良いでしょう。
経験のある技術やフェーズと期間が分かるように書く
チームとして使っていた技術のうち、自分が開発で使った技術が一部である場合もあると思います。読み手は具体的にどこの部分で経験があるか知りたいため、それが書類でわかるようにしましょう。
- アプリケーション開発の場合は”Python / Fast API”など、言語とフレームワークを書きましょう。これは結構定着しているように思います。
- パブリッククラウドの場合は、経験のあるサービス名まで書きましょう。というのも、例えばAWSだけでも200以上のサービスがあるため、例えば”EC2 / Lambda / API Gateway / EventBridge” など書かないと案件にマッチするのかどうかが分からないためです。
- 同様に特にウォータフォールでの開発の場合にどのフェーズに関わったのかも明記しましょう。例えば、”設計-開発-テスト” などです。
- ソフトウェアプロダクトの場合、インフラ、バックエンド、フロントエンドなど、を一つのチームで行うことも多いかと思います。ですので、自分がどの分野を手がけたかがわかるように記載しましょう。例えば、”JavaとSprint BootによるバックエンドのWeb APIの設計/開発/テスト”と、GitHub ActionsによるCI/CD環境構築”などです。
経験のある業務内容を書く
技術に加えて業務経験を重視する場合もあります。エンジニアであれば技術スキルの方が重視される傾向にはありますが、業務スキルが複雑だったり、より即戦力が欲しい場合に重視されるようです。
- 例えば、”ECサイト”や”物流”、”認証/認可”などです。
成果を書く
単に”パフォーマンスチューニングをした”と書くよりも”SQLとアプリケーションロジックの最適化により3秒掛かっていたレスポンスを30ミリ秒まで改善した”と書いた方が、より説得力があります。
取得した資格を書く
経歴を補強するような役目がありますし、実績がない分野の場合に、読み手にとって知識があることやキャッチアップが可能なことが証明できます。
IT系コミュニティ活動やブログ、GitHub、登壇資料、書籍などのアウトプット活動を書く
IT系コミュニティ活動やブログ、GitHub、登壇資料はどんなことに興味があり、自己学習できることが読み手に分かります。また書籍やWebメディアなどは特定分野の知識とそれをまとめる力があることを証明できます。
サマリと自信があるエリアを書く
経歴の中でも特に力を発揮できる分野を書くことで、経歴の補足や読み手に重要な箇所のヒントを与えることができます。
大文字小文字スペースを正確に書く
正確な表記からはプロフェッショナルな印象を受けます。また、ほとんどのプログラミング言語では大文字小文字や全角半角は区別されます。そして、ドキュメントを記載する場合にも表記揺れや不正確な表記は読みにくくなるだけです。極端な例ですが、 ”ＪＡＶＡ” と書いている職務経歴書と “Java” と書いている職務経歴書のうち、どちらかのエンジニアだけ採用するなら後者を選択する方が多いはずです。
よくある間違い
- 大文字小文字
- Typescript → ○ TypeScript
- Github → ○ GitHub
- IOT → ○ IoT
- java → ○ Java
- Postgresql → PostgreSQL
- スペース
- Cloud Front → ○ CloudFront
- Fast API → ○ FastAPI
- ElasticBeanstalk → ○ Elastic Beanstalk
人間と生成AIが理解しやすい形式で書く
生成AIが職務経歴書を読んでいる場合もあるかもしれません。その場合に、特に表形式で書かれた内容は2025年1月現在では、必ずしも正確に理解できない可能性があります。＊いずれ解決される可能性があります。
機密情報を適切に取り扱って書く
各社と業務委託契約を結ぶ時に機密保持契約を結んでいる場合、当然それに従って書く必要があります。そうでなかった場合にそれに違反することに加え、企業担当が読んだ時に自分のところの情報も出されるかもしれない、と思われる可能性があります。
一般的には企業名などは出さずに、”ゲーム業界”など特定できないように出します。また、内部事情や詳細な業務内容など機密情報に当たるものは書かないようにしましょう。
適切な分量を書く
長くなりすぎると重要な箇所の印象が薄まってしまうので、長くてもA4 5枚以内に収まるよう、新しい経歴を中心に書きましょう。
まとめ
スキルシートはおそらく多くの方が思ってる以上に重要で、面談までの一番の判断材料になります。ソフトウェアと同様に読み手が必要な情報が正しく伝わるように書くことで、適切な案件と巡り合える可能性が高まります。
フリーランス専門エージェント「プロパゲート」
プロパゲートは、エンジニアの皆様へ事業会社やクラスメソッドの案件をご紹介する、フリーランス専門エージェントです。