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

SAP PP/QMコンサルのスキルシートは、業態（組立型かプロセス型か）と生産方式、使った指図の種類、検査の段階をプロジェクトの冒頭に書き、PPとQMの比重を分けたうえで、担当内容には通常の流れより「例外の扱い」と作成した成果物を書くのが基本です。工場の作り方によってPP/QMの中身は大きく変わるため、前提が書かれていないと、読み手は経験を自分の案件に当てはめられません。

分野ごとに問われる設定はSAP PP/QMコンサルのスキルの記事で扱っています。この記事では、それをシートの上でどう見せるかを解説します。製造業の経験全般の書き方は製造業の経験をスキルシートで伝える書き方もあわせてご覧ください。

プロジェクトの冒頭に「工場の前提」を書く

PP/QMのシートでよく見るのが、案件概要を「製造業向け SAP導入（PP担当）」とだけ書く形です。同じ製造業でも、部品を組み立てる工場と、原料を配合する工場では、計画・指図・検査の仕組みがまったく違います。プロジェクトの冒頭に、次の項目を短く書いておくと、読み手は案件との近さを判断できます。

すべてを書く必要はありません。自分が設定や要件定義で扱った範囲だけを書けば十分です。製品名や工程の条件など、会社や技術が特定される情報は書かないでください。書いてよい範囲の考え方はスキルシートと守秘義務の記事で扱っています。

PPとQMの比重を書き分ける

PPとQMの両方に関わった方は多いものの、多くの場合、どちらかが主で、もう一方は連携の範囲です。「PP/QM担当」とまとめて書くと、読み手は両方を同じ深さで任せられると受け取ります。担当の欄は、次のように分けて書くと、面談での説明と食い違いません。

• 主担当：PP（MRP、製造指図、実績確認）
• 連携の範囲：QM（入庫時の検査ロットと使用決定の連携部分）、CO（指図の決済の確認）

スキル一覧でも、PPとQMの経験年数を分けて書きます。合計の年数だけを書くと、どちらの経験が厚いのかが伝わりません。

担当内容には「例外の扱い」を書く

計画を回し、指図を出し、実績を上げ、検査するという通常の流れは、多くのプロジェクトで共通しています。経験の深さが表れるのは、例外の扱いです。

例外の扱いを書くと、面談で「そのとき在庫はどう動いたか」「誰が判定する運用にしたか」と具体的な質問が来るようになります。答えられる範囲で書くことが大切です。

作成した成果物を書く

PP/QMのコンサルタントは、設定のほかに多くの文書を作ります。成果物の種類を書いておくと、設計の工程から任せられるかが伝わります。

• 工場の業務フローと、標準の機能との差を整理した一覧
• 品目・部品表・作業手順の設計方針と移行の手順
• 帳票の仕様書（作業指示書、現品票、検査成績書など）
• MESや検査機器との連携の項目の対応表
• 計画から製造、検査、入庫、原価の決済までの統合テストのシナリオ

成果物は見せられないため、種類の名前と、作るときに気をつけたことを一言添えて書きます。

記入例（架空）

次は、書き方の型を示すための例です。業種と規模はぼかしてあり、実在のプロジェクトではありません。

期間：20XX年4月〜翌々年3月（2年）
環境：S/4HANA（オンプレミス）／ECCからの移行と業務の見直し
業態・方式：プロセス型（中堅規模の化学品メーカー）。見込み生産中心、一部受注生産。プロセス指図を使用
検査の段階：受入検査、出荷前検査。ロット単位で記録
立場：生産・品質チーム5名のうち、QMの主担当。PPはプロセス指図と検査の連携部分
担当工程：現行調査、要件定義、設計・設定、統合テスト、本番切替の支援
担当内容：受入検査・出荷前検査の検査計画と検査特性を設計し、設定。不合格時の使用決定と在庫の区分の変更、品質通知への流れを設計。検査機器からの結果の取り込みの項目の対応表を作成
工夫・成果：旧環境のアドオンで行っていた判定の処理を、標準の使用決定で置き換える案を品質保証部門と検討した。切替の当日、検査中のロットの移行手順に沿って移行結果を確認した

実際に書くときは、ご自身の経験に置き換えてください。

スキル一覧は分野の単位で書く

スキル一覧では、「PP 7年」「QM 3年」のようなモジュール単位の年数に加えて、深く扱った分野を並べておくと、案件の要件と突き合わせやすくなります。

分野ごとに「設定から担当」「運用の経験のみ」のように深さを添えると、得意な部分とそうでない部分を、読み手が誤解なく受け取れます。資格を持っている場合の書き方はSAP認定コンサルタントの記事で扱っています。

導入と保守、移行が混ざった経歴の書き方

同じ工場のシステムに、導入から保守、移行まで長く関わる方も多くいます。1件のプロジェクトとしてまとめて書くと、設定を組んだ期間と、問い合わせに答えていた期間の区別がつきません。導入・保守・移行は期間を分けて、別のプロジェクトとして書きます。

保守の欄では、「問い合わせ対応」とまとめず、「計画手配が二重に作られた原因を品目マスタと部品表の有効期間から調べた」「検査ロットが作られない原因を検査の設定から調べた」のように、原因を追った経験を書くと、導入の案件でも生かせる力として伝わります。移行の役割の書き方はS/4HANA移行のスキルシートの記事で解説しています。

よくある質問

PPとQMの両方を同じくらい担当してきました。どう書けばよいですか？

プロジェクトごとに、どちらを主に担ったかを書けば、全体として両方の経験が伝わります。同じプロジェクトで両方を担った場合は、分野ごとに担当を並べ、入庫時の検査や工程内の検査など、両方にまたがる流れをどう組んだかを書くと、両方を任せられる人として伝わりやすくなります。

MESや検査機器との連携は、どこに書けばよいですか？

プロジェクト冒頭の「連携するシステム」に書き、担当内容には自分が関わった部分（項目の対応表の作成、エラー時の再処理の設計など）を書きます。相手側のシステムの製品名は、社名の特定につながらない範囲で書くか、「製造実行のシステム」のように一般的な言葉にしておくと安心です。

工場で品質保証や生産管理を担当していた経験は書いてよいですか？

書いてかまいません。SAPの経験とは別のプロジェクト欄にして、担当していた業務と、使っていたシステムを書きます。SAPを利用者として使っていた場合は「キーユーザーとして利用」と書き、設定の経験とは分けておくと、面談で説明しやすくなります。