スキルシートは、同じ「開発した」でも職種によって案件先が見たい工程が違います。同じ書き方をしても、職種によって刺さる部分が変わる、ということです。
この記事では、主要な職種ごとに「日常語のままの書き方」と「案件に伝わる書き方」のサンプルを、いくつか並べて紹介します。自分の職種のところを見て、書き換えの方向をつかんでください。
基本の考え方は 経験を“案件に伝わる言葉”に翻訳するスキルシートの書き方 に、全体像は スキルシート完全ガイド にまとめています。まだ形ができていない場合は、先にそちらで全体像をつかむと、このサンプルが活きます。
職種ごとに、見られる工程が違う
本題の前に、全体像を押さえておきます。案件先が特に見る工程は、職種によって次のように変わります。
| 職種 | 特に見られる工程・観点 |
|---|---|
| バックエンド | 設計判断、非機能要件（性能・可用性） |
| インフラ・SRE | 構築だけでなく運用・信頼性・自動化 |
| フロントエンド | UI実装に加えて性能・設計・チーム連携 |
| PM・PMO | 何人を動かし、何を決めたか |
| データ基盤・DBA | 設計・チューニング・移行の実績と規模 |
自分の職種の欄を意識しながら、以降のサンプルを見てください。書き換えの方向がつかみやすくなります。
共通して言えるのは、「何を作ったか」だけでなく「どこまで任されていたか」を書くと伝わる、ということです。案件先が知りたいのは、この人にどこから任せられるか。職種ごとに強調点は違っても、この芯は変わりません。
バックエンド
設計判断と非機能要件（性能・可用性）への関与を具体化すると伝わります。「実装した」だけだと、指示された範囲を作った人なのか、設計から考えた人なのかが区別できません。案件先は、その違いで任せられる範囲を判断しています。
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| APIを作った | 会員基盤APIの設計・実装を担当（REST／Go）。月間◯◯万リクエスト規模で、レスポンス改善とDB設計まで対応 規模と、設計・性能への関与まで書きます。 |
| バグを直した | 決済処理の不具合を原因調査のうえ改修し、再発防止のテストを追加 原因と再発防止まで書くと、運用も任せられると伝わります。 |
| DBを設計した | 機能要件からテーブル設計を担当し、正規化とインデックス方針を決定 設計判断の中身を添えます。 |
インフラ / SRE
構築だけでなく、運用・信頼性・自動化への関与が見られます。「作った」で終わらず、その後どう回したかまで書くのがポイントです。
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| サーバーを管理した | AWS上の本番環境の構築・運用を担当。IaC（Terraform）化、監視・アラート整備、障害対応とポストモーテム運用まで 構築と運用の両面を書くと評価が上がります。 |
| 監視していた | 監視・アラートを整備し、障害を早期検知できる運用体制を構築 「見ていた」ではなく「仕組みを作った」に変えます。 |
| コストを下げた | クラウド費用を分析し、不要リソースの整理と構成見直しで月額を削減 分析と手段を添えます。 |
フロントエンド
UI実装に加えて、性能・設計・チーム連携を具体化します。画面を作れることは前提として見られているので、その先の設計や他職種との連携まで書けると差がつきます。
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| 画面を作った | 管理画面のフロントを React／TypeScript で実装。コンポーネント設計、表示パフォーマンス改善、デザイナー・バックエンドとの仕様調整を担当 実装だけでなく設計と連携まで書きます。 |
| スマホ対応した | レスポンシブでモバイル用ナビを実装し、狭幅での回遊性を改善 対象と改善点を具体にします。 |
| デザインを揃えた | 共通ヘッダー／フッターに切り出して全ページのUIを統一し、保守性を向上 共通化の狙いを書くと、設計判断ができる人だと伝わります。 |
PM / PMO
「何人をどう動かし、何を決めたか」を具体化します。役割の名前だけでなく、実際に担った調整の中身を書きます。
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| プロジェクトを進めた | 開発5名のスクラム運営を担当。要件の優先度調整、スケジュール・リスク管理、ステークホルダー折衝でリリースを推進 人数・担った調整・成果をセットで書きます。 |
| 朝会をやっていた | スクラムマスターとしてスプリント運営を担当し、障害の早期可視化を推進 役割と成果を書くと、プロセスを回せる人だと伝わります。 |
| 工数を出した | 機能要件から工数を見積もり、リスクと前提を添えて開発計画に反映 前提とリスクまで書くと、計画づくりを任せられます。 |
データ基盤 / DBA
設計・チューニング・移行の実績を、規模とセットで書きます。データは規模がそのまま難易度に直結するので、件数やデータ量を添えるだけで説得力が変わります。
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| データベースをいじった | Aurora／Oracleの設計・チューニングとデータ移行を担当。クエリ最適化と移行手順の設計・検証まで対応 設計・最適化・移行のどこを担ったか書きます。 |
| データを移した | オンプレからクラウドへのデータ移行を設計・実施（約◯万件規模） 規模を書くと、移行を任せられる経験値が伝わります。 |
QA / テスト
テストの粒度と、品質にどう関与したかを書きます。「テストした」だけだと、どの工程を担ったのかが見えません。テスト設計から入ったのか、実行だけだったのかで、任せられる範囲は大きく変わります。
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| テストした | テスト設計から単体・結合テストまで担当し、リリース前の品質を担保 どの粒度のテストかを書き分けます。 |
| 負荷テストをした | 想定ピークで負荷試験を実施し、ボトルネックを特定してDB接続数を見直し 何を測り、何を直したかまで書きます。 |
職種が複数にまたがるとき
実務では、職種がきれいに分かれないことも多いです。バックエンドをやりつつインフラも触る、といったケースです。
その場合は、取りたい案件の職種を軸に据えて、そこに関連する工程を主に書くのがコツです。
| 取りたい案件 | 並べ方 |
|---|---|
| バックエンド中心 | 設計・実装を主に、インフラ（構築・運用）は補足として添える |
| インフラ中心 | 構築・運用・自動化を主に、アプリ実装は補足に回す |
全部を同じ強さで並べると、何が得意なのかが伝わりません。軸を決めて、そこに厚みを持たせるほうが、案件先は判断しやすくなります。取りたい案件が変わったら、軸を入れ替えて書き直せば十分です。
両方の経験があること自体は強みです。ただ、スキルシートは「何でもできます」より「これができます」のほうが刺さります。器用さより、任せられる範囲の明確さが評価される、と考えておくとよいです。
共通のコツ
どの職種でも、担当工程・規模・使用技術・成果をセットで書くのが基本です。やった工程を案件先の語彙に翻訳し、可能な範囲で数字を添えると、ぐっと伝わりやすくなります。
4つの要素を、意識して埋めるとこうなります。
| 要素 | 書く内容 |
|---|---|
| 担当工程 | 要件定義〜運用保守のどこを担ったか |
| 規模 | チーム人数、対象の件数・リクエスト数など |
| 使用技術 | 言語・フレームワークをバージョンまで |
| 成果 | 改善した数値や、任された範囲の広がり |
すべてを埋められなくても構いません。特に担当工程と使用技術の2つが入っていれば、案件先が判断できる情報の大半は揃います。規模や成果は、思い出せる範囲で後から足していけば十分です。盛る必要はなく、やったことの粒度を上げるだけで伝わり方は変わります。
書き換えるときの、よくあるつまずき
サンプルを見て書き換えるときに、つまずきやすい点を挙げておきます。
| つまずき | どうするか |
|---|---|
| サンプルの文言をそのまま写す | 自分がやっていない内容は書かない。粒度だけを真似る |
| 数字が思い出せない | 「約◯名」「約◯万件」で構わない。無理に正確な数字を作らない |
| すべての案件を詳しく書こうとする | 直近と関連の強い案件に絞る。古い案件は工程と技術だけでよい |
| 盛りたくなる | 面談で崩れるので逆効果。担当した工程を正確に書くほうが強い |
サンプルは、あくまで「どのくらい具体的に書けばいいか」の見本として使ってください。文言をそのまま写すのではなく、粒度だけを真似て、中身は自分の経験に置き換える、という前提です。
職種別に、もっと細かい工程の書き分けを知りたい場合は担当工程の書き方（工程別の記入例）を、自己PR欄の書き方は自己PR欄の書き方を参照してください。
テンプレートに沿って埋めたい方は Relayの無料登録でスキルシートのExcelテンプレートを配布しています。整えたスキルシートをもとに、経験に合う案件を担当者がメールでご紹介します。登録面談なし・営業電話なしです。