S/4HANA移行のスキルシートの書き方｜面談で評価される実績の見せ方
公開 2026-10-29 監修：株式会社エージェントベスト
S/4HANA移行のスキルシートは、移行方式、旧環境と新環境の版、自分の役割の3つをプロジェクトの冒頭に書き、長い移行のプロジェクトはフェーズに分けて、どのフェーズで何を担ったかを示すのが基本です。「S/4HANA移行経験あり」とまとめて書くと、新規導入なのか変換なのか、現行調査だけなのか本番の切替まで担ったのかが、読み手に伝わりません。
移行方式と役割の種類はS/4HANA移行がフリーランスになるには、役割ごとに求められるスキルと数字で示す項目はS/4HANA移行のスキルの記事で扱っています。この記事では、移行の経験をシートの上でどう組み立てるかを解説します。
最初に「どの立場のシートか」を決める
S/4HANA移行の案件に関わる人は、もともとの専門がばらばらです。会計や販売・購買のコンサルタント、Basisのエンジニア、データ移行の担当、アドオンを改修する開発者、移行の計画を管理するPMOなどがいます。
そのため、スキルシートを書く前に、自分のシートの軸を決めておく必要があります。
| シートの軸 | S/4HANA移行の経験の載せ方 |
|---|---|
| 業務モジュール（FI/CO、SD/MMなど） | モジュールの経験が主。移行はプロジェクトの「種類」として書き、担当領域で何が変わったかを担当内容に書く |
| Basis | 環境の経験が主。移行はプロジェクトの一つとして、方式と停止時間を中心に書く |
| 移行の専門（データ移行・計画管理） | 移行そのものが主。要約で移行の役割を示し、複数の移行プロジェクトを方式と役割で並べる |
モジュールやBasisが軸の方は、移行の経験だけを別に切り出すより、いつものプロジェクト欄に移行の情報を足すほうが、全体の経歴とつながって読みやすくなります。モジュールごとの書き方はSAP FI/COコンサルのスキルシートの記事、SAP SD/MMコンサルのスキルシートの記事、SAP Basisエンジニアのスキルシートの記事で解説しています。
プロジェクトの冒頭に書く4項目
移行のプロジェクトでは、次の4項目を冒頭にそろえておくと、読み手は経験の種類をすぐに見分けられます。
- 移行方式：新規導入（作り直し）、システム変換、選択的な移行のどれか
- 旧環境と新環境の版：移行元の製品と版、移行先の版と、オンプレミスかクラウドか
- 移行の範囲：対象の会社や拠点のおおまかな数、対象のモジュール
- 自分の役割：計画・管理、業務モジュール、データ移行、アドオン改修、基盤のどれか
例（架空）：「システム変換／ECCからS/4HANA（オンプレミス）へ／国内の会社コード複数、会計・販売・購買／データ移行の担当」
方式は、案件側が最も気にする項目です。同じ「移行」でも、新規導入では業務の設計の力が、変換では旧環境を読み解く力が問われます。社内の呼び方がある場合も、シートでは一般的な言葉に置き換えて書きましょう。
長い移行はフェーズに分けて書く
S/4HANAへの移行は、1件のプロジェクトが1年を超えることも珍しくありません。その間に、現行調査、設計と改修、リハーサル、本番の切替、稼働後の支援と、仕事の中身が大きく変わります。役割も、フェーズによって変わることがあります。
1件の長いプロジェクトを、担当内容の数行にまとめてしまうと、どのフェーズで何をしたのかが伝わりません。プロジェクト欄の中を、フェーズごとに区切って書く方法がおすすめです。
| フェーズ | 書いておきたいこと |
|---|---|
| 現行調査 | 調べた対象（設定、アドオン、データ量、外部とのつながり）と、整理の結果の形 |
| 設計・改修 | 自分の担当領域で決めたこと、改修や変換ルールの作成 |
| リハーサル | 回数のおおまかな規模と、各回で見つかった問題と変えた手順 |
| 本番の切替 | 当日の役割（作業の実施、照合、判断の会議への参加など） |
| 稼働後の支援 | 最初の月末・期末の処理など、どこまで見届けたか |
担当していないフェーズは、無理に書く必要はありません。「現行調査とリハーサルを担当。本番の切替は別チームが担当」と書けば、担当の範囲が正しく伝わります。
記入例（架空）
次は、書き方の型を示すための例です。業種と規模はぼかしてあり、実在のプロジェクトではありません。
期間：20XX年4月〜翌々年3月（2年）
方式・環境：システム変換／ECCからS/4HANA（オンプレミス）へ
業種・範囲：製造業（大手規模）。国内の会社コード複数、会計・販売・購買・生産
立場：データ移行チーム6名のうち、販売・購買のデータの担当リーダー
現行調査（6か月）：取引先・品目のマスタの重複と、使われていないデータを調査。移行の対象・対象外の案を作り、業務部門と合意
設計（6か月）：得意先と仕入先をビジネスパートナーにまとめる変換のルールを作成。照合の観点（件数・残高・抜き取り）を決定
リハーサル（9か月）：検証環境で複数回のリハーサルに参加。照合で見つかった不整合の原因を調べ、変換のルールと作業の順番を見直した
本番の切替・稼働後（3か月）：切替当日の照合を担当し、判断の会議に結果を報告。稼働後最初の月末の請求まで支援
実際に書くときは、ご自身の経験に置き換えてください。
リハーサルと切替は「何を変えたか」で書く
移行の経験を数字で示す項目（データの件数の規模、アドオンの数、リハーサルの回数、停止時間の計画と実績など）は、S/4HANA移行のスキルの記事で挙げています。シートに書くときは、数字を並べるだけでなく、その数字が何を意味するかが分かるように書きます。
- 書き換え前：リハーサル3回実施
- 書き換え後（架空）：リハーサルを3回実施。1回目で照合の不一致の原因を特定し、変換のルールを修正。2回目で所要時間の超過が分かり、作業の順番を入れ替えた
リハーサルは「何回やったか」より「各回で何が分かり、次の回までに何を変えたか」が経験の中身です。本番の切替も同じで、計画どおりに進んだ場合は、それを支えた事前の準備を、想定外のことが起きた場合は、そのときの判断を書きます。
具体的な社名や、移行したデータの実際の件数・金額は書かないでください。規模は「数十万件規模」のような大まかな書き方で伝わります。書いてよい範囲の考え方はスキルシートと守秘義務の記事で扱っています。
途中参画・途中離脱の書き方
移行のプロジェクトは長いため、途中から参画したり、本番の前に契約が終わったりすることがあります。その場合は、参画していた期間とフェーズを正直に書きます。
- 「リハーサルの段階から参画。本番の切替と稼働後の支援まで担当」
- 「現行調査と設計を担当。リハーサル開始前に契約を終了」
途中で離れた経験でも、担当したフェーズの成果物が次のフェーズでどう使われたかを書けば、経験として十分に伝わります。また、プロジェクト自体が延期や方式の変更になった場合も、自分が担った範囲と、そこで作ったものを書けば、経験として扱えます。
移行の計画・管理の役割の書き方
移行の計画や課題の管理を担った方は、PMOに近い経歴になります。この場合は、管理した対象（日程、課題、リスク、切替の計画）、関わったチームの数、切替の判断の会議での役割を書くと伝わります。自分でSAPの設定をしていない場合は、その旨を書き、SAPの知識は「移行方式の違い」「データ移行と照合の流れ」など、理解している範囲として書き分けます。PMOとしての書き方はPMOのスキルシートの記事もあわせてご覧ください。
よくある質問
検証環境での作業だけで、本番の切替には関わっていません。書いてよいですか？
書いてかまいません。担当したフェーズを明記し、「本番の切替は別チームが担当」と書けば、範囲が正しく伝わります。検証環境での確認や照合の作業で見つけた問題と、その対応を書くと、移行の流れを理解している人として伝わりやすくなります。
移行のプロジェクトが複数ありますが、どれも短期間の参画です。
プロジェクトごとに方式と担当フェーズを書いたうえで、要約で「現行調査とデータ移行の工程を、複数の変換プロジェクトで担当」のようにまとめると、経験の幅が伝わります。同じ工程を何度も担っていることは、その工程の専門性として読まれることがあります。
ECCでのモジュールの経験が長く、S/4HANAの経験は移行の1件だけです。どう見せればよいですか？
ECCでの経験は、移行の案件で旧環境を読み解く力として生かせます。要約では、ECCでの経験の長さと、S/4HANAへの移行で担った内容を並べて書くと、旧環境と新環境の両方を知る人として伝わります。移行の1件は、フェーズに分けてくわしく書いておきましょう。