移送だけじゃない!SAPの設定を他環境にコピーする“BCセット”のススメ

BC-SET is a powerful workaround for Transport

カスタマイズ設定を本番環境やテスト環境に反映させる手段といえば 「移送(Transport)」だろう。SAPシステムに携わるコンサルタントやエンジニアであれば、 移送は日常的に利用しているはずである。移送はSAPの標準的な仕組みであり、ほとんどのプロジェクトや運用現場で使われるため、誰もが知る存在だ。

しかし、実は移送以外にも設定を他の環境にコピーする方法が存在する。その一つが BCセット(Business Configuration Set) である。

BCセットは移送に比べて知名度が低く、存在すら知らないSAPコンサルタントも少なくない。しかし、特定の場面では移送よりも手間が少なく、柔軟且つスピーディに設定を別の環境にコピーできるのだ。

本記事では、BCセットの仕組み から移送との違いメリット・デメリット活用できるシーン、そして具体的な操作方法までを徹底解説する。実務経験の浅い初心者からベテランコンサルまで、BCセットを使ったことがないコンサルにとっては、目からウロコの情報かもしれない。ぜひ最後まで読んでいただきたい。

目次

BCセットとは?

カスタマイズ設定コピーの選択肢を増やす

SAPではカスタマイジング設定を他環境へコピーする手段として、まず「移送」が思い浮かぶだろう。移送依頼にカスタマイジング設定をまとめ、リリースし、対象システムへインポートすることで設定を反映するのが、移送の基本的な流れだ。

一方、BCセットは 特定のカスタマイジング設定内容を、ひとまとめにして保存・再利用する仕組みである。

「設定の保存・再利用」と聞けば、「移送と同じでは?」と思うだろう。しかし、BCセットには移送にはないメリットや運用のしやすさがある。

BCセットの基本概念と特徴

BCセットの特徴は次の通りである。

  • 特定のIMGノードの設定を切り出し「BCセット」として保存し、別の環境に適用できる
    • 部分的なカスタマイジング設定の反映が可能
  • 移送のような「リリース」操作は不要
    • 保存したBCセットは、そのまま他の環境にコピーして適用可能

移送の場合、カスタマイズ設定した内容は「移送依頼」に集積し、移送依頼をリリースした後、別環境にインポートすることで設定内容をコピーする。

BCセットも設定内容を別の環境にコピーできる点は同じだが、IMGノードおよび、その設定値まで明示的に指定できる。さらに、移送のような「リリース」操作が不要など、「カスタマイジング設定コピーを迅速に行える」点が特徴だ。

SAP Best Practices でも使われている

BCセットは、実はSAP自身も公式に活用している仕組みである。その代表例が SAP Best Practices(SAP-BP)のインストール だ。

SAP-BPには、FI, MM, SD, PP,COなどの主要モジュールでよく利用される設定があらかじめ定義されているが、それらの設定がBCセットとして、まとめて提供されている。BCセットによるカスタマイジングの一括設定は、ゼロからIMGを設定するよりもはるかに効率的である。

ここで重要な概念が 「スコープアイテム(Scope Item)」 だ。

スコープアイテムとは、Best Practices の中で提供される 業務プロセス(業務シナリオ)の構成単位 のことを指す。たとえば、SD(販売領域)であれば「受注から請求まで」といった業務プロセスが、一つのスコープアイテムとして定義されている。

これらのスコープアイテムは、裏側では BCセットを用いて構築されており、SAP-BPのインストール時に選択・適用することで、該当する業務プロセスの設定がSAPシステムに反映される仕組みになっている。

つまり、スコープアイテムは Best Practicesを構成する最小単位 であり、その設定にBCセットが利用されている。これにより、自分たちが必要とするスコープアイテム(裏ではBCセット)を選択することで、迅速にテンプレートシステムを構築できる。

このように、BCセットは「プロジェクトでの便利ツール」にとどまらず、SAP公式の標準提供物(Best Practicesとスコープアイテム)を実現する中核的な仕組みでもあるのだ。

BCセットのメリットとデメリット

BCセットのメリットとデメリットを整理しておく。

メリット

  1. 迅速なコピー
    IMGで設定した内容をそのままBCセットとして保存し、他クライアントやシステムに即座に反映可能。
  2. 柔軟性の高さ
    リリースなどの運用承認プロセスを待たずに、自分の権限範囲でスピーディに適用できる。
  3. 部分適用が可能
    IMGの特定の設定項目だけをコピーできる。

デメリット

  1. 依存関係に弱い
    移送のような依存関係は考慮されないため、自身で関連する設定を一緒に持ってこないと動作しない場合がある。
  2. 知識不足による失敗リスク
    T-CDや対象IMGノードを知らないと、正しく作成・適用できない。
  3. 設定の「削除」はできない
    BCセットは設定の「追加」や「変更」に特化しており、削除は不可能。一方、移送では削除の移送依頼を作成し、別環境に削除を反映できる。不要設定のクリーンアップを伴う場面では、BCセットは使えない。
  4. 本番では非推奨
    柔軟性が高い=統制に欠けるため、検証環境や本番環境の構築には向かない。

BCセットと移送の違い

「BCセット」と「移送」は、どちらも「カスタマイジング設定を他の環境にコピーする」という目的は共通している。そのため、使い分けに迷う場面もあるかもしれない。しかし、それぞれの特徴を比較してみると、違いや使いどころがはっきりと見えてくるはずだ。

ここでは、「移送」の仕組みとデメリットをあらためて整理しつつ、移送とBCセットの決定的な違いを見ていく。

移送とは何か?

移送(Transport)は、SAPシステム間で カスタマイジング設定やアドオンプログラムなどの開発オブジェクトを、検証環境、本番環境へと、確実にコピーするためのSAP標準機能である。

移送プロセスは以下のようになる。

  1. 開発者やコンサルタントが 移送依頼(Transport Request) を作成
  2. カスタマイジング設定の内容をその移送依頼に登録
  3. 移送依頼をリリース
  4. 運用管理者がターゲット環境で移送依頼をインポート

なお、移送について詳しく解説した記事は以下。

移送のデメリット

移送はSAPにおける標準的かつ必須の仕組みで、運用統制に非常に優れている。システム構成・品質を一貫して保つという点において、絶対的に信頼のおける仕組みだ。

しかし、実務で使っていると、いくつかのデメリットを感じることもある。特に、小規模な設定変更や試行的な作業 においては不便を感じる場面が多い。ここでは移送のデメリットを整理してみる。

  1. 手続きが煩雑でリードタイムが長い
    移送依頼の作成、リリース、承認、インポートという複数のステップを踏む必要がある。特に運用部門の承認が絡むと、数時間から数日かかる場合もある。小さな設定を反映するだけでも大掛かりになってしまう。
  2. 柔軟性の欠如
    部分的に設定を反映したい場合でも、移送は「すべてまとめて」が原則。実際の運用では、一つの移送依頼(移送依頼番号)に複数の設定をぶら下げるため、「この設定だけ反映したい」という運用ができない。これは、テストやPoCの場面ではオーバースペックになりがちである。
  3. 影響範囲が広い
    本番環境を含めた複数システムに影響を与えるため、万一誤った設定を移送してしまうとリカバリーに多大な工数がかかる。一部の設定だけ戻すことも難しい。

このように、移送は「統制」や「本番運用」には適しているが、スピードや柔軟性を求められる場面では不向きである。ここにこそ、BCセットを使う余地があるといえる。

BCセットと移送の決定的な違い

BCセットと移送は、どちらも「設定をコピーする」という目的は同じであるが、重視しているポリシーのようなものがそれぞれ異なる。このポリシーの違いは、依存関係のあるパラメータに対する挙動に表れてくる。

たとえば、PP(生産管理)モジュールには「指図タイプ依存パラメータ」というものがある。このパラメータは、その名の通り「指図タイプ」に依存しているため、指図タイプが登録されていないと設定することができない。

では、この「指図タイプ依存パラメータ」の設定において、移送とBCセットではどのような違いがあるのか?
それぞれの挙動から、ポリシーが浮かび上がってくる。

移送:整合性重視

移送の場合、インポート時に依存関係のチェックが行われるため、指図タイプが存在しない環境に、指図タイプ依存パラメータをインポートすればエラーとなる。

このように、移送では設定の不整合は回避されるので、システムを不整合なく、健全に保つことができる

移送の操作は手間がかかるが、それはシステムの一貫性と整合性を維持することを重視した結果の手間なのだ。

BCセット:スピード重視

BCセットの場合、依存関係のチェックは行われず、パラメータはダイレクトに対象環境に適用できる。この結果、設定の不整合を許容したままシステム環境は構築されてしまい、動作不良が起きたとき、その原因を調査するのに時間がかかってしまう。

これが、BCセットは本番環境構築には向かない大きな理由だ。

その代わり、BCセットは移送のような手間は軽減されるため、スピーディに設定コピーができる。システムの整合性維持は、BCセットを作成するコンサルタントの力量にかかっているといえる。

移送とBCセットの比較

以下の表は、移送とBCセットを実務的観点も含めて比較したものである。

比較項目移送(Transport)BCセット(Business Configuration Set)
主な用途開発環境から本番環境への正式な設定反映手段設定の再利用・テンプレート化
操作の手間移送依頼の作成 → リリース → インポートと、工程が多い。設定内容を直接作成・適用できる。作業者自身で即時反映可能。
作業時間の目安小規模な設定でも上記の操作が必要で、数分~数時間かかる。承認プロセスも加わればリードタイムはさらに長くなる。数分程度で設定をコピー可能。
担当者の関与レベル開発者/コンサルタントが移送依頼を作成し、運用管理者が承認・インポート。複数担当者が関与コンサルタント自身で作成・適用可能。原則1人で完結
利用する場面プロジェクトの全場面
検証環境/本番環境の構築など、正式な設定を反映するとき
統制が必須の環境
開発環境、プロトタイプ、PoC、教育用環境
部分的に設定をコピーしたい時
統制よりも、作業効率を優先するフェーズ

BCセットの操作方法

BCセットを作成および適用するためのトランザクションコードは以下である。

  • BCセットの登録・変更・照会: SCPR3
  • BCセットに記録されている設定内容を対象のクライアントに適用する: SCPR20

BCセットの作成方法

  1. T-CD: SCPR3 を開始し、メニュー「ビジネスコンフィギュレーションセット」->「登録」を選択。
  2. 次図のように、BCセット/テキストに名称を入力する。
ビジネスコンフィギュレーションセット名称入力画面

BCセットは次の3つの中から選択できる。

BCセット化できるオブジェクト説明
IMG階層IMGノード(T-CD: SPRO, SIMG)と設定値を選択してBCセットを作成する
BCセットのセット登録済みのBCセットから、設定項目と設定値を選択し、BCセットを作成する
移送依頼登録済みの移送依頼から、IMGノードと設定値を選択してBCセットを作成する

なお、以下に示す手順は「IMG階層」を選択した場合の例である。

  1. SAP完全版IMG」が表示される。このタイトルからわかる通り、表示されるIMG階層は、T-CD: SPROまたはSIMGで表示されるIMGメニューと同じである。
    このIMGメニューから、設定を保存したいIMGノードと、その値を選択していく。複数のIMGノードと値を、連続して選択することが可能だ。
IMG階層から設定値を選択しBCセットを作成
  1. 選択を終えたら、[保存]ボタンを押下する。
    「オブジェクトディレクトリエントリ登録」が表示され、「パッケージ」を入力するよう促されるが、正式なオブジェクトでなければ「$TMP」と入力して保存すればよい。

これでBCセットの登録は完了である。

BCセットを使った設定の反映方法

  1. T-CD: SCPR20 を起動。
  2. メニュー「ビジネスコンフィギュレーションセット有効化」を選択。
BCセットの有効化を開始
  1. 移送依頼を指定する画面がポップアップするので、移送依頼を指定する。
  1. 有効化オプション」画面が表示される。データの上書きを行うかどうかなどを聞いてくるが、基本的にデフォルトのままでOK。[Enter]を押下して続行する。
BCセット有効化のオプションを指定
  1. 「有効化は正常に完了しました」というメッセージが表示されれば、適用は完了である。
BCセット有効化の完了

BCセットを再利用する

BCセットの範囲

BCセットは同一環境(同一サーバ)内で有効である。あるクライアントで登録したBCセットは、同一環境内であれば、別のクライアントからも参照可能である。

BCセットのダウンロード/アップロード

登録済みのBCセットは、メニューから「ダウンロード」を選択することで、ファイルとしてダウンロードできる。また、ダウンロードしたBCセットファイルは別環境に「アップロード」して再利用することが可能だ。

移送依頼もファイルとして保存できるが、まったく別の環境にインポートしようとすると整合性チェックに引っかかりエラーとなるケースが多い。これは移送というものが、同じプロジェクト内での構成管理と整合性維持に重点を置いているためである。

一方のBCセットは、カスタマイジングテーブルにダイレクトに設定値を登録する仕組みなので、良くも悪くも整合性チェックは緩い。このため、別環境であっても設定内容をエラーなくコピーできる。

BCセットを運用に組み込むポイント

環境によって使い分ける

移送とBCセットを使い分けるポイントは以下。

  • 移送: 統制の効いた本番向けの手段。通常はこちら。
  • BCセット: 柔軟で小回りの効く補助的な手段。開発環境で使える。

環境別のベストプラクティスを整理した表は以下。統制重視の検証環境/本番環境の構築は移送に限る。一方、生産性を重視する場面では、BCセットを積極的に利用できる。

環境適した手法理由
Sandbox / Demo / 教育環境BCセットスピード・自由度重視。頻繁なリセットや試行錯誤に向く。
開発環境(DEV)BCセット + 移送個人開発や試行錯誤はBCセット、正式な設定は移送依頼にまとめる。
検証環境(QA)移送(原則)本番を想定した統制環境のため、移送で設定内容をコピーする。
本番環境(PRD)移送のみガバナンス・監査対応・変更管理のため、移送が必須。

まとめ:BCセットでSAP設定コピーの選択肢を増やす

BCセットは移送に比べるとマイナーであり、現場で使いこなせるコンサルタントは多くない。しかし、PoC・教育環境・部分的なテスト など特定の場面では、移送よりも効率的に設定コピーを行える。

ポイントは、それぞれの特徴を理解し、適切に使い分けることだ。そうすることで、カスタマイジングにおける整合性維持と生産性向上の両立が可能となる。

SAPプロジェクトや運用の現場では、移送だけに頼らずBCセットも選択肢に加えることで、作業効率と柔軟性を両立できるだろう。

BCセットを理解して活用できるコンサルタントの生産性は高いはずだ。そのようなコンサルタントは、間違いなく現場で重宝される存在となるだろう。


カスタマイズの差異を可視化・解消する

移送にせよBCセットにせよ、カスマイズを他の環境にコピーすれば、いつか設定の「差異」が発生する。カスマイズ差異の可視化と、解消方法を具体的に解説した記事は以下。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

CAPTCHA

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください

目次