職務経歴書が「プロジェクトに参画しました」で終わる人へ｜担当範囲・判断・結果に分けて書く方法
対象：SIer・SES・社内SE・インフラ・サポートで、「プロジェクトに参画した」以上の書き方が分からないと感じている方
公開 2026年8月24日 更新 2026年8月29日 読了 約12分
職務経歴書を書き始めると、案件名と期間のあとに「プロジェクトに参画しました」で止まってしまうことがあります。
- プロジェクトに参画しました
- Java開発を担当しました
- 大規模案件に従事しました
- 運用保守を経験しました
しかし、経歴が足りないわけではありません。
通らない原因は、経験を「参画」「担当」「従事」といった動詞で止め、求人要件が判断できる範囲まで書いていないことにあります。
この記事では、1案件を担当範囲・判断・結果に分けて、職務経歴書へ落とす方法を解説します。
この記事の要点
- 1「参画」「担当」だけでは、求人要件は判断できない
- 21案件を担当範囲・判断・結果に分けて書く
- 3先頭に置く案件は、応募先が先に見たい経験にする
- 4やっていない工程や成果は足さない
「参画しました」が通らない理由
職務経歴書は、採用側が求人要件と突き合わせるための文書です。案件名、期間、技術名までは書いてあっても、その人が何を判断できるのかが書いていないと、要件との対応が取れません。
SIer・SES・社内SEいずれでも、次のような書き方になりがちです。
- 〇〇プロジェクトに参画
- Java／AWSを使用した開発に従事
- 大規模基幹システムの運用保守
- 社内SEとして問い合わせ対応
- チームの一員としてテストを担当
これらは間違いではありません。ただし、採用側から見ると「詳細設計まで入ったのか、手順どおりに実施したのか、障害の一次切り分けまで判断したのか」が分かりません。
必要なのは、職種名を盛ることではなく、1案件の中で担当した範囲と判断したことを分解することです。
動詞で止めた書き方
- 参画しました
- 担当しました
- 従事しました
判断できる書き方へ分解
- どこまで担当したか
- 何を見て判断したか
- 何が残ったか
1案件を書く3つの軸
1
担当範囲
工程名ではなく、自分が終わらせた範囲
2
判断
誰に何を確認し、どこまで自分で決めたか
3
結果
手順・手戻り・共有の仕方で何が残ったか
1．どこまで担当したか
工程名は、案件のラベルにはなりますが、担当範囲にはなりません。同じ「開発」でも、実装だけなのか、詳細設計から入ったのか、結合の切り分けまで見たのかで、読める求人は変わります。
- 自分で書いた成果物（詳細設計、テスト項目、手順書など）
- 自分で実施した確認（単体、結合、復旧後確認など）
- 自分では決めず、リーダーや顧客へ確認した点
- 他担当へ渡した範囲と、渡すときに添えた情報
- 案件の規模・人数は、確認できる数字だけ
「大規模」「多数」だけでは判断できません。人数や件数は、事実として確認できる場合だけ書きます。確認できない数字は、盛らずに省略します。
2．何を見て判断したか
採用側が見たいのは、次に同じ状況が来たときに任せられる判断です。大きな決裁である必要はありません。日常の確認でも構いません。
- 仕様の不明点を、誰に、何を確認して進めたか
- 不具合や障害を、何を見て一次切り分けしたか
- 自分で案内できるものと、上位へ渡すものを分けたか
- 優先度や影響範囲を、関係者へどう共有したか
- 手戻りが起きないように、先に揃えた確認項目
判断していないことを「リーダー相当」と書く必要はありません。確認した相手と、自分で進めた境界が書いてあれば十分です。
3．何が残ったか
結果は、売上や削減金額である必要はありません。次の担当が再現できる変化があれば、経歴書の材料になります。
- 同じ確認を繰り返さないための手順やチェックリスト
- 結合や障害のあと、設計や運用へ戻した点
- 問い合わせや障害が戻らなくなった工夫
- 引き継ぎできる形で残した確認項目
- 数字で書ける変化は、確認できる範囲だけ
やっていない改善を「リードした」と足してはいけません。残ったものが手順の1行でも、事実なら書いた方が、参画だけでは伝わらない仕事が見えます。
職務経歴書のBefore／After
仕事を大きく見せる必要はありません。1案件の中で実際に担当した範囲を、判断できる文にする例です。
開発案件
Before
基幹システム刷新プロジェクトに参画し、Java開発を担当しました。
After
基幹システムの刷新で、詳細設計・実装・単体テストを担当。仕様の不明点はリーダーへ確認し、結合テストで出た不具合の切り分けを開発へ戻した。
テスト案件
Before
大規模案件の結合テストに従事しました。
After
結合テストの実施、不具合の再現確認、原因箇所の切り分けを担当。調査結果を開発へ共有し、修正後の確認まで行った。
運用案件
Before
客先で運用保守を担当しました。
After
業務システムの障害時に、ログ確認による一次切り分け、影響範囲の特定、関係部署への状況共有を担当。復旧後は対応手順と確認項目を更新した。
社内SE
Before
情シスとして社内システムの運用を担当しました。
After
問い合わせを権限・操作・不具合に切り分け、繰り返す内容は手順書へ残した。ベンダーへの依頼は、確認済み項目と未確認項目を分けて渡した。
これらはあくまで整理例です。実際に担当していない工程や成果を追加してはいけません。
先頭に置く案件と、求人票との突き合わせ
新しい順に全部並べる必要はありません。採用側は最初の案件で、応募要件との対応を見ます。先に置くのは、応募先が判断したい経験に近い1件です。
詳細設計〜テスト
開発・上流候補の求人
要件との接点と、後工程からの戻しを先に書く
障害対応・運用
社内SE・運用改善の求人
切り分けと、戻らなくした工夫を先に書く
問い合わせ・権限
社内SE・サポートの求人
切り分けと、同じ質問を減らした事実を先に書く
伝わりにくい例
〇〇更新プロジェクト（2023年4月〜2024年3月）Java開発に参画。
判断できる例
販売管理システムの更新（2023年4月〜2024年3月）。詳細設計・実装・単体テストを担当。仕様の不明点はリーダーへ確認し、結合で出た不具合の切り分けを開発へ戻した。
- 必須の担当工程と、自分が書いた範囲が対応しているか
- 顧客折衝・部門調整が「あり」のとき、誰と何を確認したか書いてあるか
- 運用・障害対応が主か、開発の一部かが分かる書き方か
- 必須スキルが技術名だけか、切り分け・改善の記述を求めているか
- 書いていない工程を、応募のために足していないか
| 求人側が見たいこと | 経歴書で先に書くこと | 書いてはいけないこと |
|---|---|---|
| 担当工程の深さ | 自分が終わらせた範囲と成果物 | 見ていない工程を経験ありと書く |
| 判断できる範囲 | 確認先と、自分で進めた境界 | 役職名だけのリーダー相当 |
| 再発防止・改善 | 残した手順、戻した点、共有の仕方 | 確認できない削減数字 |
| 部門・顧客との接点 | 誰に、何を、どこまで説明したか | 折衝経験の水増し |
| 技術スキル | 使った場面と担当範囲 | 触っていない製品名の列挙 |
職務経歴書を求人要件の「判定表」に変える
この文章の目的は、きれいに見せることではありません。採用側が必須要件の有無を、案件ごとに誤解なく判定できる状態にすることです。
求人要件との対応
| 比較する職種 | 見られる要件 | 示す証拠 |
|---|---|---|
| 開発・上流候補 | 担当工程、成果物、仕様確認の境界 | 案件冒頭に「何を終わらせたか」「不明点を誰へ戻したか」を記載 |
| 社内SE・情シス | 利用部門対応、優先順位、ベンダー管理 | 問い合わせの切り分け、依頼内容、受入確認、再発防止を一続きで記載 |
| PL・PMO候補 | 進捗・課題・品質を見た範囲 | 人数ではなく、対象範囲、判断したこと、エスカレーション先、残した管理物を記載 |
次の職種へ進む前に不足しやすい条件
必須要件との対応
求人票の必須要件を1行ずつ抜き、自分のどの案件・どの文が証拠になるかを横に置きます。対応しない要件は空欄のままにします。
判断の境界
「担当」だけでなく、自分で決めた範囲、確認して進めた範囲、担当外だった範囲を分けます。
再現性
成果の大きさより、別の案件でも再現できる確認順・観点・調整方法が読めるかを確認します。
今は進まない方がよいケース
- 応募先が違うのに、同じ要約・同じ先頭案件のまま提出しようとしている場合
- 確認できない工数削減率や件数を、文章を強くするために追加しようとしている場合
- 職種名と技術スタックだけで長くなり、誰に何を返した仕事かが書けていない場合
90日で作れる実績
-
1〜30日
過去2案件の事実を、担当範囲・判断・相手・変化の4列で棚卸しする
残す証拠：事実台帳。数字には確認元も記載する
-
31〜60日
狙う職種の求人3件から共通する必須要件を抽出し、事実台帳と対応付ける
残す証拠：求人要件対応表と、不足要件の一覧
-
61〜90日
先頭案件と職務要約を応募先ごとに組み替え、第三者が要件を判定できるかレビューする
残す証拠：職種別の職務要約2版と、修正理由
診断結果タイプ別の読み分け
- 上流SE・PL/PM
- 要件との接点、設計判断、後工程へ返した内容を先頭に置く。
- PMO・ITコンサル
- 課題の分類、期限・影響、意思決定者へ上げた材料を先頭に置く。
- 社内SE・DX推進
- 利用部門の困りごとから、ベンダー依頼・受入・定着までを一続きで書く。
- 技術スペシャリスト
- 技術名より、制約、比較、選定理由、品質確認を読める順に書く。
- 現職で実績づくり
- 空欄になった必須要件を水増しせず、現職で作る証拠として90日計画へ戻す。
自分の経歴書を確認するチェックリスト
次の質問に答えられるか、確認してみてください。すべてに答えられる必要はありません。答えにくかった項目が、これから書く文と、いまの職場で意識して積むポイントになります。
- 案件ごとに、自分の担当範囲を工程名以外で言える
- 判断したこと（確認先、切り分け、優先度）を1つ以上書ける
- 残した変化を、事実として確認できる範囲で書ける
- 応募先の必須要件と、自分の文が対応している
- 規模・人数・期間は、確認できる数字だけを使っている
- やっていない要件定義やマネジメントを足していない
- 職種名を変えて、仕事内容まで変えていない
まずは、1案件を判断できる文にする
全部の案件を一度に直す必要はありません。先に直すのは、応募先が最初に読む1案件です。
- 担当した範囲（工程名だけで終わらせない）
- 判断したこと（誰に、何を確認したか）
- 残した変化（手順、手戻り、共有の仕方）
- 応募先の必須要件との対応
ITキャリア診断では、12問への回答から、今の経験と比較しやすいキャリア方向を整理できます。診断結果はキャリアを決定するものではなく、比較候補を整理するための仮説です。職務経歴書の文面までは、診断だけでは判断できません。
関連記事
この記事は経験の伝え方の整理です。転職成功や年収アップを保証するものではありません。診断結果はキャリアを決定するものではなく、比較候補を並べるための仮説です。数値は、事実として確認できる場合のみ使ってください。