スキルシートの「担当工程」は、案件先が最初に見る欄のひとつです。ここが「設計・実装・テスト」とだけ書かれていると、どの範囲まで任せられるかが伝わりません。
この記事は、要件定義から運用・保守まで工程ごとに「よくある書き方」と「案件先に伝わる書き方」を並べた記入例集です（全60パターン）。
見出しは、Relayが無料配布しているスキルシートのExcelテンプレートの担当工程の欄に対応しています。手元のテンプレートを開いて、埋めたい欄と同じ見出しから読んでください。他社フォーマットでも工程の考え方は共通です。
担当工程を書き分けると、何が変わるか
案件先が見ているのは「この人にどこから任せられるか」です。工程名を並べるだけでは、その工程で何をしたのかが読み取れません。
設計・実装・テストを担当
間違いではありませんが、これだと設計が基本設計か詳細設計か、テストが単体か結合かが分かりません。担当した範囲まで書けば、同じ経験でも任せられる幅が伝わります。盛る必要はなく、やったことを案件先の言葉に置き換えるだけです。
工程から探す
要件定義
何を作るかを決める段階に関わった経験を書きます。
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| ユーザーと打ち合わせした | 顧客と要件をヒアリングし、仕様の認識合わせと優先順位の調整を実施 「何を決めたか」で調整役を担えると伝わる。 |
| 会議に出た | 要件定義MTGに参加し、技術的な実現可否の整理と代替案の提示を担当 担った役割を書くと、参加者止まりでないと伝わる。 |
| 仕様を決めた | 機能要件を整理して仕様を策定し、設計方針をチームで合意形成 決めた範囲で、上流から関われる人だ。 |
| お客さんに説明した | 顧客に技術仕様を説明し、要件のすり合わせと合意形成までを担当 合意まで持っていくと、折衝力が評価される。 |
| 要望を聞いた | 顧客の要望をヒアリングし、要求として整理して要件定義に反映 要件に落とした点で上流の力が伝わる。 |
| 工数を出した | 機能要件から工数を見積もり、リスクと前提を添えて開発計画に反映 前提とリスクまで書くと、計画づくりを任せられる。 |
基本設計
システム全体の構造や機能の骨格を決めた経験を書きます。
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| 新しい技術を試した | 新フレームワーク導入の可否をPoCで検証し、結果を技術選定に反映 確かめた点と活用先で、技術選定に関われる人だ。 |
| 設計図を書いた | 機能の基本設計・詳細設計を担当し、設計書としてドキュメント化 どのフェーズの設計かを書き分ける。 |
| セキュリティを見た | 権限設計の見直しと脆弱性対応を担当し、アクセス制御を強化 対象を具体に書くと、専門性が伝わる。 |
| マッチングの仕組みを作った | 人材と案件の自動マッチングを設計・実装し、情報のDB化から突合ロジックまで担当 どこまで担ったかで、ロジック設計を任せられる。 |
| 古いシステムを作り直した | 言語が混在し老朽化したバックエンドのリプレースを設計・実施 なぜ・何を刷新したかで、移行を任せられる。 |
| ユーザーを移した | 独自IdPのユーザーを対象システムへ移行し、認証連携を再設計 対象と再設計で、認証まわりの移行を任せられる。 |
| 技術を選んだ | 要件と運用体制から技術選定を主導し、比較検討の結果を選定理由として整理 判断軸で、選定を任せられる人だ。 |
詳細設計
実装できる粒度まで落とし込んだ経験を書きます。
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| テーブルを作った | 機能要件からテーブル設計を担当し、正規化とインデックス方針を決定 設計判断（正規化/索引）でDBを任せられる。 |
| APIを作った | REST APIの設計・実装を担当し、外部サービス連携とレート制御を実装 設計と連携の勘所で、統合を任せられる。 |
| 速くするために工夫した | Redisでキャッシュ層を設計し、参照系の負荷とレスポンスを改善 キャッシュ設計まで書くと性能改善を任せられる。 |
| デザインを揃えた | 共通ヘッダー/フッターに切り出して全ページのUIを統一し、保守性を向上 共通化の狙いで、設計判断ができる人だ。 |
実装・開発
実際にコードを書いた経験。本数が最も多く、書き方の差が出やすい欄です。担当領域から探せるよう5つに分けました。
画面・UI
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| 管理画面を作った | 管理画面の基本設計から実装までを担当（React / TypeScript） 担当工程と技術で、即戦力かが判断しやすい。 |
| スマホ対応した | レスポンシブでモバイル用ナビ(ハンバーガー)を実装し、狭幅での回遊性を改善 対象と改善点で、UXまで見られる人だ。 |
| 表示崩れを直した | モバイルでの横スクロール(はみ出し)の原因を特定し、レイアウトを修正 原因特定で、レスポンシブを任せられる。 |
| 動きを軽くした | 体感が重いスクロール挙動の原因を特定し、構成を見直して操作性を改善 入れる/外すの判断で、性能と体験を両立できる。 |
| 表示バグを直した | 画面遷移からの復帰時に要素が消える不具合を再現・原因特定し修正 再現と原因まで書くと不具合を追える。 |
| 管理画面に機能を足した | 目標・週次レビュー・指標を集約するダッシュボードを実装 何を可視化したかで、指標運用まで作れる人だ。 |
サーバー・API・データ処理
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| ログイン機能を作った | 認証基盤をOAuth2/OIDCで実装し、トークン管理とセッション設計を担当 方式と設計で、セキュリティ領域も任せられる。 |
| 決済をつないだ | 外部決済APIを連携し、冪等性・失敗時のリカバリまで含めて実装 例外系まで書くと、決済まわりを任せられる。 |
| 検索をつけた | 全文検索を設計・実装し、検索精度と応答速度の両立を担当 精度と速度の両立で、検索まわりを任せられる。 |
| 日次処理を作った | 日次バッチを設計・実装し、失敗検知とリトライで運用の手離れを実現 失敗系まで書くと、安定運用を任せられる。 |
| 定期実行を作った | 常駐プロセス内にジョブスケジューラを実装し、定期処理を安定運用 実装方式で、バッチ運用を設計できる。 |
| メールを送る機能を作った | フォーム送信をトリガに自動メール送信を実装し、初動連絡を仕組み化 トリガと効果で、業務フローまで作れる人だ。 |
| ファイルのアップロードを直した | 受付形式をバリデーションで制限し、想定外ファイルの混入を防止 検証と目的で、堅牢に作れる人だ。 |
不具合対応・品質改善
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| バグを直した | 決済処理の不具合を原因調査のうえ改修し、再発防止のテストを追加 原因と再発防止まで書くと、運用も任せられる人だ。 |
| レビューした | プルリクのコードレビューを担当し、設計・可読性の観点で改善提案を実施 見た観点と改善の成果で、品質を任せられる人だ。 |
| 古いコードを整理した | 保守性向上のためリファクタリングを実施し、技術的負債を解消 なぜ整理したかで、設計判断力が伝わる。 |
| 処理を速くした | SQLとインデックスを見直し、一覧表示の応答を約◯秒→◯秒に改善 改善の数字を入れると、成果がひと目で伝わる。 |
| 重複を防ぐ処理を入れた | 近重複・同一テーマの検出ロジックを実装し、生成物の品質を担保 判定ロジックで、品質の作り込みができる人だ。 |
ビルド・リリース・SEO
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| 環境変数まわりを直した | SSR時に環境変数が渡らない不具合を特定し、ビルド構成を修正 原因で、ビルド/デプロイを追える人だ。 |
| ビルドエラーを直した | フレームワークのメジャー更新に伴うAPI変更へ追従し、型・ビルドを修正 追従の背景で、バージョン移行を任せられる。 |
| フラグで切り替えられるようにした | ジョブ単位の有効/無効フラグを実装し、段階リリースと運用制御を可能に 運用制御の狙いで、安全にリリースできる人だ。 |
| 検索エンジンに通知する仕組みを作った | IndexNow対応でURL更新を検索エンジンへ自動通知する仕組みを実装 自動化で、運用まで作れる人だ。 |
| 著者情報を足した | 著者にPersonスキーマと経歴を実装し、E-E-A-T(信頼性)を強化 目的(E-E-A-T)でSEO設計まで見られる。 |
AI活用
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| AIにコードを書いてもらった | AIを活用して実装を進め、生成コードのレビュー・修正・テストを担当 「自分が品質を担保した点」を書くと信頼される。 |
| AIのシステムを作った | 生成AIを用いたPoC・受託開発を担当し、Amazon Bedrockで機能を実装 使った基盤と役割で、AI開発の実務者だ。 |
| AIの出力を調整した | 生成物の事実性を担保するチェックを実装し、誤情報の混入を防止 品質担保の観点で、AI活用を任せられる。 |
テスト（単体・結合・総合）
どの段階のテストかを書き分けます。「テストを担当」だけでは単体か結合か伝わりません。
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| テストした | テスト設計から単体・結合テストまで担当し、リリース前の品質を担保 粒度を書き分けると品質保証の幅が伝わる。 |
| バグを見つけた | 不具合を検出し、原因特定と再現手順の整理まで行い修正につなげた 特定・整理まで書くと、原因を追える人だ。 |
| 負荷テストをした | 想定ピークで負荷試験を実施し、ボトルネックを特定してDB接続数を見直し 測った値と直した点で、性能設計に関われる。 |
運用・保守
リリース後の運用・障害対応・改善を担った経験。継続して任せられるかの判断材料になります。
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| エラーの原因を調べた | 本番障害の原因をログから調査し、影響範囲の特定と一次対応を実施 目的と範囲を添えると、調査の深さが伝わる。 |
| 障害に対応した | 本番障害のインシデント対応を担当し、原因調査・復旧から恒久対策まで実施 恒久対策まで書くと運用も任せられる。 |
| 監視していた | 監視・アラートを整備し、障害を早期検知できる運用体制を構築 仕組みを整えたと書くと、運用設計まで任せられる。 |
| リリースした | 週次のリリース作業を担当し、デプロイ手順の整備で本番反映を安定化 頻度と手順で、安定運用の力が伝わる。 |
| 手順書を作った | 運用手順書を整備し、担当が代わっても回せる状態を構築 誰でも回せる状態にした点で属人化を防げる。 |
| 問い合わせに対応した | 問い合わせの一次対応を担当し、FAQ整備で対応件数そのものを削減 仕組み化まで書くと、改善力が伝わる。 |
| デプロイした | 本番デプロイを担当し、Blue-Greenでの無停止リリース手順を整備 “どう出したか”で安定リリースを任せられる。 |
| 障害当番をやっていた | オンコール対応を担当し、一次切り分けから復旧・報告までの運用フローを整備 対応範囲とフロー整備で、運用を任せられる人だ。 |
| ログを見ていた | ログ基盤を整備し、指標のダッシュボード化で障害の早期検知を実現 仕組み化で、可観測性の設計まで任せられる。 |
| コストを下げた | クラウド費用を分析し、不要リソースの整理と構成見直しで月額を削減 分析と手段で、コスト設計を任せられる。 |
| 障害の振り返りをした | ポストモーテムを主導し、原因分析から再発防止策の実装・仕組み化まで担当 振り返りを行動に変えた点が信頼につながる。 |
| デプロイを楽にした | ワンショットのデプロイスクリプトを整備し、手作業の本番反映を削減 自動化の効果で、リリース運用を任せられる。 |
| 設定まわりを直した | デプロイ時に既存の環境変数を保持しつつ必要なキーを追加する構成に修正 副作用を防いだ点で、慎重に運用できる人だ。 |
| エラーが分かるようにした | 処理失敗の理由をAPIレスポンスに露出し、障害の切り分けを容易化 可観測性で、運用まで見られる人だ。 |
まとめ
6つの工程・全60パターンを見てきました。工程は違っても、やることは一つ——自分の作業を、案件先が使う言葉に置き換えるだけです。経験を足したり大きく見せたりする必要はありません。
手元のスキルシートを開いて、担当工程の欄から埋めてみてください。書けたら、工程名だけで終わっている行が残っていないかを見直します。「設計」「テスト」とだけの行は、まだ何も伝えていません。その工程の見出しに戻れば、書き換え例が並んでいます。
工程に収まらない経験（チーム内での立ち回りなど）は「役割」「業務内容」の欄へ。言い換えの考え方そのものは 経験を“案件に伝わる言葉”に翻訳するスキルシートの書き方 で解説しています。