SCMコンサルタントのスキルシートの書き方｜面談で評価される実績の見せ方

SCMコンサルタントのスキルシートは、プロジェクトごとに「扱った領域と局面」「対象の範囲」「自分の立場」「変えた決め方」「前後で動いた指標」をそろえて書くのが基本です。読み手は、SCMという大きな言葉の中で、あなたが需要予測・S&OP・在庫・調達・物流のどこを、どの深さで担ったのかを探しています。

この記事では、要約の作り方、プロジェクト欄で厚く書く項目、架空の記入例、数字を出せないときの書き方を整理します。スキルシート全般の基本はスキルシートの書き方の基本で解説しています。

読み手は「どの領域の、どの局面の人か」を先に探す

SCMの案件の募集は、領域と局面で書かれることが多くあります。スキルシートを読む側は、まず次の3点を探します。

1. 領域：需要予測、S&OP、在庫、調達、物流のどれが中心か
2. 局面：構想、業務とシステムの設計、導入と定着のどこを担ったか
3. 立場：分析の担当か、領域のリードか、改革全体の責任者か

「SCM改革プロジェクトに参画」とだけ書かれていると、この3点が読み取れません。プロジェクト名より先に、領域と局面が目に入るように書くことが大切です。

要約は「領域・業態・得意な局面」で組み立てる

スキルシートの冒頭の要約は、3〜4行で次の要素を入れます。

• 中心の領域（2つ程度に絞る）
• 経験した業態（組立型の製造、素材・化学、卸、小売、物流会社など）
• 得意な局面と立場
• 領域をまたいだ経験があれば一言

業態は、製造業なら組立型かプロセス型か、流通なら卸か小売かまで書くと、計画の作り方の違いが伝わります。製造業の経験の書き分けは製造業界のスキルシートの記事、物流の経験は物流業界のスキルシートの記事で詳しく扱っています。

プロジェクト欄で厚く書く項目

「変えた決め方」が一番読まれる

SCMの実績で評価されやすいのは、分析した結果より、それを受けて何の決め方を変えたかです。「在庫の分析を実施」ではなく、「品目を売れ方で3つに分け、分類ごとに補充の周期を変えるルールを設計」のように、ルールや手順として書くと、担った深さが伝わります。

「合意を取った相手」は省かない

SCMの仕事の難しさは、部門ごとの利害をそろえるところにあります。誰と、どんな対立を、どう解いたかを一行添えるだけで、領域のリードを任せられる人かどうかが伝わりやすくなります。

記入例（架空）

以下はすべて架空の例です。実在の会社や案件をもとにしたものではありません。

要約
需要予測と在庫の領域で、計画の手順と補充ルールの見直しを中心に担当。組立型の製造業と卸売業で、構想から定着までの経験あり。営業・工場・物流の部門をまたぐ月次の需給会議の立ち上げに関わった。

案件A（期間：1年）

• 領域と局面：需要予測・S&OP／構想〜定着
• 対象の範囲：国内の販売拠点数か所、工場2か所、製品数百品目
• 立場：業務側のリード（チーム4名中、計画の手順の設計を担当）
• 変えた決め方：営業の見込みと統計的な予測を別々に出していた手順を改め、品目群ごとに予測の出し方を決めたうえで、月次の会議で営業と工場が一つの計画に合意する流れを設計
• 合意を取った相手：営業部門（見込みの提出時期の前倒し）、工場（計画の確定のタイミング）
• 指標の変化：計画を決めるまでの日数が短くなり、欠品の件数が減少（数値は守秘のため割合で説明可能）
• 使った道具：需給計画システム（導入時の業務要件を担当）、BIツール、SQL

案件B（期間：8か月）

• 領域と局面：在庫・物流／現状分析〜業務設計
• 対象の範囲：卸売業の物流拠点3か所、取扱品目数千点
• 立場：分析と設計の担当（チーム3名）
• 変えた決め方：拠点ごとに同じ品目を持っていた在庫を、売れ方で分類し、動きの少ない品目を一か所に集める配置に変更する案を作成
• 合意を取った相手：営業部門（納品までの日数が延びる品目の説明）
• 指標の変化：在庫の総量が減る見込みを試算し、経営会議で採用

数字の書き方で迷うところ

数字を出せないときの置き換え方

在庫の金額や欠品率は、発注元にとって社外に出したくない情報です。具体的な値を書けないときは、次のように置き換えられます。

• 割合で書く（在庫の総量が◯割減少、など）
• 変化の向きだけを書く（欠品の件数が減少、計画の確定が早まった）
• 指標の種類だけを書き、面談で口頭で補う

どこまで書いてよいかは、契約の秘密保持の定めによって変わります。迷うときは、発注元を特定できない書き方にとどめましょう。秘密保持の考え方は秘密保持契約の記事で解説しています。

組み合わせで特定されないようにする

業態、拠点の数、品目の数、期間を細かく並べると、組み合わせから会社が分かってしまうことがあります。拠点の数や品目の数は「数か所」「数百品目」のように幅で書くと、規模感を伝えつつ特定を避けられます。

チームの成果と自分の担当を分ける

在庫の削減や欠品の減少は、多くの人が関わった結果です。チーム全体の成果を書いたうえで、自分が担った部分（たとえば補充ルールの設計）を分けて書くと、面談で深掘りされたときにも答えやすくなります。

スキル一覧は「領域の知識」と「手法・道具」を分けて並べる

スキル一覧は、次の2つに分けると読み手が探しやすくなります。

システムは、設定を担ったのか、利用者として使ったのか、業務要件を出したのかを書き分けます。ERPの設定そのものを担った経験は、SAP SD/MMコンサルのスキルシートの記事の書き方が参考になります。

出身による書き分け

事業会社の需給・物流の担当だった場合

自社の業務の改善を、プロジェクトの形に置き換えて書きます。「担当業務」として並べるより、「見直しのテーマ」「変えた決め方」「前後の変化」の形にすると、コンサルの案件の募集と結びつきやすくなります。

コンサルティング会社で短い案件が続いた場合

数か月の構想や分析の案件が多く並ぶと、どれも同じに見えてしまいます。案件ごとに「領域」と「変えた決め方」を一行目に置き、同じ領域の案件はまとめて書くと、得意な領域が読み手に伝わりやすくなります。提案で終わった案件は、提案した内容と、発注元が次に何を決めたかを分けて書きます。

システム導入プロジェクトの業務側だった場合

導入したシステムの名前より、そのシステムで回すことにした計画の流れや補充のルールを先に書きます。システムに合わせて業務を変えた部分、手作業で残した部分を書けると、業務を決めた人として伝わります。

よくある質問

SCMの複数の領域を経験しています。全部書くと散らかりませんか？

要約では中心の領域を2つ程度に絞り、残りはプロジェクト欄で示すと散らかりにくくなります。応募する案件の領域に合わせて、プロジェクトの並び順を変えるのも一つの方法です。

分析だけで終わったプロジェクトはどう書けばよいですか？

分析で終わった経験も、何を明らかにし、どんな案を出したかを書けば価値が伝わります。採用されなかった案でも、「どの部門の事情で見送られたか」を説明できると、面談では合意形成の理解として受け止められることがあります。

使ったシステムの製品名は書いてよいですか？

一般に流通している製品の名前は、書いてよい場合が多くあります。ただ、発注元が使っているシステムの組み合わせから会社が分かることもあるため、気になる場合は「需給計画システム」「倉庫管理システム」のように種類で書きましょう。