【フェーズとレイヤーで書く】ITエンジニアの職務経歴書

「Webサービスのバックエンドを6年」と書いた職務経歴書が、読み手にどう届くか。書いた本人の頭の中には、具体的なサービスと言語とチームがあります。しかし読む側にとって、その6年は要件定義から運用まで全部かもしれないし、渡された仕様の実装だけかもしれない状態です。

技術職の職務経歴書がうまくいかない原因は、業界を問わずほぼ同じ場所にあります。職種名が総称になっていて、担当範囲を読み手が復元できないという一点です。製造業の技術職についてはこの構造を技術職の職務経歴書：生産技術・機械設計・品質保証の書き分けで扱いました。この記事は、同じ問題がIT・Webではどういう形で現れるか、そしてITでは何を書けば範囲が伝わるのかを整理します。

なお、用紙・枚数・必須項目・並べ方といった様式（器）の部分は職種によらず共通です。そちらは職務経歴書の書き方（様式と構成）にまとめてあるので、まだ形が決まっていない場合は先にそちらをご覧ください。この記事は器の中身、それもIT固有の部分だけを扱います。

製造業の技術職とIT職の、公的分類上の位置関係

製造業の技術職から読み進めてきた方のために、先に地図を示します。厚生労働省編職業分類（第5回改定）では、コンピュータそのものの開発・設計は「開発技術者」、コンピュータを製造するための工程設計・作業設計は「製造技術者」に分類され、この記事で扱う情報処理・通信技術者の枠には含まれません。つまり、ハードウェアの設計者や生産技術者は、公的分類上はIT職とは別の場所にいます。

一方で、ひとつだけ明確な接点があります。「ソフトウェア開発技術者（組込・制御系）」です。同分類では、各種の機械器具に組み込まれて動作を制御するマイクロコントローラのソフトウェアを作成する仕事として定義され、例示される職業名には「システムエンジニア（組込、IoT）」「ファームウェア開発技術者」「制御系ソフトウェア開発技術者」が並びます。製造業側で装置制御やファームウェアに触れてきた経験は、ここに接続します。

この記事の書き方は、その接点にいる方にも、純粋にWeb・業務システムの世界にいる方にも同じように使えます。工程の全体像から自分の位置を確認したい場合は製造業の職種・工程の全体像と技術経験の活かし方もあわせてご覧ください。

ITの職種は、公的分類では「つくる側」と「それ以外」に分かれる

職務経歴書を書くとき、自分の職種名をそのまま書けばよいと考えがちです。しかし読み手が最初に置きたいのは、もっと粗い区分です。厚生労働省編職業分類では、情報処理・通信技術者が2つの中分類に分けられています。

この分かれ方が職務経歴書に効くのは、読み手が最初に立てる問いと一致しているからです。この人は何かをつくっていた人なのか、動かしていた人なのか、決めていた人なのか。ここが1行目で分かると、以降の記述の読み方が定まります。

実際の求人票では「システムエンジニア」「インフラエンジニア」「社内SE」といった呼称が使われ、公的分類の名前とは一致しません。それでも対応関係を知っておく価値はあります。社内でしか通じない肩書きを、業界共通の言葉に置き直す手がかりになるからです。同じ発想は製造業でも使われていて、その考え方は技術職の職務経歴書と実績の伝え方で扱っています。

公的分類に例示されている職業名（抜粋）

各区分には具体的な職業名が例示されています。自分の仕事に近い名前がどこに置かれているかを確認すると、書き出しの言葉が決めやすくなります。

区分	例示されている職業名（抜粋）
ソフトウェア開発技術者 （WEB・オープン系）	Web系ソフトウェア開発技術者／オープン系ソフトウェア開発技術者／システムエンジニア（WEBサイト開発）／システムエンジニア（業務用システム）／ソフトウェア開発技術者（パッケージソフト）／ソフトウェア開発技術者（スマートフォンアプリ）／モバイルアプリケーション開発技術者
ソフトウェア開発技術者 （組込・制御系）	組込系ソフトウェア開発技術者／システムエンジニア（組込、IoT）／制御系ソフトウェア開発技術者／ファームウェア開発技術者
プログラマー	ソフトウェアプログラマー／Webアプリケーションプログラマー／Webプログラマー／HTMLコーダー／コンピュータゲームプログラマー ほか
その他（開発）	ソフトウェアテスト技術者／テストエンジニア／ソフトウェアテスター／デバッガー／ローカライズ技術者／ソフトウェア開発技術者（汎用機器系）
ITシステム設計技術者	システムアーキテクト／ITアーキテクト／ソフトウェアアーキテクト／システムエンジニア（基盤システム）／システム設計技術者／社内システムエンジニア（主にシステムの設計に従事するもの）
ITシステム運用管理者	サーバー管理者／システム運用管理者／運用監視オペレーター／ネットワーク管理者／システム保守員／情報セキュリティ技術者／セキュリティエンジニア（オペレーション）／社内システムエンジニア（主にシステムの運用に従事するもの）
通信ネットワーク技術者	ネットワークエンジニア／ネットワーク技術者／サーバーエンジニア（構築・設定を行うもの）／サーバー構築技術者／電気通信技術者／伝送プロトコル技術者
その他（開発を除く）	AIエンジニア／データエンジニア／ビッグデータエンジニア／情報システム監査技術者／セキュリティエンジニア（脆弱性診断）

太字にした3つに注目してください。ここに、職務経歴書で最も誤解を生みやすい2つの分かれ目が現れています。ひとつは社内SEが「設計中心」と「運用中心」で別の区分に置かれること。もうひとつはサーバーの「構築・設定」と「運用・管理」が別の区分に置かれることです。「社内SEです」「インフラエンジニアです」とだけ書くと、読み手はこの分かれ目のどちら側かを判断できません。

ITで範囲を決めるのは「担当フェーズ」

製造業では、担当範囲を示す言葉が工程でした。ITでそれに当たるのが担当フェーズです。これは書き手が勝手に決めた枠組みではなく、公的分類の定義文そのものに現れています。

「情報処理・通信技術者（ソフトウェア開発）」の定義には、この職種が行う仕事として要件定義、基本設計書・詳細設計書・仕様書の作成、プログラムの開発、作成したソフトウェアのテストが列挙されています。一方「情報処理・通信技術者（ソフトウェア開発を除く）」の定義には、適用業務の分析、情報処理システムの企画・設計、システム開発プロジェクトの管理、コンピュータネットワークの構築、構築されたシステムの運用・管理が挙げられています。

つまり、職種の違いはそのままフェーズのどこを持っているかの違いとして公的に記述されています。だから職務経歴書でも、フェーズを書けば範囲が伝わります。

この図の使い方は簡単です。自分の各社での担当を、この6マスに塗り直してみる。塗った結果が、そのまま職務経歴書の各社の冒頭に置く1行になります。「要件定義から運用まで一貫して担当」なのか、「詳細設計以降を担当」なのか。それが書かれているかどうかで、同じ年数の経歴の読まれ方が変わります。

ここで正直さが効きます。全部を濃く塗りたくなりますが、塗りすぎた経歴書は面談で崩れます。実装とテストだけを持っていたなら、そう書いたうえで「要件定義には仕様の確認者として参加」と関与の度合いを分けて書けば、記述は具体になります。

職種別の書く軸

フェーズを塗ったうえで、職種ごとに「先に書くべき1行」が変わります。以下は本サイトによる整理です。呼称は企業により異なるため、自分の仕事の実態に近いものを見てください。

サーバーサイド・バックエンド

デジタルスキル標準（経済産業省・IPA）では、バックエンドエンジニアの責務を「デジタル技術を活用したサービスを提供するためのソフトウェアの機能のうち、主にサーバサイドの機能の実現に主たる責任を持つ」と定義しています。「機能の実現に主たる責任を持つ」という言い方が示すとおり、読み手が見たいのは責任の範囲です。

• 担当したのは機能単位か、サブシステム単位か、サービス全体か。ここを最初に書く。
• データの持ち方に関与したか。テーブル設計・API設計・スキーマ変更のどこまでを決めたか。
• 既存システムへの追加なのか、新規構築なのか、リプレースなのか。この3つは求められる力が違うので必ず区別する。
• 他システム・外部サービスとの連携の有無。連携がある場合、仕様の調整相手は誰だったか。

陥りやすい書き方：使用言語とフレームワークを並べて終えること。それは「対象」であって「担当」ではありません。

フロントエンド

同じくデジタルスキル標準では、フロントエンドエンジニアを「主にインターフェース（クライアントサイド）の機能の実現に主たる責任を持つ」と定義しています。この職種の経歴書は、画面の見た目の話に寄りやすいのが難所です。

• デザインを受け取る側だったのか、情報設計や画面仕様の検討から入ったのか。
• 状態管理・コンポーネント設計・ビルド構成のうち、どこを自分が決めたか。
• パフォーマンス、アクセシビリティ、対応ブラウザ・端末など、見た目以外の要件にどう関与したか。
• APIの仕様決めにバックエンドと関わったか。関わったなら、その調整は実績として書けます。

陥りやすい書き方：担当した画面数だけを書くこと。画面数は作業量の指標であって、判断の証拠にはなりません。

インフラ・クラウド・SRE

この領域は、公的分類での分かれ方をそのまま利用できます。前述のとおり、サーバーの構築・設定は「通信ネットワーク技術者」、運用・監視・維持・管理・保守は「ITシステム運用管理者」と、別の区分に置かれています。「インフラエンジニア」という呼称はこの両方をまたぐため、書き手が指定しないと範囲が定まりません。

デジタルスキル標準では、クラウドエンジニア／SREのロールを「ソフトウェアの開発・運用環境の最適化と信頼性の向上に責任を持つ」と定義しています。最適化と信頼性向上、という2つの言葉が軸になります。

• 構築側か、運用側か、両方か。両方なら、時期ごとの比重まで。
• 設計したのは何か。ネットワーク構成、権限設計、監視設計、バックアップ・復旧の方式、デプロイの仕組み。
• 障害対応の経験は「対応した」で止めない。検知の仕組み、切り分けの手順、恒久対策までのどこに関与したか。
• 移行・更改の経験があれば、規模ではなく止められる時間の制約と、その中でどう組んだかを書く。
• コストに触れた経験は、非公開の金額を書かなくても「構成見直しによる費用最適化を担当」の形で書けます。

陥りやすい書き方：使ったクラウドサービス名の羅列。どのサービスを使ったかより、なぜその構成にしたかが読まれます。

社内SE・情報システム

この職種は、公的分類で3つに分かれるという珍しい扱いを受けています。設計に主に従事する社内システムエンジニアは「ITシステム設計技術者」、運用に主に従事する社内システムエンジニアは「ITシステム運用管理者」、社内からの問い合わせ対応や機器設定は「ITヘルプデスク」です。

これは、社内SEという呼称が実務の幅を1語で覆い隠していることの公的な裏づけでもあります。だからこそ、書き分けの効果が大きい職種です。

• 企画・要件定義に入っていたか。社内の業務課題を聞き取り、要件に落とす側だったのかを明示する。
• ベンダー・SIerとの関係。発注側として仕様を決め、検収の判断をしていたなら、それは中核の経験です。
• 内製の範囲。自分で書いたのか、選定と管理だったのか。
• 運用の対象。基幹システム、ネットワーク、端末、アカウント、セキュリティのどこを持っていたか。
• ヘルプデスク的な業務の比率。隠す必要はなく、比率を書けば全体像が正確に伝わります。

陥りやすい書き方：「社内システムの企画・開発・運用を担当」の一行で全部を包むこと。読み手はこの一行から何も復元できません。

QA・テストエンジニア

公的分類では、テストに関する職業（ソフトウェアテスト技術者、テストエンジニア、ソフトウェアテスター、デバッガー）はプログラマーとは別の区分に置かれています。さらに、プログラムの誤り・欠陥などのバグを修正する仕事はプログラマーではなくこちらに分類される、という注記まで付いています。つまり公的にも独立した職種として扱われています。

• 担当したのはテスト設計か、実行か、自動化か、プロセス構築か。この4つは別の能力です。
• テスト観点を自分で設計したか。既存の観点表に沿って実行したのか、観点そのものを作ったのか。
• どのレイヤーのテストか。単体、結合、システム、受入のどこを持っていたか。
• 不具合の扱い。起票して終わりか、原因の切り分けまで入ったか、再発防止の仕組みに関与したか。
• 開発チームとの関係。工程の後ろに置かれていたのか、設計段階から参加していたのか。

陥りやすい書き方：検出した不具合の件数だけを書くこと。件数は対象の品質にも依存するため、単独では実力を示しません。

データ・AI

公的分類では、AIエンジニア、データエンジニア、ビッグデータエンジニアは「その他の情報処理・通信技術者（ソフトウェア開発を除く）」に置かれています。既存の区分に収まりきらない新しい職種であることが、この置かれ方に表れています。だからこそ、自分で範囲を説明する必要が最も大きい職種です。

デジタルスキル標準は、この領域を「データサイエンティスト」と「データマネジメント」の2類型に分け、後者にデータスチュワード、データエンジニア、データアーキテクトのロールを置いています。このうちデータエンジニアの責務は「収集・統合・加工・提供などの各プロセスにおけるデータ整備、前処理の実施、データパイプラインの設計・実装を通じて、組織全体の継続的なデータ利活用を支える役割」と説明されています。

• データを運ぶ側か、分析する側か、活用戦略を立てる側か。まずここを分ける。
• 基盤を作ったのか、既にあるものを使ったのか。作ったなら、どこから設計したか。
• 分析の結果が何に使われたか。レポートで終わったのか、業務やプロダクトに組み込まれたのか。
• データの品質・権限・個人情報の扱いに関与したか。この領域では、統制側の経験が評価対象になります。

モバイル

公的分類では、スマートフォンアプリの開発は「ソフトウェア開発技術者（WEB・オープン系）」に含まれ、例示にも「ソフトウェア開発技術者（スマートフォンアプリ）」「モバイルアプリケーション開発技術者」が挙がっています。つまり分類上はWeb系と同じ枠です。

そのため経歴書では、Web系との違いを自分で書くことになります。対応OSとバージョン、審査・配信の運用、端末やOS更新への追随、オフライン時の挙動、プッシュや権限の扱い。こうしたモバイル固有の制約にどう対処したかが、この職種の判断の証拠になります。

組込・制御系

製造業の技術職から接続するのがこの区分です。デジタルスキル標準にも近い位置づけのロールがあり、フィジカルコンピューティングエンジニアは「現実世界（物理領域）のデジタル化を担い、デバイスを含めたソフトウェア機能の実現に責任を持つ」と定義されています。

• ハードとの境界のどちら側にいたか。回路・機構側の設計者と、どう仕様を分け合っていたか。
• 制約条件。メモリ、消費電力、応答時間、安全面の要求のうち、どれが設計を縛っていたか。
• 検証の方法。実機評価、シミュレーション、量産前の確認のどこに関わったか。
• 量産・出荷後の不具合対応に入っていたか。ここは製造業側の経験がそのまま強みになります。

職種別の対比：読み手が最初に知りたいこと

職種（求人でよく使われる呼称）	読み手が最初に知りたいこと	先に書く1行	陥りやすい書き方
サーバーサイド・バックエンド	責任を持っていた単位の大きさ	担当した単位（機能／サブシステム／サービス全体）と、新規・追加・リプレースの別	言語とフレームワークの羅列
フロントエンド	見た目の実装だけか、設計に入っていたか	情報設計・コンポーネント設計・状態管理のどこを決めたか	担当画面数だけを書く
インフラ・クラウド・SRE	構築側か、運用側か	構築／運用の比重と、自分が設計した対象（構成・監視・権限・復旧）	使ったサービス名の羅列
社内SE・情報システム	企画・発注・内製・運用のどこを持っていたか	4つの比率と、ベンダーとの関係（発注側か、実装側か）	「企画・開発・運用を担当」で包む
QA・テスト	テストを設計していたか、実行していたか	設計／実行／自動化／プロセス構築の別と、担当したテストレイヤー	検出件数だけを書く
データ・AI	運ぶ側か、分析する側か	基盤・分析・活用のどこを担い、結果が何に使われたか	使ったツール名だけを書く
モバイル	プラットフォーム固有の制約にどう対処したか	対応OS・配信運用・端末制約への対処	Web系と同じ書き方で済ませる
組込・制御系	ハードとの境界のどこにいたか	制約条件（メモリ・電力・応答時間・安全）と、検証の方法	製品名と機能の説明で終わる

※職種の呼称・区分は企業により異なります。表は整理のための一般的なものです。

技術スタックは「名前」ではなく「関与の深さ」で書く

ITの職務経歴書に特有の失敗が、技術名の羅列です。書ける情報が多いぶん、埋めやすく、そして読み飛ばされやすい。名前だけでは、その技術と自分の距離が伝わらないからです。

この4段階で分けると、書く場所も自然に決まります。③と④は職務経歴の本文で、判断の根拠として書く。①と②は「活かせる能力」欄にまとめる。様式上、使用機器や技術を職務内容に付記してよいこと、および見出しを「得意な技術」などに変えてよいことは様式と構成の記事で扱っています。

伝わりにくい書き方	伝わりやすい書き方	理由
使用技術：（言語・FW・DB・クラウドの列挙）	［機能単位の担当］に対し、［技術］を用いて実装。データ設計とAPI仕様の決定を担当	技術と、自分が決めたことが結びつく
クラウド移行を担当	オンプレミス環境からクラウドへの移行にあたり、構成方式の比較検討と切替手順の設計を担当	「移行」の中身と関与範囲が分かる
パフォーマンス改善を実施	応答遅延の要因をクエリと通信回数に切り分け、データ取得方式の見直しで改善	切り分けの筋道が、再現できる力として読める
チームでアジャイル開発	2週間単位の反復開発で、見積りとタスク分解、および仕様確認の窓口を担当	手法名ではなく、自分の役割が書かれている
保守・運用を担当	稼働監視、障害一次対応、および定期的な構成変更の適用を担当（対応手順書の改訂も実施）	「運用」に含まれる行為が具体化する

※表現例は整理のための一般的なものです。実際の記載は、勤務先の守秘条件と応募先の様式に合わせてください。

チーム規模と役割：「リーダー」はマネージャではない

チーム規模を書くべきか迷う方は多いのですが、書く価値があるのは人数そのものではなく、その人数の中での自分の位置です。ここについて、公的分類にはっきりした整理があります。

「ITプロジェクトマネージャ」は、システム開発を担当するプロジェクトの責任者として、プロジェクト実行計画の作成、予算・要員・進捗・品質の管理、業務の監督などプロジェクト全体を管理する仕事と定義されています。一方で、プロジェクトリーダー（システム開発）、技術リーダー、チームリーダーは、この区分ではなくソフトウェア開発の側で「主に従事する仕事に即して分類する」とされています。プロジェクトの一員として担当業務に従事しながら、チームを統括して仕事の割り当て・作業手順の決定・工数や進捗の管理も行う立場、という説明が添えられています。

この区別は、経歴書に直接使えます。「リーダー」と書いただけでは、手を動かしていた人なのか、全体を管理していた人なのかが伝わらないということだからです。

• 自分は担当業務を持ちながらの取りまとめだったのか、管理に専念する立場だったのか。
• 何を決めていたか。タスクの割り当て、作業手順、見積り、要員、予算、品質基準のうちどれか。
• チーム人数は、役割の説明と一緒に書く。人数だけでは責任の重さを示しません。
• 社外の要員を含むチームだったか。委託先や派遣を含む場合、その調整は別の能力として書けます。

デジタルスキル標準にも、1人の人材が複数のロールを兼ねる場合や、複数の人材で1つのロールを担うこともあると明記されています。兼務は珍しいことではないので、兼務なら兼務と書き、比重を添えるのが正確です。

非機能要件への関与を1行入れる

IT職の職務経歴書で書ける具体物のうち、守秘義務に触れにくく、かつ実力が伝わりやすいのが非機能要件への関与です。機能の中身は書けなくても、「どういう性質の要求と向き合っていたか」は書けることが多いためです。

IPAが公開した「非機能要求グレード」は、非機能要求についてユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的として、非機能要求項目を網羅的にリストアップし分類したものです。そこでは非機能要求が次の6つの大項目に整理されています。

大項目	職務経歴書に書ける関与の例
可用性	停止できない時間帯の制約下での構成設計、冗長化方式の検討、復旧手順の整備
性能・拡張性	想定利用者数からの性能要件の整理、負荷試験の設計、処理方式の見直し
運用・保守性	監視項目の設計、運用手順書の整備、保守を前提とした設計方針の決定
移行性	移行方式の比較検討、並行稼働の設計、切替時の停止時間の見積り
セキュリティ	権限設計、脆弱性への対応方針の検討、インシデント発生時の手順整備
システム環境・エコロジー	設置環境や拠点数などの制約を踏まえた構成の検討

※右列は本サイトによる整理です。非機能要求グレードは現在IPAのアーカイブとして公開されており、当該ページには2023年8月時点の情報である旨が明記されています。最新の考え方については、公式の情報をご確認ください。

この表の使い方は、自分がどれに触れたかを1つか2つ選び、経歴の中に1行入れることです。全部書く必要はありません。むしろ、ひとつでも具体的に書かれていると、機能を作るだけの人ではないことが伝わります。

コード・成果物・守秘義務の扱い

守秘義務のある情報を書けないという問題自体は業界共通で、粒度を上げる対処法は技術職の職務経歴書と実績の伝え方で整理しています。ここではIT固有の論点だけを補足します。

• 業務で書いたコードは、原則として自分の持ち物ではありません。 職務著作の扱いや秘密保持の条項は雇用契約・就業規則によって異なるため、社外に見せられるかどうかは必ずご自身で確認してください。
• 個人で公開しているリポジトリや技術記事は、本人が公開している範囲であれば紹介できます。様式上、「作品集」を別紙として添える形は想定されています（様式と構成の記事参照）。
• サービス名を書けない場合は、領域と規模の性質で示します。「一般消費者向けのWebサービス」「社内の基幹業務システム」「特定業種向けの受託開発」など。
• 利用者数・処理件数などの数値が非公開なら、その数値がもたらしていた制約を書きます。「深夜帯も含めて停止できない前提での構成」といった書き方は、数値を出さずに規模感を伝えます。
• 受託・請負の場合、顧客名を出さずに「どの立場だったか」は書けます。元請けか、下請けか、どの層と仕様を詰めていたか。

資格の扱い

IT分野の国家試験としては、独立行政法人情報処理推進機構（IPA）が実施する情報処理技術者試験および情報処理安全確保支援士試験があります。試験区分には、ITパスポート試験、情報セキュリティマネジメント試験、基本情報技術者試験、応用情報技術者試験、ITストラテジスト試験、システムアーキテクト試験、プロジェクトマネージャ試験、ネットワークスペシャリスト試験、データベーススペシャリスト試験、エンベデッドシステムスペシャリスト試験、ITサービスマネージャ試験、システム監査技術者試験、情報処理安全確保支援士試験があります。

このほか、クラウドや製品に関する民間の認定資格も広く使われています。ただし、試験の名称・区分・受験要件・有効期間は変更されることがあります。受験や記載を検討する場合は、必ず各試験の公式情報でご確認ください。

職務経歴書に書く際は正式名称で、取得年月を添えます。勉強中のものや一部合格のものも、その旨を明記すれば記載できるとされています。なお、実務経験者の応募において資格が経験の代わりになるとは限りません。資格欄より、職務経歴の本文で何を担ってきたかが読まれます。

提出前チェックリスト

• 各社の冒頭に担当フェーズ（要件定義〜運用・保守のどこか）が書かれている
• 自分がつくる側か、設計・管理・構築・運用の側かが1行目で分かる
• 「インフラエンジニア」「社内SE」などの総称を、構築／運用／企画などに分解している
• 技術名が羅列で終わっていない（③選定・設計、④運用・障害対応の関与が書かれている）
• 担当した単位の大きさ（機能／サブシステム／サービス全体）が書かれている
• 新規構築・既存への追加・リプレースの別が書かれている
• 「リーダー」と書いた箇所に、何を決めていたかが添えられている
• チーム人数を書いた場合、その中での役割が併記されている
• 非機能要件への関与が1行以上入っている
• 社名・サービス名・数値を、守秘の範囲内で粒度を上げて表現している
• 公開しているコードや記事を挙げる場合、公開してよい範囲を自分で確認した
• 応募先の募集内容と、強調している経験がずれていない
• 面談で、書いた内容をすべて自分の言葉で説明できる

よくある疑問

会社での肩書きが「システムエンジニア」だけで、何をしていたか伝わりません

公的分類でも「システムエンジニア」という語は複数の区分にまたがって例示されています。システムエンジニア（業務用システム）は開発側、システムエンジニア（基盤システム）は設計側、システムエンジニア（組込、IoT）は組込側です。肩書きを言い換えるより、担当フェーズと担当対象を書くほうが確実に伝わります。応募職種の欄には、募集側の呼称をそのまま簡潔に書けば足ります。

受託開発で、担当した案件が多すぎて2枚に収まりません

本文を削る前に、案件の一覧を別紙に分けることを検討してください。様式上、「開発担当プロジェクト一覧」などを別紙として付ける場合は必要枚数分増えても差し支えないとされています（詳細は様式と構成の記事）。本文には代表的な数件を厚く書き、網羅性は別紙で担保する形が読みやすくなります。

使える言語やツールが少ないのが不安です

技術の数は、経歴の評価軸のひとつにすぎません。前述の関与の深さで言えば、①②をいくつ並べるより、③④がひとつでもあるほうが、説明できる材料は多くなりがちです。少ない技術で、選定の理由と運用まで語れるなら、それは書ける材料です。

SIerから事業会社へ、あるいはその逆に移りたい場合は

担当フェーズの分布が変わることが多いため、移りたい側で必要になるフェーズの経験を前に出すと、つながりが読めるようになります。発注側・受注側のどちらにいたかは経歴の重要な情報なので、隠さず明記したうえで、相手側とどうやりとりしていたかを書くと具体になります。

製造業の技術職から、組込やIoTの領域に移りたい場合は

公的分類では、ハードウェアの開発・設計や製造の工程設計は情報処理・通信技術者とは別の区分です。したがって、ソフトウェア側でどこまで手を動かしたかが読み手の関心になります。装置制御のプログラム、試験用の治具やツールの作成、データ収集の仕組みなど、ソフトウェアに関わった部分を切り出して書くと、経験の接続点が見えるようになります。職種をまたぐ場合の考え方は技術職の職務経歴書：職種別の書き分けでも扱っています。

ブランクや、短期間での離職があります

経歴の事実は変えられません。各社で何を担い、何を身につけたかが一貫して読めれば、経験の積み上がりとして理解されやすくなります。事実と異なる記載は避けてください。面談で説明できない記述は、書かないほうが安全です。

まとめ：次の一歩

IT・Webの職務経歴書がうまくいかない原因の多くは、書くことがないからではなく、書けることが多すぎて、範囲を指定しないまま並べてしまうことにあります。読み手は職種名からも技術名からも、担当範囲を復元できません。範囲は書き手が指定する必要があります。

次の一歩として、①各社の担当を6つのフェーズに塗り分け、②技術スタックを関与の深さで①〜④に仕分け、③非機能要件への関与を1行足す、の順で進めてみてください。職種の呼称・区分は企業により異なり、求められる経験も募集ごとに違うため、応募にあたっては必ず募集要項でご確認ください。記載可能な情報の範囲も、雇用契約・就業規則によって異なります。

関連記事

• 職務経歴書の書き方（様式と構成）：A4で1〜2枚に収める
• 技術職の職務経歴書：生産技術・機械設計・品質保証の書き分け
• 技術職の職務経歴書と実績の伝え方（社内用語の変換・守秘）
• 製造業の職種・工程の全体像と技術経験の活かし方

【出典・情報の確認について】
職種の区分・定義・例示されている職業名に関する記述は、第5回改定「厚生労働省編職業分類」（独立行政法人 労働政策研究・研修機構が公開する職業分類表／2026年8月29日確認）に基づいています。人材類型・ロールの名称および責務に関する記述は、経済産業省・独立行政法人情報処理推進機構（IPA）「デジタルスキル標準 ver.2.0」（2026年4月公表／2026年8月29日確認）に基づいています。非機能要求の大項目に関する記述は、IPA「非機能要求グレード2018」（IPAのアーカイブとして公開。当該ページには2023年8月時点の情報である旨の記載あり／2026年8月29日確認）に基づいています。試験区分の名称は、IPAが公開する情報処理技術者試験・情報処理安全確保支援士試験の試験区分一覧（2026年8月29日確認）によります。
職種ごとの書く軸、対比表、チェックリスト、および図解の一部は本サイトによる整理です。職種の呼称・区分は企業により異なります。試験の名称・区分・受験要件は変更されることがあるため、必ず各試験の公式情報でご確認ください。応募書類の様式や提出方法は企業ごとに異なり、指定がある場合はそちらが優先されます。記載可能な情報の範囲は雇用契約・就業規則により異なるため、必ずご自身でご確認ください。本記事は特定サービスの推薦ではなく、判断材料の整理を目的としています。

• 厚生労働省編職業分類（第5回改定）／独立行政法人 労働政策研究・研修機構
• 経済産業省・独立行政法人情報処理推進機構（IPA）「デジタルスキル標準」
• 独立行政法人情報処理推進機構（IPA）「非機能要求グレード」（アーカイブ）
• 独立行政法人情報処理推進機構（IPA）情報処理技術者試験・情報処理安全確保支援士試験の公式情報
• 各事業会社・開発会社の公式求人情報および募集要項