皆さん、こんにちは。本投稿では、最近日本企業の中で盛り上がりを見せているSAP導入プロジェクトの基本について解説します。
SAPとは、言わずと知れた基幹業務システムのシェアNo.1のERPパッケージシステムのことで、多くの日本企業においても既に導入されています。
SAPのERPパッケージの最新バージョンはSAP S/4 HANAとなるのですが、ひとつ前のモデルであるSAP ECCは2025年にサポート対応が終了するため、2022年現在、多くの日本企業がすでに導入済みのSAP ECCをS/4 HANAへ移行しようとプロジェクトを企画しています。
SAP導入プロジェクトの必要性が高まっている一方で、過去にSAP ECCを自社企業に導入した人材はすでに定年退職済みというケースも多く、SAPに関する知見を持つ人材が相対的に少ない状況であり、この問題をSAP業界では2025年問題と呼ばれています。
そうした状況下において、事業会社、SIer、コンサルティングファームなどではSAPの知見を持つ方を広く募集しており、SAPの知見を持つ人にとっては高い市場価値を発揮するチャンスとなっています。さらに、現時点ではSAPの知見がなかったとしても業界としては深刻な人材不足であるため、勇気をもってこの領域でキャリア形成を図ろうとする方は大歓迎される状況です。
私の周りでも多くのSAP導入未経験の元エンジニアの方がコンサルティングファームに転職され、SAP導入プロジェクトに関与するようになってきています。
本投稿では、そうしたSAP導入プロジェクトにこれから関わっていくという方向けに、SAP導入プロジェクトの基本知識を提供したいと思います。
今回は、SAP導入プロジェクトの基本アプローチであるWaterfallアプローチおける開発、Buildフェーズにおける作業内容について解説します。開発フェーズには多くの作業が発生するのですが、本投稿ではカスタマイズ設計、カスタマイズの実施、そしてカスタマイズのテストの実施までを取り扱います。
なお、実際のプロジェクトの中で皆様が経験されるものと一部異なる点がある可能性がございますが、本投稿で解説する内容は一般的なケースとしてご参考にして頂ければと思います。
Agenda
想定読者
- SAP導入プロジェクトに初めて参加することになった事業会社、SIer、コンサルティングファームの方
- SAP導入プロジェクトを担当するSIer、コンサルティングファームのポジションへの転職を考えている方
SAP初心者向けの投稿記事まとめはこちら
先にこちらのブログで取り扱っているSAP初心者向けの投稿記事のまとめをこちらでご紹介しておきます。もしご興味がある投稿がありましたら、ぜひ見て頂ければと思います。
開発/Buildフェーズの作業内容、成果物
SAP導入プロジェクトの設計/Designフェーズが終わったら、開発/Buildフェーズが始まります。
ここでは、設計/Designフェーズの最後に実施した、開発に対する承認取得において、承認が得られた開発オブジェクトを実際に開発していきます。
想定読者である皆様はプロセス/Processチームに所属しているわけですが、この開発/Buildフェーズでは開発者のチームと協力しながら業務要件を実装するプログラムを作り込んでいきます。
SAP標準機能で対応が出来る業務要件については開発者に作業をしてもらうことにはならず、皆様ご自身の手でSAPに対してカスタマイズを行い、標準機能を業務要件に合わせていくことになります。
開発/Buildフェーズで実施する作業と、このフェーズで作成する成果物は以下の通りとなります。
実施する作業
- カスタマイズ、開発作業スケジュールの作成
- カスタマイズ設計（CSの作成）
- カスタマイズの実施
- カスタマイズテストの実施（CuTの作成）
- 承認済み開発オブジェクトに対する機能設計（FSの作成）
- 開発チームとの機能設計図書の内容確認
- 開発チームによる詳細設計（TSの作成）
- 開発実施、単体テストの実施（TuT、FuTの作成）
- 結合、統合テストケースの作成
成果物
- カスタマイズ一覧
- カスタマイズ設計書図書（CS：Configuration Specification）
- 単体カスタマイズテスト結果（CuT：Configuration Unit Test）
- 機能設計図書（FS：Functional Specification）
- 詳細設計図書（TS：Technical Specification）
- 単体詳細テスト結果（TuT：Technical Unit Test）
- 単体機能テスト結果（FuT：Functional Unit Test）
- WRICEFリスト（更新）
- 結合テストケース、統合テストケース
馴染みのない用語がいくつか出てきたと思いますが、あとでしっかり解説していきます。
本投稿では、以下を対象に解説していきます。
- カスタマイズ設計（CSの作成）
- カスタマイズの実施
- カスタマイズテストの実施（CuTの作成）
カスタマイズ設計（CSの作成）
開発フェーズでは、事前に作成しておいたカスタマイズのスケジュールに従って実際にカスタマイズを行っていく作業を始めます。
なお、日本企業のケースでは、カスタマイズの作業はコンサルティングファームやSIerに委託しているケースがほとんどとなります。
まずはSandboxで検証
カスタマイズ設計を行う際ですが、まずは今からどのカスタマイズを実施すればいいのか、という点にあたりを付けて、それを実際に試してみる、という方法が一般的です。
SAPの開発環境は、Goldenクライアント、Unit Testクライアント、Sand Box環境とさらに分割されており、最初に機能検証を実施したいカスタマイズがある場合はSand Boxというクライアントを使用します。
Goldenクライアントではプロジェクトとして正式に認められたカスタマイズが実際に実行されます。そして、Goldenクライアントではテストデータの作成などは行いませんが、代わりにGoldenクライアントに実施されたカスタマイズをUnit Testクライアントにコピーします。コピーを実施した後、Unit Testクライアントでカスタマイズのテストを実施します。
Goldenクライアント上でテストデータを作成しないのにはしっかりとした理由があり、それは最終的にこのGoldenクライアント全体をコピーすることで実際の業務の中で使用する本番環境を作るからです。本番環境を動かし始めたときに、開発の時に適当にテスト目的で作ったデータまでコピーされていたら、あとあと面倒になるので、テストデータが一切存在しないようにGoldenクライアントを保つわけです。
Sand Boxは意味合いとしては砂場、つまり何でもやってみてOKというクライアントのことです。もし、要件実装のためにどのカスタマイズを行えばいいのか、十分に自信がある場合はSand Boxでの機能検証はスキップして構いませんが、ちょっと自信がない場合はSand Boxを活用しましょう。
Sand Boxで実際にカスタマイズを行ってみて、テストをしてみたところ、期待していた通りに動きそうであれば、どういったカスタマイズを行うか、という内容をドキュメントにまとめ、これをカスタマイズ設計図書（CS：Configuration Specification）とし、責任者の方にレビューしてもらいます。
Sand Boxで機能検証を目的にカスタマイズを実施する際も、Goldenクライアントでカスタマイズを実施するときも手順は同じになるので、そちらについてはどちらも「カスタマイズの実施」のセクションで解説します。
カスタマイズ設計図書を作る単位
カスタマイズ設計図書を作ることになる、という点はご認識いただけたかと思いますが、この図書はどの単位で作るのでしょうか。プロジェクトによってさまざまあるのですが、ここでは筆者がこれまでのプロジェクトで経験してきたケースをご紹介します。
- カスタマイズノードの単位で作成する（ノードごとに別々にする）
- 業務プロセスIDの単位で作成する（業務プロセスごとに別々にする）
- チーム単位で作成する（チームで1つの文書だけ作る）
カスタマイズノードの単位で作成する（ノードごとに別々にする）
カスタマイズノードというのは、SAPでカスタマイズを実施する対象のことを指します。
もし、SAPにアクセス出来るようでしたら、Transaction code：SPROと打ってEnterを押下してみてください。以下のような画面に切り替わると思います。
Transaction Code：SPROを入力して実行
SAP Reference IMGをクリック
カスタマイズ対象が一覧で表示され、ドリルダウンでさらに詳細を確認できる
カスタマイズを実施するときは、実際にこの画面から行います。各項目をクリックしていくと、業務領域別にカスタマイズを実施できる対象が確認できます。これらがノードと呼ばれるもので、それぞれのノードはクリックしていくことでさらに下位のノードへと細分化されていきます。
このノードを一つの単位として、カスタマイズ設計図書を作る、というアプローチが1つ目のやり方となります。
見ての通り、非常にノード数は多いので、一番細かいノードをカスタマイズ設計図書作成の単位にするのではなく、一番上から2番目、もしくは3番目あたりのノードを一つの単位にするというやり方もあります。
業務プロセスIDの単位で作成する（業務プロセスごとに別々にする）
2つ目の方法は、業務プロセスごとに作成するというものです。要件一覧を作成した際に、業務プロセスIDというものを要件に対して振ったのを覚えてますでしょうか。
これが同じであれば、同じ業務プロセスIDに紐づくカスタマイズは1つのカスタマイズ設計図書にまとめる、という方法もあります。
チーム単位で作成する（チームで1つの文書だけ作る）
3つ目の方法は、業務プロセスチームで1つのカスタマイズ設計図書を作成する、という方法です。1つのドキュメントになるのでわかりやすい反面、そのドキュメントが重厚長大になります。
様々な方法がありますが、まずは皆さんのプロジェクトには方針があるかを確認し、方針があればそれに則るようにしましょう。
カスタマイズ設計図書に含める内容
次に、カスタマイズ設計図書に含める内容をご紹介します。企業、あるいはプロジェクトごとにテンプレートが存在しますが、ここでは一般的な内容についてご紹介します。
- カスタマイズの概要、目的
- 関連する要件概要
- カスタマイズ詳細、ノード情報
- テストケース
カスタマイズの概要、目的
カスタマイズ設計図書一つ一つに対して、その文書内に記載されているカスタマイズについて大枠がわかるように概要と目的を記載します。
後でプロジェクトに参加した人が、特定のカスタマイズの内容を確認したいと思ったときに、どのカスタマイズ設計図書を見ればいいのか、という点を把握するためにカスタマイズ設計図書ごとにその概要、目的を制しておくことは一般的となります。
関連する要件概要
カスタマイズを実施するということは、要件が当然ながら存在します。したがって、その要件の番号や、要件の詳細を要件一覧から抜粋してカスタマイズ設計図書に乗せておく、ということも一般的となります。
カスタマイズ詳細、ノード情報
実際に行うカスタマイズの詳細、カスタマイズを行うノード情報を記述するセクションはカスタマイズ設計図書において必須と言えるでしょう。
カスタマイズの詳細といっても、カスタマイズ設計図書の作成においてはそんなに難しく考える必要はありません。実際にSAPに対して行うカスタマイズの内容を表形式などで整理するだけとなります。
必要であればなぜそういったカスタマイズをしているのか、といった補足情報を加えてもいいでしょう。
カスタマイズの詳細を記述する際、これはプロジェクトの方針にも依存しますが、実際にSAPに対してカスタマイズを行い、その画面キャプチャをカスタマイズ設計図書に貼っておくという方法もあります。
ただし、これを行うとなるとカスタマイズ設計図書に対して承認を行う前からカスタマイズを実施してしまうという意味になるので、Sand Boxで実施したカスタマイズの画面キャプチャを取るようにする、もしくはカスタマイズについてはカスタマイズ設計図書のレビュー前でもGoldenクライアントにカスタマイズを実施しても良いものとする、というルールを柔軟にしておく必要があります。
カスタマイズの詳細を記述する際は、ノード情報も必須となります。カスタマイズの内容が書かれていても、それをどこに実施したのかがわからないと不便だからですね。
例えば、以下のようなノードを例にとってみましょう。カスタマイズを使用としているノードは、「Define Field Status Variants」となります。
このノード情報は、以下のように整理することが一般的です。
ノード情報の整理の仕方
Path: Financial Accounting Global Settings(New) > Ledgers > Fields > Customer Fields > Define Field Status Variants
カスタマイズノードはツリー形式でどんどんドリルダウンしていくことが出来るので、その頭からカスタマイズを実施する一番細分化された箇所までのPathを書いてあげることが重要です。
テストケース
カスタマイズを実施したら、カスタマイズがきちんと期待した通りに動くかどうかをテストするためのテスト内容も整理する必要があります。これも例を挙げておきましょう。
- カスタマイズの内容
- 発注伝票用の伝票タイプの新規作成
- テストケース
- 新規作成した伝票タイプを用いた発注伝票の作成
- 新規作成した伝票タイプを用いた発注伝票の変更
- 新規作成した伝票タイプを用いた発注伝票の照会
新しく何かを使えるようにするというカスタマイズであれば、実際にそうして使えるようにしたものを用いて伝票などのオブジェクトを作成する、いったん作成したものを変更してみる、作成や変更をしたものを照会してみる、という3つがよくあるテストケースの内容となります。
テストケースの内容はカスタマイズの内容に大きく依存しますので、これも抜け漏れは無いようにしつつも最低限の工数になるように整理しましょう。
カスタマイズ設計図書のレビュー
カスタマイズ設計図書が作成出来たら、責任者に方にレビューをしてもらいます。コンサルティングファームの方が作成したカスタマイズ設計図書であればクライアント側の責任者にレビューしてもらいますし、もし自社のメンバーで導入をしている場合はチームメンバーが作成した文書をチームリードの方に確認して頂くことになります。
自社導入をしているプロジェクトで、自分自身がチームリードでありカスタマイズ設計図書を作成しているというケースでは、プロジェクトの方針にも依存しますがレビューはスキップするか、さらに上位のプロセスチーム全体のリードポジションの方にレビューしてもらう、ということになります。
多くの場合、チームリードはあくまでチームメンバーのサポートをするという役割にしておき、カスタマイズ設計図書などの文書を作成するのはチームメンバーである、という役割分担にしていれば、チームリードが文書をレビューする、というように役割分担が明確になります。
カスタマイズの実施
カスタマイズ設計図書のレビューが完了したら、実際にGoldenクライアントにカスタマイズを実施することになります。Sand Boxで機能検証を目的にカスタマイズを実施するというときも、同じカスタマイズの手順を踏むので、合わせてこちらのセクションで解説します
カスタマイズを実施するときは、すでにご紹介している通り、Transaction code：SPROを実行し、以下の画面にアクセスします。そして、カスタマイズを実施したい箇所までドリルダウンしていき、実行ボタンをクリック、またはF8を押下します。
カスタマイズの方法は、カスタマイズしたい内容によって多種多様あるため、ここではサンプルを用いてどんなことをするのかイメージを持って頂きたいと思います。
カスタマイズ実行のサンプル：伝票タイプ（Document Type）の新規作成
要件として、これもすでに何度か例として使用していますが、物品の購入とサービスの購入を分けて管理したいというものがあったとしましょう。製造業を例にとると、製造を行うための原材料という品物として目に見えるものの購入と、製造業の業務効率化のためのシステム導入を外部のソフトウェア会社に発注するというサービスの購入は扱いを分けたいので別々にしておきたい、というような要件です。
こちらの要件を実装するにはカスタマイズを複数実施しないといけないという点もすでに述べていますが、このセクションではまず、発注行為を行ったときに作成される発注伝票につけられる、伝票タイプ（Document Type）というものを物品用途とサービス用途で別々に作成するというカスタマイズを取り扱います。
Transaction Code：SPROを実行
SAP Reference IMGをクリック
まず初めに、どのノードに対してカスタマイズを実施しなくてはいけないのかというところからですが、今回カスタマイズを実施したい内容は発注に関連するところなので、SAP用語ではMaterials Managementという領域となります。
Materials Managementは日本語訳すると資材管理に相当するので、物品の管理のことと思えそうですが、SAPでは資材だけでなくサービスなどの購入も含みます。そして、購買発注に関するカスタマイズになるので、このMaterials Managementの中でもPurchasingというノードをドリルダウンしていくことになります。
ノードの実行ボタンをクリック
Materials Managementのなかに、発注/購買を意味するPurchasingというノードが見つかりましたので、それをドリルダウンしていくと発注伝票を意味するPurchase Orderがあります。そのなかに、Define Document Typeというノードが見つかるので、このノードの実行ボタンをクリックします。
あとは、新規作成をすることになるのでNew Entriesのボタンをクリックし、新たに追加したい伝票タイプ（Document type）を表の中に追記しましょう。
新規に追加したい伝票タイプを追加
表の中にはさまざまな項目が存在していますが、ここでは流れのご説明にとどめることとして、これらの項目の詳細は割愛させて頂きます。各項目が何を意味していて、どんな内容を入力しないといけないのか、という点を知りたい場合は、それらの項目にカードルを合わせて、F1ボタンを押下しましょう。SAPが各項目の意味合いなどを紹介してくれるヘルプウィンドウが表示されます。
出来たら、あとはセーブすることになります。
セーブしようとすると、なにやら番号が自動採番され、名称を付けるように促すポップアップが出てくると思います。このポップアップは、今カスタマイズを実施した内容に対してどんな移送番号を付けるか、という点を聞いてくれています。
移送番号について解説するため、まずスリーランドスケープというものからご説明します。
スリーランドスケープと移送/Transportについて
まず、スリーランドスケープと、移送というものについて解説します。
Goldenクライアントでカスタマイズを実施した際、それを後でUnit Testクライアントにコピーするという点を以前ご紹介しました。このとき、どのカスタマイズをコピーするのか、という点を識別するためにカスタマイズには固有の移送番号というものが割り当てられます。それが、カスタマイズを終え、セーブをしたときに自動採番される番号です。
カスタマイズに対して割り当てられた番号（移送番号）
なぜ移送と表現するのかというと、カスタマイズは最終的には環境を超えて別の環境に移送/Transportされるからです。
こちらの図は、スリーランドスケープのコンセプトを解説しています。
スリーランドスケープとは、開発、検証、そして本番という3つの環境を準備するというSAPの環境の持ち方のことであり、このように3つ分けて持つことで、より堅実にSAPの導入を進めていくことを可能にしよう、というコンセプトです。
開発環境は、様々なチームがどんどん開発を行っていて、単体テストもどんどん行われているので、テストデータも豊富な状況です。しかしながら、実際のビジネスの現場では発生することのないテストデータが作成されてしまうという可能性もありあります。
つまり、開発環境では問題なく動いてくれたカスタマイズが、より本番に近いデータと一緒に動かそうとしてみると失敗してしまう、という危険性があるのです。そこで、開発環境で動作が確認できたカスタマイズは、開発環境での単体テスト後に、検証環境という別の環境に送ります。これを移送/Transportと表現します。
検証環境では、好き勝手にデータを作ってはいけないという決まりにしておくことで、ビジネスの現場で作成されるデータに近い状況を再現しておきます。この検証環境でも同様にカスタマイズした内容が動けば、問題がないことが確認できるわけです。
また、検証環境で問題ないことが確認できたカスタマイズは、最終的にはまとめて本番環境に移送されます。
話を元に戻すと、このように、カスタマイズした内容は開発環境から別の環境へ移送されていくので、そのときにどのカスタマイズを移送したらいいのか、という点を把握するためにカスタマイズには個別の移送番号というものが付与されます。
なお、同じ環境の中の別のクライアントに対してカスタマイズを送ることは、移送とは表現せず、カスタマイズのコピー（クライアント間コピー）と表現するので、注意しましょう。
なお、移送をまとめて送りたいというときは、ここで発行された移送番号をグループにしておくということも出来ます。
カスタマイズ実行のサンプル：カスタマイズをUnit Test環境へコピーする
Goldenクライアントへのカスタマイズの実施が完了し、移送番号も取得出来たら、次はGoldenクライアントからUnit Testクライアントへコピーします。
Unit Testクライアントにログインし、Transaction code：SCC1を実行すると、移送番号を入力することが出来るので、これを入力してどこからコピーするのかを指定します。Unit Testクライアントでは、Goldenクライアントからカスタマイズをコピーするので、GoldenクライアントをSource Clientに指定し、あとは実行したら、カスタマイズのコピー完了です。
Transaction code：SCC1を実行
カスタマイズの方法がわからない場合は、Google検索、SAP Community検索で対応
カスタマイズの実施作業を行う際、どんなカスタマイズを実施すればいいのか全くわからない、そもそもその前のカスタマイズ設計図書を作成する時点で、どんなカスタマイズを実施すればいいのか全くわからないのでカスタマイズ設計図書も作成できない、というケースもあるでしょう。
そんな時はどうするかですが、Google検索とSAP Communityを有効活用しましょう。今、皆さんが実施しようと考えているカスタマイズは、過去に世界のどなたかが既に実施していて、その方法をインターネットで公開されていることが少なくありません。
Google検索は説明不要として、SAP Communityとは、世界中のSAP利用者が情報交換を行うことが出来る場で、カスタマイズの方法を公開してくれているユーザーや、とあるユーザーから「こういうカスタマイズをしたいのだけど、どのノードをいじればいいの？」といった質問に対する回答というやりとりが公開されている場となります。
SAP Communityで発注伝票の伝票タイプのカスタマイズ方法を検索した例
大事なのは、日本語で検索しないことです。日本語でSAPのカスタマイズを解説している事例はほぼ見つかりませんので、英語で検索をするようにしましょう。
「どんな検索キーワードで検索すればいいのかがそもそもわからない！」というSAP初心者の方は、カスタマイズをしたい対象までは何とか情報収集しましょう。
例えば、今回はサンプルとして物品とサービスの購入を別々に管理したいという要件がありましたが、それに対するソリューションとして、チームリードといったポジションの自分よりも上位のメンバーが伝票タイプを分けましょう、という方向性にしてくれたとします。
ここで注目すべきは、伝票タイプという言葉です。これをSAP用語（英語）にすると、Document Typeとなります。このDocument Typeがカスタマイズをする対象であり、検索すべきキーワードです。
あとは、業務領域、オブジェクト名、実施したい事、を合わせて検索します。検索キーワードの例は、以下の通りです。
- Purchasing Document Type New Create Customize
à新規に伝票タイプを定義する方法を検索 - Purchasing Document Type SPRO path
à新規に伝票タイプを定義するためにいじるべきノード情報を検索
SAP導入コンサルタントとしてそれなりに経験のある方でも、何をすればいいのかはなんとなくわかっているけどカスタマイズの手順、カスタマイズノードがどこなのかわからない、というときは同じような検索キーワードで検索をかけています。
他人に一から教えてもらうよりも自分で何とかできるようにするのが一番自分の知識として定着しますので、ぜひご自分の力でどういったカスタマイズをすればいいのかを確認してみる、というアクションを取って頂けたらと思います。
カスタマイズテストの実施（CuTの作成）
カスタマイズをGoldenクライアントで実施し、Unit Testクライアントへコピーすることが出来ましたので、カスタマイズを実施した内容がきちんと期待通りに動くかをテストしましょう。
テストを行うときは、カスタマイズ設計図書に事前に記載しておいたテストケースを用います。
テストケースに従ってテストを実行するのですが、カスタマイズテストの結果はきちんと記録し文書にまとめておく必要があります。
カスタマイズテスト結果に含める内容
カスタマイズテスト結果について解説すると、まずこちらのカスタマイズテスト結果を作る単位は、カスタマイズ設計図書と1対1になります。カスタマイズテストの結果に含める内容ですが、以下4つとするケースが一般的となります。
- カスタマイズ概要
- テストケース
- テストステップ、期待結果、実行結果
- バグの有無
カスタマイズ設計図書の作成時点ではテストケースが作成されていましたが、カスタマイズテスト結果を文書にまとめるときはテストケースを実行するにあたっての手順を細かく分け、テストステップとして整理します。
さらに、各テストステップを実行した場合に「このように動いてほしい」という内容を期待結果として整理し、「実際に実行してみた結果」を実行結果に記述します。
問題なく期待結果と実行結果が一致すればいいのですが、差異が出てしまった場合にはバグが発生しているということなので、バグはバグとして記録しておき、バグ解消の対応を実施した後に再度同じテストケースを実行します。
なお、バグが発生したという記録自体はそのまま残すので、カスタマイズテスト結果にはバグが発生した際のテストと、バグが解消された後のテストの双方が記録されます。
カスタマイズテストのサンプル：伝票タイプ（Document Type）の新規作成
サンプルとしてカスタマイズテスト結果の作成方法を見ていきましょう。発注伝票の伝票タイプを新規に作成する、というカスタマイズを実施しましたので、テストケースとしては以下の3つとします。
- 新規作成した伝票タイプが発注伝票の新規作成画面上で確認でき、発注伝票の保存が出来る
- 新規作成した伝票タイプを使用した発注伝票を変更モードにし、保存できる
- 新規作成した伝票タイプを使用した発注伝票を照会モードで照会出来る
これらの結果を実行し、結果を記録していきますが、イメージしやすい「新規作成した伝票タイプが発注伝票の新規作成画面上で確認でき、発注伝票の保存が出来る」というテストケースについてのみ取り扱います。
テストケースを基に、テストステップ、期待結果、実行結果を整理していきます。
まずステップと期待結果を整理してから実行に取り掛かる、という方法をとることが出来るのはどんな手順で進めればいいのかを完全に理解している方だけになるので、実際には画面上でデータの入力を行いながら、期待結果、実行結果を双方記録していく方法がとられます。
- ステップ①
- ステップ：Transaction code：ME21Nを実行し、発注伝票の新規作成画面へ遷移する
- 期待結果：発注伝票の新規作成画面へ遷移する
- 実行結果：発注伝票の新規作成画面へ遷移した
- ステップ②
- ステップ：発注伝票の伝票タイプ：XXを選択し、その他の必須項目を入力する
- 期待結果：発注伝票の伝票タイプ：XXが選択され、その他の必須項目が入力される
- 実行結果：発注伝票の伝票タイプ：XXが選択され、その他の必須項目が入力された
- ステップ③
- ステップ：発注伝票を保存する
- 期待結果：発注伝票が保存される
- 実行結果：発注伝票が保存された（番号：51000000XX
実行結果は、きちんとテストを実行したという証拠を残すという意味もあるので、SAP内で作成された伝票等があればその番号も控えておくようにしましょう。
カスタマイズテスト完了後、検証環境への移送/Transportが行われる
カスタマイズテストが完了したら、開発環境内では問題なく動くということが分かったことになるので、その後検証環境へ移送/Transportが行われます。
移送/Transportが完了したら、今度はもう一度検証環境で動くかどうかをテストします。このときは、比較的バグが発生する可能性は少ないため、カスタマイズテスト結果に相当する文書を残すことは必須ではないものとしているプロジェクトが一般的です。
検証環境で問題なく動作することが確認出来たら、一連のカスタマイズは完了、となります。
事前に作成していたカスタマイズスケジュールに従って、次の作業に取り掛かりましょう。
ご参考：カスタマイズ実施、設計図書作成、テスト結果の記録を同時に実施
ここまでの解説では、まずSand Boxで機能検証を行い、カスタマイズ設計図書を作成し、レビューが完了したらカスタマイズを実施して、その後テストを行い、結果を記録する、という方法をご紹介してきました。
実際のプロジェクトでは、ルール私大の部分もありますが、カスタマイズの実施、カスタマイズ設計図書の作成、そしてカスタマイズテストの実施と記録を同時に行い、最後にまとめてカスタマイズ設計図書とテスト結果のレビューを行う、という手順を踏むことをOKとしているケースもあります。
その背景は主に以下の2つです。
- Sand Boxは誰でも好きにカスタマイズできるので機能検証に向いていないこともある
- カスタマイズは基本的に行った後でも元の状態に戻せる
まず、Sand Boxは本当に誰でも許可なくカスタマイズできる環境になるので、きちんと管理されていません。そのため、適当にカスタマイズされたものが残されているとしたら、その環境で機能検証をした場合、本来動くはずのものが動かない、あるいは本来は動かないはずのものが動いてしまうというケースがあるため、カスタマイズした内容がきちんと動くかどうかはSand BoxではなくUnit Testクライアントで検証すべき、という考えがあります。
次に、カスタマイズは組織構造などの基幹業務の根幹にかかわるものを除けば、基本的に後から元に戻すことが出来ます。そのため、Goldenクライアントにカスタマイズを実施してみて、Unit Testクライアントで検証してみて、だめならGoldenクライアントを戻すという対応をしても良い、という風にルールを定めることもあります。
よって、カスタマイズをGoldenクライアントに実施してみて、Unit Testクライアントにコピーして機能検証をして、OKなら実際に行ったカスタマイズの内容をカスタマイズ設計図書に記載し、カスタマイズテスト結果には機能検証の結果を記録する、という手順を取ることをOKとしているケースもあるのです。
個人的にはこのアプローチの方が効率的にカスタマイズを進めていくことが出来るので好みではありますが、プロジェクトのルール次第ではNGであるケースもあるので、注意しましょう。
終わりに
本投稿では、SAP導入プロジェクトの基本としてWaterfallアプローチにおける開発フェーズの作業内容と成果物について解説してきました。
今後も、SAP導入プロジェクトの基本について少しずつ解説をしていきたいと思いますので、ご参考になれば幸いです。