S/4HANA移行のフリーランス案件で求められるスキルと経験

S/4HANA移行のフリーランス案件では、旧環境から何が変わるかを自分の担当領域で説明する力、アドオンとデータを整理して移す範囲を決める力、移行の結果を照合で確かめる力、本番の切替を計画どおりに進める力が見られます。「移行に関わった」ことより、移行のどの場面で、何を決め、どう確かめたかが問われます。

この記事では、移行の案件に共通するスキルと、役割ごとに重みが変わるスキルを整理し、経験を数字で示す方法を解説します。移行方式の種類や独立の手順はS/4HANA移行がフリーランスになるにはで扱っています。

移行の案件が求めるスキルの全体像

S/4HANAへの移行の案件が続いている背景には、旧環境の保守期限があります。SAPは2020年2月の発表で、SAP Business Suite 7の主要なアプリケーションについて、標準の保守を2027年末まで、オプションの延長保守を2030年末まで提供し、S/4HANAの保守を2040年末まで約束するとしています。個別の企業の期限は契約によって変わることがあるため、案件ごとの事情は発注元に確かめる必要があります。

移行のプロジェクトでは、立場の違う人が同じ日程に向かって動きます。役割によって求められるスキルの重みは次のように変わります。

どの役割でも共通して問われるのが、次に述べる「旧環境と新環境の違いを読む力」です。

旧環境との違いを担当領域で説明する力

移行の案件では、旧環境で当たり前だった仕組みがS/4HANAでどう変わるかを、自分の担当領域の言葉で説明できることが前提になります。

たとえば会計では、SAPの資料によると、S/4HANAではFIとCOの伝票が一つの仕訳（ユニバーサルジャーナル）にまとめられ、テーブルACDOCAに書き込まれます。旧来のテーブルの一部は更新されなくなりますが、互換性のためのビューがACDOCAから読み出すため、旧テーブルを使う既存のレポートは動き続けるとされています。移行の担当者にとっては、「既存のレポートが動くか」だけでなく、「旧テーブルを直接更新していたアドオンがないか」「数字の出どころが変わることで照合の手順が変わらないか」を確かめる視点が必要になります。

販売・購買では、得意先と仕入先をビジネスパートナーとして一つの仕組みで扱う形への切り替えが、移行前の大きな準備になります。マスタの重複や項目の不足を、移行の前にどこまで整理しておくかが論点です。

こうした違いは、担当領域ごとにたくさんあります。全部を覚えることより、自分の領域で影響の大きい変更を挙げ、それぞれでプロジェクトとして何を決めたかを説明できることが評価されます。会計と販売・購買の側のスキルはSAP FI/COコンサルのスキルとSAP SD/MMコンサルのスキルで解説しています。

アドオンを整理する力

長く使われてきたSAPのシステムには、多くの追加開発（アドオン）が積み重なっています。移行の案件では、これを全部そのまま持っていくのではなく、整理する力が求められます。

1. 使われているかを確かめる：実行の記録をもとに、一定期間使われていないプログラムや帳票を洗い出す
2. 標準の機能で置き換えられるかを見る：S/4HANAで標準の機能が増えた部分は、アドオンをやめて標準に寄せる判断をする
3. 新環境で動くように直す：変わったデータの構造や廃止された機能に合わせて、プログラムを改修する
4. 直したものを確かめる：改修したアドオンの動作を、業務のシナリオで確かめる

廃止の判断は、業務部門の合意が要るため、技術の調査だけでは終わりません。「使われていない」というデータを示して、業務部門に廃止を受け入れてもらった経験は、面談で具体的に話すと評価されやすい部分です。

データを移し、照合で確かめる力

変換のルールを文書にする

データ移行では、旧環境のデータを新環境の形に合わせて変換します。項目の対応、コードの読み替え、不要なデータの除外条件などを、変換のルールとして文書にまとめる力が求められます。ルールが担当者の頭の中にしかないと、リハーサルのたびに結果が変わり、原因を追えなくなります。

照合の設計が品質を決める

移行が正しくできたかは、照合で確かめます。照合の設計には、次のような段階があります。

照合で数字が合わないときに、変換のルール、元のデータ、移行の手順のどこに原因があるかを切り分けられる人は、どの移行のプロジェクトでも頼られます。データの整理や変換の考え方は、SAP以外のデータ基盤の経験とも共通する部分があり、データエンジニアのスキルも参考になります。

本番の切替を組み立てる力

切替の手順と判断の基準

本番の切替は、業務を止められる限られた時間の中で行います。ここで求められるのは、作業の順番、担当、所要時間、前後のつながりを一覧にした手順書を作り、当日に判断する基準を事前に決めておく力です。

特に大切なのが、進めるか戻すかの判断の基準です。照合の結果がどこまで合えば次へ進むのか、どの時点を過ぎたら切り戻せなくなるのかを、関係者と事前に合意しておく必要があります。

停止時間を短くする工夫

停止時間の長さは、移行方式と基盤の作業に大きく左右されます。SAPの公式サポートページでは、ソフトウェアの更新とデータベースの移行を組み合わせるDMO（Database Migration Option）の中に、S/4HANAへの変換に向けた方式や、大きなテーブルをシステムの稼働中に移して停止時間を短くする方式があると説明されています。基盤の担当でなくても、こうした方式があることと、その前提を知っておくと、日程の会議で話がかみ合います。基盤の側のスキルはSAP Basisエンジニアのスキルで解説しています。

テストと稼働後の支援の力

移行のプロジェクトでは、新しい機能を作るより、今までどおりに業務が回ることを確かめるテストの比重が大きくなります。旧環境の業務のシナリオを集め、移行後も同じ結果になるかを確かめる回帰テストの設計と実施の経験は、多くの案件で求められます。

稼働後は、締めの処理や月末の業務で問題が表に出ることがあります。最初の月次決算や、最初の大きな出荷の日までを見届けた経験は、移行を最後まで担える人として評価されます。

経験を数字で示す

移行の経験は、数字を添えると規模と難しさが伝わります。社名を伏せたうえで、プロジェクトごとに次のような点を書いておきましょう。

• 移行方式と、旧環境・新環境のバージョン
• 自分の役割と担当した工程
• 扱ったデータの種類と件数の規模、照合の段階
• 整理したアドオンの数（調査した数と、廃止・改修した数）
• リハーサルの回数、本番の停止時間の計画と実績

書き方の詳細はS/4HANA移行のスキルシートの書き方をご覧ください。

よくある質問

移行の経験が一度だけでも案件に参画できますか？

参画できる案件はあります。一度の経験でも、自分が担った工程と、リハーサルや照合で何を学んだかを具体的に話せると、移行の流れを理解している人として伝わります。担当した役割に近い案件から選ぶと、立ち上がりやすくなります。

ABAPの経験はアドオン改修の役割以外でも役立ちますか？

役立ちます。データ移行の担当では、変換のプログラムや照合の仕組みを読む場面があり、業務モジュールの担当でも、アドオンの影響を調べるときにプログラムの動きを追えると判断が早くなります。書けなくても、読める程度の知識があると会話がかみ合います。

移行の計画・管理の役割にはSAPの知識がどこまで必要ですか？

業務の設定までは求められないことが多いものの、移行方式の違い、データ移行と照合の流れ、基盤の作業が停止時間に与える影響は理解しておく必要があります。プロジェクト管理の側のスキルはPMOのスキルもあわせてご覧ください。