はじめに｜「移送」を制する者はプロジェクトを制す
SAPコンサルタントとして現場に入り、最初に突き当たる大きな壁。それが**「移送（Transport Management）」**です。
開発機（DEV）で作った設定やプログラムを、検証機（QAS）、そして本番機（PRD）へと届けるこの作業。一見すると「ボタン操作」に見えますが、その実態はプロジェクトの命運を握る「大動脈」です。
- 「移送の順番を間違えて、本番環境の機能が動かなくなった」
- 「リリースしたはずなのに、検証機に反映されていない」
- 「リターンコード『8』が出たけれど、何を見ていいかさっぱり分からない」
こうしたトラブルは、SAPプロジェクトでは日常茶飯事です。しかし、移送の仕組みを根本から理解していれば、これらは未然に防げます。今回は、概念から実務の手順、エラーの調べ方まで、**「現場でマニュアルとして使える」**内容を凝縮してお届けします。
そもそも「移送」とは？（仕組みの理解）
SAPにおける移送とは、簡単に言えば**「異なるシステム間でのデータの同期」**です。
3システムランドスケープの原則
通常、SAPプロジェクトは以下の3つのシステムで構成されます。
- 開発機（DEV）: 設定や開発を行う場所。
- 検証機（QAS）: 業務シナリオに沿ったテストを行う場所。
- 本番機（PRD）: 実際のビジネスが動く場所。
移送依頼（Transport Request）の正体
移送を行う際、変更内容は**「移送依頼」**という箱に詰め込まれます。依頼には大きく分けて2種類あります。
- カスタマイズ依頼（Customizing Request）: クライアント依存（特定のクライアントのみに影響）。例：会社コードの設定、販売組織の定義など。
- ワークベンチ依頼（Workbench Request）: クライアント非依存（全クライアントに影響）。例：ABAPプログラム、テーブル定義など。
移送依頼の取得方法：2つのパターン
移送依頼を手に入れるには、**「自分で先に作る」方法と、「保存時に自動で聞かれる」**方法の2つがあります。
ポップアップによる自動取得（実務で最も多いパターン）
カスタマイズ（SPRO）やアドオン開発（SE80/SE38等）で「保存（Save）」ボタンを押した際、システムが自動的に**「移送依頼のプロンプト」**を表示します。
- 既存の依頼を選択: すでに自分が持っている未リリースの依頼を選択します。
- 新規作成: その場で新しい依頼番号を発行することも可能です。
ここで重要！「パッケージ」と「$TMP」の概念
オブジェクト作成時に必ず聞かれるのが**「パッケージ（Package）」**です。
- 移送対象パッケージ（Z…など）: 移送を前提としたパッケージ。これを選択すると、必ず移送依頼が求められます。
- ローカルオブジェクト（$TMP）: 自分の開発機内だけで完結するオブジェクト。これを選択すると移送依頼は聞かれませんが、他のシステム（検証・本番）へ運ぶことはできません。
失敗談あるある
「検証機にプログラムがない！」と騒いでいたら、実は**$TMP（ローカルオブジェクト）**で保存していて、移送の箱にすら入っていなかった……というのは新人が必ず通る道です。
手動による事前作成（SE10 / SE09 / SE01）
大規模な要件や、複数のメンバーで一つの箱を共有したい場合は、あらかじめトランザクションコード SE10 で依頼を作っておきます。
- 階層構造: 移送依頼は「依頼（親）」と「タスク（子）」の2階層です。
- 依頼（Request）: コンテナそのもの。
- タスク（Task）: 誰がどの作業をしたかの記録。
移送の方法：リリース（開発環境での作業）
開発・設定が完了したら、箱に封をして搬出できる状態にする**「リリース」**を行います。
- タスク（子）のリリース: まず作業者レベルのタスクをリリースします。
- 依頼（親）のリリース: すべてのタスク完了後、親の依頼をリリースします。
リリースが完了すると、OSレベルに「データファイル」と「制御ファイル」が生成されます。一度リリースした依頼の中身は二度と変更できないため、修正が必要な場合は新しい依頼を作り直す必要があります。
移送の方法：インポート（検証・本番環境での作業）
リリースされた依頼を受け取り側のシステムに取り込むのが**「インポート」**です。
STMS（移送管理システム）の操作
通常は STMS から行います。
- インポートキューの確認: 受け取り側システムにリリース済みの依頼が並んでいるか確認。
- インポートの実行: トラックアイコン（単一インポート）をクリックして実行。
インポート順序の「鉄則」
移送で最も多い事故は、**「順序の追い越し」**です。
- 正しい: テーブルA（依頼1）を先にインポート → プログラムB（依頼2）をインポート。
- 間違い: プログラムBを先にインポート → テーブルがないためエラー（RC=8）に。
リターンコード（Return Code）の読み解き方
インポート後の「通信簿」であるリターンコードの意味を正しく理解しましょう。
| コード | 意味 | 状態 | アクション |
| 0 | 成功 | 完璧です。 | 特になし。 |
| 4 | 警告 | 反映はされたが軽微な不一致あり。 | ログを確認し、実害がなければ静観。 |
| 8 | エラー | 反映失敗。 オブジェクトが無効。 | 原因調査と修正、再移送が必須。 |
| 12 | 致命的 | システム障害や重大な不整合。 | Basis（基盤担当）に即連絡。 |
RC=8 の主な原因
- 有効化漏れ: 開発機で「保存」だけで「有効化（Activate）」し忘れている。
- 依存関係の欠落: 必要な他のオブジェクトが同じ依頼に入っていない。
移送でよくあるトラブル
「追い越し移送」によるデグレ（先祖返り）
古い依頼を後からインポートしてしまい、最新の設定を上書きしてしまう現象です。リリース順（番号順）にインポートするのが鉄則です。
有効化の「ドミノ倒し」
一つのテーブル変更が、それに関連する何十個ものプログラムをエラーにするケース。移送前に影響範囲を特定する癖をつけましょう。
移送を調べるときの調査術
- 移送ログの詳細確認（SE01）: どのステップ（辞書有効化、メインインポート等）でコケたかを見極めます。
- テーブル E070 / E071 の活用:
- E070: 依頼のヘッダ情報（誰がいつリリースしたか）。
- E071: 依頼の明細情報。**「このオブジェクト、どの依頼に入っている？」**を逆引きする際に最強の武器になります。
- STMS インポート履歴: 過去のインポート順を追い、デグレの原因を特定します。
現場で使える「移送チェックリスト」
【リリース前：開発者用】
- [ ] オブジェクトはすべて**「有効（Active）」**か？
- [ ] パッケージは正しく設定されているか（$TMPになっていないか）？
- [ ] 必要なオブジェクトがすべて依頼に含まれているか？
- [ ] 構文チェックでエラーが出ないか？
【インポート前：担当者用】
- [ ] インポート順序は正しいか？
- [ ] 先行する「前提移送」は漏れていないか？
- [ ] インポート後の動作確認手順は準備できているか？
- [ ] 万が一のエラー時の切り戻し方針は決まっているか？
おわりに｜「確実な移送」がシステムの信頼を作る
移送は、単なる事務作業ではありません。あなたが苦労して作り上げた「ビジネスの仕組み」を、安全にユーザーへ届けるための**「ラストワンマイル」**です。
リターンコード「0」が並ぶ画面は、コンサルタントにとって最も安心できる景色です。この基本手順を徹底し、トラブルによる深夜残業をゼロにしていきましょう。
コメント