スキルシートの案件詳細の書き方｜担当フェーズ・規模・体制の粒度
最終更新日：2026/08/19
スキルシートの案件詳細（案件欄）とは、参画した各プロジェクトごとに担当フェーズ・規模・体制・使用技術・成果を書き分ける、スキルシート内で発注側が特に重視しやすい領域です。ここの粒度が甘いと、書類選考や単価交渉で不利になりやすくなります。「担当工程しか書けない」「上流経験をどう表現していいか分からない」フリーランスエンジニアに向けて、案件欄を単価とマッチ率に効く形に仕上げる書き方を解説します。実際の評価基準は発注者や案件によって異なるため、本記事では書類で伝わりやすい記載の型として整理しています。
先に結論
スキルシートの案件詳細は、各案件について「何を・どの範囲で・どの規模で・どんな体制で・どんな成果を出したか」を1件ごとに示す欄です。
案件詳細に必ず入れる5要素はプロジェクト概要／担当フェーズ／規模／体制／成果です
担当フェーズは要件定義・基本設計・詳細設計・実装・単体テスト・結合テスト・運用保守のうちどこを担当したかを1件ごとに明示します
上流工程は「参画」ではなく成果物名と判断の主体（自分主導か支援か）で書くと、経験の解像度が伝わり評価されやすくなります
規模は人月・予算・利用者数・処理件数のいずれかで見せ、可能な範囲で桁が伝わる表現にするのが基本です
スキルシートの全体書式（自己PR・保有資格・スキル要約）は別記事で扱います。本記事は案件欄1点に絞ります
この記事でわかること
案件欄で必ず書くべき5要素と、それぞれの適切な粒度
担当フェーズを書き分ける具体表現と、複数フェーズをまたぐ場合の表記
上流工程（要件定義・基本設計・アーキ検討・PM補佐）の経験をどう言語化するか
プライム／2次請け／自社開発／PMO／SREなどケース別のテンプレート
NG表現とその直し方、コピペで使えるミニテンプレート
目次
スキルシートの案件詳細（案件欄）とは｜本記事のスコープ
案件詳細に必須の5要素｜過不足なく書く粒度
担当フェーズの書き方｜要件定義から運用保守まで表記のコツ
上流工程の経験を案件欄でどう表現するか
規模の書き方｜人月・予算・ユーザー規模・トランザクション量
体制の書き方｜チーム構成と自分の役割・報告ライン
ケース別テンプレート｜プライム／2次請け／自社開発／PMO／SRE
NG表現→OK表現｜案件欄でよくある失敗と直し方
まとめ
よくある質問
スキルシートの案件詳細（案件欄）とは｜本記事のスコープ
スキルシートは自己PR・保有資格・スキル要約・案件履歴（案件詳細）で構成されます。このうち発注側が特に重視しやすいのが案件詳細の欄です。書類選考では短時間で見られることが多く、案件欄が薄いとスキルサマリの数字の裏付けが弱く見えやすくなります。
本記事はスキルシートの中でも「案件欄1件ごとをどう書くか」に絞って解説します。自己PRやスキル要約の書き方、フォーマットのダウンロードなどスキルシート全体の書式は既存記事にあるため、そちらに委譲します。
全体書式の解説はフリーランスエンジニアのスキルシートの書き方｜記入例・フォーマット付きを参照してください
職務要約（冒頭サマリ）の書き方はスキルシートの職務要約の書き方｜冒頭3行で読ませる型を参照してください
実績を単価に翻訳する定量表現はスキルシートで単価を上げる書き方を参照してください
なぜ案件欄の粒度が単価に効くのか
発注側の商流視点では、案件欄は「即戦力の判定材料」であると同時に「単価根拠の材料」です。人月120万円の案件と70万円の案件では、商流や技術需給の違いもありますが、求められるフェーズと責任範囲が異なることが多いのも実情です。担当フェーズが「実装のみ」と書かれた人と、「基本設計〜結合テスト」と書かれた人では、書類の段階で見られるレンジが分かれる傾向があります。
案件欄は、自分の責任範囲や成果を事実ベースで示し、単価交渉の根拠にもなる場所と捉えるのが実践的です。
ミニFAQ｜案件欄の位置づけ
Q. スキルサマリの表と案件欄の内容が重複していい？
A. 重複は問題ありません。サマリは「合計何年」の視点、案件欄は「案件単位でどう深く関わったか」の視点で、読み手が求める情報が異なります。
Q. 案件は何件まで書くべき？
A. フリーランスエンジニアのスキルシートでは、直近5年で5〜8件、それ以前は主要案件だけを圧縮する形に整理されることが多いです。10年以上前の案件は職種の一貫性を示すためだけに数行に短縮しても構いません。
案件詳細に必須の5要素｜過不足なく書く粒度
案件欄1件ごとに、以下5要素をこの順で書くと過不足がなくなります。
要素 | 書く内容 | 目安の分量 |
|---|---|---|
概要 | 業界・システムの目的・自分が呼ばれた背景 | 2〜3行 |
担当フェーズ | 要件定義〜運用保守のうち関与範囲 | 1行＋補足 |
規模 | 人月・予算・ユーザー数・トランザクション量のいずれか | 1〜2行 |
体制 | チーム人数・自分の役割・報告ライン | 2〜3行 |
成果・使用技術 | 定量的な成果と使用スタック | 3〜5行 |
プロジェクト概要は、業界（金融／小売／SaaSなど）と、システムの目的（新規／リプレース／機能追加）を1文で書きます。自分がなぜ呼ばれたか（例：Kubernetes移行のため／マイクロサービス分割のため）を加えると、担当範囲の妥当性が伝わりやすくなります。
担当フェーズは次章で詳しく扱います。ここでは「実装のみ」より「基本設計〜結合テスト」の方が単価評価につながりやすい傾向がある、というレンジの目安だけ押さえておきます（実装専任でも高単価な案件はあります）。
規模は数字を1つ入れます。人月・予算・利用者数・処理件数のいずれか、NDAで書けない場合は「約○人月」「エンドユーザー数万規模」など幅を持たせた表現を選びます。
体制は自分がリーダーなのかメンバーなのか、報告ラインは誰かを1行加えます。5名のチームでリーダーだった人と、50名のチームで1メンバーだった人では、同じ2年でも身についた経験が違います。
成果は「導入して終わり」ではなく、導入後に何が変わったかまで書くのが基本です。次章以降で具体例を示します。
ミニFAQ｜必須要素
Q. 秘密保持契約（NDA）で会社名や具体規模を書けない場合は？
A. 業界と規模感を抽象化して書きます。「大手都市銀行の勘定系」は「メガバンク級の勘定系」、「1000万ユーザー」は「1000万ユーザー規模のtoC」などです。会社名を伏せても、規模感が伝われば単価根拠として機能します。
担当フェーズの書き方｜要件定義から運用保守まで表記のコツ
担当フェーズは、以下の粒度で分解して自分が関わった範囲を明示するのが基本です。
フェーズ | 主な成果物 | 単価レンジへの影響 |
|---|---|---|
要件定義 | 要件定義書・業務フロー | 上流経験として単価根拠になりやすい |
基本設計 | 画面設計・DB設計・API設計 | 単価レンジを1段上げる代表フェーズ |
詳細設計 | クラス設計・シーケンス図 | 実装スキルと合わせて評価される |
実装 | ソースコード | 単価は言語・FWの需給で変動 |
単体テスト | 単体テスト仕様・実施 | 実装セットで評価される |
結合テスト | 結合テスト仕様・実施 | 品質担保経験として加点 |
運用保守 | 障害対応・改修 | 継続稼働経験として加点 |
書き方の実例は次のとおりです。
❌ 「開発全般を担当」
✅ 「基本設計〜結合テストを担当（要件定義はプロパー社員、単体テストは若手メンバーが実施）」
「開発全般」は情報量ゼロです。担当外を1文で添えると、逆に担当内の解像度が上がります。
複数フェーズをまたいだ場合の書き方
複数フェーズをまたぐ長期案件では、フェーズごとに関与度を書き分けます。
✅ 「要件定義：業務要件のヒアリングと非機能要件の一部（性能）を担当」
✅ 「基本設計〜実装：主担当としてリード」
✅ 「結合テスト：外部ベンダー窓口として品質確認」
主担当か、支援か、レビュアー側か、で発注側の評価が変わります。関与度の書き分けが単価に直結するという感覚で書くと精度が上がります。
ミニFAQ｜フェーズ表記
Q. アジャイル案件で「要件定義〜運用保守」を全てやった場合は？
A. 「スプリント内で要件定義〜運用保守まで一気通貫」と書いた上で、担当したロール（開発／リード／PO補佐）を明示します。アジャイルでも発注側が知りたいのは責任範囲なので、ロールで補います。
上流工程の経験を案件欄でどう表現するか
上流工程の経験は、「参画した」ではなく「何を決めたか・どんな成果物を出したか」で書くのが原則です。
要件定義の書き方
❌ 「要件定義工程に参画」
✅ 「業務部門3部署へのヒアリング（計8回）を担当し、業務要件書のうち販売管理領域（30ページ）を執筆。非機能要件のうち性能要件（同時アクセス2000／レスポンス3秒）の設定を提案し、合意を得た」
参画・従事・関与だけで終わる書き方は、上流経験が伝わりません。成果物名・分量・意思決定した論点の3つのうち1つは必ず書きます。
基本設計・アーキテクチャ検討の書き方
❌ 「アーキテクチャ検討を担当」
✅ 「マイクロサービス化にあたり、認証／注文／在庫の3ドメイン分割を提案。データ整合性の担保方法（Saga／Outbox）の比較検討を実施し、Outboxパターンを採用。CTO・アーキテクトへの説明資料を作成」
比較検討した選択肢と、採用した理由を1行添えると、判断の主体が自分だったことが伝わります。IPAのシステムアーキテクト試験やプロジェクトマネージャ試験の出題範囲で使われる用語（非機能要件・可用性・トレーサビリティなど）を借りると、粒度が揃いやすくなります。
PM補佐・リードエンジニアの書き方
上流に近いポジションだった場合、PM本人でなくても書き方があります。
✅ 「PM補佐として、進捗管理（EVM）・課題管理・週次報告資料作成を担当。ステークホルダー会議（月2回）に同席し議事録・アクションアイテムを管理」
✅ 「テックリードとして、8名のメンバーへのタスク分解・レビュー・技術判断を主導。週3件のPRレビューを継続」
「補佐」「同席」「主導」の3語は、責任範囲を等身大で伝えるのに便利です。過剰に大きく書かず、発注側が面談時に裏取りできる範囲で書くのが安全です。
上流スキル自体を伸ばしたい場合は、エンジニアの設計力・上流スキルの磨き方を並行して読むと、書き方だけでなく経験の積み方まで整理できます。
ミニFAQ｜上流工程
Q. 上流工程は「経験あり」で書いたら盛りすぎと思われない？
A. 「経験あり」だけだと確かに疑われます。上のとおり成果物・分量・意思決定の3要素のうち1つを書けば、盛らずに事実ベースで表現できます。面談で必ず聞かれる領域なので、書類と面談で辻褄が合うレベルに留めるのが安全です。
規模の書き方｜人月・予算・ユーザー規模・トランザクション量
規模は可能な範囲で数字を1つ入れるのが基本です。書ける数字は次の4つのいずれかです。
指標 | 例 | 使いどころ |
|---|---|---|
人月 | 総規模120人月／自チーム40人月 | SI案件・受託開発案件 |
予算 | 5億円規模／年間3億円 | プライム／PMO案件 |
利用者数 | エンドユーザー数万規模 | toC・SaaS・自社サービス |
処理件数 | 日次数百万件のトランザクション | 決済／広告／IoTなど大量データ系 |
すべてを1件に書く必要はありません。その案件で最も規模感が伝わる指標を1つ選ぶのが実践的です。
NDAで具体値が書けない場合
会社名や具体数値をぼかす方法として、以下の表現があります。
「メガバンク級」「地方銀行上位クラス」「中堅小売」など業界内ポジション
「大規模」ではなく「数千万人規模」「日次数百万件」など桁で表現
「年商○億〜○億円クラス」など幅を持たせた表現
単なる「大規模」「多数」だと規模感が伝わりません。桁が1つ違えば単価も違うため、書ける範囲で少なくとも規模感の桁が伝わる表現にします。NDAで数字が出せない場合は、業界内ポジション表現に置き換えます。
ミニFAQ｜規模
Q. 小規模案件（5人月・500万円）は書かない方がいい？
A. 職種の一貫性を示すためには残します。ただし、案件詳細は圧縮して2〜3行にまとめ、直近の大規模案件との書き分けを明確にします。
体制の書き方｜チーム構成と自分の役割・報告ライン
体制は「チーム全体の人数」「そのうち自分の役割」「報告ライン」の3点を1件ごとに書きます。
✅ 「開発チーム12名（PM1・テックリード1・開発9・QA1）／自分はバックエンド開発の主担当としてテックリードに週次報告。プロパー3名・パートナー9名の混成」
❌ 「大規模プロジェクトのチームに参画」
プロパーとパートナーの構成比を書くと、意思決定の近さや調整負荷が伝わり、役割の重さを補足しやすくなります。フリーランスとして商流のどこに入るかは単価に効きやすいため、案件欄でも一言添えると効果的です。
発注元・商流を書くべきか
商流（プライム／2次請け／エンドユーザー直）は、書ける範囲で明示するのが有利です。
✅ 「エンドユーザー直（金融事業会社）」
✅ 「元請SIer経由（プライム）」
✅ 「2次請け（プライム→自社→パートナー）」
同じ職種でも、商流が上流なほど単価が高くなる傾向があるため、書類の段階で商流が示されていると単価根拠として機能しやすくなります。
ミニFAQ｜体制
Q. リーダー経験があるが、公式に「リーダー」の肩書きは付いていなかった。書いていい？
A. 「実質リーダーとして」「テックリード相当として」など、事実ベースの表現なら問題ありません。「新人2名の技術指導」「PRレビューを主導」など、具体的な行為を1行足すと納得感が上がります。
ケース別テンプレート｜プライム／2次請け／自社開発／PMO／SRE
代表的なケース別に、案件欄の型を用意しました。コピペしてから自分の数字に置き換える使い方を想定しています。以下は記載粒度の参考例で、数値は自分が説明できる事実ベースに置き換えてください。
プライム／SI案件
【概要】大手小売のPOS基盤リプレース。既存パッケージから内製へ移行し、店舗×EC統合を実現
【担当フェーズ】基本設計〜結合テスト（要件定義は元請PM、単体テストはパートナー社員）
【規模】総規模200人月／予算3億円／全国800店舗
【体制】開発20名（プロパー5・パートナー15）／自分はバックエンド主担当・週次でPMへ報告
【成果】決済APIの応答時間を平均800ms→200msに短縮（負荷試験ベース）／レジ待ち時間の削減に寄与
【使用技術】Java 17／Spring Boot 3／PostgreSQL 15／AWS ECS
自社サービス／SaaS
【概要】BtoB SaaSの新機能（請求書発行）開発。既存プランからのアップセルを狙った追加機能
【担当フェーズ】要件定義（PdM補佐）〜運用保守まで一気通貫
【規模】既存顧客3万社／MRR約1億円のプロダクトへの追加機能
【体制】スクラムチーム7名（PdM1・エンジニア5・デザイナー1）／自分はテックリードとしてバックエンド設計・実装を主導
【成果】リリース3ヶ月で有料化率12%を達成／既存顧客からのアップセル月額約200万円に貢献
【使用技術】TypeScript／Next.js／NestJS／Prisma／PostgreSQL／AWS
PMO／プロジェクト管理支援
【概要】保険会社の基幹システム刷新PJのPMO支援。ベンダー4社・約80名の統合管理
【担当フェーズ】プロジェクトマネジメント全般（進捗・課題・リスク・変更管理）
【規模】総規模500人月／予算8億円／期間18ヶ月
【体制】PMO4名／自分はサブリードとして週次報告資料と課題管理を担当
【成果】未解決課題の持ち越し件数（赤伝票）が月40件→月10件に減少／ステアリングコミッティ資料の質向上でクライアント継続受注につながる
【使用技術・ツール】JIRA／Confluence／Excel（EVM管理）
SRE／インフラ
【概要】マイクロサービス化に伴うKubernetesベース基盤の構築と運用
【担当フェーズ】基盤設計・構築〜運用（アプリ側の実装はプロダクトチームが担当）
【規模】マイクロサービス30本／日次リクエスト数億／SLO 99.9%
【体制】SREチーム5名／自分は基盤設計とオンコール当番のシフト設計を担当
【成果】p99レイテンシを1200ms→400msに改善／週次デプロイ回数を10→50回に増加
【使用技術】Kubernetes（EKS）／Terraform／ArgoCD／Prometheus／Grafana
ミニFAQ｜ケース別
Q. 副業として関わった案件はスキルシートに書ける？
A. 書けます。「副業として週◯時間稼働」など稼働形態を1行添えると誤解が生じません。フリーランスの案件詳細と混ざっても、稼働時間の粒度で見分けがつくようにします。
NG表現→OK表現｜案件欄でよくある失敗と直し方
案件欄で頻出のNG表現を、OK表現に書き換える対応表です。
NG | OK | ポイント |
|---|---|---|
開発全般を担当 | 基本設計〜結合テストを担当（要件定義はプロパー社員） | 担当範囲を明示 |
大規模プロジェクト | 総規模200人月・エンドユーザー100万人 | 桁を数字で示す |
チームリーダー | 開発チーム8名のテックリード（週次進捗をPMへ報告） | 人数と報告ラインを添える |
パフォーマンス改善 | 平均応答800ms→200msへ改善（負荷試験ベース） | 定量値＋測定条件 |
上流工程に参画 | 要件定義書のうち販売管理領域（30ページ）を執筆 | 成果物名と分量 |
モダンな技術スタック | React 18／Next.js 14／TypeScript／GraphQL | 具体名で列挙 |
品質向上に貢献 | 障害発生件数を月10件→月2件に削減 | 数字で成果を出す |
「〜に参画」「〜に貢献」「〜を担当」だけで終わる表現は、案件欄では情報量が不足しやすいという読み手側の感覚があります。1行内に数字か固有の成果物名を入れるだけで、印象が変わります。
ミニFAQ｜NG表現
Q. 定量成果が計測されていない案件（社内ツール等）はどう書く？
A. ユーザー数・稼働時間削減・レビュー承認数など、間接指標で構いません。「経理部10名の月次締め作業を6時間→3時間に短縮」など、業務側の数字を借りるのが実践的です。
案件詳細のミニテンプレート｜コピペOK
上のケース別サンプルの汎用型として、案件詳細1件分の空白テンプレートを置いておきます。ワード・スプレッドシートのスキルシートに貼り付けて使えます。
【期間】YYYY/MM 〜 YYYY/MM（○年○ヶ月）
【業界／システム】〔業界〕〔システム名 or 目的〕
【担当フェーズ】〔要件定義／基本設計／詳細設計／実装／単体テスト／結合テスト／運用保守〕から選択
【役割】〔テックリード／メンバー／PMO／SRE 等〕
【規模】人月／予算／ユーザー数／トランザクション量のいずれか1つ以上
【体制】〔チーム人数と構成〕／自分は〔役割〕として〔誰〕に〔頻度〕で報告
【業務内容】〔担当した具体的な業務を3〜5行〕
【成果】〔定量成果を1〜2件〕
【使用技術】〔言語／FW／DB／インフラ／ツールを列挙〕
このテンプレートで書くと、5要素の抜けを防げます。書き終えたら「担当フェーズ・規模・体制の3項目で数字が入っているか」だけを最終チェックするのがおすすめです。
案件欄が整ったら、そのまま応募に進めます。フリコンの案件一覧では各案件の単価・稼働形態・リモート可否を確認できるため、案件欄で整理した強み（例：基本設計以降・週4稼働・完全リモート）に近い募集を探しやすくなります。
まとめ
スキルシートの案件欄は、担当フェーズ・規模・体制の3要素に数字を1つずつ入れるだけで、単価根拠として機能する書類に変わります。
案件欄の必須5要素は概要／担当フェーズ／規模／体制／成果
担当フェーズは要件定義〜運用保守のどこかを明示、担当外は1行添える
上流工程は「参画」ではなく成果物名・分量・意思決定した論点で書く
規模は人月／予算／利用者／処理件数のいずれか、桁で見せる
体制はチーム人数＋自分の役割＋報告ラインの3点セット
NG表現「開発全般」「大規模」「参画」は情報ゼロ、必ず数字か固有名詞で書き換える
案件詳細のミニテンプレートで抜けを防ぎ、書き終えたら数字だけ最終チェック
スキルシート全体の書式はフリーランスエンジニアのスキルシートの書き方に整理されています。提出前は、各案件に「担当フェーズ・規模・体制・成果」が具体語で入っているかを確認してください。案件欄が整ったら、フリコンの案件一覧で単価・稼働条件を確認し、書類の強みに合う案件から応募していくのが実務的な流れです。
よくある質問
スキルシートは何枚くらいが理想？
A. フリーランスエンジニアのスキルシートでは、A4で4〜6枚程度に収めると読みやすいことが多いです。経験年数や案件数によって前後します。案件詳細の充実で厚みを出すのが優先で、自己PRを長くして枚数を稼ぐと本題の解像度が下がりやすくなります。
「関わった程度」の案件も書くべき？
A. 週1〜2日のスポットでも、担当した業務が明確なら書いて構いません。「短期スポットで◯◯を担当」と稼働形態を明示し、常駐案件と混同しないよう分けて記載します。
使用技術は言語だけでいい？
A. 言語・FW・DB・インフラ・ツールの5層で書くのが基本です。「Python」だけだと担当範囲や案件とのマッチ度の判断材料になりにくく、「Python／FastAPI／PostgreSQL／AWS ECS／GitHub Actions」まで書くと運用まで見える人と評価されやすくなります。
過去の会社員時代の案件と、フリーランス後の案件はどう分ける？
A. 職務経歴書とスキルシートの役割分担で整理します。詳しくは職務経歴書とスキルシートの違いを参照してください。案件詳細ではフリーランス後を厚めに、会社員時代は主要案件のみを圧縮するのが実務的です。
資格や勉強中の技術は案件詳細に書ける？
A. 案件欄には基本書きません。案件履歴は実務経験の場です。資格は保有資格欄、勉強中技術は自己PR欄で扱います。案件欄に混ぜると「実務なのか学習なのか」の判別を難しくします。
業務内容を書きすぎると面談で細かく突っ込まれる。どこまで書く？
A. 書類は面談で答えられる範囲までが鉄則です。プロジェクトの背景・自分が判断した論点・使用技術は、面談で1〜2分で語れるレベルにしておきます。書けても語れない項目は書類から外した方が安全です。
AI・機械学習系の案件はフェーズ表記が違う？
A. 「データ準備／モデル選定／学習／評価／推論API化／運用監視」など、システム開発と別の粒度になります。この場合は担当フェーズ欄をAI開発向けの粒度に置き換え、業務内容欄で従来のシステム開発フェーズと接続する形にします。
実績が少ないフリーランス初年度でも通るスキルシートは？
A. 会社員時代の案件詳細を、フリーランス視点（担当フェーズ・成果・使用技術）で書き直すのが基本です。詳しくは実績が少ないフリーランスエンジニアでも通るスキルシートの書き方を参照してください。
スキルシートに単価は書くべき？
A. 一般的には書かないことが多く、単価は面談・エージェント経由の交渉で決まります。ただし、提出先のフォーマットに希望単価欄がある場合はその指示に従います。書く場合は公開案件レンジを参考に幅（例：85〜100万円）で書くのが実務的です。
更新頻度はどのくらい？
A. 案件が変わるタイミングと、直近案件の成果が確定したタイミング（3〜6ヶ月ごと）で更新します。長期案件では、四半期ごとに成果を追記していく運用が現実的です。
IPAスキル標準の職種名を使った方が単価に効く？
A. 業界横断で共通言語になるため、IPA ITスキル標準の職種名（例：アプリケーションスペシャリスト・システムアーキテクト）と、経済産業省のDX推進スキル標準の職種名は、案件欄の役割記述で使うと発注側に伝わりやすくなります。
