監修者
リメディ株式会社 ヘッドハンター
日髙 大志 | HIDAKA Taishi
筑波大学大学院を卒業後、日本工営（開発コンサルティング会社）に新卒入社。官公庁・建設・不動産・総合商社セクターでの国際開発プロジェクトにコンサルタントとして従事。その後、KPMGコンサルティング株式会社に参画し、DXコンサルタントとして、官公庁・不動産セクターでのDX推進に携わる。
コンサルタントとしてキャリアを歩む中で、優秀な人材がポテンシャルを最大限発揮して活躍することが企業の成長へ直結することを実感し、ヘッドハンターとしてリメディに参画。コンサルティングファーム、M＆A、不動産・建設業界を中心にハイキャリア層の採用・転職支援を実施。
NTTデータへの応募では、大規模案件に関わった事実だけで職務経歴書を組み立てないでください。応募先でも担える役割を一つ決め、その役割を裏づける案件から並べるのが基本です。公式の経験者採用情報には、プロジェクトマネージャー、アプリケーション開発、コンサルタント、企画営業など別の役割が示されています。2026年8月19日時点の公式情報では、応募職種によって先に示す実績と記載順が変わります。
NTTデータ向け職務経歴書のポイント
最初に応募求人の役割を読み、自分が決めたことを示せる案件を選びます。PMならQCDと合意形成、アプリケーション開発なら仕様・設計・試験、コンサルなら構想と定着、企画営業なら顧客課題と提案実行が主線です。
| 応募タイプ | 先に置く証拠 | 補足する情報 |
|---|---|---|
| PM・PL | 制約下での判断、QCD、合意、完了条件 | 規模、期間、体制、技術 |
| アプリケーション開発 | 仕様決定、設計判断、試験・リリース | 言語、製品、担当工程 |
| DXコンサル | 経営・業務課題、構想、KPI、定着 | 手法、ツール、体制 |
| IT企画営業 | 顧客課題、提案仮説、協働、実行結果 | 商材、担当顧客、契約規模 |
応募求人を決めてから案件を選ぶ
NTTデータの公式職種紹介では、SE・PMは要件定義、設計・構築、進捗管理を担います。企画・営業は顧客の事業課題を捉えて提案し、コンサルタントは将来像の構想から実装・効果創出まで伴走します。同じ会社でも役割が違うため、会社名だけでは主実績が決まりません。
職務要約を書く前に、求人から「対象顧客」「解く課題」「任される工程」「必要な経験」を抜き出します。その後、自分の案件を照合してください。応募求人を変える場合は、経歴の事実を変えず、職務要約と案件の順番を組み替えます。
公式求人4タイプで先に示す実績を決める
以下は採用の配点ではありません。募集要項の仕事内容・必要条件と、職務経歴書で示す経験を対応させた表です。
| 公式求人 | 確認できる役割・条件 | 先に示す実績 | 弱い書き方 |
|---|---|---|---|
| 法人PM | 要件定義からリリースの理解、QCDを意識したPM・PL経験 | 制約、比較した案、判断、関係者との合意、完了条件 | 人数・予算・肩書だけを書く |
| モバイル向けアプリ開発 | 要件定義から開発、顧客との直接調整など | 仕様を決めた背景、設計、試験、リリース、顧客調整 | 言語と工程を列挙する |
| AI Transformationコンサルタント | 構想、ロードマップ、課題定義、成果創出までの支援 | 経営・業務課題、KPI、データ制約、実行定着 | 提案資料を作った事実で終える |
| 公共IT企画営業 | 企画・提案・営業、長期顧客関係、チームでの活動 | 提案仮説、技術部門との協働、合意、受注後を含む実行 | 売上だけを個人成果にする |
主要案件は六つの要素で書く
案件説明は、担当工程の長さではなく、課題と結果の間にある判断を示します。次の六要素に分けると、チーム成果と本人の責任を混ぜにくくなります。これは編集部の整理であり、NTTデータが公開する評価基準ではありません。
| 要素 | 書く内容 | 確認する問い |
|---|---|---|
| 対象課題 | 顧客・利用者と当時の問題 | なぜ着手したか |
| 担当 | 工程、権限、責任の境界 | 自分が負った責任は何か |
| 制約 | 品質、納期、予算、制度、技術 | 何を同時に満たす必要があったか |
| 判断 | 比較した案と選択理由 | なぜその案を選んだか |
| 協働 | 顧客、社内、協力会社との合意 | 誰と何を決めたか |
| 結果 | 説明できる数値または状態変化 | 確認方法を説明できるか |
職種別のBefore・After構造
以下は完成文ではなく、事実を置く順番です。角括弧は自分の実績へ置き換え、担当していない工程や架空の数値を加えないでください。
PM・PL
Before：「大規模プロジェクトのPMを担当した」
Afterの構造：「[顧客業務の課題]に対し、[責任範囲]で[QCD上の制約]を整理。[比較した案]から[選択理由]に基づき方針を定め、[関係者]と合意して[確認できる結果]まで進めた」
アプリケーション開発
Before：「要件定義からリリースまで幅広く担当した」
Afterの構造：「[利用者の課題]を[要件・仕様]へ落とし込み、[設計上の制約]を踏まえて[判断]。[試験とリリースの担当]を通じて[利用・品質の変化]を確認した」
コンサル・企画営業
Before：「顧客のDX推進に貢献した」
Afterの構造：「[経営・業務課題]から[目指す状態]を定義し、[データ・IT・組織上の制約]を整理。[提案・ロードマップ]を[関係者]と実行し、[定着または成果]を確認した」
職務要約は責任から始める
職務要約の第1文では、在籍社名の列挙より、どの顧客・業務に何の責任を負ったかを答えます。続けて経験期間、代表案件、技術や手法を置きます。責任、代表案件、補助情報の順にすれば、応募求人との接点が先に伝わります。
| 順番 | 書く内容 | 避けること |
|---|---|---|
| 1 | 対象顧客・業務と自分の責任 | 「幅広く経験」だけで始める |
| 2 | 代表案件での判断と結果 | 案件名と規模だけを書く |
| 3 | 経験期間、技術、資格 | 名詞だけを長く連ねる |
| 4 | 応募先でも担える役割 | 将来の希望を現在の実績に混ぜる |
大規模案件は全体成果と本人の担当を分ける
案件全体の予算、人数、利用者数は背景情報です。チーム全体と本人の成果を別の文にしてください。本人の証拠は、担当領域、比較した条件、承認を得た方針、作成・改善した成果物、確認した結果です。
| 混ざりやすい情報 | チーム全体 | 本人の証拠 |
|---|---|---|
| システム刷新 | 全体範囲、期間、体制 | 担当領域、設計判断、合意、成果物 |
| 品質改善 | 案件全体の障害・不具合 | 変更した基準、試験、定着確認 |
| 営業成果 | 部門売上、契約全体 | 担当課題、提案、折衝、本人が確認した結果 |
隣接経験と不足を正直に分ける
別職種でも活かせる経験はあります。経験を棚卸しする一例として、社内SEは利用部門の課題整理やベンダー調整、受託開発は要件・設計・品質、法人営業は顧客課題と社内協働に分けてみます。ただし、必須条件の不足は言い換えないでください。
共通する経験、応募求人では未経験の領域、入社前に補う内容を分けます。言い換えだけでは満たせない条件がある場合は、隣接求人や準備期間も比較します。この記事は応募の可否や選考結果を保証するものではありません。
面接につながる提出前チェック
提出前の自己点検では、職務経歴書に書いた中心実績について「なぜその判断をしたか」「本人の担当はどこか」「結果をどう確認したか」を自分の言葉で説明します。書類と口頭説明をそろえることが最後の確認です。
- 応募求人と職務要約の第1文が一致している
- 主要案件に本人の判断と責任範囲がある
- 数字の算出方法と出所を説明できる
- チーム成果を個人成果として書いていない
- 未経験の工程・技術を経験済みに見せていない
- 求人の必要条件を提出直前に再確認した
まとめ｜応募職種と中心実績を一つに絞る
NTTデータ向けの職務経歴書では、応募先でも担える役割を決め、その役割を示す案件から並べるのが基本です。PM、開発、コンサル、企画営業では、同じ経歴でも先に示す実績が変わります。求人要件と自分の案件を照合できる人は、自分で進めて構いません。複数職種で中心実績を決められない場合や、本人の担当を切り分けにくい場合は、提出前に第三者と整理すると判断が早まります。