スキルシートの技術スタック表記｜バージョン・年数・習熟レベルの書き方

技術スタック欄が書類選考で見られる理由

書類選考で初期に照合されるのは、案件のスキル要件と技術スタック欄の突き合わせです。多くの担当者は要件の主要スキルを上から順にチェックし、「実務経験の有無」「該当バージョン」「習熟の粒度」を判定します。ここが曖昧だと、実際は経験があってもマッチしないと判断されることがあります。

技術スタックの粒度はスキルシート全体の第一印象を左右します。案件詳細の書き方はスキルシートの案件詳細の書き方｜担当フェーズ・規模・体制の粒度で扱っており、本記事は「技術欄そのものの粒度」に絞って解説します。

発注側が最初に見る箇所

• 案件要件との合致技術（言語・FW・DB・クラウド）

• 該当バージョンの記載有無

• 実務経験年数と現行性（直近で触れているか）

• 習熟レベルが要件を満たすか

上4つを1〜2分で判定できるように書けているかが、書類通過率の差を作ります。詳細に書けば通るわけではなく、担当者の視点で必要情報が上位に配置されていることが重要です。

「経験あり」と「即戦力」の境界線

「経験あり」と書くだけでは即戦力かどうかは伝わりません。担当者は次の3点で即戦力かを判断します。

• 業務としての稼働期間（月数）

• バージョンが現行と近いか

• 業務範囲（設計から実装まで／改修中心／運用中心）

これらを技術ごとに書き分けることで、経験ありの層と即戦力の層を区別できます。

ミニFAQ：技術スタック欄は要件表とどう照合される？

案件の要件表は「必須スキル」「歓迎スキル」に分かれています。担当者は必須スキルに該当する技術を技術スタック欄で検索し、経験年数・バージョン・習熟レベルの3点を確認します。必須スキルがヒットしない、またはバージョンが乖離していると次工程に進みにくくなります。

技術スタック欄の標準フォーマット

技術スタック欄の基本は、技術名を列で並べた表形式です。文章で羅列するより、担当者が視線を上下に走らせるだけで判定できる粒度が有効です。

表の列構成（基本4列＋任意2列）

任意2列は、経験年数だけでは現行性が伝わりにくい場合や、同じ技術で担当範囲が違う案件を複数抱える場合に活用します。全技術で列を統一しないと、粒度がバラついて見え、担当者から比較・評価しづらくなることがあります。

表と箇条書きの使い分け

技術数が10件を超える場合、箇条書きだと視線が横に飛んで比較しにくくなります。主要技術は表で、周辺ツール（IDE・チャット・チケット管理）は箇条書きで、と使い分けると読みやすくなります。

• 表：言語・FW・DB・クラウド・IaC・監視・CI／CD

• 箇条書き：エディタ・チャット・チケット管理・ドキュメントツール

記載順（応募先の要件順に並び替える）

技術スタック欄は、応募先の案件要件で上位に来る技術から順に並べます。使用歴が古い順や自分の得意順ではなく、案件ごとに並び替えるのが基本です。同じスキルシートを使い回す場合も、直近3案件で頻出する技術を上位に配置しておくと、担当者に要件適合が伝わりやすくなります。

ミニFAQ：応募先ごとに並びを変えるのは手間ではないか？

案件要件が近い応募先はまとめて同じ並びで運用します。担当者は上位3〜5技術しか集中して見ないため、その5行の並びだけ最適化すれば全体を書き直す必要はありません。

バージョン表記の書き方

バージョン表記の粒度は、案件マッチの精度に直結します。「メジャー.マイナー」までを基本にし、案件で問われる区切りがある技術は必ず記載します。

メジャー.マイナーまでを基本にする

パッチバージョン（例：3.11.7 の末尾7）は原則不要です。理由は、パッチはバグ修正やセキュリティ更新の単位であり、案件要件で問われることが少ないためです。ただし、フレームワークの一部（例：Laravel）ではマイナーで機能追加が入るため、マイナーまでは書きます。

• 記載例（Python）：3.11系

• 記載例（Node.js）：20 LTS

• 記載例（Java）：17 LTS

• 記載例（React）：18系

• 記載例（Vue）：3.4

セマンティックバージョニング（メジャー.マイナー.パッチ）の仕様についてはsemver.org（日本語版）を参照してください。

案件で問われる区切りは必ず明示

一部の技術は、メジャーバージョンでエコシステム全体が変わるため、区切りが案件要件になります。以下は代表例です。

サポート期限やLTSの詳細は各公式の情報を参照します。Node.jsはNode.js Previous Releases、Pythonのバージョン状況はPython Developer's Guide - Status of Python Versions、JavaはOracle Java SE Support Roadmapで確認できます。案件要件と乖離しない年次を選ぶには公式のロードマップを直接見に行くのが安全です。

幅で表記する場合

複数バージョンにまたがって業務してきた場合は、幅で表記します。ただし、幅が広すぎると「どのバージョンが得意か」が伝わりにくくなるため、幅とあわせて主に触ったバージョンを併記します。

• 記載例：Python 3.8〜3.12（主に3.10）

• 記載例：Java 8〜17（現行案件は17）

• 記載例：Node.js 14〜20（LTSは18・20）

古いバージョンは残すべきか

古いバージョン（Java 6、Python 2、Node.js 12、CentOS 6など）は、保守案件でまだ需要があります。実務が続いている場合は残し、既に終わった場合は「〜202X年」と時期を付記します。時期がないと「今も現行と勘違いされるリスク」と「古いバージョンしか触れない印象」の両方を招きます。

• 現行維持：Python 2.7（保守中／継続中）

• 実務終了：Java 6（〜2022年）

ミニFAQ：マイナーバージョンまで書くべきか？

フレームワーク（Vue・React・Laravel・Rails）はマイナーまで書きます。マイナーで機能追加やDeprecatedが入るためです。言語本体（Python・Java・Node.js）はメジャーとLTS区分のみで足りるケースが多くなります。

経験年数の書き方

経験年数は、業務としての単独稼働期間を月数で積算し、年月表記に変換します。誤った積算をすると書類通過率だけでなく、面談で経歴と辻褄が合わなくなる原因になります。

「業務としての単独実務期間」を月数で積算する

経験年数は、その技術を主要に使った業務期間の合計です。単に「触った期間」ではなく、次の条件を満たす期間を積算します。以下は業界統一基準ではなく、過大申告を避けるための実務上の目安です。

• 業務時間の3割以上をその技術で費やしていた（目安）

• 単独で設計・実装・改修などのタスクを完了させた

• 継続的な稼働（数週間の単発ではない）

条件を満たさない期間は経験年数に含めず、備考欄で「短期参画」「学習中」として書き分けます。

重複期間は加算しない

複数案件に並行して稼働していた期間があっても、実時間としては1つの期間です。「案件Aで2年、案件Bで2年並行→合計4年」の書き方はNGです。並行稼働は「2020/04〜2022/03の期間、案件A・Bを並行」と書き、経験年数は2年で計上します。

実務外は別カラムか括弧で区別する

自己学習・OSS貢献・副業・個人開発の期間は、業務経験と混ぜないのが基本です。混ぜたい場合は、備考列や括弧で明示します。

• OK：Python 業務経験3年（別途OSS貢献1年）

• OK：Rust 実務0年／学習・個人開発2年

• NG：Rust 業務経験2年（実際は学習と個人開発だけ）

多くのエージェント担当者は、自己学習と業務経験を分けて見る傾向があります。混ぜると面談で乖離が出やすくなるため、区別を徹底します。

ブランク・空白期間を挟む場合

技術Aを2年使い、1年他技術に移り、再びAに戻って1年使った場合は「Python 2年＋1年（ブランク1年）」または「実務期間：2020/04〜2022/03、2023/04〜2024/03」と書きます。ブランクの理由や他技術の期間は、スキルシートの空白期間の書き方｜フリーランスエンジニアの表現例と粒度にまとまっています。

ミニFAQ：複数案件で並行に使った期間はどう数えるか？

並行稼働は実時間で1期間として計上します。案件ごとに主要業務時間の比率が異なる場合、「案件Aで6割、案件Bで4割」など備考で書き分けると誤解を防げます。

習熟レベルの書き方

習熟レベルは、担当者が案件アサイン可否を判断する重要な列です。段階は3〜4段階に絞り、全技術で統一します。

5段階レベル定義の例

以下は汎用的に使いやすい定義例で、業界標準規格ではありません。送付先エージェントの指定フォーマットがある場合はそちらを優先します。3〜4段階に絞る場合はレベル2以上を統合します。

3段階に絞るなら「基本／実務／自走」、4段階なら「基本／実務／自走／指導」の並びが実務的です。段階数を絞ると自己申告のブレが減り、担当者にも判定しやすくなります。

職種別の目安

同じレベル4でも、職種によって求められる粒度は異なります。応募先職種に応じてレベル定義を調整します。

• Webフロント：レベル4＝FW選定・状態管理設計・パフォーマンス改善まで担当

• インフラ・SRE：レベル4＝IaC設計・障害対応・SLO設定まで単独対応

• PM／PMO：レベル4＝要件定義・スコープ管理・体制設計まで単独遂行

• QA：レベル4＝テスト戦略設計・自動化基盤構築まで担当

• データ・AI：レベル4＝データ基盤設計・モデル選定・精度改善まで担当

職種別の具体的な書き方は次の記事にまとまっています。

• インフラエンジニアのスキルシートの書き方｜構築・運用実績の数値化と職種別テンプレ

• PMOスキルシートの書き方｜PMとの違いと体制規模・予算・工数の定量化

• データ・AIエンジニアのスキルシートの書き方｜モデル精度と基盤規模の定量表現

• QAエンジニアのスキルシートの書き方｜品質実績の数値化と職種別テンプレ

自己申告レベルとエージェント指定フォーマット

エージェントによっては「S／A／B／C」や「◎○△×」など独自の段階を指定してきます。応募先ごとに書き分けるのは手間ですが、フリコンや複数エージェントに提出する場合は、自分側で3〜5段階を用意し、それを送付先の指定に書き換える運用が現実的です。段階の対応表を1枚作っておくと変換が楽になります。

ミニFAQ：レベル4か5か迷う場合の判断基準

「他メンバーへ指導した経験」が業務内で継続的にあれば5、なければ4に留めます。1〜2回だけレビューを担当した経験だけで5にすると、面談で深掘りされたときに乖離が出やすくなります。

職種別の書き方の違い

技術スタック欄の書き方は、職種で見られる列が違います。以下は主要職種の書き方の粒度です。

Web／アプリ系（言語＋FW＋主要ライブラリ）

• 言語：TypeScript／JavaScript／Python／PHP

• FW：React／Vue／Next.js／Laravel／Django／Rails

• 主要ライブラリ：Redux／Zustand／TanStack Query／Prisma／SWR

• テスト：Jest／Vitest／Playwright／Cypress

• 状態管理・スタイリング等の設計選択が単価に効くため、FWとライブラリを対で書く

インフラ・SRE系

• クラウド：AWS／GCP／Azure（主要サービス列挙）

• IaC：Terraform／Pulumi／CloudFormation

• 監視：Datadog／New Relic／CloudWatch／Prometheus＋Grafana

• CI／CD：GitHub Actions／GitLab CI／CircleCI／ArgoCD

• 構築規模（月間PV・トラフィック・インスタンス数）を経験年数の横に書くと即戦力度が伝わりやすい

PM／PMO

• 体制規模（PM人数・開発人数・関与ベンダー数）

• 予算規模（数千万〜数億などの帯）

• 工程（要件定義／基本設計／詳細設計／テスト／運用移行）

• 使用ツール（Jira／Backlog／Redmine／Confluence）

• 技術スタックそのものより「体制と工程の担当範囲」を書く

QA／テスト

• テスト対象（Webアプリ／モバイル／API／組込／ゲーム）

• テストレベル（単体／結合／システム／受入）

• テストタイプ（機能／性能／セキュリティ／ユーザビリティ／回帰）

• 自動化：Selenium／Playwright／Appium／Cypress

• 品質実績（バグ検出率／リリース後不具合数の削減）を数値で書く

データ・AI

• データ基盤：BigQuery／Snowflake／Redshift／Databricks

• ETL：dbt／Airflow／Dataform

• モデル：LLM／機械学習（scikit-learn、XGBoost）／深層学習（PyTorch、TensorFlow）

• 精度指標：Precision／Recall／F1／AUC

• データ規模（TB／PB）・モデル種別・精度指標を経験年数の横に書く

通らないNG表記と直し方（このページにしかない整理）

以下は書類選考で通りにくくなる典型的なNGパターンと、その直し方の一覧です。

技術スタック表テンプレ（コピペ用）

コピペしてすぐ使える基本テンプレです。列を統一し、応募先の要件に沿って上位技術を並び替えて使います。

基本テンプレ（Web系）

インフラ系テンプレ

PM系テンプレ

PM系はスキルシートというより経歴の粒度になりやすいため、PMOスキルシートの書き方｜PMとの違いと体制規模・予算・工数の定量化も併せて参照してください。

スキルシート全体の中での技術スタック欄の位置づけ

技術スタック欄はスキルシートの中でも書類通過率に直結する重要な部分ですが、単独で完結する部分ではありません。スキルシート全体の流れは以下の記事にまとまっています。

• 総論：フリーランスエンジニアのスキルシートの書き方

• 職務要約：スキルシートの職務要約の書き方｜冒頭3行で読ませる型と職種別テンプレ

• 単価アップに直結する定量表現：スキルシートで単価を上げる書き方｜評価される定量表現と実績の翻訳

• 案件詳細：スキルシートの案件詳細の書き方｜担当フェーズ・規模・体制の粒度

• SES経験が長い場合：SESスキルシートの書き方｜案件数が多い時の集約術と粒度

• 通らない場合の見直し：フリーランスのスキルシートが通らない7つの原因｜書類選考の改善策

• AIで下書きを作る場合：スキルシートをAIで作る手順｜下書き活用と情報漏えい対策

技術スタック欄で単価に効くのは、案件要件のバージョンと即戦力度の粒度です。自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方はフリーランスエンジニアの単価相場と単価の上げ方で整理しています。

案件との突き合わせは要件バージョンの確認から

技術スタック欄を整えたら、次に応募先の案件でバージョン要件を確認します。案件側の頻出セットはフリーランス案件の技術スタック組み合わせ｜求人から読む必須セット2026で整理しており、要件バージョンに自分のスタックが噛み合うか事前にチェックしておくと空振りが減ります。案件を探すときはフリコンの案件一覧から要件を絞り込んで確認できます。

まとめ

技術スタック欄は「バージョン・経験年数・習熟レベル」の3点を粒度統一で書くことで、書類選考での判断されやすさや、面談時の即戦力の伝わり方に差が出やすくなります。以下の要点を押さえて整えるのが実務的です。

• バージョンはメジャー.マイナーまで書き、Python 2/3・Vue 2/3・Java LTS・Node.js LTSなどの区切りは必ず明示する

• 経験年数は単独稼働期間を月数で積算し、並行案件の重複加算をしない

• 習熟レベルは3〜4段階に絞り、全技術で定義を統一する

• 応募先案件の要件順に上位3〜5技術を並び替える運用にする

• 職種別で見られる列（Web・インフラ・PM・QA・データ）が違うため、自分の職種のスキルシート記事を併せて参照する

技術スタック欄が整ったら、案件側の要件バージョンとの突き合わせに進みます。フリコンの案件一覧から自分のスタックに合う案件を絞り込むか、単価を体系的に把握したい場合は単価診断で市場単価の目安を確認できます。