
SAPコンサルの職務経歴書|案件の担当者に伝わる書き方
SAPコンサルタントの職務経歴書は、「〇〇社のS/4HANA導入プロジェクトに参画(3年)」のような1行で終わってしまいがちです。ただ、この書き方だと、案件の担当者には「どのモジュールの、どの段階で、どんな役割だったのか」が分かりません。
この記事では、SAPの案件の担当者が経歴書のどこを見ているかを、当社に届いた案件の必須条件を整理した結果から読み解き、そのうえで、全モジュールに共通する経歴書の書き方をまとめます。モジュールごとの書き方は、各モジュールの記事で紹介しているので、この記事では「どの領域の方にも当てはまる骨組み」に絞ります。
このnoteは、SAP人材に特化した案件紹介サービス「アサインコネクト」が書いています。
当社には、SAPの導入・移行・運用保守など、さまざまな領域の案件が継続的に届いています。この記事でも、実際に届いた32件の必須条件を整理して紹介しています。
SAPの導入や運用保守で積んできた経験を活かせる案件を探している方には、これまでのご経験と、稼働率・リモートの可否などの希望条件をうかがったうえで、合う案件を個別にご案内しています。
下の画像か、その下のリンクを押すと、アサインコネクトのページが開きます。案件の例やご利用の流れを確認でき、LINEから希望条件を登録できます。

この記事でわかること
SAPの案件の担当者が、経歴書をどう読んでいるか
当社に届いた32件の必須条件が、どんな言葉でできていたか
プロジェクト1件ごとに書いておきたい6つの項目と、書き方の例
経歴書でよくあるつまずきと、その直し方
1. 案件の担当者は、必須条件と経歴書を1行ずつ照らしている
SAPの案件には、たいてい「必須スキル」と「尚可スキル」が書かれています。案件の担当者は、候補者の経歴書を受け取ると、この必須の項目を1つずつ経歴書の記載に照らして、合うかどうかを確かめます。
当社でも、案件に合う方を探すときは、必須の項目ごとに経歴書のどこに根拠があるかを確かめ、書かれていないものは「まだ確認できていない」として扱っています。ご本人に聞けば分かることもありますが、案件によっては、経歴書だけで次に進めるかが決まることもあります。
つまり、経歴書は「経験したこと」ではなく「書いてあること」で読まれる資料です。実際には要件定義を担当していても、経歴書に「導入プロジェクトに参画」としか書いていなければ、「要件定義の経験がある」とは読んでもらえません。
2. 当社に届いた32件の必須条件は、6つの言葉でできていた
2026年の7月〜10月に当社が受け取ったSAPの案件のうち、重複を除いた33件で、必須条件が書かれていた32件の中身を、当社で分類しました。1件の案件が複数の項目に当てはまることがあります。当社1社に届いた範囲から読み取れる傾向で、業界全体の比率を示すものではありません。
担当する領域(モジュール・製品・業務):32件中28件。FI・CO・SD・MMなどのモジュール、SACやBTPなどの製品、経理や販売物流などの業務を名指しする条件
工程(段階):32件中20件。「要件定義の経験」「設計とコンフィグの経験」「テストの計画と推進」「運用保守の経験」のように、どの段階の経験かを名指しする条件
顧客や関係者と話して決める経験:32件中15件。顧客との要件や課題の整理、折衝、関係者との調整を求める条件
役割:32件中12件。リーダー・サブリーダー・リードの補佐、PMO、メンバーのタスク管理やレビューを求める条件
自分で進められること:32件中6件。「一人称で」「自走して」「主体的に」など、指示を待たずに作業を進められることを求める条件
英語・規模:英語でのやり取りが3件、50名以上の規模のプロジェクトの経験が2件。英語の条件の重さ(会話か読み書きか)の違いは、別記事「英語を使うSAP案件|グローバル・バイリンガルの案件で求められること」で整理しています。
この結果から言えるのは、「どの領域で」「どの段階を」「どんな役割で」「誰と話して」担当したかが、経歴書に1件ずつ書かれていれば、32件の必須条件の多くに経歴書だけで答えられる、ということです。逆に、プロジェクト名と期間だけの経歴書では、この6つのどれにも答えられません。
ご自身の経験が、どの案件の必須条件に近いか気になった方へ。希望条件をLINEで登録いただくと、近いSAP案件が出たときに個別にご案内します。
3. 経歴書の全体の形|最初の数行で「どんな人か」を伝える
SAPコンサルタントの経歴書は、上から次の順にまとめると読みやすくなります。
要約(3〜5行):主な領域、経験した段階、役割、年数をひと目で分かるように書く
スキルの一覧:担当したモジュール・製品、扱ったバージョン(ECC/S/4HANA、オンプレミス/クラウド)、使える言語(英語など)
プロジェクトの経歴:新しい順に、1件ずつ(第4章の6項目)
資格:SAPの認定資格は、名前と取得した年を書く
自己PR(任意):得意な進め方や、次に担当したい領域
案件の担当者は、何人分もの経歴書を続けて読むことが多いので、最初の要約で「この人はどの枠に合いそうか」が分かると、続きを読んでもらいやすくなります。たとえば「SD・MMを中心に、S/4HANAの導入で要件定義から設定までを担当。直近2件はサブリーダー」と書いておけば、販売物流の上流の枠の人だとすぐに伝わります。
SAPの認定資格の種類や選び方は、別記事「SAP資格一覧|レベル・領域別の選び方と、2026年に変わった認定制度」で整理しています。
4. プロジェクト1件ごとに書いておきたい6つの項目
プロジェクトの経歴は、第2章の6つの言葉に答えられるように、1件ごとに次の項目を書いておくと、案件の担当者が判断しやすくなります。
期間と体制:いつからいつまでか。プロジェクト全体の人数と、自分のチームの人数
顧客の業種と規模:顧客名を出せない場合は「国内の電機メーカー(グループ会社10社)」のように、業種と規模で書く
製品と方式:ECC/S/4HANA、オンプレミス/クラウド。新規導入・移行・運用保守のどれか
担当した領域:モジュールと、その中で受け持った業務(例:MMの購買と在庫管理)
担当した工程:構想策定・要件定義・設計・設定・テスト・データ移行・本番稼働の支援・運用保守のうち、自分が担ったもの
役割と、自分でしたこと:メンバー/サブリーダー/リーダーのどれか。自分で決めたこと、顧客と合意したこと、まとめた人数
工程の名前は、SAPの導入の進め方(SAP Activate)の段階に合わせて考えると整理しやすくなります。SAPの公式の説明では、SAP Activateは「Discover(調査)」「Prepare(準備)」「Explore(標準との適合の確認)」「Realize(構築)」「Deploy(本番への移行)」「Run(稼働後の運用)」の6つの段階に分かれています。経歴書には、案件の条件と同じく「要件定義」「設計」のような日本語の言葉で書いて構いません。各段階の仕事の中身は、別記事「SAP導入コンサルの仕事|構想策定・要件定義・設計の各段階で何をするか」で詳しくまとめています。
書き方の例(架空の例です)
伝わりにくい例:
2023年4月〜2025年3月 製造業のS/4HANA導入プロジェクトに参画(MM担当)
伝わりやすい例:
2023年4月〜2025年3月(2年) 国内の機械メーカー(グループ会社5社)のS/4HANA新規導入(オンプレミス)。プロジェクト全体は約60名、ロジチームは8名
担当領域:MMの購買と在庫管理。SDとの在庫の引当、FIとの請求書の照合の連携も担当
担当工程:要件定義、設計、設定、結合テスト、受け入れテストの支援
役割:サブリーダー(メンバー3名)。購買部門との要件の定例を進め、承認の流れと発注の種類を合意して決定。メンバーの設計書のレビューと、テストの結果の確認を担当
2つ目の書き方なら、第2章の6つのうち「領域」「工程」「顧客と話して決める経験」「役割」が、読むだけで分かります。
5. 経歴書でよくある4つのつまずき
「参画」だけで、自分の担当が書かれていない
「〇〇プロジェクトに参画」は、何をした人なのかが分からない書き方の代表です。チームとしての成果と、自分が担当したことを分けて、「自分で決めたこと」「自分が進めたこと」を書きます。
工程を「上流」「全般」でまとめている
「上流工程を担当」「導入全般を担当」では、要件定義なのか設計なのかが分かりません。第2章のとおり、案件の条件は工程を名指しすることが多いので、経歴書でも工程を1つずつ書きます。
役割が書かれていない
リーダーやサブリーダーの経験があっても、役職の名前が書かれていないと読み取れません。リーダーの経験は、まとめていた人数と、レビューやタスク管理など何をしていたかまで書くと伝わります。PMOの経験の書き方は、別記事「SAP PMOの仕事|SAP導入のPMO案件で求められる経験」でも紹介しています。
古いプロジェクトほど長い
経歴を古い順に書き、昔のプロジェクトの説明が長くなっていると、直近の経験が埋もれます。案件の担当者がまず見るのは、直近の数年です。新しい順に並べ、直近のプロジェクトほど詳しく書きます。
6. 領域ごとに、経歴書で見られる点
ここまでの骨組みは全モジュールに共通ですが、領域ごとに「書いておくと伝わりやすいこと」は少しずつ違います。各領域の書き方は、次の記事で紹介しています。
経営管理・計画:「SAP SAC(Analytics Cloud)コンサルの仕事|経営管理・計画の案件で求められる経験」
クラウドの導入:「SAP Public Cloudの導入案件|Fit to Standardでコンサルに求められること」
モジュール同士のつながりを整理したいときは「【2026年版】SAPモジュール一覧と業務のつながり」、業務コンサルと技術寄りのコンサルの違いは「SAPコンサルタントとは|仕事内容・4つのタイプ・キャリアの進み方」も参考にしてください。
7. よくある質問
顧客の会社名は書いてもよいですか?
守秘の取り決めがある場合は、会社名を出さず、業種と規模で書くのが無難です。「国内の大手食品メーカー」「売上〇千億円規模の製造業」のように書いても、案件の担当者は経験の中身を判断できます。
何年前までのプロジェクトを書けばよいですか?
決まりはありませんが、直近の数年を詳しく、それより前は1〜2行に短くまとめると、全体が読みやすくなります。古いプロジェクトでも、今の案件の必須条件に当てはまる経験(たとえば、ある領域のリーダーの経験)があるなら、その部分は省かずに書きます。
スキルシートと職務経歴書は、別に作るべきですか?
呼び方は会社によって違いますが、案件の担当者が知りたいことは同じです。この記事の6つの項目が入っていれば、どちらの形でも伝わります。紹介の会社から決まった形式を指定された場合は、その形式に、この6つの項目を入れていきます。
希望の単価や稼働率も、経歴書に書いたほうがよいですか?
当社では、希望の単価・稼働率・リモートの可否などの条件は、経歴書とは別にうかがっています。経歴書は経験を伝える資料として、条件は別にまとめておくと、案件ごとに条件だけを調整しやすくなります。
まとめ
SAPの案件の担当者は、必須条件を1つずつ経歴書の記載に照らしている。経歴書は「経験したこと」ではなく「書いてあること」で読まれる
当社に届いた32件の必須条件は、「領域」「工程」「顧客と話して決める経験」「役割」「自分で進められること」「英語・規模」の6つの言葉でできていた
プロジェクト1件ごとに、期間と体制・顧客の業種と規模・製品と方式・領域・工程・役割と自分でしたこと、を書いておくと、必須条件の多くに経歴書だけで答えられる
アサインコネクトは、SAP人材に特化した案件紹介サービスです。
希望条件をLINEで登録すると、条件に合うSAP案件を個別に受け取れます。
参考資料
SAP Learning「Describing the Methodology Structure」(Discovering SAP Activate - Implementation Tools and Methodology) https://learning.sap.com/courses/discovering-sap-activate-implementation-tools-and-methodology/describing-the-methodology-structure_d959f6fc-ebfc-4143-94b3-6b83a6339b8b