SAP SD/MMコンサルのスキルシートの書き方｜面談で評価される実績の見せ方
公開 2026-10-29 監修：株式会社エージェントベスト
SAP SD/MMコンサルのスキルシートは、業種と取引の形（受注生産か在庫販売か、直送や委託在庫があるかなど）をプロジェクトの冒頭に書き、SDとMMの比重を分けたうえで、担当内容には通常の流れより「例外の処理」を具体的に書くのが基本です。販売と購買は会社ごとの商習慣で中身が大きく変わるため、取引の形が書かれていないと、読み手は経験を自分の案件に当てはめられません。
業務の流れに沿った経験の棚卸しはSAP SD/MMコンサルがフリーランスになるには、機能ごとに問われる設定はSAP SD/MMコンサルのスキルの記事で扱っています。この記事では、それをシートの上でどう見せるかを解説します。
業種だけでなく「取引の形」を書く
SD/MMのシートでよく見るのが、案件概要を「製造業向け 基幹システム導入」とだけ書く形です。同じ製造業でも、受注してから作る会社と、在庫から出荷する会社では、受注・出荷・購買の仕組みがまったく違います。プロジェクトの冒頭に、次のような取引の形を短く書いておくと、読み手は案件との近さを判断できます。
| 書いておきたい項目 | 書き方の例 |
|---|---|
| 販売の形 | 在庫販売中心、受注生産あり、代理店経由の販売あり |
| 請求の形 | 締め日でまとめて請求、都度請求、前受け |
| 調達の形 | 見込みの発注中心、外注加工あり、委託在庫あり |
| 特殊な取引 | 直送、会社間の取引、返品の多い商材 |
| 外部とのつながり | 取引先とのEDI、倉庫管理のシステム、ECサイト |
すべてを書く必要はありません。自分が設定や要件定義で扱った取引の形だけを書けば十分です。取引先の名前や、特定の会社と分かる独自の商習慣は書かないでください。書いてよい範囲の考え方はスキルシートと守秘義務の記事で扱っています。
SDとMMの比重を書き分ける
SDとMMの両方に関わった経験がある方は多いものの、多くの場合、どちらかが主で、もう一方は連携の範囲です。シートで「SD/MM担当」とまとめて書くと、読み手は両方を同じ深さで任せられると受け取ります。
担当の欄は、次のように主と従を分けて書くと、面談での説明と食い違いません。
- 主担当：SD（価格決定、請求、返品）
- 連携の範囲：MM（在庫の引当と出荷の連携部分）、FI（売上の仕訳の確認）
スキル一覧でも、SDとMMの経験年数を分けて書きます。合計の年数だけを書くと、どちらの経験が厚いのかが伝わりません。
担当内容には「例外の処理」を書く
販売・購買の通常の流れ（受注・出荷・請求、発注・入庫・照合）は、多くのプロジェクトで共通しています。そのため、通常の流れだけを書くと、どのシートも同じように見えます。経験の深さが表れるのは、例外の処理です。
| 書き換え前 | 書き換え後（架空） |
|---|---|
| 受注〜請求の設定を担当 | 締め日でまとめる請求と、得意先ごとの請求書の分け方を設定。返品と値引きの後付けの流れを設計 |
| 購買の設定を担当 | 金額と品目の区分による発注の承認を設定。請求書照合で差異が出たときの保留と解除の流れを購買・経理と決定 |
| 在庫管理を担当 | 拠点間の在庫の移動の手順を設計。委託在庫の受け払いと月末の精算の流れを設定 |
例外の処理を書くと、面談で「そのとき会計はどう動いたか」「誰が解除する運用にしたか」と具体的な質問が来るようになります。それに答えられる範囲で書くことが大切です。
作成した成果物を書く
SD/MMのコンサルタントは、設定のほかにも多くの文書を作ります。成果物の種類を書いておくと、設計の工程から任せられるかが伝わります。
- 業務フローと、標準の機能との差を整理した一覧
- 追加開発の仕様書（帳票、インターフェース、受注の入力チェックなど）
- インターフェースの項目の対応表（EDI、倉庫管理のシステムなど）
- 統合テストのシナリオ（受注から入金、購買から支払までの通しの確認）
- マスタの移行の手順と、移行後の確認の観点
成果物は見せられないため、種類の名前と、作るときに気をつけたことを一言添えて書きます。
記入例（架空）
次は、書き方の型を示すための例です。業種と規模はぼかしてあり、実在のプロジェクトではありません。
期間：20XX年1月〜翌年12月（2年）
環境：S/4HANA（オンプレミス）／新規導入
業種・取引の形：卸売業（中堅規模）。在庫販売中心、締め日でまとめる請求、仕入先からの直送あり、取引先とのEDIあり
立場：販売・購買チーム4名のうち、SDの主担当
担当：主担当はSD（価格決定、出荷、請求）。MMは直送の発注と入庫の連携部分
担当工程：要件定義、設計・設定、統合テスト、本番稼働の支援
担当内容：得意先別の特別価格と数量による値引きの判定順を設計し、設定。直送の受注から仕入先への発注、請求までの流れを設計。EDIの受注データの項目の対応表を作成
工夫・成果：価格の判定順を一覧にし、営業部門が自分で確認できる形にした。稼働直後の締め請求に立ち会い、請求書の分け方の問い合わせに対応した
実際に書くときは、ご自身の経験に置き換えてください。
スキル一覧は機能の単位で書く
スキル一覧では、「SD 6年」「MM 3年」のようなモジュール単位の年数に加えて、深く扱った機能を並べておくと、案件の要件と突き合わせやすくなります。
| 区分 | 記入例（架空） |
|---|---|
| SD | 6年。価格決定・請求・返品は設定から担当、与信は運用の経験のみ |
| MM | 3年。発注の承認・請求書照合を設定、在庫の評価はFI/CO担当と決定 |
| 業務知識 | 卸売の締め請求、直送、委託在庫の精算 |
| 周辺 | EDIの項目の対応表の作成、追加開発の仕様書の作成 |
機能ごとに「設定から担当」「運用の経験のみ」のように深さを添えると、得意な部分とそうでない部分を、読み手が誤解なく受け取れます。
導入と保守が混ざった経歴の書き方
同じ会社のシステムに、導入から保守まで長く関わる方も多くいます。その場合、1件のプロジェクトとしてまとめて書くと、設定を組んだ期間と、問い合わせに答えていた期間の区別がつきません。
導入と保守は、期間を分けて別のプロジェクトとして書きます。
- 導入のプロジェクト：期間、工程、担当した機能、作った成果物
- 保守のプロジェクト：期間、対応した問い合わせの種類、自分が要件を決めた改修、月末・期末の役割
保守の欄では、「問い合わせ対応」とまとめず、「出荷が止まったときに伝票とマスタから原因を調べた」「請求書照合の保留が増えた原因を調べ、許容範囲の設定を見直した」のように、原因を追った経験を書くと、導入の案件でも生かせる力として伝わります。
マスタと移行の経験の書き方
販売・購買の領域では、取引先や品目のマスタの経験が評価されることがあります。S/4HANAへの移行で、得意先と仕入先をビジネスパートナーに統合する作業に関わった場合は、担当内容に「重複の整理のルールを決めた」「移行後の確認の観点を作った」のように、自分が決めたことを書きます。
移行のプロジェクト全体での役割を書く方法はS/4HANA移行のスキルシートの記事で解説しています。会計との連携が厚い方はSAP FI/COコンサルのスキルシートの記事もあわせてご覧ください。
よくある質問
SDとMMの両方を同じくらい担当してきました。どう書けばよいですか？
プロジェクトごとに、どちらを主に担ったかを書けば、全体として両方の経験が伝わります。同じプロジェクトで両方を担った場合は、機能ごとに担当を並べ、会社間の取引や直送など、両方にまたがる取引をどう組んだかを書くと、両方を任せられる人として伝わりやすくなります。
EDIや倉庫管理のシステムとの連携は、どこに書けばよいですか？
プロジェクト冒頭の「取引の形」に外部とのつながりとして書き、担当内容には自分が関わった部分（項目の対応表の作成、エラー時の再処理の設計など）を書きます。相手側のシステムの製品名は、社名の特定につながらない範囲で書くか、「倉庫管理のシステム」のように一般的な言葉にしておくと安心です。
営業や購買の実務経験は、スキルシートに書いてよいですか？
書いてかまいません。SAPの経験とは別のプロジェクト欄にして、担当していた業務と、使っていたシステムを書きます。SAPを利用者として使っていた場合は「キーユーザーとして利用」と書き、設定の経験とは分けておくと、面談で説明しやすくなります。