富士通の職務経歴書の書き方｜コンサル・SE・開発・営業・PM別に解説

富士通向けの職務経歴書では、「IT業界でDXに関わった」と広く見せるより、応募ロールで担う工程と、自分の主案件を一対一で結ぶことが重要です。コンサルタント、ソリューションエンジニア、開発、セールス、プロジェクトマネジメントでは、同じ案件でも残すべき判断が異なるからです。

書き分けの基準は、富士通の公式職種紹介と現行募集です。公開されていない選考基準は推測せず、本人が面接でも説明できる事実に絞ります。

富士通向けの職務経歴書は応募ロールから逆算する

富士通の公式職種紹介には、セールス、コンサルタント、ソリューションエンジニア、データ、インフラ、研究開発、ソフトウェア開発など幅広い仕事が掲載されています。システム関連職も、ビジョン策定や検証、構築、運用、その先の価値創出まで連続しています。

そのため、職務経歴書の起点は会社の大きさや技術名ではありません。まず応募する募集要項を一つ選び、「その仕事のどの工程に、自分のどの案件が対応するか」を決めます。応募先が変われば、職務要約と最初に置く案件も変えてください。

応募ロール	最初に示す経験	案件欄で残す判断
コンサルタント	顧客課題を構造化した案件	調査、仮説、ユースケース、データ要件
ソリューションエンジニア	要件を実装・運用へ落とした案件	設計、移行、品質、運用上の選択
研究開発・ソフトウェア開発	技術課題を検証・実装した案件	選択肢比較、実装、最適化、成果物
セールス	顧客と社内外を動かした提案	課題、提案仮説、体制、意思決定
プロジェクトマネジメント	制約下で成果物を成立させた案件	計画、予算、契約、リスク、合意

先に募集要項と主案件を一対一で結ぶ

募集要項の業務を左側、自分の案件を右側に書き出します。対応する案件が複数ある場合は、応募職種の中心工程を最も長く説明できるものを主案件にします。足りない要件は無理に補わず、関連経験として範囲を限定してください。

職務要約・案件欄・スキル欄の役割を分ける

• 職務要約：応募ロール、対象顧客・業務、主な責任を短く示す
• 案件欄：課題、自分の判断、関係者、実行、結果を時系列で示す
• スキル欄：案件欄で使った技術・方法・資格だけを裏づけとして並べる

スキル欄にある製品名や方法論が案件欄に登場しないと、経験の深さが伝わりません。逆に案件欄で重要な判断をしているのに、職務要約が「幅広く経験」とだけ書かれている場合も、主張がぼやける原因です。

コンサルタントは仮説から実装への接続を書く

Data & AI領域の現行募集は、業界・競合・技術の調査、顧客業務の整理、課題仮説、AIユースケース、データ要件・制約、提案資料を仕事として挙げています。職務経歴書では「提案した」という結果だけでなく、何を調べ、どの業務を分解し、なぜその仮説を選んだかを残します。

記載項目	書く内容	確認できること
調査	業界、顧客業務、競合、技術のどこを見たか	仮説の前提
課題仮説	現象と原因をどう分けたか	論点の組み立て
ユースケース	誰のどの判断・作業を変える案か	技術と業務の接続
実装接続	データ要件、制約、検証、次工程	提案後まで見ている範囲

前職がエンジニアの場合は、実装の詳細を減らすのではなく、顧客業務の課題をどう発見し、どの選択肢を提案し、実装条件へ落としたかを前に出します。前職が企画職なら、企画書だけで終わらず、検証と実装部門への引き渡しまでを書きましょう。

ソリューションエンジニアは要件と運用の判断を残す

富士通の公式職種紹介は、顧客のビジョンから検証、システム構築、運用、その先の価値までを仕事の流れとして示しています。「上流から下流まで担当した」だけでは、どこで自分が判断したか分かりません。

• 要件が対立した場面で、何を優先し、誰と合意したか
• 設計の選択肢と、性能・品質・費用・移行・運用のどの制約を見たか
• 構築後に起きた障害や運用負荷へ、どの変更を加えたか
• 顧客部門へ定着させるため、手順や役割をどう変えたか

成果数値を置く場合は、本人が説明できる範囲に限定します。守秘義務で数値を出せない案件は、処理の対象、改善の方向、影響を受けた部門、定着した運用など、事実として説明できる変化で補えます。

研究開発・ソフトウェア開発は技術選択と外部価値を示す

次世代アクセラレータ向けソフトウェア開発の現行募集は、研究から開発、設計・実装・最適化、OSSを含む成果、社内外関係者との連携を扱っています。技術名を並べるだけでなく、技術課題、比較した案、採用理由、検証、利用先をつないでください。

例えば「生成AI関連の開発に従事」では、責任範囲が不明です。「どの処理上の制約を対象にし、どの設計案を比較し、何を実装・検証し、次の開発や外部成果へどう渡したか」という順にすると、技術選択の再現性が伝わります。論文、特許、OSS、製品化などは、本人の関与範囲を明記してください。

セールスは顧客課題と社内リソースの組み合わせを書く

大手金融グループ向けの現行募集は、顧客の新規ビジネスに対し、SE、プロダクト、アライアンス先と連携し、顧客と社内のキーパーソンを動かす仕事を示しています。個人売上だけでは、この体制をどう作ったかが見えません。

案件欄の順序	具体化する問い
顧客課題	顧客のどの事業・業務判断が停滞していたか
提案仮説	製品起点ではなく、何を変える案を作ったか
体制	SE、プロダクト、外部パートナーの誰をなぜ組み合わせたか
意思決定	顧客内の論点と、前進させた材料は何か
結果	受注だけでなく、実行・次工程へ何が移ったか

プロジェクトマネジメントは予算・成果物・リスクを分解する

AIアクセラレータのプロジェクトマネジメント募集は、計画、実績、予算、成果物、マイルストーン、委託先、契約、リスクを管理対象に挙げています。「大規模プロジェクトを管理」だけでなく、管理対象ごとに起きた差異と、自分が行った是正を書きます。

人数や予算を示せる場合も、それだけを成果にしません。マイルストーンが遅れた原因、成果物の受入条件、委託先との契約上の論点、技術チームと事業側の認識差などから一つを選び、どの判断材料で合意したかを説明してください。

募集要項の仕事と自分の案件を対応させる

募集要項の言葉をそのまま自己PRへ貼っても、経験の証明にはなりません。「仮説」「リーダーシップ」「技術理解」などの語を、自分が実際に行った判断へ戻します。

Before / After

Before	Afterの構造
金融業界のDX案件で顧客折衝から導入まで幅広く担当	対象業務の課題→調査・仮説→顧客と社内の論点→提案・設計判断→実装・運用への接続→本人の確定実績
コミュニケーション力を生かしてプロジェクトを推進	利害が異なった関係者→共有した判断材料→変更した計画・要件→合意後の成果物
最新技術を活用して性能を改善	技術上の制約→比較した案→採用理由→実装・検証→利用または外部成果への接続

前職別の対応表

• SIer経験者：担当工程の広さより、要件・設計・移行・運用で自分が判断した箇所を選ぶ
• 事業会社の企画経験者：企画の名称より、業務課題、検証、実装部門との合意、定着を書く
• ソフトウェア企業の営業経験者：売上だけでなく、顧客の意思決定と技術部門をどう接続したかを書く
• 研究開発経験者：技術成果だけでなく、利用条件、開発移管、外部成果のどこまで担ったかを書く

職務要約・案件・スキルの内容をそろえる

職務要約では主案件を一文で要約し、案件欄でその判断を展開し、スキル欄で使った方法や技術を裏づけます。三つの欄で別々の強みを主張しないことがポイントです。

欄	役割	確認項目
職務要約	応募職種との接点を示す	顧客・課題・責任・主結果があるか
案件詳細	主張を事実で証明する	判断、関係者、実行、結果がつながるか
スキル	案件を再現する手段を示す	案件内で使った事実があるか

面接で深掘りされる説明を先に整える

面接回数や質問内容を予測するより、職務経歴書に書いた主案件を、背景、担当範囲、判断、反対意見、結果、次に変える点の順で説明できるようにします。チーム成果は、チーム全体と自分の担当を分けてください。

応募求人が変わる場合は、同じ案件でも説明の中心を変えます。コンサルタントなら課題仮説、セールスなら顧客と体制、PMなら制約と是正を中心にします。ただし、事実や自分の担当範囲を求人に合わせて変えてはいけません。

富士通の職務経歴書に関するよくある質問

関連記事

• 富士通の年収を見る
• SIer業界の年収を比較する
• NECの年収を見る