1社だけ・長期在籍エンジニアの職務経歴書の書き方：社内異動・担当案件を分けて見せる項目設計

本記事は広告（アフィリエイト）を含みます。掲載するエージェントは編集部が厳選した提携先です。

この記事の結論

転職を考えて職務経歴書を開いたとき、「ずっと同じ会社だから、書くことが少ない…」と手が止まる人、多いですよね。私も取材でいちばん相談されるのがここです。でも安心してください。1社だけの経歴は、弱点ではありません。同じ会社の中で起きた異動や担当案件の変化を「分けて」見せると、むしろ一貫した成長ストーリーになります。

コツは、会社を1つの塊にまとめないこと。社内異動・担当案件ごとに「役割・担当工程・使用技術・数字の成果」を1セットで並べる。たったこれだけで、採用担当はあなたが何をできる人かを3分でつかめます。1社のみの職務経歴書の書き方は、転職回数が多い人より実はシンプルです。区切る単位を「会社」から「案件」に変えるだけだからです。

長期在籍エンジニアの経歴書でいちばんもったいないのは、9年の経験が2行で終わってしまうこと。この記事では、案件の分け方・記入見本・数字への翻訳・やりがちなNGまで、順番に手を動かせる形で整理します。書き終えたら、後半のロードマップで全体の流れも確認できます。

1社だけの職務経歴書は転職で不利？

「転職回数ゼロって、逆に世間を知らないように見えませんか？」と聞かれることがあります。気持ちは分かります。私も最初は、社数が少ないと見劣りすると思っていました。でも採用側が本当に気にするのは社数ではなく「何を、どこまでやったか」です。実は、日本の一般労働者の平均勤続年数は約12.5年（令和5年賃金構造基本統計調査｜厚生労働省）。長く在籍すること自体は、まったく珍しくありません。

むしろ長期在籍には、短期で動いてきた人には出せない説得力があります。同じシステムを長く担当した運用知識、トラブル時の対応力、社内を巻き込む調整力。どれも一朝一夕では身につかないものです。気づいたんですけど、面接官はこの「継続して任されてきた事実」を、地味だけど高く評価します。

では、長期在籍エンジニアの経歴書で何が問題になるのか。それは1社を「1つの塊」で書いてしまうことです。9年分の経験が「株式会社○○テック 2017年入社、Webシステム開発に従事」の2行で終わると、何ができる人か伝わりません。年数を強みに変えるには、その中の変化を分解するのが先。これが出発点です。

社内異動・担当案件はどう分けて見せる？

ここがこの記事のいちばん大事なところです。1社のみの職務経歴書の書き方でつまずくのは、たいてい「分け方」だからです。私がおすすめするのは、会社名を大きな見出しにして、その下に社内異動や担当案件を「プロジェクト」として時系列で並べる方法です。

転職を3回した人の経歴書が「会社ごと」に区切られているなら、長期在籍の人は「案件ごと」に区切ればいい。つまり、区切る単位を会社から案件に変えるだけです。たとえば「2018〜2020:基幹システム保守」「2020〜2023:ECサイト新規開発」「2023〜現在:SREチームへ異動」のように、社内の動きをそのままブロックにします。これで、1社でも3つの異なる経験として読ませられます。

社内異動で職種が変わった人ほど、この分け方が効きます。保守から開発、開発からSREへと役割が広がった事実は「対応範囲の広さ」として伝わるからです。1社の中での職種変更は、転職と同じくらいの経験の幅を持っています。下の図のように、同じ9年でも「埋もれる書き方」と「評価される書き方」では、受け取られ方がここまで変わります。

1社経歴の職務経歴書には何を書く？

具体的な中身は、記入見本で見たほうが早いです。下が、9年同じ会社にいるエンジニアを想定した職務経歴書の例。冒頭の職務要約で全体像を3〜4行にまとめ、そのあと社内異動を反映した案件ブロックを時系列で並べています。日本の標準的な構成（職務要約→職務経歴→活かせる経験・技術→保有資格→自己PR）に沿っているので、そのまま型として使えます。

見てほしいのは、案件ごとに「担当工程・開発環境・数字の成果」がワンセットで入っている点です。「保守を担当」ではなく「月間120万PVのECサイトを3名で保守し、障害対応時間を平均40%短縮」のように、役割と数字をくっつける。曖昧な「○○を担当」を避けるだけで、読み手の納得感がまるで違います。

もうひとつ、活かせる経験・技術の欄では、言語やクラウドに「経験年数」を併記します。長期在籍の人は、ここで年数の厚みを正直に出せるのが強みです。「Go(4年・主担当)」「AWS(6年)」のように書けば、即戦力かどうかが一目で伝わります。1社経歴でも、この型で書けば十分に戦えます。

長期在籍の強みをどう数字に変える？

長期在籍の人だけが書ける強みがあります。それは「同じシステムを育て続けた数字」です。新しく入った人には書けない、運用の積み重ねこそ武器になります。私も最初は「ずっと同じことの繰り返しで、書けることなんて少ない」と思っていました。でも担当者に聞いてみると、改善の宝庫だったんです。

やり方はシンプルで、「長く担当した」を数字に置き換えるだけ。リリース当時の処理時間と現在を比べる、障害件数の年次推移を出す、運用コストをどれだけ下げたか、後任を何人育てたか。こうした変化は、長く担当した人にしか書けません。「維持した」で終わらせず「○○を保ち続けた」と継続を数値で示すと、ぐっと伝わります。

下の図のように、同じ事実でも数字に翻訳すると印象が変わります。完璧な集計じゃなくて大丈夫です。「とりあえず3分」で、担当案件1つ分の数字を思い出して書き出してみてください。ざっくりした概算でも、空欄よりはるかに強い武器になります。

1社経歴の職務経歴書は何から作る？

順番を間違えると、いきなり職務要約で固まります。私がおすすめするのは、要約を最後に回すこと。先に案件を全部出してから、共通点を要約にまとめるほうが、ずっと書きやすいからです。冒頭の自己PRから書き始めて手が止まった経験、ありませんか。あれは順番のせいです。

最初の一歩は、頭の中にある担当案件を時系列でただ書き出すだけ。きれいに書こうとしなくて大丈夫です。案件名と期間が並んだら、次に各案件の数字を集める。数字が集まったら時系列に整え、最後に全体を3〜4行の要約に圧縮する。この順番なら、白紙から下書きまで一気に進みます。

下の5ステップの通りに手を動かせば、迷う場面はほとんどありません。それでも案件の見せ方や数字の出し方に迷うときは、IT・Web領域に強いギークリー（Geekly／IT・Web・ゲームに特化した転職エージェント）のような専門エージェントに添削してもらうのも近道です。第三者の目が入ると、自分では当たり前すぎて省いていた実績に気づけます。

1社経歴でやりがちなNGは？

最後に、相談を受けていて「もったいない！」と感じるNGを3つだけ紹介します。どれも直すのは簡単です。1社のみの職務経歴書の書き方で差がつくのは、結局この3点を避けられるかどうかです。

会社をひとまとめにすると、9年の中身が見えません。年数だけを前面に出すと「で、結局何ができるの？」で読み手が止まります。案件を並べても成果が書かれていないと、指示をこなす作業者に見えてしまう。逆に言えば、この3つを直すだけで読み手の印象は大きく変わります。

下の図に、ありがちなNGとその直し方をまとめました。全部を一度に直そうとしなくて大丈夫です。まず1個だけ、いちばん心当たりのあるところから手を入れてみてください。長期在籍エンジニアの経歴書は、ちょっと意識するだけで見違えます。