SAPのアップグレードやS/4HANA移行でSPDD/SPAUが出てくると、どこから確認すればよいか迷いやすいです。この記事では、実務で確認する順番、担当分け、判断時の注意点をチェックリスト形式で整理します。
SPDD/SPAUの位置づけ
SPDDはディクショナリオブジェクト、SPAUはリポジトリオブジェクトの調整に使います。どちらも「SAP標準に対して過去に入れた変更を、アップグレード後の標準差分とどう整合させるか」を確認する作業です。
概要だけ知りたい場合は、先にSPDDとSPAUについてを読むと流れをつかみやすいです。
まず確認すること
- 対象システムのアップグレード範囲
- 影響を受けるアドオン、拡張、修正ノート
- SPDD/SPAUの実行タイミング
- 調整対象の件数と優先度
- 開発、BASIS、業務担当の責任分界
- 本番移送までの承認フロー
SPDD/SPAUは単なる技術作業ではなく、標準へ戻すのか、自社変更を残すのかを判断する作業です。開発担当だけで完結させず、業務影響を確認できる担当者を早めに巻き込む必要があります。
SPDD対応のチェックポイント
SPDDでは、テーブル、データ要素、ドメインなどのディクショナリ関連を確認します。ここでの判断ミスは後続のアクティベーションやテストに影響しやすいため、早い段階で整理します。
- 標準変更と自社変更の差分を確認する
- 本当に自社変更を残す必要があるか確認する
- 参照先のプログラムや画面への影響を洗い出す
- アクティベーションエラーが出る対象を優先する
- 移送順序をBASIS担当と合わせる
SPAU対応のチェックポイント
SPAUでは、プログラム、クラス、汎用モジュール、画面、メニューなどのリポジトリオブジェクトを確認します。過去の修正ノート適用や標準拡張が多いシステムでは、件数が多くなりやすいです。
- SAPノート由来の変更か、自社修正かを分ける
- 標準に戻せるものは戻す
- 残す変更は理由を記録する
- ユーザExit、BAdI、拡張ポイントへの置き換え可否を確認する
- 重要業務のテストケースに紐づける
SPAUで重要なのは、過去の変更を機械的に残さないことです。古い標準修正が新バージョンで不要になっている場合もあるため、変更理由が不明なものほど慎重に扱います。
担当分けの考え方
BASIS担当はアップグレード手順、クライアント、移送、システム停止時間を管理します。開発担当は差分内容と修正方針を確認します。業務担当は、変更を残す場合と戻す場合の業務影響を判断します。
実務で詰まりやすいポイント
- 変更理由がドキュメント化されていない
- 退職者が作った修正の意図が追えない
- 標準に戻す判断を誰も承認できない
- テスト観点が技術確認だけになっている
- 移送漏れや順序違いで後続環境に差分が残る
進め方のテンプレート
- SPDD/SPAUの対象一覧を取得する
- オブジェクト種別ごとに担当を分ける
- 標準へ戻す、変更を残す、調査中に分類する
- 変更を残す理由を記録する
- 影響する業務プロセスを紐づける
- 開発環境で調整し、移送を作成する
- 品質環境で回帰テストを実施する
- 本番移行時の手順に反映する
まとめ
SPDD/SPAU対応は、アップグレード作業の中でも技術判断と業務判断が混ざる領域です。短時間で終わらせるには、対象一覧を早めに出し、標準へ戻せるものと残すものを分け、判断理由を残すことが重要です。
SAP経験をキャリアに活かす場合
SPDD/SPAUやS/4HANA移行の経験は、SAP案件で評価されやすい実務経験です。現在の経験を転職市場でどう見せられるか確認したい場合は、SAP専門の転職相談で求人傾向を見ておくと判断しやすくなります。