複数プロジェクトを職務経歴書に整理する方法｜並行期間と優先判断を見せる

案件が重なると、時系列だけの職務経歴書は同じ月が何度も現れ、在籍の連続性が分かりにくくなります。案件だけで構成すると、どの会社や役割に属する経験かが隠れます。在籍タイムラインと案件一覧の二層で解決します。

直近の経験が重要なら、会社は逆編年体で並べます。各社の中で、案件を期間と関連度の順に置きます。コンサルティングや業務委託で短期案件が多い場合は、契約期間の下に案件単位の行を置きます。

期間、案件または課題、分かる場合の工数比率、役割、人数、結果を列にします。例は「2025.01〜2025.06｜在庫APIの信頼性回復｜工数約40%｜テックリード｜6名｜リリース頻度を回復」です。偽の精密さより、30〜50%のような正直な範囲を使います。

案件一覧は経験の広さと重複を説明する場所です。二つ目の詳細経歴にはしません。各行は一行にし、特定技術が成果の中心でない限り、技術は短いスキル欄へまとめます。

応募職種との関連、自分の責任の強さ、根拠の質、新しさ、他案件との違いで各案件を評価し、上位二〜三件だけ詳しく書きます。同種案件は「同様の連携を8件実施」とまとめ、一件を代表例として説明します。

予算が最大の案件だけを選ぶ必要はありません。小さな案件でも、応募先が求める判断を自分が担っていれば強い根拠です。一覧で全体を残しながら、一ページ目を求人要件への回答にします。

「多数の案件を担当」では優先順位の証拠になりません。重大な本番障害をロードマップより優先した、週次工数会議で保守枠を守った、共有の専門担当者に合わせてマイルストーンをずらした、など実際の運用ルールを書きます。

一つの衝突、使った情報、選んだトレードオフ、結果を示します。優先順位を上司が決めた場合は、ポートフォリオ全体を決めたように書かず、その判断の中で自分が担った範囲を説明します。

Before: 八つの案件すべてに同じ長さで「要件定義、設計、実装、テスト」と書く。重複期間、重要案件、本人の判断が見えません。

After: 六行の一覧で全期間を示し、二案件だけ詳述します。「請求移行を約半分の工数で支援しながら、在庫信頼性の緊急対応を担当。障害件数と依存リスクを根拠に2週間の機能開発停止を提案し、失敗していた照合処理を復旧、運用引継ぎも実施。関係者合意の上で請求側のマイルストーンを1週間変更し、在庫不一致は以前の管理範囲へ回復。」これは架空の形式例です。

合計が不可能な工数、説明のない空白、同じ成果の重複、実際の案件期間外に書かれた技術がないか確認します。詳述した各案件には、それぞれ異なる掲載理由が必要です。

求人票に合わせて根拠の順番は変えても、経歴自体は書き換えません。履歴書マッチ分析で一覧に埋もれた要件を見つけ、詳しく書く二案件を選びます。日付と事実は固定します。一覧と詳細欄で長くなりすぎる場合は、タイムラインや優先判断の根拠を削る前に、重複する作業説明を短くします。