職務経歴書とスキルシートの違い｜SES用12項目・無料テンプレート

職務経歴書・スキルシート・社内指定様式を、読み手で分ける

職務経歴書は、在籍会社、職務要約、案件経験、活かせる能力、自己PRなどを通じて、採用担当者と配属部門が職歴全体を判断する応募書類です。技術者ではない読み手にも、どの業務課題へどの責任で関わったかが伝わる言葉を使います。志望先で再現できる強みを先に示し、技術の羅列だけで終えません。

スキルシートは、案件ごとの期間、工程、技術環境、役割、成果物を比較しやすくする補助資料として使われます。採用企業、転職支援、現在の所属会社で名称や列が異なるため、「この列が必須」という全国共通様式は前提にしません。提出先から様式と目的を指定されたら、その指示を優先します。

現在の所属会社が案件提案に使うスキルシートは、営業担当が顧客へ提出する文書です。無断で書式を変えたり、顧客名・商流・単価を転職用文書へ複製したりしません。転職準備では、公開可能な事実だけを整理した自分用マスターを別に持ち、現在の会社の資産や取引情報を持ち出さないようにします。

厚生労働省のマイジョブ・カードは、職務経歴シートや職業能力証明シートの内容を、履歴書・職務経歴書へ転記して活用できると案内しています。公式様式をそのままSES専用スキルシートと呼ぶのではなく、職歴、資格、学習、実務能力を漏れなく棚卸しする材料として使います。

提出物を確認する質問は三つです。「応募に必要なのは職務経歴書だけか」「技術担当が確認する案件表も必要か」「指定テンプレートとファイル形式はあるか」。不要な資料を大量に送り、読み手へ選別を委ねません。指定がなければ、職務経歴書を主文書にし、案件数が多い場合や技術範囲を補う場合だけスキルシートを付けます。

• 職務経歴書: 職歴全体・強み・再現できる責任
• スキルシート: 案件別の工程・環境・成果物・深さ
• 社内指定様式: 現在の所属会社と提出先のルールを優先
• 自分用マスター: 公開可能な事実だけを蓄積
• 提出前: 読み手・目的・指定形式を確認

客先名・単価・画面・障害を出さず、案件の目的を伝える

最初に、雇用契約、秘密保持契約、就業規則、所属会社の転職時の情報取扱いを確認します。顧客企業名、サービス名、社内画面名、構成図、アカウント、ソースコード、設計書、障害記録、未公開の件数・性能・脆弱性、契約単価・商流は、本人が知っていることと外部へ開示できることが同じではありません。迷う項目は伏せ、所属会社へ確認します。

客先名を伏せても案件の目的は説明できます。「A社向けシステム」ではなく、「小売業の店舗在庫・発注管理」「金融機関の口座手続き」「製造業の部品調達」「社内従業員向けアカウント管理」のように、業界、利用者、業務用途へ一般化します。特定企業を推測できる固有機能は、申込、審査、照合、集計、通知など業務上の役割へ置き換えます。

数字は、公開可否と測定根拠の両方を確認します。画面数、対象テーブル、テスト件数、監視対象、チーム人数を正確に書けない場合は、勝手な概数を作りません。「複数の外部システムと連携」「担当チーム内でレビュー」と、責任を説明するのに必要な粒度まで一般化できます。数字がなくても、入口・判断・出口を具体化すれば仕事は伝わります。

経済産業省は営業秘密に関する指針を公開していますが、転職者が個別情報の法的区分を自己判断するための記事ではありません。公開ページに似た情報があるから、以前の顧客情報も書けるとは限りません。自分が作った資料でも権利や秘密保持は別に確認し、ファイル、画像、コード、ログを持ち出さず、経験を自分の言葉で再構成します。

生成AIへ書類を整形させる場合も、顧客名を仮名へ置き換えただけで安全とは限りません。会社のAI利用規程を優先し、内部の仕様、障害、データ、契約条件を入力しません。当サイトの職務経歴書ツールは入力をブラウザ内で整形しますが、それでも入力する内容自体を公開可能な範囲へ一般化してください。

• 顧客名 → 業界・利用者・業務用途
• 製品・画面名 → 申込・審査・照合・集計などの機能
• 正確な規模 → 公開できる範囲または責任が分かる表現
• 障害詳細 → 対象を特定しない検知・切り分け・復旧・再発防止
• 単価・商流 → 転職用の経験説明へ持ち込まない
• 資料・コード・画像 → 持ち出さず自分の言葉へ再構成

一案件を十二項目で書き、技術名と責任を分離する

一案件の最初に、期間、業界・用途、利用者、体制、自分の立場を置きます。期間は年月、体制は全体を知らなければ所属チームだけを書きます。「メンバー」だけでなく、実装担当、テスト担当、運用一次対応、サブリーダー、PMOなど、実際に担った役割を添えます。正式な役職がないのにリーダーとは書きません。

次に、担当工程、成果物、技術環境、業務内容を分けます。工程は要件整理、基本設計、詳細設計、実装、単体・結合・総合テスト、移行、運用、保守などから実際に関わった範囲を選びます。成果物は設計書、コード、テスト仕様、手順、調査報告、課題表など。技術環境はOS、言語、フレームワーク、DB、クラウド、監視、CI/CD、チケット管理を実態に合わせて分類します。

最後に、自分の責任、レビュー・承認者、結果、担当外を置きます。「詳細設計」と丸を付けても、既存書の修正か、新規作成か、論点整理から持ったかで深さが違います。自分が作成したもの、誰のレビューで完了したか、他チームや上位者が決めたことを分けると、誇張せず任せられる範囲を説明できます。

十二項目は、期間、業界・用途、利用者、体制・立場、担当工程、成果物、技術環境、入口となる依頼・問題、自分の判断・行動、レビュー・承認、結果・変化、担当外です。すべてを長文にせず、最初の七項目は表、残る五項目は三〜五行の案件要約にすると読みやすくなります。

技術経験年数は、案件期間を単純加算する前に重複と利用頻度を確認します。同じ半年にJavaとSQLを使っても、どちらも毎日設計・実装したとは限りません。「Java三年」という合計だけでなく、既存改修、API実装、テスト支援など使い方を案件側へ残します。学習だけの技術は実務欄へ混ぜず、学習・個人開発欄へ分けます。

• 1 期間
• 2 業界・システム用途
• 3 利用者
• 4 体制・自分の立場
• 5 担当工程
• 6 作成・更新した成果物
• 7 技術環境
• 8 入口となる依頼・問題
• 9 自分の判断・行動
• 10 レビュー・承認
• 11 結果・変化
• 12 担当外・責任分界

経験レベルは、年数や丸印より「何を一人で判断したか」で示す

スキル欄へ「初級・中級・上級」や五段階評価を書く場合は、基準を一緒に示します。人によって中級の意味が違うため、数値だけでは比較できません。「手順とレビューを受けて実施」「既存例を参照して作成」「論点を整理してレビュー依頼」「方針を提案し関係者と合意」「他者の成果物をレビュー」のように、行動と責任へ置き換えます。

経験年数も補助情報です。同じ三年でも、毎回指示された修正を行った人と、仕様差分、影響範囲、テスト、リリース確認まで担当した人では任せられる範囲が異なります。年数を消す必要はありませんが、直近利用時期、案件での使い方、単独で行った範囲、レビューが必要な範囲を併記します。

「一人でできる」とは、誰にも相談しないことではありません。業務システムでは、要件、権限、品質、リリースを関係者と確認すること自体が責任です。資料や既存コードを調べ、判断が必要な論点を特定し、適切な人へレビューを求め、指摘を反映して完了できる状態を示します。

厚生労働省のIT分野向け実践的能力証明シートやIPAのデジタルスキル標準は、職務や能力を振り返る参照枠として使えます。ただし、公式資料の役割名へ自分を当てはめただけで、その能力が証明されるわけではありません。期待される役割から、自分が実際に担当した成果物と不足する経験を見つけます。

求人へ合わせてレベルを上げるのではなく、証拠の順番を変えます。設計求人なら仕様差分と設計判断、QAなら観点と不具合分析、社内SEなら利用部門との合意とベンダー調整、自社サービスならリリース後の監視と改善を先に置きます。経験の事実と期間は変えず、読み手が探す責任を前へ移します。

• L1 手順・指示・レビューを受けて実施
• L2 既存例を参照して成果物を作成
• L3 論点と影響範囲を整理してレビュー依頼
• L4 方針を提案し関係者と合意して完了
• L5 他者の成果物をレビューし品質基準を改善
• 共通: 相談先・承認者・担当外を明記

テスト・アプリ運用保守は、件数より観点と切り分けを書く

テスト実行では、「テストケースに沿って実施」だけで終えず、仕様理解、データ準備、実行、証跡、不具合再現、回帰確認のうち担当した範囲を書きます。追加した境界値・異常系、権限・状態遷移・日付・外部連携の観点があれば、なぜ必要と判断し、誰のレビューを受けたかを一件示します。消化件数が多いだけで品質責任を断定しません。

テスト設計では、要件や設計書から観点を抽出したのか、既存項目の修正か、実行担当への説明や不具合傾向の分析まで持ったのかを分けます。「結合テスト担当」より、「仕様変更点と既存機能の影響を整理し、正常・異常・権限差分の観点を追加。レビュー指摘を反映して実行担当へ説明」の方が責任を再現できます。

アプリ運用保守では、問い合わせ受付、再現、ログ・SQL調査、原因範囲、暫定対応、恒久改修、テスト、本番確認、再発防止を分けます。問い合わせを開発へ転送しただけか、自分で仮説と証拠を揃えたかを明確にします。顧客の障害詳細は出さず、検知から出口までの判断順序を書きます。

定型作業でも、チェックリストの改善、実行前後の確認、失敗時の停止条件、属人化した手順の整理は経験になります。回数だけを実績にせず、誤操作や確認漏れをどう防いだか、次の担当者が同じ基準で進められるよう何を残したかを示します。測定していない削減率は作りません。

例文は「通信業向け契約管理システムの保守で、問い合わせ内容とログ・SQLから影響範囲を整理。既存仕様との差分を開発担当へ共有し、小規模改修では実装、異常系テスト、本番確認まで担当。再発時の確認順序を手順へ追記し、チームレビューを受けて運用へ反映」です。顧客名や内部名称がなくても入口、判断、出口、結果が伝わります。

• テスト実行: データ・証跡・再現・回帰までの範囲
• テスト設計: 仕様差分から追加した観点とレビュー
• 問い合わせ: 受付ではなく仮説・ログ・SQL・原因範囲
• 小規模改修: 影響調査・実装・異常系・本番確認
• 定型作業: 停止条件・前後確認・手順改善・引き継ぎ

インフラ・PMOは、操作名より変更と意思決定の責任を書く

インフラ運用では、監視製品名やコマンドだけでなく、アラート確認、影響判定、一次切り分け、エスカレーション、復旧確認のどこを担当したかを書きます。定期変更なら、申請、手順、事前確認、実施、動作確認、切り戻し条件、結果記録へ分けます。本番変更の承認者と自分の担当範囲を混ぜません。

構築補佐では、指示されたパラメータ投入だけか、既存構成の調査、設定案、レビュー、テスト、移行まで関わったかを示します。個人環境で試したクラウドやIaCを本番実務年数へ足さず、学習欄へ分けたうえで、実務で使える状態へするために不足するレビュー・変更・運用経験を明確にします。

PMOでは、会議数、議事録数、Excel操作より、計画との差、課題、リスク、変更、依存関係をどう区別し、誰の判断をいつ必要としたかを書きます。意思決定そのものがプロジェクト責任者の担当なら、自分は情報整理、選択肢提示、期限・担当の追跡を行ったと分けます。役職名を盛らず、前へ進めた判断の流れを示します。

数字を使う場合は、対象、期間、測定方法、自分以外の変更を説明できるものだけにします。「障害を50%削減」「進捗を20%改善」といった結果を測っていないなら作りません。「重大度の判定基準を一覧化」「未決事項へ判断者と期限を付与」「変更前後の確認項目を統一」のように、観察できる成果物と運用の変化を書けます。

例文は「基盤更改で、既存構成と監視項目の差分を整理し、変更手順・確認項目・切り戻し条件を更新。レビュー後の作業では担当サーバーの設定変更と疎通・監視確認を実施し、結果を変更記録へ反映」「PMOとして課題・リスク・変更要求を別台帳へ整理し、判断者・期限・依存タスクを会議前に提示。決定後は担当者と完了条件を確認」です。

• 監視: 検知・影響・切り分け・連絡・復旧確認
• 変更: 申請・事前確認・実施・確認・切り戻し・記録
• 構築: 既存調査・設定案・レビュー・テスト・移行
• PMO: 計画差・課題・リスク・変更・依存関係
• 数字: 対象・期間・測定・自分の寄与を説明できる場合だけ

マスターを作り、転職用二ページと重点三案件へ編集する

まず全案件を十二項目で埋めたマスターを作ります。古い案件や短期案件も期間の空白が出ないよう残し、提出版では応募先に近い三案件を詳しくします。案件数が多いから削除するのではなく、全体一覧と重点案件を分けます。同じ業務が続く場合は、共通作業をまとめ、案件ごとの技術・判断・責任の差だけを残します。

職務経歴書の冒頭には、現在任せられる責任、重点技術、次に広げたい工程を二〜四行で置きます。スキルシートはその主張の根拠として、案件表と経験レベルを示します。二つの文書で期間、技術、工程が食い違わないよう、マスターから編集します。退職理由や志望動機までスキルシートへ詰め込まず、面接資料と分けます。

提出前に七問で確認します。期間に矛盾はないか、顧客を特定できないか、実務と学習を分けたか、工程の丸印を責任で説明したか、自分とチームの成果を分けたか、数字の根拠があるか、深掘りされた時に入口・判断・出口・担当外を答えられるか。答えられない項目は削るか、事実へ戻します。

転職支援へ相談する場合は、対象条件に合う二社までへ同じ職務経歴書と重点案件を渡します。TechGoは実務経験二年以上のITエンジニアが年収と技術環境を見直す候補、STRATEGY CAREERは主に二十〜三十代の経験者が企業・職種の幅を確認する候補です。社内SE転職ナビは社内SE・情シス、TechClipsエージェントは自社サービス企業などを確認する時の候補として分けます。

比較中の全社へ登録する必要はありません。年齢、実務経験、勤務地、希望進路が合う候補へ「この経歴で紹介可能な求人」「評価された案件・不足する証拠」「応募先に合わせて削る箇所」「面接で確認される責任」を同じ順番で聞きます。担当者が文章をきれいにしたかではなく、求人要件と案件証拠を具体的につないだかを比較します。応募は求人ごとに自分で同意し、書類の修正と応募判断を分けてください。

• 全案件マスターを十二項目で作る
• 応募先に近い三案件だけ詳しくする
• 職務経歴書と期間・技術・工程を一致させる
• 入口・判断・出口・担当外を深掘りできる
• 対象条件に合う二社へ同じ経歴を渡す
• 添削量ではなく求人要件との接続を比較する

職務経歴書の変換例

技術と工程の丸印に、案件の用途、入口、自分の判断、レビュー、担当外を足すと、誇張せず任せられる範囲が伝わります。

行動前チェックリスト

• 提出先が職務経歴書とスキルシートのどちらを求めるか確認した
• 所属会社の指定様式と自分用マスターを混同していない
• 顧客名・製品名・商流・単価・内部資料を持ち出していない
• 案件ごとに期間・用途・体制・工程・成果物・環境を書いた
• 入口・自分の判断・レビュー・結果・担当外を書いた
• 実務経験と学習・個人開発を分けた
• 経験レベルを年数や丸印だけでなく責任で示した
• テスト・保守を件数ではなく観点と切り分けへ変えた
• インフラ変更の承認者と自分の担当を分けた
• PMOの判断者と自分の整理・追跡を分けた
• 数字は対象・期間・測定方法を説明できる
• 対象条件に合う二社までへ同じ経歴と質問を渡す