SIer転職での履歴書・職務経歴書の書き方｜例文・テンプレート付き

この記事にはアフィリエイト広告が含まれます。

SIer転職で年収アップを狙うなら、履歴書より先に職務経歴書を作り込むことが重要です。

採用担当者が見ているのは、学歴や資格だけではありません。

「どの工程を担当したか」「どの規模の案件で働いたか」「自分の工夫によって何が改善されたか」まで具体的に書ける人ほど、市場価値を正しく評価してもらいやすくなります。

まずは記事内の無料Wordテンプレートをダウンロードし、担当工程・案件規模・使用技術・役割・成果をプロジェクトごとに書き出してみてください。

この記事では、SIer向け職務経歴書の書き方から、コピペできるテンプレート、完成例、年収アップにつながる経験の言い換え方、転職先別のアピール方法まで解説します。

SIerの職務経歴書で採用担当者が見るポイント

SIerの職務経歴書では、プロジェクト名や担当業務を並べるだけでは十分ではありません。

採用担当者が知りたいのは、どの工程を担当し、どの規模のプロジェクトで、どのような役割を果たしたのかです。

さらに、使用した技術や自分なりの工夫、成果まで書けると、入社後に活躍する姿をイメージしてもらいやすくなります。

採用担当者が見るポイント	確認される内容
担当工程・業務範囲	どこからどこまで担当したか
プロジェクト規模	期間、人数、予算、システム規模
使用技術	言語、クラウド、DB、ツール
役割・貢献	チーム内で何を任されたか
工夫・成果	課題に対して何を改善したか

担当した工程と業務範囲

職務経歴書では、要件定義、基本設計、詳細設計、開発、テスト、運用保守など、担当した工程を明確に書きましょう。

「システム開発を担当」とだけ書いても、実際のスキルは伝わりません。

「基本設計書の作成」「Javaによる機能開発」「結合テスト仕様書の作成」など、担当業務まで具体化することが大切です。

私もSIerの現場でテスト業務に携わっていますが、単に「テストを担当」と書くより、仕様書作成、不具合の切り分け、開発担当者との調整まで分解したほうが、経験の中身を伝えやすいと感じます。

プロジェクトの規模・期間・開発予算

同じ業務内容でも、プロジェクトの規模によって求められる調整力や責任の大きさは異なります。

職務経歴書には、プロジェクト期間、全体人数、所属チームの人数を可能な範囲で記載しましょう。

数百人規模の案件や長期プロジェクトに参加した経験があれば、大規模開発への理解をアピールできます。

開発予算については、PM・PL・PMOなど予算管理に関わった場合に書くのがおすすめです。

正確な金額を把握していない場合は無理に記載せず、「数億円規模」「大規模基幹システム」など、守秘義務に配慮した表現を使いましょう。

使用した言語・クラウド・ツール

使用した言語やツールは、名前を並べるだけでなく、どの業務でどの程度使ったのかまで記載します。

たとえば、Javaなら「既存機能の改修」「新規APIの実装」、AWSなら「EC2の設定」「CloudWatchを使った監視」など、利用場面を書くとスキルレベルが伝わりやすくなります。

分類	記載する内容の例
言語	Java、Python、JavaScript、SQL
フレームワーク	Spring Boot、Django、React
クラウド	AWS、Azure、Google Cloud
データベース	Oracle、MySQL、PostgreSQL
ツール	Git、Jira、Redmine、Docker

実務で少し触っただけの技術を、経験豊富であるかのように書くのは避けましょう。

チーム内での役割と個人の貢献

SIerの仕事はチームで進めるため、プロジェクト全体の成果と、自分が担当した内容を分けて書く必要があります。

「チームで納期を達成した」だけでは、本人が何をしたのかが分かりません。

「進捗管理を担当した」「設計書レビューを実施した」「新入社員2名を支援した」など、自分の役割を具体化しましょう。

役職がなくても、主体的に動いた経験はアピールできます。

担当者間の認識をそろえた経験や、手順書を改善した実績なども、調整力や課題解決力を示す材料になります。

課題に対して工夫したことと成果

職務経歴書で差がつくのは、担当業務そのものよりも、業務上の課題に対してどのように動いたかです。

以下の順番で整理すると、読み手に伝わりやすくなります。

1. どのような課題があったか
2. 自分が何を考えて行動したか
3. どのような結果につながったか

たとえば、「テストを実施した」ではなく、「過去の不具合を分析して確認項目を追加し、後工程での不具合流出を防いだ」と書くことで、品質を意識して行動できる人材だと伝わります。

成果を数字で示せる場合は、「作業時間を月10時間削減」「問い合わせ件数を20％削減」のように記載しましょう。

数字がない場合でも、手戻りの削減や業務の標準化など、変化が分かる表現を使うことが重要です。

【コピペ可】SIer向け職務経歴書テンプレート

SIerの職務経歴書は、一般的なテンプレートへ会社名と担当業務を入力するだけでは、経験の価値が伝わりにくくなります。

担当工程、プロジェクト規模、使用技術、チーム内での役割、成果まで整理することが重要です。

そこで、SIer社員が経験を棚卸ししやすいWord形式の職務経歴書テンプレートを用意しました。

テンプレートには、以下の項目が含まれています。

項目	記載する内容
職務要約	経験年数、得意分野、担当工程、主な成果
活かせる経験・スキル	技術、顧客対応、マネジメント、業務知識
職歴	在籍企業、事業内容、雇用形態、役職
プロジェクト経歴	案件概要、規模、役割、担当工程、使用技術
成果・工夫	課題、行動、成果を数字とともに記載
顧客対応・マネジメント	顧客折衝、進捗管理、レビュー、課題管理
資格・学習内容	保有資格と実務・応募先とのつながり
自己PR	強み、具体的な経験、転職先での再現性

無料ダウンロード

SIer転職・年収アップ向け 職務経歴書テンプレート

担当工程・案件規模・役割・成果を、採用担当者に伝わる順番で整理できる記入式のWordテンプレートです。プロジェクト経歴、顧客対応、マネジメント、自己PRまで、入力欄と書き方例を用意しています。

• 担当工程を「要件定義・設計・開発・運用保守」に分けて整理
• 人数・期間・件数・削減時間など、数字で成果を伝えやすい
• 大手SIer・社内SE・ITコンサルなど、応募先別の調整ポイント付き

無料でテンプレートをダウンロード（Word）

形式：DOCX（Word）／入力例・提出前チェック付き
応募時は、黄色の編集メモと「応募先別カスタマイズガイド」を削除してご利用ください。

職務要約は経験年数と強みを250〜350文字でまとめる

職務要約では、これまでの経歴を250〜350文字程度にまとめます。

最初に経験年数と担当領域を書き、続けて得意な工程、使用技術、顧客対応やマネジメント経験、成果を記載すると伝わりやすくなります。

記載する順番は以下がおすすめです。

1. SIerでの経験年数を書きます。
2. 担当した業界やシステムを書きます。
3. 得意な工程と技術を書きます。
4. 顧客対応やマネジメント経験を書きます。
5. 数字で示せる成果を書きます。
6. 応募先で活かせる強みをまとめます。

記載例は以下のとおりです。

SIerにて4年間、金融業界向け業務システムの開発・保守に従事しました。Javaを用いた詳細設計から結合テストまでの経験に加え、顧客との仕様調整や5名チームの進捗管理を担当しています。運用作業の自動化を提案・実装し、月10時間の工数削減を実現しました。今後は、開発経験と顧客調整力を活かし、上流工程からシステム改善に貢献したいと考えています。

職務要約だけを読んでも、どのような経験を持つ人なのか分かる状態を目指しましょう。

活かせる経験・スキルは業務と結びつけて書く

スキル欄では、Java、AWS、Oracle、Gitなどの名前を並べるだけでなく、どのような業務で使ったのかを整理します。

たとえば、同じJava経験でも、「研修で使用した」と「基本設計から結合テストまで3年間使用した」では評価が異なります。

テンプレートでは、以下の項目に分けて経験を整理できます。

• 得意な工程には、要件定義、設計、開発、テスト、運用保守などを書きます。
• 技術には、言語、フレームワーク、データベース、クラウド、ツールなどを書きます。
• 顧客対応には、ヒアリング、要望整理、仕様調整、問い合わせ対応などを書きます。
• マネジメントには、進捗、品質、課題、レビュー、ベンダー管理などを書きます。
• 改善経験には、工数削減、品質向上、自動化、手順整備などを書きます。
• 業務知識には、金融、通信、製造、公共などの経験業界を書きます。

すべての欄を埋める必要はありません。

応募先で評価される経験を優先し、実務で説明できる内容だけを記載してください。

プロジェクト経歴は新しい案件から順番に書く

プロジェクト経歴は、原則として新しい案件から順番に記載します。

直近の経験ほど、現在のスキルや市場価値を判断する材料になるためです。

案件ごとに、以下の情報を整理しましょう。

項目	記載例
期間	2024年4月～2026年3月
顧客業界	金融、通信、製造、公共など
案件概要	金融機関向け業務システムの更改
規模	全体50名、自チーム8名、利用者約2,000名
役割	メンバー、サブリーダー、PL、PMO
担当工程	基本設計、詳細設計、開発、結合テスト
使用技術	Java、Spring Boot、Oracle、AWS、Git
商流・立場	元請、一次請、顧客窓口の有無

顧客名や正式なシステム名は、守秘義務に配慮して一般化します。

「株式会社〇〇向け」ではなく、「大手通信事業者向け」「金融機関向け」と記載すれば十分です。

成果は「課題・行動・結果」の順番で整理する

職務経歴書では、「業務に貢献した」「品質向上に努めた」と書くだけでは、具体的な行動が伝わりません。

テンプレートでは、成果を以下の3段階で整理できるようにしています。

項目	記載内容
課題	どのような問題が発生していたか
行動	課題に対して何を考え、何を実行したか
結果	工数、件数、期間、品質がどう変化したか

たとえば、次のように書きます。

月次集計を手作業で実施しており、担当者2名が毎月15時間を費やしていました。処理手順を整理し、SQLとバッチ処理による自動化を提案・実装しました。その結果、月10時間の工数を削減し、作業漏れを0件にできました。

大きな成果がない場合でも、対応件数、レビュー件数、手戻りの削減、手順書の整備などを振り返ると、数字にできる経験が見つかります。

肩書きがなくても顧客対応やマネジメント経験を書く

マネージャーやリーダーの役職がなくても、実際に担当した責任は記載できます。

たとえば、以下の経験は職務経歴書でアピールできます。

• 顧客との定例会で進捗や課題を報告した経験
• 後輩や協力会社メンバーへ仕様を説明した経験
• 設計書やソースコードをレビューした経験
• チーム内のタスクや課題を管理した経験
• 障害発生時に関係者との調整を担当した経験
• ユーザー部門の要望を整理した経験

「メンバーだったからマネジメント経験はない」と判断せず、自分が任されていた業務を分解しましょう。

ただし、チーム全体の成果を自分一人の実績として書いてはいけません。

「チームで実現した成果」と「自分が担当した行動」を分けて記載することが大切です。

自己PRは強みと再現性まで書く

自己PRでは、「コミュニケーション能力があります」「責任感があります」といった抽象的な表現だけでは不十分です。

以下の順番で書くと、仕事で活かせる強みが伝わります。

1. 自分の強みを最初に示します。
2. 強みを発揮した状況を書きます。
3. 実際に行ったことを書きます。
4. 得られた成果を書きます。
5. 応募先でどのように活かすかを書きます。

記載例は以下のとおりです。

私の強みは、関係者の認識を整理し、プロジェクトを前に進める調整力です。結合テストで仕様の認識違いが発生した際には、設計書とテスト結果を整理し、開発担当者と認識合わせを実施しました。確認事項を一覧化して関係者へ共有したことで、修正方針を早期に決定でき、後続作業への影響を抑えられました。今後も、技術面と調整面の両方からプロジェクトの円滑な進行に貢献します。

応募先によって、自己PRで前に出す経験を変えましょう。

大手SIerなら大規模案件や調整経験、社内SEなら業務理解や運用改善、ITコンサルなら課題整理や顧客折衝が評価されやすくなります。

テンプレートを使った職務経歴書の作り方

テンプレートは、次の手順で編集すると効率的です。

1. これまで参加したプロジェクトをすべて書き出します。
2. 期間、規模、工程、技術、役割を整理します。
3. 担当業務を工程ごとに分解します。
4. 工夫したことや成果を数字で整理します。
5. 応募先で評価される経験を前に出します。
6. 記入例、編集メモ、不要なページを削除します。
7. PDFに変換し、文字切れや表の崩れを確認します。

最初から文章を完成させようとすると手が止まりやすいため、まずは箇条書きで経験を埋めるのがおすすめです。

その後、応募する求人の仕事内容や必須条件と照らし合わせながら、職務要約と自己PRを調整してください。

職務経歴書の内容に不安がある場合は、完成後にIT業界へ強い転職エージェントへ添削を依頼しましょう。

自分では当たり前だと思っていた経験が、転職市場では評価されるケースもあります。

添削を依頼するなら、ユニゾンキャリア転職とTechGoがおすすめです。

【完成例】若手SIer社員の職務経歴書

若手SIer社員の職務経歴書では、経験年数の短さを無理に隠す必要はありません。

担当した工程や使用技術に加え、現場で任された業務、課題に対して工夫したことを具体的に書けば、入社後の活躍イメージを伝えられます。

ここでは、SIerで約3年間働き、大規模システムの開発・テストを経験した若手社員を想定して、職務経歴書の完成例を紹介します。

なお、以下は架空の人物を想定したサンプルです。

前章で紹介したWordテンプレートの職務要約、プロジェクト経歴、成果、自己PRなどの項目に沿って作成しています。

完成例の想定プロフィール

項目	内容
年齢	25歳
SIer経験	約3年
担当領域	通信業界向け大規模監視システム
主な担当工程	詳細設計、開発、単体テスト、結合テスト
使用技術	Java、SQL、Oracle、Linux、Git、Jenkins
役割	アプリケーション開発チームのメンバー
転職先の希望	大手SIer、社内SE、自社開発企業
アピールする強み	品質管理、課題整理、関係者との調整

このような若手社員の場合、PMやPLの経験がなくても問題ありません。

担当した機能、テスト件数、不具合対応、レビュー、進捗共有などを細かく整理すると、実務経験の中身が伝わります。

職務経歴書

作成日：20XX年XX月XX日
氏名：〇〇 〇〇

職務要約

大学卒業後、独立系SIerへ入社し、約3年間にわたり通信事業者向け大規模監視システムの開発に従事してきました。

アプリケーション開発チームのメンバーとして、Javaを用いた既存機能の改修、詳細設計書の修正、単体テスト、結合テストを担当しています。テスト工程では、仕様書の作成、証跡確認、不具合の切り分け、開発担当者との調整まで経験しました。

また、テスト項目の重複や確認漏れを防ぐため、観点表の整理とレビュー手順の見直しを提案しました。これまでの開発・テスト経験と関係者との調整力を活かし、今後は設計や要件整理など、より上流の工程にも携わりたいと考えています。

活かせる経験・知識・スキル

分類	経験・スキル
担当工程	詳細設計、開発、単体テスト、結合テスト
開発経験	Javaを用いた既存機能の改修、SQLの作成・修正
テスト経験	テスト仕様書作成、テスト実施、証跡確認、不具合管理
品質管理	テスト観点の整理、レビュー指摘対応、不具合の原因切り分け
調整経験	チーム内の進捗共有、開発担当者との仕様確認、課題管理
業務知識	通信システム、監視システム、大規模開発の進め方
使用技術	Java、SQL、Oracle、Linux、Git、Jenkins、Redmine

職歴

株式会社〇〇システムズ
20XX年4月入社～現在

項目	内容
事業内容	システム開発、運用保守、ITコンサルティング
雇用形態	正社員
所属	システム開発部
役職	一般社員

プロジェクト経歴

通信事業者向け大規模監視システムの開発・更改

項目	内容
期間	20XX年7月～現在
顧客業界	通信
案件概要	通信設備を監視する大規模システムの開発・更改
プロジェクト規模	全体約60名、自チーム8名
役割	アプリケーション開発メンバー
担当工程	詳細設計、開発、単体テスト、結合テスト
使用技術	Java、SQL、Oracle、Linux、Git、Jenkins、Redmine
商流・立場	元請SIerの開発メンバー

担当業務

• 既存機能の仕様調査と影響範囲の確認
• 詳細設計書および処理フローの修正
• Javaを用いた既存アプリケーションの改修
• SQLの作成およびデータ確認
• 単体テスト仕様書の作成とテスト実施
• 結合テストのテスト項目作成とレビュー対応
• テスト証跡の確認と管理
• 不具合発生時の原因切り分け
• 開発担当者や他チームとの仕様確認
• Redmineを用いた課題・不具合の管理
• チーム内会議での進捗・課題報告

「開発を担当」「テストを担当」とまとめるのではなく、実際に行った作業まで分解することがポイントです。

若手社員でも、仕様調査、レビュー対応、不具合管理、他チームとの調整など、評価につながる経験を持っている可能性があります。

成果・工夫

項目	内容
課題	複数の担当者がテスト項目を作成しており、確認観点の重複や抜け漏れが発生していた
行動	過去の不具合とレビュー指摘を整理し、機能別のテスト観点表を作成した。チーム内レビューで観点を共有し、担当者ごとの認識差を減らした
結果	テスト仕様書のレビュー指摘数を前回の工程と比べて約30％削減し、テスト開始後の項目追加も減らした

不具合対応における工夫

項目	内容
課題	不具合発生時に、アプリケーション、データ、環境のどこに原因があるのか判断するまで時間がかかっていた
行動	発生条件、ログ、対象データ、再現手順を一定の形式で整理し、開発担当者へ共有した
結果	調査に必要な情報の確認回数が減り、不具合の原因切り分けと修正方針の決定を円滑に進められた

数字で示せる成果がない場合でも、「何が変わったか」を具体的に書けば問題ありません。

たとえば、確認回数の減少、手戻りの防止、認識差の解消、作業の標準化なども立派な成果です。

顧客対応・チーム内での役割

• チーム内の進捗会議で、自分の担当機能に関する進捗と課題を報告
• 仕様に不明点がある場合は、設計担当者へ確認事項を整理して共有
• 結合テストで検出した不具合について、再現条件と影響範囲を整理
• 後から参加したメンバーへ、テスト手順や開発環境の使い方を説明
• 他チームとの接続部分で発生した課題について、双方の仕様を確認して調整

若手社員の場合、正式なリーダー経験がなくても、実際に任された役割を書けば評価につながります。

「会議に参加した」ではなく、「何を報告したか」「何を整理したか」「誰と調整したか」まで記載しましょう。

テクニカルスキル

技術	経験期間	使用レベル
Java	約2年6カ月	既存ソースを理解し、機能改修と単体テストを実施できる
SQL	約2年6カ月	データ抽出、更新、テストデータの作成ができる
Oracle	約2年6カ月	開発・テスト時のデータ確認に使用
Linux	約2年	基本的なコマンド操作、ログ確認ができる
Git	約2年6カ月	ブランチ作成、コミット、マージ、差分確認ができる
Jenkins	約1年6カ月	ビルド・デプロイ結果の確認に使用
Redmine	約2年6カ月	課題、進捗、不具合の管理に使用

技術欄では、「Java：2年」と書くだけでなく、どの程度扱えるかまで記載します。

経験年数が長くても、実際に使った業務を説明できなければ評価されにくいため、無理にスキルを大きく見せる必要はありません。

保有資格・学習中の技術

取得年月	資格・学習内容	実務とのつながり
20XX年6月	基本情報技術者試験	開発工程、ネットワーク、データベースの基礎知識を業務で活用
20XX年11月	AWS Certified Cloud Practitioner	クラウドの基本概念とAWSサービスを学習
学習中	AWS Certified Solutions Architect – Associate	クラウド環境の設計・構築に必要な知識を学習中

資格は、名称を並べるだけでなく、現在の業務や今後のキャリアと結びつけます。

ただし、職務経歴書では資格よりも実務経験が優先されます。資格欄を長くしすぎず、プロジェクト経歴や成果を充実させましょう。

自己PR

品質を意識して業務を改善する力

私の強みは、与えられた作業を実施するだけでなく、品質を高めるための改善点を考えられることです。

結合テストの準備では、担当者によって確認観点に差があり、レビュー指摘やテスト開始後の項目追加が発生していました。そこで、過去の不具合とレビュー指摘を整理し、機能別のテスト観点表を作成しました。

チーム内で観点を共有した結果、テスト仕様書のレビュー指摘数を前回の工程と比べて約30％削減できました。今後も、開発や運用の現場で発生している課題を整理し、品質と作業効率の向上に貢献します。

関係者の認識を整理して課題を前に進める力

私は、関係者ごとに異なる情報を整理し、課題を前に進めることを得意としています。

結合テストで不具合が発生した際は、再現条件、対象データ、ログ、関連する仕様書を整理したうえで、開発担当者へ共有しました。必要な情報を先にまとめることで、確認のやり取りを減らし、原因調査を円滑に進められました。

今後は、これまでの開発・テスト経験を活かしながら、設計や要件整理にも担当範囲を広げたいと考えています。技術面と調整面の両方から、プロジェクトを着実に前へ進められるエンジニアを目指します。

---

完成例を自分の職務経歴書へ置き換えるポイント

上記の完成例をそのまま使うのではなく、自分が実際に経験した内容へ置き換えてください。

完成例の項目	自分の経験に置き換える内容
通信向け監視システム	金融、製造、公共、流通などの担当業界
Javaによる開発	自分が使用した言語や担当機能
テスト観点の整理	自分が工夫した作業や改善した業務
レビュー指摘30％削減	工数、件数、期間など実際に説明できる成果
8名チーム	全体人数と自分が所属したチームの人数
上流工程を目指す	応募先で実現したいキャリア

私もSIerの現場で働いていると、日々の業務を「テスト」「課題対応」「会議」と大まかに捉えてしまいがちです。

しかし、職務経歴書では、テスト仕様書を作成したのか、不具合を切り分けたのか、関係者と仕様を調整したのかまで分解する必要があります。

普段の業務を細かく振り返ると、若手でも職務経歴書に書ける経験は意外と多く見つかります。

SIer経験を年収アップにつなげる書き換え例

SIerの職務経歴書では、担当業務をそのまま並べるのではなく、転職先でも再現できるスキルとして言い換えることが重要です。

たとえば、「テストを担当した」だけでは、指示どおりに作業した印象になりかねません。

一方で、品質上の課題を見つけて改善した経験まで書けば、品質管理や課題解決ができる人材として伝わります。

元の経験	職務経歴書で伝えたい強み
テスト	品質管理、原因分析、改善提案
運用保守	障害対応、業務改善、安定稼働への貢献
開発	技術力、設計力、担当機能への理解
顧客対応	要件整理、合意形成、関係者調整
PM・PL	QCD管理、チーム管理、予算管理

経験を必要以上に大きく見せる必要はありません。

自分が実際に行ったことを分解し、応募先で評価される言葉へ置き換えましょう。

テスト経験を品質改善の経験として書く

テスト経験は、実施した件数だけでなく、品質向上のために考えたことまで書くと評価されやすくなります。

特に若手SIer社員の場合、開発よりテストを任される期間が長いことも珍しくありません。

しかし、テスト仕様書の作成、不具合の切り分け、レビュー対応、関係者との調整まで担当していれば、品質管理に関する経験としてアピールできます。

書き換え前	書き換え後
結合テストを担当しました	結合テスト仕様書の作成からテスト実施、不具合の原因切り分け、開発担当者との修正調整まで担当しました
テスト項目を作成しました	過去の不具合と仕様変更の内容を確認し、境界値や異常系を含むテスト項目を作成しました
不具合管理を担当しました	不具合の発生条件、ログ、対象データを整理し、開発担当者が原因を調査しやすい形式で共有しました
レビューに対応しました	レビュー指摘の傾向を整理して観点表へ反映し、同じ指摘の再発防止に取り組みました

運用保守を課題解決・改善経験として書く

運用保守では、システムを安定して動かした実績に加え、障害対応や業務改善の経験を具体的に書きましょう。

「問い合わせ対応」「定例作業」とだけ記載すると、決められた手順を繰り返していたように見えてしまいます。

対応件数、原因分析、再発防止、手順の改善まで示すことで、課題解決力を伝えられます。

書き換え前	書き換え後
システムの運用保守を担当しました	業務システムの監視、問い合わせ対応、障害一次切り分け、月次作業を担当しました
障害対応を行いました	ログと処理履歴を確認して原因を切り分け、開発担当者やインフラ担当者と復旧対応を進めました
手順書を作成しました	担当者ごとに異なっていた作業手順を整理し、判断基準を含む運用手順書を作成しました
問い合わせに対応しました	月平均30件の問い合わせ内容を分類し、頻出する質問をFAQへ反映しました

開発経験を担当機能と技術レベルまで書く

開発経験は、使用したプログラミング言語だけでなく、担当機能、担当工程、自分で対応できる範囲まで書きます。

採用担当者は、「Java経験3年」という情報だけでは、どの程度の開発を任せられるのか判断できません。

既存機能の改修なのか、新規機能の設計・実装なのか、レビューまで担当したのかを明確にしましょう。

書き換え前	書き換え後
Javaによる開発を担当しました	Javaを用いて、顧客情報の検索・更新機能の詳細設計、実装、単体テストを担当しました
SQLを使用しました	Oracle環境でデータ抽出・更新用のSQLを作成し、テストデータの準備と不具合調査に使用しました
既存システムを改修しました	既存ソースと設計書から影響範囲を調査し、対象機能の改修と回帰テストを実施しました
コードレビューに参加しました	月平均10件のソースコードレビューを担当し、例外処理や可読性の観点から改善点を指摘しました

顧客対応を要件整理・調整経験として書く

顧客対応は、単に会議や問い合わせへ対応した経験ではなく、要望を整理し、関係者と合意形成した経験として書きます。

SIerでは、顧客の要望をそのまま開発担当者へ伝えるだけではプロジェクトが進みません。

背景や目的を確認し、システムで実現する範囲へ落とし込む能力が求められます。

書き換え前	書き換え後
顧客との会議に参加しました	顧客との週次定例に参加し、進捗、課題、仕様変更の影響を説明しました
顧客の要望を聞きました	ユーザー部門へのヒアリングを行い、現行業務と要望を整理して要件一覧を作成しました
仕様調整を担当しました	顧客要望について、納期や既存機能への影響を整理し、実現方法を開発チームと調整しました
問い合わせに回答しました	問い合わせの背景と利用状況を確認し、仕様上の回答と代替案を顧客へ説明しました

PM・PL経験を人数・予算・QCDで書く

PM・PL経験は、役職名だけでなく、管理した人数、期間、予算、担当範囲、成果まで書きます。

採用担当者が確認したいのは、「PLを経験した」という肩書きではなく、どの規模のプロジェクトで、どのような責任を負っていたかです。

QCDとは、以下の3つを指します。

項目	意味	記載する内容
Quality	品質	不具合件数、レビュー、品質改善
Cost	コスト	開発予算、工数、要員、外注費
Delivery	納期	スケジュール、進捗、納期遵守

書き換え例は以下のとおりです。

書き換え前	書き換え後
PLとしてプロジェクトを管理しました	8名の開発チームでPLを務め、進捗、課題、品質、メンバーのタスクを管理しました
予算管理を担当しました	約5,000万円規模の開発案件で、月次の工数実績と見込みを確認し、予算超過リスクを管理しました
進捗管理を行いました	WBSを用いて週次で進捗を確認し、遅延タスクの原因と対応策を顧客へ報告しました
品質管理を担当しました	設計書とソースコードのレビュー状況、不具合件数を管理し、重点レビュー対象を設定しました
ベンダー管理を行いました	協力会社2社・計10名の成果物、進捗、課題を管理し、仕様確認と受け入れレビューを担当しました

履歴書・職務経歴書に不安があるなら転職エージェントを活用しよう

SIer転職で履歴書・職務経歴書に不安があるなら、自己流で応募する前に転職エージェントを活用するべきです。

特に年収アップを狙う場合、書類の見せ方ひとつで「ただの開発担当」に見えるか「上流工程やリーダーを任せられる人材」に見えるかが変わります。

活用するメリット	具体的にできること	年収アップにつながる理由
書類添削を受けられる	履歴書・職務経歴書の弱い部分を直せる	採用担当者に経験や強みが伝わりやすくなる
求人ごとに対策できる	社内SE、SIer、ITコンサルなどに合わせて内容を変えられる	応募先に合ったアピールができる
年収交渉を任せられる	希望年収や現年収をもとに条件交渉してもらえる	自分では言いにくい条件面を相談しやすい

まずは社内SEを狙うなら社内SE転職ナビ、SIerやITコンサルも含めて高年収求人を見たいならTechGoに相談してみましょう。

あわせてＩＴ専門転職エージェント＠ＰＲＯ人、ユニゾンキャリア転職、TechClipsエージェントなども使うと、求人の選択肢を広げやすくなります。

転職エージェントなら書類添削を受けられる

転職エージェントを使う大きなメリットは、履歴書・職務経歴書の添削を受けられることです。

SIer経験者は、普段やっている仕事をそのまま書くと「開発を担当」「運用保守を担当」のようにあいまいになりがちです。

エージェントに見てもらうことで、担当工程、案件規模、役割、成果を採用担当者に伝わる形へ整理できます。

自己流で書いた場合	添削後の見せ方
業務システムの開発を担当	販売管理システムの基本設計、詳細設計、開発、単体テストを担当
チームで案件を進めた	5名チームのサブリーダーとして進捗管理とレビューを担当
顧客対応をした	顧客との定例会で要望整理、仕様確認、課題共有を担当

私もSIerで働いていて感じますが、同じ経験でも書き方でかなり印象が変わります。

特に職務経歴書に自信がない人は、応募前に一度プロに見てもらうだけでも、書類通過率を上げやすくなります。

求人ごとにアピール内容を変えられる

転職エージェントを活用すると、求人ごとにアピール内容を変えやすくなります。

たとえば、社内SEを目指すなら業務理解や社内調整力、大手SIerを目指すなら大規模案件やマネジメント経験、ITコンサルを目指すなら課題整理や顧客折衝を強調するべきです。

転職先	強調すべきアピール内容	相性のよいエージェント
社内SE	業務理解、ユーザー対応、運用改善、ベンダー調整	社内SE転職ナビ
大手SIer・ITコンサル	上流工程、PM・PL経験、顧客折衝、案件推進力	TechGo
ITエンジニア全般	開発経験、使用技術、クラウド、設計経験	ＩＴ専門転職エージェント＠ＰＲＯ人
IT・Web・ゲーム業界	技術経験、転職理由、希望職種との相性	ユニゾンキャリア転職

職務経歴書は、1つ作って終わりではありません。

応募先ごとに求められる経験が違うため、求人票を見ながら強調するポイントを変える必要があります。

転職エージェントに相談すれば、求人に合わせてどの経験を前に出すべきか判断しやすくなります。

年収交渉を任せやすい

年収アップを狙うなら、年収交渉を任せやすい点も転職エージェントの大きなメリットです。

自分で企業に希望年収を強く伝えるのは難しいですが、エージェント経由なら現年収、希望年収、経験年数、担当工程をもとに条件交渉してもらえます。

自分で交渉する場合	エージェントに任せる場合
希望年収を伝えにくい	希望年収を事前に共有して交渉してもらえる
相場が分からず低めに伝えてしまう	経験や求人相場をもとに現実的な年収帯を確認できる
内定後に条件交渉しづらい	内定時の条件確認や交渉をサポートしてもらえる

ただし、年収交渉を有利に進めるには、職務経歴書で年収に見合う経験を伝えておく必要があります。

要件定義、設計、顧客折衝、PM・PL経験、クラウド・セキュリティなどの強みを整理したうえで、エージェントに相談しましょう。

SIer転職で年収を上げるなら履歴書より職務経歴書が重要

SIer転職で年収アップを狙うなら、履歴書よりも職務経歴書を優先して作り込むべきです。

履歴書は年齢・学歴・職歴などの基本情報を確認する書類ですが、職務経歴書は「どの案件で、どんな役割を担い、どれだけ成果を出したか」を伝える書類だからです。

比較項目	履歴書	職務経歴書
主な目的	基本情報を伝える	経験・スキル・実績を伝える
見られる内容	学歴、職歴、資格、志望動機	担当工程、案件規模、役割、成果
年収への影響	最低限の確認材料になりやすい	年収交渉や評価に直結しやすい
SIer転職での重要度	ミスなく整えることが重要	市場価値を伝えるために最重要

SIerの転職では、同じエンジニア経験でも運用保守だけを担当していた人と要件定義から設計、顧客折衝まで担当していた人では評価が変わります。

だからこそ、職務経歴書では経験をただ並べるのではなく、年収アップにつながる強みとして整理することが大切です。

履歴書は基本情報、職務経歴書は市場価値を伝える

履歴書では、氏名・住所・学歴・職歴・資格・志望動機など、応募者の基本情報を確認されます。

ここで大切なのは、誤字脱字をなくし、空欄を作らず、読みやすく整えることです。

履歴書だけで大きく差がつくというより、マイナス評価を避けるための書類と考えるとわかりやすいです。

一方で、職務経歴書は市場価値を伝えるための書類です。

SIer経験者なら、担当した工程、開発環境、顧客業界、プロジェクト規模、自分の役割、改善実績などを具体的に書く必要があります。

私もSIerで働いていて感じますが、「何をやったか」だけでなく「どの立場で、どんな成果を出したか」まで言える人は評価されやすいです。

書類	意識すべきポイント
履歴書	基本情報を正確に伝え、書類上の不備をなくす
職務経歴書	経験・スキル・成果を整理し、採用後の活躍イメージを伝える

SIer転職で年収アップを狙う【履歴書】の書き方

SIer転職で年収アップを狙う履歴書では、基本情報を正確に書いたうえで「なぜ転職するのか」「どんなキャリアを実現したいのか」を一貫させることが重要です。

履歴書だけで年収が決まるわけではありませんが、志望動機や転職理由が浅いと、職務経歴書の内容が良くても評価を落とす可能性があります。

項目	書くときのポイント
志望動機	応募先で実現したいキャリアを明確にする
転職理由	年収だけでなく成長・挑戦と結びつける
自己PR	開発経験、顧客対応、課題解決力を伝える
希望条件	年収、職種、働き方、担当工程を整理する

履歴書では、必要以上に立派なことを書く必要はありません。

むしろ、今までのSIer経験と次に目指すキャリアが自然につながっているかが大切です。

職務経歴書で実績を詳しく伝える前提で、履歴書では応募先に対する納得感を作りましょう。

志望動機ではSIerで実現したいキャリアを明確に伝える

志望動機では、応募先の事業内容に触れながら、自分がSIer経験を活かして何を実現したいのかを書くことが大切です。

「貴社に魅力を感じました」だけでは弱く、採用担当者に入社後の活躍イメージが伝わりません。

たとえば、要件定義や設計経験を活かして上流工程に挑戦したい、顧客課題に深く関わりたいなど、キャリアの方向性まで書くと説得力が出ます。

弱い志望動機	改善した志望動機
年収を上げたいから応募しました	SIerでの開発・顧客対応経験を活かし、より上流工程から課題解決に関わりたいと考え応募しました
IT業界で成長したいです	現職で培った設計・調整経験を活かし、より大規模なプロジェクトでPM・PLを目指したいと考えています

転職理由は年収だけでなくスキルアップや上流工程への挑戦と結びつける

転職理由で年収アップを伝えること自体は問題ありません。

ただし、年収だけを前面に出すと「条件だけで転職する人」と見られる可能性があります。

SIer転職では、年収を上げたい理由をスキルアップや担当工程の拡大と結びつけると自然です。

たとえば、運用保守から設計へ、開発メンバーからPLへ、受け身の案件対応から提案型の働き方へ進みたいという流れにすると前向きに伝わります。

転職理由	伝え方の例
年収を上げたい	経験に見合った評価を得ながら、より責任ある工程に挑戦したい
今の仕事が物足りない	開発経験を活かし、要件定義や基本設計にも関わりたい
客先常駐から抜け出したい	長期的にサービスやシステム改善に関われる環境で働きたい

自己PRではシステム開発・顧客対応・課題解決の経験をアピールする

自己PRでは、SIerで培った経験を「応募先で活かせる強み」として伝えましょう。

特に、システム開発、顧客対応、課題解決の経験は評価されやすいです。

アピールする経験	履歴書での書き方
システム開発	JavaやSQLを用いた業務システム開発に携わり、設計からテストまで担当しました
顧客対応	顧客との定例会に参加し、要望整理や仕様調整を行いました
課題解決	テスト工程で発生した課題を整理し、関係者と調整しながら納期内の対応に貢献しました

希望条件には年収だけでなく職種・働き方・担当工程も整理する

希望条件を書くときは、年収だけでなく、職種・働き方・担当工程まで整理しておくことが大切です。

希望年収だけを強く出すと条件面の主張が目立ちますが、担当したい業務やキャリアの方向性まで書けていると、企業側も配属後のイメージを持ちやすくなります。

特にSIer転職では、社内SE、ITコンサル、大手SIer、外資系SIerなどで求められる経験が変わるため、希望条件を明確にしておきましょう。

希望条件	整理しておく内容
年収	現年収、希望年収、最低ラインを分けて考える
職種	SE、PM、PL、社内SE、ITコンサルなどを整理する
働き方	リモート可否、客先常駐の有無、残業時間などを確認する
担当工程	要件定義、設計、開発、運用保守のどこに関わりたいかを明確にする

希望条件は、すべてを履歴書に細かく書く必要はありません。

ただし、転職エージェントとの面談や企業との面接では必ず聞かれます。

応募前に条件を整理しておくと、年収アップを狙いながらも、自分に合わない求人を避けやすくなります。

転職先別に見るSIer職務経歴書のアピール方法

SIerの職務経歴書は、転職先によって強調するポイントを変えるべきです。

大手SIer、外資系SIer、社内SE、ITコンサルでは、同じSIer経験でも評価される部分が異なります。

応募先に合わせて、担当工程・案件規模・顧客対応・マネジメント・業務理解のどれを前に出すか整理しましょう。

転職先	強調すべき経験	職務経歴書での見せ方
大手SIer	大規模案件、PM・PL経験、上流工程	案件規模、担当工程、チーム内の役割を数字で書く
外資系SIer	専門スキル、成果、主体的な改善経験	実績やスキルを簡潔に示し、成果ベースで伝える
社内SE	業務理解、社内調整、運用改善	ユーザー部門との調整やシステム改善経験を書く
ITコンサル	課題整理、要件定義、提案、顧客折衝	技術よりも課題解決プロセスを中心に書く

大手SIerへ転職する場合

大手SIerへ転職する場合は、大規模案件への対応力や上流工程の経験を強調しましょう。

採用担当者は、複数部署・協力会社・顧客を巻き込みながら案件を進められる人材かを見ています。

職務経歴書では、プロジェクト人数、期間、担当工程、チーム内での役割を数字で示すと評価されやすくなります。

アピール項目	書き方の例
案件規模	30名体制の基幹システム刷新プロジェクトに参画
担当工程	基本設計から結合テストまでを担当し、一部仕様調整にも対応
役割	5名チームのサブリーダーとして進捗確認とレビューを担当
実績	レビュー観点を整理し、手戻り削減と品質向上に貢献

社内SEへ転職する場合

社内SEへ転職する場合は、技術力だけでなく、業務理解や社内調整の経験を強調しましょう。

社内SEはシステムを作るだけでなく、ユーザー部門の要望を整理し、既存システムを改善しながら会社全体の業務を支える仕事です。

SIerでの顧客対応や運用改善の経験は、社内SEでも評価されやすいです。

アピール項目	書き方の例
業務理解	顧客業務を理解したうえで、システム改修内容を整理
ユーザー対応	利用部門からの問い合わせ対応や要望整理を担当
運用改善	問い合わせ内容を分析し、FAQや手順書を整備
ベンダー調整	開発会社や社内関係者と連携し、改修スケジュールを調整

社内SE向けの職務経歴書では、「どんな技術を使ったか」だけでは弱いです。

業務部門とどう関わったか、システム改善にどう貢献したかまで書くと、入社後の活躍イメージが伝わります。

ITコンサルへ転職する場合

ITコンサルへ転職する場合は、開発経験そのものよりも、課題整理・要件定義・提案・顧客折衝の経験を強調しましょう。

ITコンサルは、顧客の課題を整理し、解決策を考え、システムや業務改善の方向性を示す仕事です。

SIerで上流工程や顧客対応を経験している人は、職務経歴書でその強みを前に出すべきです。

アピール項目	書き方の例
課題整理	顧客からの要望を整理し、業務課題とシステム課題に分けて整理
要件定義	ヒアリング内容をもとに、必要機能や業務フローを整理
提案経験	運用負荷を下げるための改善案を作成し、関係者へ説明
顧客折衝	顧客との定例会で課題、進捗、仕様変更の影響を説明

ITコンサル向けに書くときは、単なる開発担当者に見えないように注意しましょう。

どのように課題を見つけ、関係者と調整し、解決策につなげたのかを具体的に書くことが大切です。

技術を理解したうえで顧客課題を整理できる点は、SIer出身者の強みになります。

自社開発企業を目指す場合

自社開発企業を目指すなら、職務経歴書では受託開発の経験を「自分で考えてプロダクトを改善した経験」へ言い換えることが重要です。

自社開発企業では、決められた仕様どおりに作る力だけでなく、ユーザーの課題を理解し、開発後も継続的に改善できる人材が評価されます。

そのため、担当工程や使用技術に加えて、仕様の背景を考えた経験、改善提案、リリース後の効果まで記載しましょう。

SIerでの経験	自社開発向けのアピール方法
顧客の要望に沿って開発した	ユーザーの課題や利用目的を整理し、仕様へ反映した
既存機能を改修した	影響範囲を調査し、品質を保ちながら機能改善を進めた
テストを担当した	ユーザーの利用場面を想定し、異常系や操作性まで確認した
運用保守を担当した	問い合わせや障害を分析し、機能・運用の改善につなげた
他チームと調整した	開発、インフラ、業務担当者と連携して課題を解決した

記載例は以下のとおりです。

業務システムの既存機能改修において、利用部門から寄せられた問い合わせ内容を分析し、操作手順が分かりにくい箇所を特定しました。開発チームと改善方法を検討し、入力画面の表示内容とエラーメッセージを修正した結果、同機能に関する問い合わせ件数を約30％削減しました。

自社開発企業では、JavaやPythonなどの技術名だけでなく、Gitを使ったチーム開発、コードレビュー、CI/CD、クラウド、アジャイル開発の経験も評価されやすくなります。

外資系SIerへ転職する場合

外資系SIerへ転職する場合は、担当業務を細かく並べるよりも、専門スキルと成果を分かりやすく伝えることが大切です。

外資系は成果やスキルの再現性を重視されやすいため、「何を担当したか」だけでなく「何を改善したか」「どんな技術を使えるか」を明確に書きましょう。

アピール項目	書き方の例
専門スキル	AWS環境での運用監視、ログ確認、障害一次対応を担当
成果	問い合わせ対応フローを見直し、対応漏れの削減に貢献
主体性	既存手順の課題を整理し、改善案をチーム内に提案
英語・グローバル対応	英語資料の確認や海外メンバーとのやり取り経験があれば記載

外資系SIerを狙うなら、職務経歴書はできるだけ成果ベースで書くのがおすすめです。

たとえば「運用を担当」ではなく「障害対応フローを整理し、対応スピード改善に貢献」と書くと、主体的に動ける印象になります。

数字で示せる実績があれば、必ず入れましょう。

SIer転職の履歴書・職務経歴書でやってはいけないNG例

SIer転職で年収アップを狙うなら、履歴書・職務経歴書で「何をしてきた人なのか」が伝わらない書き方は避けるべきです。

担当工程があいまいだったり、プロジェクト名だけを書いたりすると、経験の深さや市場価値が採用担当者に伝わりません。

NG例	採用担当者に伝わりにくい理由	改善ポイント
担当工程があいまいになっている	どこまで任せられる人材か判断できない	要件定義・設計・開発・運用保守に分けて書く
プロジェクト名だけで実績が伝わらない	役割や成果が見えない	案件規模・担当範囲・成果を数字で書く
資格だけを強くアピールしている	実務で何ができるか分かりにくい	資格と実務経験をセットで伝える
希望年収だけが先行している	条件面だけで転職する印象になる	年収に見合う経験・スキル・貢献内容を書く

担当工程があいまいになっている

担当工程があいまいな職務経歴書は、SIer転職ではかなりもったいないです。

「システム開発に従事」「プロジェクトに参画」とだけ書いても、要件定義から関わったのか、開発だけなのか、運用保守中心なのかが伝わりません。

特に年収アップを狙う場合、上流工程や設計経験の有無は重要な判断材料になります。

NGな書き方	改善した書き方
業務システム開発に参画	販売管理システムの基本設計、詳細設計、開発、単体テストを担当
運用保守を担当	問い合わせ対応、障害一次対応、月次レポート作成、改善提案を担当

職務経歴書を書くときは、まず自分の経験を工程ごとに分けて棚卸ししてください。

担当工程を明確にするだけで、採用担当者が経験レベルを判断しやすくなります。

プロジェクト名だけで実績が伝わらない

プロジェクト名だけを書いても、採用担当者には実績が伝わりません。

たとえば「基幹システム刷新プロジェクト」と書くだけでは、案件の規模も、自分の役割も、成果も分からないからです。

SIer転職では、案件名よりも「どの立場で、何を担当し、どう貢献したか」が見られます。

項目	書くべき内容
案件規模	期間、人数、利用者数、対象業務などを書く
自分の役割	メンバー、サブリーダー、PL、PMOなどを明確にする
実績	工数削減、品質改善、納期遵守、障害削減などを書く

たとえば「20名体制の基幹システム刷新案件で、詳細設計から結合テストまで担当し、レビュー観点の整理により手戻り削減に貢献」と書くと、経験の具体性が一気に増します。

資格だけを強くアピールしている

資格だけを強くアピールする書き方も避けましょう。

ITパスポート、基本情報技術者、応用情報技術者、AWS資格などは評価材料になりますが、資格名だけでは実務で何ができるのか分かりません。

SIer転職で年収アップを狙うなら、資格よりも実務経験とのつながりを見せることが大切です。

NGな書き方	改善した書き方
AWS資格を取得しています	AWS資格で学んだ知識を活かし、クラウド環境の運用監視やログ確認に携わりました
基本情報技術者を取得しています	基本情報技術者で学んだ知識を土台に、JavaとSQLを用いた業務システム開発を担当しました

資格はあくまで補強材料です。

職務経歴書では資格を持っている人ではなく、「実務で使える人」と伝わるように書きましょう。

希望年収だけが先行している

希望年収だけが先行している書類も、採用担当者には良い印象を与えにくいです。

もちろん年収アップは大切ですが、書類上で条件面ばかりが目立つと「なぜその年収を希望するのか」が伝わりません。

年収を上げたいなら、その金額に見合う経験・スキル・貢献内容をセットで示す必要があります。

避けたい伝え方	改善した伝え方
希望年収は〇〇万円です	基本設計から開発、顧客折衝まで担当してきた経験を活かし、より責任あるポジションで貢献したいと考えています
年収アップを目的に転職したいです	担当工程を広げ、PM・PLに近い立場で案件推進に関わりたいと考えています

希望年収は、履歴書や職務経歴書で強く主張しすぎるより、転職エージェントや面接の場で調整するほうが現実的です。

まずは書類で、自分を採用するメリットを伝えましょう。

SIer転職の履歴書・職務経歴書に関するよくある質問

SIer転職の履歴書・職務経歴書では、書き方に迷いやすいポイントがいくつかあります。

特に、経験が浅い場合や年収アップを狙う場合は「何をどこまで書くべきか」で悩みやすいです。

ここでは、SIer転職でよくある質問に回答します。

質問	結論
履歴書と職務経歴書はどちらが重要ですか？	年収アップを狙うなら職務経歴書がより重要です
経験が浅くても職務経歴書でアピールできますか？	担当工程や工夫した点を書けばアピールできます
資格はどれくらい書くべきですか？	実務経験と関連する資格を中心に書きましょう
希望年収は履歴書に書くべきですか？	基本的には面談や面接で伝えるのがおすすめです
職務経歴書は求人ごとに変えるべきですか？	応募先に合わせて強調する経験を変えるべきです

SIer転職では履歴書と職務経歴書のどちらが重要ですか？

SIer転職で年収アップを狙うなら、履歴書よりも職務経歴書のほうが重要です。

履歴書は氏名、学歴、職歴、資格などの基本情報を確認する書類ですが、職務経歴書は担当工程、案件規模、役割、成果を伝える書類です。

特にSIer経験者の場合、要件定義、設計、開発、運用保守、顧客折衝、マネジメント経験などをどう書くかで評価が変わります。

履歴書はミスなく整え、職務経歴書で市場価値をしっかり伝えましょう。

SIer経験が1～2年でもアピールできますか？

SIer経験が浅くても、職務経歴書で十分アピールできます。

大切なのは、経験年数の長さではなく「どの工程を担当し、どんな工夫をしたか」を具体的に書くことです。

運用保守やテスト中心でも、問い合わせ対応、障害対応、手順改善、課題整理の経験は評価対象になります。

たとえば「テストを担当」だけでなく「テスト観点を整理し、検出した不具合を開発担当へ共有した」と書くと、主体的に動いた印象になります。

経験が浅い人ほど、担当範囲を具体的に書きましょう。

SIer転職で資格は履歴書・職務経歴書にどれくらい書くべきですか？

資格は、応募先の業務に関係するものを中心に書きましょう。

ITパスポート、基本情報技術者、応用情報技術者、AWS認定資格、Azure関連資格、情報処理安全確保支援士などは、SIer転職でもアピール材料になります。

ただし、資格だけを強く押し出すのは避けたほうがよいです。

採用担当者が見たいのは「資格を持っているか」だけでなく「実務で何ができるか」です。

資格名に加えて、開発、設計、運用、クラウド、セキュリティなどの実務経験と結びつけて書きましょう。

開発予算は職務経歴書に書くべきですか？

開発予算は、PM・PL・PMOとして予算や工数管理に関わった場合に書くのがおすすめです。

案件規模と責任範囲が伝わりやすくなり、マネジメント経験の説得力も高まります。

一方、予算を正確に把握していない場合や、管理に関与していない場合は無理に記載する必要はありません。

推測した金額を書くのは避け、「数千万円規模」「数億円規模」「全体100名以上の大規模案件」など、把握している範囲で表現しましょう。

記載する場合は、金額だけでなく自分の役割までセットで書きます。

約5,000万円規模の開発案件で、月次の工数実績と見込みを確認し、予算超過リスクの管理を担当しました。

契約金額や顧客との取り決めが機密情報に当たる可能性もあるため、具体的な金額を出してよいか判断できない場合は、規模を一般化するのが安全です。

顧客名や常駐先の会社名は書いてもよいですか？

顧客名や常駐先の会社名は、原則として職務経歴書へ実名で書かず、業界や企業規模が分かる表現に置き換えましょう。

たとえば、「株式会社〇〇向けシステム」ではなく、「大手通信事業者向け監視システム」「金融機関向け基幹システム」「大手製造業向け業務システム」と記載します。

正式なシステム名や未公開プロジェクト名、個人情報、具体的な契約内容も書かないよう注意が必要です。

書かないほうがよい表現	書き換え例
株式会社〇〇の社内システム	大手製造業向け社内業務システム
〇〇銀行の勘定系更改	金融機関向け基幹システム更改
株式会社〇〇へ常駐	大手通信事業者の開発拠点に常駐
〇〇システムという正式名称	通信設備向け監視システム