36歳でエンジニア転職を考える場合、職務経歴書では「どんな技術を使ってきたか」だけでは評価されにくくなります。
36歳前後でSIerや受託開発から社内SEを目指すなら、職務経歴書には使用技術や担当工程だけでなく、「どの範囲を任され、誰と調整し、何を改善したか」まで書く必要があります。
社内SEは、自社の業務を理解し、関係者と調整しながらシステムを安定して動かす役割です。
そのため、要件定義・顧客折衝・保守運用・障害対応といったSE経験は、見せ方を変えることで十分に評価されます。
実際に私は36歳からキャリアを見直し、38歳で社内SEに転職を経験しました。
この記事では、36歳前後のエンジニアが社内SEを目指す際に、職務経歴書で何をどう整理すべきかを解説します。
とんび（管理者）の転職歴まとめ
- 23歳：年収200万円 コールセンター（契約社員）を経て、IT派遣会社で勤務開始
- 25歳：年収380万円 大手POS開発・運用会社に転職
- 30歳：年収450万円 自社アプリ開発・運用会社に転職
- 31歳：年収360万円 研究関連の事務サポート（契約社員）
- 32歳：年収470万円 中堅SIerに転職。派遣やSES（技術派遣と客先常駐のITサポート）として勤務
- 38歳：年収700万円 地方創成企業に転職。管理職（40歳以降はシステム開発責任者）として勤務
※年収は40時間/月残業時の提示金額
36歳エンジニアの職務経歴書で見られるポイント
36歳の転職では、20代のように「経験を積ませれば伸びそう」という見られ方だけでは通用しにくくなります。
企業側は、入社後にどの役割を任せられるか、現場で再現性のある経験を持っているかを見ています。
社内SEとして入社した後に、どの業務を任せられるか採用側がイメージできる職務経歴書にすることが重要です。
技術環境・担当工程に加えて「任された範囲」も見られる
36歳の職務経歴書では、担当工程や使用技術だけを並べても弱く見えます。
企業側は、あなたがどのような立場で案件に関わり、どの範囲を任されてきたのかを見ています。
たとえば「Javaで開発を担当」と書くだけでは、業務の中でどのような役割を担ったのかが伝わりません。
一方で、「顧客要望を整理し、改修方針を検討したうえで開発を担当」と書けば、業務理解や判断力まで伝わります。
36歳では、単に手を動かせることよりも、周囲と連携して仕事を進められることが評価されます。
職務経歴書では、技術力に加えて、任せられた役割や判断した場面を見せる必要があります。
PL・PM経験がなくても調整・改善経験は評価材料になる
36歳で転職を考える人の中には、明確なPLやPM経験がなく不安に感じる人も多いはずです。
しかし、社内SEで求められるのは、利用部門やベンダーと調整しながら業務を進める力です。
たとえば、会議で要望を整理した、問い合わせ内容を分類した、顧客やベンダーとの認識合わせをした経験は、社内SEでも活かせます。
PLと記載できる経験がなくても、実際に担った調整や改善の範囲を具体的に示すことで、評価につなげることが可能です。
採用側は36歳エンジニアの職務経歴書のどこを見るか
職務経歴書は、経験を並べるための書類ではありません。
採用側に「この人なら入社後にこの役割を任せられそうだ」と思ってもらうための書類です。
36歳エンジニアの場合、採用側は技術だけでなく、業務理解・調整・改善・再現性を見ています。
技術スタックより、業務との接点があるか
採用側は、技術スタックだけを見ているわけではありません。
その技術をどの業務で使い、どのような課題解決につなげたのかを見ています。
社内SEは、業務とシステムの間に立つ職種です。
そのため、業務との接点が見えない職務経歴書は、社内SE向けとしては弱くなります。
年齢相応に、改善・調整・再発防止まで考えられるか
36歳の転職では、指示された作業をこなすだけでは評価されにくくなります。
採用側は、課題を見つけ、改善し、同じ問題を繰り返さない視点があるかを見ています。
年齢相応の強みは、必ずしも管理職経験だけではありません。
改善・調整・再発防止まで考えた経験を示すことで、36歳らしい価値を伝えられます。
社内SEとして入社後の役割がイメージできるか
採用側が最後に見るのは、入社後のイメージです。
職務経歴書を読んだときに、「この人は自社でどの業務を任せられそうか」が見える必要があります。
職務経歴書は、過去の説明で終わってはいけません。
過去の経験を、応募先でどう活かせるかまで伝えることで、選考での説得力が高まります。
面接で聞かれやすい質問や回答の考え方は、「36歳エンジニア転職の面接で聞かれる質問｜評価される答え方とNG回答」で詳しく整理していますので、こちらもあわせてご確認いただければと思います。
SIerの案件経験を7項目で棚卸しする
職務経歴書を書く前に、まずは過去の案件を棚卸しします。
案件名と担当工程だけでなく、責任範囲や判断したことまで整理すると、職務要約や自己PRに使える材料が見つかります。
経験は、以下の7項目で整理するとまとめやすいです。
- 規模：案件期間、チーム人数、利用者数、対象部署、システム規模など。
- 担当工程：要件定義、基本設計、詳細設計、開発、テスト、保守運用など。
- 責任範囲：自分がどこまで任されていたか。
- 関係者：顧客、利用部門、営業、開発者、運用担当、協力会社、ベンダーなど。
- 判断したこと：自分で優先順位を決めた、対応方針を提案した、影響範囲を切り分けたなど。
- 工夫：認識ずれを防いだ、手順を見直した、進め方を変えた、資料を整理したなど。
- 結果：納期内に完了した、問い合わせが減った、障害の再発を防いだ、作業負担を軽減したなど。
案件ごとに「規模」・「工程」・「責任範囲」を整理する
まず、案件期間、チーム人数、利用部門、担当工程、使用技術などの基本情報を整理します。
そのうえで、指示された作業だけでなく、自分が責任を持った範囲を書き出します。
棚卸しする項目は、すべての案件を詳しく書く必要はなく、直近の案件や応募先との接点が強い案件を優先しましょう。
「関係者」・「自分の判断」・「工夫」を具体化する
社内SEでは、利用部門、経営層、ベンダー、開発担当など、立場の異なる人と関わります。
SIerで顧客、営業、開発、運用、協力会社の間に立った経験があれば、関係者を具体的に整理します。
また、どの場面で自分が判断したかも重要です。
仕様の優先順位を整理した、障害の影響範囲を確認した、遅延リスクを早めに共有したなど、実際に考えて動いた経験を拾いましょう。
「成果」は数字だけでなく対象範囲でも示せる
成果を数値で示せる場合は、作業時間、問い合わせ件数、障害件数などを記載すると具体性が高まります。
一方で、正確な削減率や金額が分からない場合に、数字を推測して作ってはいけません。
数値化が難しい場合は、利用人数、対象部署数、担当システム数、案件期間、関係者数などでも経験の規模を示せます。
「複数部門の要望を整理した」「月数十件の問い合わせに対応した」など、確認できる範囲で書きましょう。
社内SE向け職務経歴書の構成と書き方
棚卸しした経験は、職務要約、職務経歴、活かせるスキル、自己PRへ配置します。
同じ経験を繰り返すのではなく、各項目の役割を分けることで、採用側が短時間で内容を理解しやすくなります。
①職務要約では社内SEで活かせる経験を先に示す
職務要約は、これまでの経歴を数行で説明する場所です。
会社名や案件を順番に並べるのではなく、経験年数、得意領域、応募先で活かせる役割を先に示します。
たとえば、「SIerで業務システムの設計・開発・保守を経験し、顧客部門との要件整理や障害対応も担当」とまとめます。
最後に「これらの経験を活かし、利用部門と開発側をつなぐ社内SEを目指す」とつなげると、転職理由との一貫性が出ます。
②職務経歴では案件概要より自分の役割を詳しく書く
案件欄には、プロジェクトの目的、期間、規模、技術環境、担当工程を記載します。
ただし、システムの説明を長くするより、自分が何を任され、どのように動いたかを詳しく書きます。
「販売管理システムの開発」だけではなく、「利用部門の要望整理、仕様調整、設計、障害発生時の原因切り分けを担当」と記載します。
応募先に近い経験ほど、工夫や結果まで具体的に説明しましょう。
活かせるスキルは技術と業務経験を分けて書く
活かせるスキルでは、開発言語やOSなどの技術と、要件整理やベンダー調整などの業務経験を分けます。
技術だけを並べるより、社内SEとして何ができるかが伝わりやすくなります。
技術面には、言語、データベース、クラウド、担当可能な工程などを記載します。
業務面には、顧客折衝、障害対応、業務改善、進捗管理、後輩支援など、複数の案件で使った経験をまとめます。
自己PRでは複数案件に共通する強みを伝える
自己PRでは、単発の成果ではなく、複数の案件で繰り返し発揮した強みを伝えます。
「コミュニケーション力があります」と書くのではなく、どのような場面で発揮したかを具体化します。
たとえば、顧客と開発担当の認識差を整理し、仕様確定を支援した経験が複数あるなら、調整力としてまとめられます。
強みを示した後に、社内SEとしてどのように活かすかまで書くと、自己PRが応募先につながります。
【例文】SIer経験を社内SE向けに言い換える
職務経歴書で最も重要なのは、経験を「社内SEに伝わる言葉」に変換することです。
同じ経験でも、書き方によって作業者に見える場合と、社内SEで活躍できる人に見える場合があります。
要件定義・顧客折衝の書き換え例
要件定義や顧客折衝は、社内SEにとって重要な経験です。
単に「顧客と要件調整を行った」と書くのではなく、相手の要望を整理し、実現可能な形に落とし込んだ経験として表現しましょう。
▼伝わらない書き方
- 顧客要望をもとに仕様を作成した
- 要件定義を担当した
- 顧客との打ち合わせに参加した
▼評価されやすい書き方
- 顧客部門の業務課題をヒアリングし、要望の背景と優先度を整理したうえで仕様に反映した
- 現場運用を確認し、業務フローに沿った機能要件・非機能要件の整理を担当した
- 顧客・開発メンバー間の認識差を整理し、仕様確定までの調整を担当した
設計・開発経験の書き換え例
設計・開発経験は、社内SE転職でも強みになります。
ただし、開発言語や担当機能だけを書くのではなく、業務要件を理解したうえで設計・改修したことを示す必要があります。
▼伝わらない書き方
- Javaで画面開発を担当した
- 詳細設計と実装を担当した
- 機能追加を行った
▼評価されやすい書き方
- 業務要件を踏まえ、入力ミスを減らす画面改修を担当した
- 保守性と運用時の確認しやすさを考慮し、設計・実装を担当した
- 現場からの改善要望をもとに、業務効率化につながる機能追加を実施した
保守運用・障害対応の書き換え例
保守運用や障害対応は、社内SEとの親和性が高い経験です。
原因切り分け、関係者連絡、影響範囲確認、再発防止まで書くことで、安定運用を支えた経験として伝わります。
▼伝わらない書き方
- 障害対応を担当した
- 問い合わせ対応を行った
- 保守作業を担当した
▼評価されやすい書き方
- 障害発生時に影響範囲を確認し、原因切り分けから暫定対応・再
- 問い合わせ内容を分類し、頻出課題を整理して運用手順の改善につなげた
- 定常保守に加え、運用上の課題を抽出し、作業手順の見直しを行った
SIer経験を社内SE向けに整理するには、社内SEが情シス部門でどのような役割を担うのかを理解しておく必要があります。
仕事内容の全体像を確認したい方は、「情シスの役割を完全解説｜運用・ガバナンス・社内開発まで整理」も参考にしてみてください。
応募先の社内SEタイプ別に職務経歴書を出し分ける
社内SEといっても、会社によって仕事内容は大きく違います。
同じ職務経歴書を使い回すと、応募先の期待とズレてしまうことがあります。
情シス・運用寄りなら、安定運用と問い合わせ対応を強調する
情シス・運用寄りの社内SEでは、システムを安定して使える状態に保つ力が重視されます。
そのため、保守運用、障害対応、問い合わせ対応、手順整備の経験を前に出しましょう。
SIer出身者の場合、保守運用の経験を軽く扱ってしまうことがあります。
しかし、社内SE求人では、むしろ安定運用を支えた経験が評価されることがあります。
業務改善・DX寄りなら、要件整理と改善提案を強調する
業務改善・DX寄りの社内SEでは、現場課題を整理し、システムやツールで改善する力が求められます。
このタイプでは、要件定義や改善提案の経験を前に出すべきです。
大きなDX案件でなくても、手作業の削減、入力ミスの防止、集計業務の効率化などに関わった経験があれば十分です。
「何を改善したか」だけでなく、「なぜ改善が必要だったか」まで書くと説得力が出ます。
開発寄り社内SEなら、設計・開発経験を前に出す
開発寄りの社内SEでは、SIerでの業務そのものが強みになります。
特に、自社システムの改修や内製化を進める企業では、開発経験者が評価されやすいです。
ただし、開発言語だけを強調しても不十分です。
業務要件を理解し、保守性や運用負荷を考えながら設計・改修した経験として書く必要があります。
ベンダー管理寄りなら、顧客折衝・進行管理経験を活かす
ベンダー管理寄りの社内SEでは、自分で開発する力よりも、外部ベンダーと調整しながら案件を進める力が求められます。
SIer時代に顧客や協力会社と調整した経験があれば、活かしやすい領域です。
職務経歴書では、仕様調整、見積確認、進捗管理、課題管理、受入テストなどの経験を整理しましょう。
ベンダー側で働いていた経験は、社内側からベンダーを動かす際にも役立ちます。
社内SEは、開発寄り・保守運用寄り・ヘルプデスク寄りなど、担当領域によって求められるスキルが変わります。
領域ごとに必要とされるスキルは「社内SEに必要なIT基礎スキル｜転職前に押さえたい実務知識」で整理していますので、応募先ごとのスキルの違いを整理したい方はぜひ参考にしてみてください。
まとめ｜36歳エンジニア転職で失敗しないための3つのポイント
36歳エンジニアが社内SEを目指す場合、職務経歴書では技術力だけでなく、任せられる役割を伝える必要があります。
SIerでの要件定義・顧客折衝・開発・保守運用は、見せ方を変えることで社内SE向けの強みになります。
大切なのは、SE経験をそのまま並べるのではなく、社内SEの評価軸に合わせて翻訳することです。
求人タイプに合わせて、業務理解・調整力・改善力・安定運用の経験として整理すると、採用側に伝わりやすくなります。
①SIer経験はそのまま書かず、業務理解・調整力・改善力に変換する
SIer経験は、社内SE転職で十分に活かせます。
ただし、開発工程や使用技術だけを並べると、社内SEでの再現性が伝わりにくくなります。
要件定義は業務課題の整理、顧客折衝は社内調整、開発経験は改善提案、保守運用は安定稼働の経験として書き換えましょう。
②マネジメント経験がなくても、調整役・改善役の経験は評価される
36歳でマネジメント経験がない場合でも、評価される経験はあります。
正式な役職ではなくても、現場で調整役や改善役として動いた経験があれば、職務経歴書に書くべきです。
会議での論点整理、仕様調整、問い合わせ分類、進捗確認、ベンダー連携などは、社内SEでも活かせる経験です。
自分の経験を小さく見せず、任せられる役割として整理しましょう。
③社内SE求人のタイプに合わせて、前に出す経験を変える
社内SE求人は、会社によって求められる役割が違います。
運用寄り、開発寄り、DX寄り、ベンダー管理寄りでは、職務経歴書で強調すべき経験も変わります。
すべての求人に同じ職務経歴書を出すのではなく、応募先ごとに前に出す経験を調整しましょう。
36歳の転職では、経験の量よりも、応募先に合わせて経験を選び直す力が重要です。
職務経歴書は、36歳エンジニア転職における重要な準備のひとつです。
ただし、実際の転職活動では、応募先の選び方、面接対策、年収や働き方の判断軸まで含めて整理しておく必要があります。
転職活動全体の流れを確認したい方は、「36歳からエンジニア転職ロードマップ」もあわせて参考にしてみてください。