職務経歴書のファイルを開いたまま、三十分が過ぎる。

案件名は書けない。担当したのはテストと改修で、「設計しました」とも書けない。書くことがない、と感じたことはありませんか。

これは経験が足りないからではなく、SESという契約の形が、経歴の書き方のほうを縛っているからです。順番に整理していきます。

目次

書けることが少ない

多くの職務経歴書のフォーマットには、「プロジェクト名」「担当工程」「使用技術」という欄が並んでいます。この三つを埋めようとすると、SESで働いてきた人は同時に止まります。

プロジェクト名は常駐先のシステム名なので、そのまま書けない。担当工程はテストと障害対応で、工程表の右端だけが埋まる。使用技術は自分で選んだものではなく、現場で指定されたものです。

二年間の仕事が、たったの数行で終わる。この見え方が「自分には実績がない」という結論につながっていきます。面接で「他に担当されたことはありますか」と聞かれて、言葉に詰まった経験があるかもしれません。

ただ、こうなる理由は、働き方の構造の側にあります。職務経歴書の記載欄ごとに、何が書きにくく、何に置き換えられるのかを整理すると次のようになります。

契約が記述を縛る

なぜこの四つが同時に書きにくくなるのか。原因は一つで、契約の類型です。

【1】準委任契約は役務を単位にする

SESで結ばれることが多いのは準委任契約です。準委任契約は、成果物を完成させることではなく、役務を提供することを約束する契約です。

対になるのが請負契約です。請負は成果物の完成を約束するため、「何を作ったか」が契約上の単位になります。同じ開発の仕事でも、契約の型が違えば、残る記録の形が変わります。

ここが経歴書と噛み合いません。準委任では契約上の単位が「作業への従事」なので、「何を作ったか」という問いに答える形になっていないのです。

【2】経歴書の様式は請負を前提にしている

一方、世の中に出回っている職務経歴書のフォーマットの多くは、請負や自社開発を前提にしています。「担当した機能」「開発した機能の概要」といった欄が用意されているのはそのためです。

準委任の経歴をこの様式に流し込むと、成果物の欄が空きます。様式と契約類型がずれているだけで、経験の量とは関係がありません。

自社開発の経験者が書いた経歴書を参考にすると、この差はさらに開きます。参考にする相手の契約形態が違えば、埋まらない欄が増えるのは当然だからです。

【3】常駐先の名称は書けないことが多い

常駐先の企業名やシステム名を書けないのも、秘密保持契約に基づく運用であることが一般的です。

この場合は「金融系の勘定系システム」「通信キャリアの会員基盤」といった業種と領域の表記に置き換える方法があります。

ただし書ける範囲は締結している契約の内容によって異なります。業種表記まで制限されている場合もあるため、条項を確認したうえで判断してください。

工程では差がつかない

契約の話を踏まえたうえで、次は書き方そのものの問題に入ります。

【1】同じ工程名に十人が並ぶ

担当工程を並べる書き方には、避けにくい弱点があります。同じ現場にいた十人が、ほぼ同じ文字列になることです。

「結合テスト」「障害対応」「改修」。この三語だけでは、読む側は差を見つけられません。工程は配属で決まるものなので、工程名は本人の情報をほとんど含んでいないのです。

同じことは使用技術の欄にも起きます。現場で指定された言語とフレームワークを並べても、同じ現場の全員が同じ並びになります。

【2】選考側が探しているのは判断の跡

ところが実際には、同じ結合テストでも中身は分かれています。手順書のとおりに実行した人と、手順書に抜けがあることに気づいて指摘した人がいる。

工程名は同じで、書けることは違います。選考側が読み取ろうとしているのは、どの工程にいたかではなく、その工程の中で何を判断したかです。

工程は与えられたものですが、判断は本人のものだからです。

経験年数が短くても書ける、という言い方もできます。判断した回数は在籍期間に比例しないためです。

判断した場面を書く

書き換えの型は単純です。作業名の後ろに、次の三つのどれかを足します。

【1】気づいた点を書く

× 結合テストを担当。障害対応を行った。

○ 結合テストを担当。仕様書に記載のない境界値の入力パターンが未検証だったため、テストケースを追加。該当箇所で不具合が出たことから、再現手順を整理して開発担当に共有した。

気づいた対象は、仕様の抜け、手順書の誤り、再現条件の偏りなど、どれでも構いません。「誰かに指摘した」という事実が入っているかどうかが分岐点になります。

【2】決めた方針を書く

× Javaを用いた開発業務に従事。

○ 既存機能の改修を担当。変更が他機能に波及する可能性があったため、呼び出し元を洗い出したうえで修正範囲を限定する方針を提案し、レビューを受けて実装した。

方針の規模は問われません。修正範囲をどう切ったか、テストをどこまで広げたか。判断の対象が小さくても、判断したこと自体は記述の対象になります。

【3】伝えた相手を書く

× 大手金融系システムの案件に参画。

○ 金融系の勘定系システムの保守チームに参画（5名）。月次のリリース前検証を担当し、検証結果は常駐先の開発リーダーへ報告。手順書の更新も兼任した。

誰に何を渡していたかが入ると、チーム内での位置がわかります。常駐先の固有名詞を出さなくても、役割の説明はできます。

なお、これらの書き換え例は文章の型を示すためのものです。実際に担当した内容に合わせて書き直してください。事実と異なる記述は、入社後の配属でも面接の深掘りでも問題になります。

経歴書の他の欄を使う

担当工程の欄で差がつかない場合、他の欄に振り分ける方法があります。

【1】職務要約の三行

冒頭の職務要約は、多くの場合いちばん先に読まれます。ここに工程名を並べるのではなく、「どの領域のシステムを、どの立場で、何年見てきたか」を置くと、後ろの記述の読まれ方が変わります。

領域が定まっている経歴は、工程が偏っていても読み手が置き場所を決めやすくなります。逆に、業種がばらばらの案件を並べただけの要約は、読み手に判断材料を渡せません。

【2】自己PR欄の扱い

自己PR欄は、人柄を書く場所として使われがちですが、担当工程の欄で書ききれなかった判断の話を置く場所にもなります。工程の欄は事実の列挙に留め、判断の経緯をこちらに寄せる配分も取れます。

どちらの欄に何を置くかは決まっていません。全体で一度だけ書ければよいので、書きやすい側に寄せて構いません。

【3】技術欄の粒度

使用技術が現場指定であっても、扱った範囲は自分の情報です。言語名だけを並べるのではなく、どの層（画面・業務ロジック・バッチ・基盤）を触ったかまで書くと、指定された技術でも粒度が出ます。

読んだだけのコードと、変更したコードを分けて書く方法もあります。範囲を正確に書くほうが、過大に書くより照会に耐えます。

書き方では届かない場合

ここまでの話が効かない場合もあります。

【1】要件が工程そのものを指定している

募集要件に「要件定義の経験3年以上」「設計書の作成経験必須」と書かれている場合、そこは表現の工夫で埋まりません。要件が工程そのものを指定しているためです。

この場合に必要なのは経歴書の書き換えではなく、その工程に入れる場所に移ることになります。

書き方を変えても通らない求人が続くなら、原因は書類ではなく経験の中身の側にあります。

【2】SESのまま上流に近づく経路

ただし、移る先が自社開発とは限りません。同じSESでも、一次請けの常駐案件では要件定義や基本設計の会議に同席できることがあります。所属会社でプロパー側の業務に配置転換される道もあります。

現場を替えるだけで担当工程が変わるなら、会社を移る判断はいったん保留できます。まず所属会社の営業担当に、上流工程を含む案件の有無を確認するほうが早い場合があります。

【3】SESの条件が合っているとき

そして、SESという働き方自体が条件に合っている人もいます。短い期間で複数の現場を見られること、勤務地や参画期間に融通が利くこと、特定の製品や業務ドメインに縛られないこと。

これらを優先するなら、経歴書の見え方だけを理由に動く必要はありません。判断が必要なのは、書き方を変えても届かない求人が、自分の行きたい方向に集中しているかどうかです。

まとめ

・経歴書が薄く見えるのは、準委任契約が「作った物」ではなく「入った作業」を単位にするため

・職務経歴書の様式は請負・自社開発を前提にしており、契約類型とのずれが空欄として現れる

・常駐先やシステム名を書けないのは秘密保持上の運用。業種と領域の表記に置き換えるが、範囲は契約内容を確認する

・工程名の羅列では差が出ない。書けるのは、気づいた点・決めた方針・伝えた相手の三つ

・担当工程の欄で足りなければ、職務要約・自己PR・技術欄の粒度で配分できる

・要件が工程経験を指定している場合は書き方の問題ではない。一次請け常駐やプロパー配置で工程が変わる余地を先に確認する