SES経験は社内SEの職務経歴書でどう書く？業務別の言い換え例

※本サイトはアフィリエイト広告（Amazonアソシエイト含む）を掲載しています。

SESで職務経歴書を書こうとすると、ちょっと困ることがあります。

案件名。

期間。

使用技術。

担当工程。

やったこと自体は書ける。

でも並べてみると、

運用保守を担当
問い合わせ対応
テスト実施
顧客との調整

……なんか弱い。

別に何もしていなかったわけではないのに、文章にすると妙に薄く見えるんですよね。

これはSES経験そのものが弱いというより、「何をやったか」だけ書いて、「その経験を次の会社でどう使えるか」が見えていないことが原因かもしれません。

社内SEへの転職を考えるなら、職務経歴書でも少し見せ方を変えたほうがいいです。

ただし、盛る必要はありません。

やっていないことを「要件定義しました」「リーダーしました」に変換すると、それは言い換えではなく錬金術です……。

この記事では、SESでありがちな経験をどう整理すると社内SE側へ伝わりやすくなるのか、具体例で見ていきます。

そもそもSESから社内SEへ移ると仕事内容や働き方がどう変わるのかは、こちらで整理しています。
→ 内部リンク：『SESから社内SEへ転職すると何が変わる？仕事内容・年収・働き方を比較』

まず「作業名」だけ書くのをやめる

たとえば、

システムの運用保守を担当

これだけだと、採用側には実態がほとんど分かりません。

何のシステムなのか。

利用者は何人くらいなのか。

どんな問い合わせがあったのか。

障害時にどこまで対応したのか。

改善したことはあるのか。

このあたりが抜けています。

なので、わたしならSESの経歴を書くときは、

何を担当したか
+
どんな環境だったか
+
自分がどう動いたか
+
その結果どうなったか

の4つで考えます。

結果といっても、必ず数字が必要なわけではありません。

「問い合わせ手順を整理した」
「エスカレーション条件を明文化した」
「関係者との確認漏れを減らした」

くらいでも十分です。

どの経験を強く見せるかは、応募する社内SE求人の仕事内容によっても変わります。求人票の見方はこちらで詳しくまとめています。
→ 内部リンク：『社内SEの求人票で見るべきポイント7つ｜入社後に「思ってたのと違う」を減らす』

運用保守は「ただ維持していた」で終わらせない

SESだと運用保守経験はかなり多いと思います。

でも、

基幹システムの運用保守を担当

だけだと、何をしていたのか分かりません。

Before

業務システムの運用保守、問い合わせ対応を担当。

After

約○○名が利用する業務システムの運用保守を担当。
利用部門からの問い合わせ一次切り分け、ログ確認、障害時の開発担当へのエスカレーション、定期作業を実施。
頻発する問い合わせについて手順を整理し、チーム内で共有した。

これなら、

利用者対応
障害切り分け
関係者連携
業務改善

が見えます。

社内SEでもこの辺は普通に使う経験です。

特に社内システムの運用担当では、技術だけではなく「利用者から何が起きているか聞き出す」能力が必要になります。

運用保守、地味に見えるけど結構使えます。

顧客調整は「会議に参加した」では弱い

SESでは客先担当者や他チームとの調整も多いです。

ただ、

顧客との定例会に参加

では、ほぼ出席記録です。

Before

顧客との定例会参加、進捗報告。

After

顧客担当者との定例会で担当タスクの進捗・課題を報告。
仕様確認が必要な事項について、開発チームと顧客側の認識差を整理し、確認事項を取りまとめた。

これなら、単なる会議参加ではなく、

説明
調整
認識合わせ

をしていたことが見えます。

社内SEは、IT部門以外との調整がかなり増えることがあります。

営業、人事、経理、総務。

相手が必ずしもITに詳しいとは限りません。

なのでSES時代の顧客調整経験は、割とそのまま転用できます。

障害対応は「復旧した」までの流れを書く

障害対応も書き方次第でかなり印象が変わります。

Before

システム障害対応。

After

システム障害発生時にログ・監視情報を確認し、影響範囲を切り分け。
開発担当およびインフラ担当と連携して復旧対応を実施し、対応後は原因・対処内容を記録した。

これなら、

状況把握
→
切り分け
→
連携
→
復旧
→
記録

という動きが見えます。

社内SEでも障害時に「全部自分で直せる」必要はありません。

むしろ、

誰へ繋ぐべきか判断できる
影響範囲を整理できる
利用者へ状況を説明できる

あたりが大事になるケースもあります。

テスト経験は「テスト実施」で終わらせない

SESだとテスト工程を長く担当した人もいると思います。

そして職務経歴書には、

結合テスト実施

だけ。

これはかなりもったいないです。

Before

結合テスト、システムテストを担当。

After

業務仕様をもとに結合テスト・システムテストを実施。
不具合発生時は再現条件、入力値、発生画面などを整理して開発担当へ連携。
修正後の再テストまで担当した。

これだけでも、

仕様理解
不具合分析
他担当への情報伝達

が見えるようになります。

もしテストケース作成までやっていたなら、その点も書けます。

逆に、実施だけだったのに「テスト設計」と書くのはやめましょう。

面接で掘られた瞬間、爆発します。

ヘルプデスク経験も社内SEでは普通に使える

「問い合わせ対応ばっかりだったから、アピールすることがない」

と思う人もいるかもしれません。

でも社内SE求人を見ると、問い合わせ対応が含まれる会社は普通にあります。

Before

ユーザーからの問い合わせ対応。

After

ユーザーからのシステム利用・アカウント・操作に関する問い合わせに対応。
内容を分類し、自チームで解決可能なものと開発・インフラ担当へのエスカレーションが必要なものを切り分けた。

さらに、

問い合わせ履歴をもとにFAQを更新

までやっていれば、業務改善としても書けます。

社内SEって、結局「使う人」と距離が近いです。

なので利用者対応の経験は、思っているより相性がいいかもしれません。

手順書作成は「ドキュメント作りました」で終わらせない

SESでは手順書を作る機会も多いです。

Before

運用手順書作成。

After

属人化していた定期運用作業について、実施条件・手順・異常時の確認先を整理した手順書を作成。
チーム内で共有し、担当者以外でも作業できる状態にした。

もし実際にそこまでやっているなら、かなり良いです。

社内SEでは、

「この作業、○○さんしか分かりません」

が普通に発生します。

あれは地味に怖い。

なので手順化・標準化の経験はちゃんと武器になります。

SES経験 → 社内SE向けの見せ方をまとめる

ざっくり整理するとこんな感じです。

SESでありがちな経験	そのまま書くと	見せたい能力
運用保守	運用を担当	障害切り分け、利用者対応、改善
顧客調整	定例会参加	認識合わせ、要望整理、説明
障害対応	障害対応	状況把握、影響確認、関係者連携
テスト	テスト実施	仕様理解、不具合整理、品質確認
ヘルプデスク	問い合わせ対応	ヒアリング、切り分け、説明
手順書	資料作成	標準化、属人化解消
ベンダー連携	他社と連携	外部調整、進行確認

ただし注意したいのは、

社内SE向けに都合のいい言葉へ変えること

ではありません。

自分が実際にやった仕事の中から、社内SEでも再現できそうな能力を抜き出すという考え方です。

数字を入れられるところは入れる

可能なら数字も入れます。

たとえば、

問い合わせ対応を担当

より、

月平均約30〜40件の問い合わせに対応

のほうが仕事量が分かります。

ほかにも、

• 利用ユーザー数
• チーム人数
• 担当期間
• サーバー台数
• 拠点数
• 問い合わせ件数
• プロジェクト人数

など。

ただし、覚えていない数字を作る必要はありません。

「多分100人くらいだったかな……」

を確定値として書くのは危ないです。

分からないなら書かない。

また、顧客情報や機密情報をそのまま書かないのも当然です。

「成果」がないなら工夫を書く

職務経歴書の記事を見ると、

成果を書きましょう

と言われがちです。

とはいえSESだと、

「売上を20％アップしました！」

みたいな成果、そんな毎案件で出ないです。

なので成果が分かりにくいなら、工夫したことを書けばいいと思っています。

たとえば、

障害時に必要な情報が毎回不足していたため、確認項目をテンプレート化した。

とか、

新規参画者向けに環境構築手順を整理した。

とか。

派手ではないです。

でも実務って、だいたいこういう小さい改善の積み重ねです……。

職務経歴書は「全部書く」必要はない

SESで長く働いていると、案件数がかなり増えることがあります。

全部同じ文字量で書くと、すごい長さになります。

なので応募先が社内SEなら、

社内SEと関係が深い案件を厚めに
関係が薄い案件は簡潔に

くらいでいいです。

たとえば、

運用保守
顧客調整
ベンダー連携
障害対応

の経験は比較的詳しく書く。

逆に短期のテスト案件などは、必要以上に膨らませない。

履歴書ではなく、応募先へ自分の経験を説明する資料なので、全部均等にする必要はありません。

まだ「そもそもSESを辞めるべきか」で迷っているなら、転職準備を始める前に一度整理しておくとラクです。
→ 『SESを辞めたいけど転職すべき？まず整理したい3つのこと』

職務経歴書に書いた内容は、面接で具体的に聞かれる前提で準備しておくと安心です。SES経験者が聞かれやすい質問と逆質問はこちらにまとめました。
→「SESから社内SEへ転職する面接で聞かれること・逆質問10例」

応募先が社内SEか自社開発かでも、職務経歴書で強調したい経験は変わります。どちらが合うか迷っている場合はこちらで比較しています。
→「社内SEと自社開発、SES経験者はどっちが向いてる？仕事内容・働き方・向き不向きを比較」

面接で説明できないことは書かない

最後にこれです。

職務経歴書を書いていると、

「もう少し強く見せたいな」

という誘惑があります。

分かります。

ただ、書いた内容は面接で普通に聞かれます。

「ベンダーコントロールとありますが、具体的には何をしましたか？」

と聞かれて、

「あ、えっと……メールをCCで見てました」

になると厳しいです。

なので、

自分が担当した
自分で説明できる
具体例を一つ話せる

この3つを満たす範囲で書く。

それで十分だと思います。

まとめ：SES経験は「次でも使える形」に翻訳する

SES経験を社内SE向けの職務経歴書に書くときは、

単に、

運用保守
テスト
問い合わせ対応

と作業名を並べるだけでは、ちょっと伝わりにくいです。

その仕事で、

何を見て
誰と関わって
どう判断して
どう動いたのか

まで一段掘る。

すると、

「SESでやっていた仕事」

から、

「社内SEでも使えそうな経験」

へ見え方が変わります。

別に経歴そのものを変える必要はありません。

見えていなかった部分をちゃんと表に出すだけです。

職務経歴書を書くとき、

「大したことやってないな……」

と思ったら、一度作業名を消して、

その仕事で自分は何を判断していたか

から考えてみると、意外と書けるものが出てくるかもしれません。