皆さん、こんにちは。本投稿では、最近日本企業の中で盛り上がりを見せている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リスト（更新）
- 結合テストケース、統合テストケース
馴染みのない用語がいくつか出てきたと思いますが、あとでしっかり解説していきます。
本投稿では、以下を対象に解説していきます。
- 承認済み開発オブジェクトに対する機能設計（FSの作成）
- 開発チームとの機能設計図書の内容確認
- 開発チームによる詳細設計（TSの作成）
- 開発実施、単体テストの実施（TuT、FuTの作成）
承認済み開発オブジェクトに対する機能設計（FSの作成）
要件定義フェーズの中で確認してきた要件の中にはSAP標準機能では太刀打ちできないものも存在します。一つ例を挙げると、既に企業がCRMのソリューションとして使用しているSalesforceと、SAPを連携させたい、といった要件です。
こうした要件に対しては、開発を行うことで対応をします。開発を行う際は、まず機能設計、そして詳細設計、単体詳細テスト、単体機能テストと実施していきます。それでは機能設計から解説していきます。
前フェーズのDesignフェーズでは、どの要件について開発を実施するのか、という点を整理しました。Buildフェーズでは、承認が得られた開発対象オブジェクトについて、機能設計図書（FS：Functional Specification）を作成します。
WRICEFリストに記載されているもの一つ一つに対して、機能設計図書を作成していきます。
機能設計図書に含める内容はWRICEFタイプに依存する
さっそく機能設計図書（FS）に含める内容がどんなものなのかを解説していきたいところですが、こちらの内容、実はWRICEFタイプのよって変わります。
WRICEFタイプとは何だったでしょうか。開発オブジェクトの性質、カテゴリーを表すもので、以下の6種類を指します。
WRICEF Type
- Workflow
- Report
- Interface
- Conversion
- Enhancement
- Form
機能設計図書の中身の話をする前に、まずWRICEFタイプのそれぞれの特徴を解説します。
開発オブジェクト（WRICEF）の解説
SAPが備えている標準機能で対応が出来ない機能が求められた場合に開発するものが、WRICEF（ライセフ）オブジェクトとも呼ばれる、開発オブジェクトです。
プロジェクトによってはアルファベットの順番を変えてFRICEW（フライス）と呼んでいるケースもあります。
開発オブジェクトを作っていくときには、プログラミング、コーディングが必要になってきますが、SAP導入プロジェクトを進める立場としては、必ずしもプログラミング、コーディングの理解は必要ではありません。
業務的には何を実施したくて、どんなデータをInputにして、何をOutputしたいのか、という点を理解することが出来れば、開発者に対して必要な機能設計について伝達することが出来ます。
そこでここでは、開発オブジェクトがどのように分類分けされるのか、そしてそれぞれがどういった機能を提供するのか、という点の解説をします。
この部分を理解することで、必要な機能を開発者に伝達するときにはどういったポイントを押さえておくとよいのかがわかるようになります。
それでは、以下に再掲したWRICEFがそれぞれどういったものなのか、確認していきましょう。
- WRICEF
- Workflow
- Report
- Interface
- Conversion
- Enhancement
- Form
Workflow
Workflowは、業務オペレーションの流れの中において特定のタイミングで、承認や確認といったステップを追加するためのものです。
SAP標準の業務オペレーションを実施していくと、必要になる承認行為などがされなくなってしまう、というときにこのWorkflowを活用します。
以下に、Workflowのイメージを図示します。
Workflowを用いると、特定のトランザクションデータが生成されたときに、そのトランザクションデータの内容の確認や承認を行う必要がある人に向かって承認の依頼を通知することが出来ます。
そして、承認がされれば次のステップに進むことが出来ますし、承認がされなかった場合は前のステップに戻る、という制御をすることが出来ます。
もちろん、承認行為の結果は記録することも出来ます。
SAPの標準機能で提供されている機能もあるので、それらを確認の上、監査対応のためにどうしても追加で開発が必要、というときにはWorkflowの開発を実施することとなります。
Report
Reportは、複数のマスターデータ、トランザクションデータの内容をまとめ、一つのレポートに仕上げるという開発になります。
SAP標準で提供されているレポート機能もあるのですが、その多くは一つのマスターデータの内容や、2－3個のトランザクションデータの内容をまとめたものとなっております。
そのため、それ以上のもっと多くの情報を一元化してみてみたい、という要望が上がったときにはReportを開発することとなります。
また、SAP標準のレポート機能では、単純にデータベースに存在するデータを検索条件に合わせて抽出する、といった機能に閉じるものが多いため、特定のプログラムロジックを実行してデータの読み替えを行う、といったことをしたあとでレポートとして出力したい場合はReportの開発が必要になるでしょう。
Interface
Interfaceは、SAPと他のシステムを連携させるための開発オブジェクトです。
SAPは基幹システムを担当し、需要予測や在庫管理、物流管理、予算管理などは他のシステムを使っている、というケースは多くあります。
そうしたときに、SAPと他システムの間で情報のやり取りをする必要があるとき、Interfaceを開発します。
以下に、Interfaceのイメージを図示します。
やり取りする情報は、SAPの視点ではマスターデータ、トランザクションデータに加え、カスタマイズ/Configurationも対象となります。
SAPから送り出すときと、SAPで受け取るときで処理は明確に異なるため、それぞれを別のプログラムとして開発することとなります。
なお、Interfaceが対象とする情報は、日々更新がされるようなデータで、継続的にSAPと他システムの間で連携が必要とされる情報となります。
グローバル企業などは買収を行ったことで子会社となった企業がSAPではない独自のシステムを持っているケースがあり、それらとの連携をするためにInterfaceの開発が大量に発生してしまうことが多いのですが、大量に開発を行うことはプロジェクトのスケジュールを長引かせる要因にもなりますので、出来るのであれば大半の業務をSAPで行うようにすると、Interfaceの必要性は減っていきます。
Conversion
Conversionは、旧システムから新システムであるSAPへデータを移し替えるときに使用されます。
以下にイメージを図示します。
対象となるのは、マスターデータ、トランザクションデータとなります。
カスタマイズ/Configurationはここには登場しませんが、新システムであるSAPを動かすときには、それはカスタマイズ/Configurationは手作業で実施するからです。
なお、旧システムから移すのではなく、Excelなどのファイルからデータを取り込んで移すという場合にもConversionは使用されます。旧システムからExcelファイルにデータの中身を出力して、それをSAPに取り込んでいるというケースも多いかもしれません。
Interfaceでは、日常的に情報の連携をしなくてはいけない性質のデータを取り扱いましたが、Conversionは基本的には一回だけデータを移し替えればあとは使用しないものとなります。
しかしながら、移し替えなくてはいけないデータのボリュームが大量になっている場合はもちろんプログラムでデータを移し替える以外に選択肢はありませんので、頻度高く使うものではないのですが利用する開発オブジェクトとなります。
ただし、買収などによって子会社が増え、取り扱う必要のあるマスターデータが増えた場合などは何回かConversionのプログラムを実行することもあります。
Enhancement
Enhancementは、SAP標準機能が提供していない項目を作る、または業務の自動化を進めるためにトランザクションデータ生成を自動化する、といったものです。
以下にイメージを図示します。
マスターデータ、トランザクションデータに存在していない項目を追加する、これはイメージしやすいですね。
なお、項目を追加することを項目の拡張、と表現し、こうして追加された項目は追加項目、または拡張項目と言われます。
あるいは、業務の自動化を進めたいので、特定のトランザクションデータを生成したときにボタンを押して処理を実行すると自動で後続のステップで必要なトランザクションデータを生成する、といったことも可能です。
トランザクションデータの中で見ても、とある項目を指定すれば、SAP標準機能では参照していないマスターデータから自動で情報を取得し、項目を埋める、といったことも可能です。
Enhancementは、無いと業務が全く実行できない、という性質のものが多くないため、開発オブジェクトの数を減らしたいというときには真っ先に減らすターゲットとなります。
Form
Formは、マスターデータやトランザクションデータの内容を使用して外部に出力できる形式の帳票を作成します。
以下にイメージを図示します。
例えば、企業は発注書や領収書などを作成しますよね。そうしたものを作る機能がFormです。
Formを開発するときは、どの情報を取って、どこに表示するかというレイアウトなどを設計していきます。
Formは商習慣的に、あるいは規制当局への提出の必要性などから必須なものが多いです。
機能設計図書に含める内容（どのWRICEFタイプにも共通するもの）
ここまでで、WRICEFオブジェクトについて、タイプごとにどういったものなのか、という点を解説してきました。
どのタイプなのかによって、機能設計図書（FS）に記載すべき内容が変わりそうだ、という点がイメージできたのではないでしょうか。
それではここから、機能設計図書に記載する内容について解説していきます。
まずは一般的に、どのWRICEFタイプであっても変わらずに記載するものから解説します。
- 機能設計図書の概要、目的
- 関係する要件概要
- 関係するカスタマイズ一覧
- 前提条件
- プログラムの処理、順番
- テストケース
まずは概要と目的ですが、これは簡単ですね。この機能設計図書で実現する機能はどんなものなのか、その目的はビジネス的には何なのか、という点を記述します。
次に、この機能を開発するにあたって関連する要件を整理します。要件一覧からの抜粋でOKです。
次に、この機能を動かすために必要なカスタマイズの一覧を整理します。例えば、カスタマイズで新規に作成した発注伝票の伝票タイプが選択されているときだけ動いてほしいプログラムを開発するのであれば、その伝票タイプの作成というカスタマイズが関連するカスタマイズ一覧の中に記述されている必要があります。
カスタマイズとは全く無関係な開発であればこちらはブランクになります。
そして前提条件ですが、こちらにはプログラムが動く際の前提条件を記載します。関係するカスタマイズもある意味ではそうしたカスタマイズがされていることを前提にプログラムが動作するのであれば前提条件という扱いになりますが、そうしたカスタマイズとは別の前提条件があればここに記載します。
例えば、別のプログラムが出力したファイルを処理するというプログラムを作る場合は、そもそも別のプログラムがファイル出力をきちんと行ってくれることが前提になる、といったことを記述します。
そして最も手厚く記載をしてあげる必要があるのが、プログラムの処理、順番です。
こちらは後程WRICEFタイプ別にいくつかサンプルをお見せするので、そちらをご覧ください。
最後に、テストケースです。プログラムの処理として、複数の分岐がある場合はそれらの分岐をすべて網羅的にテストする様に複数のテストケースを作るようにします。
機能設計図書に含める内容（WRICEFタイプ別に書くもの）
それでは次に、特定のWRICEFタイプの時に機能設計図書に含めなくてはいけないものを解説します。
それぞれ、解説していきます。
Workflow
WorkflowプログラムのFSを作成するときは、ワークフロー実施のトリガーを記述します。
Workflowとは何かというと、業務オペレーションの流れの中において特定のタイミングで、承認や確認といったステップを追加するためのものでした。
したがって、どのタイミングでワークフローを動かすのか、つまりワークフローを実施するトリガーを記述する必要があります。
例えば、SAPの標準機能では、発注伝票が作成されたとき、その発注伝票の合計金額を確認して、ある一定以上の金額になってしまっている場合は発注に対する承認行為を必要とする、という設定を行うことが出来ます。
しかしながら、発注伝票の個別の明細、つまり何を買うのか、という対象品目について細かな確認を設けることは出来ないため、この部分をWorkflow開発で対応することになったとしましょう。
実装する機能のイメージとしては、発注伝票に含まれる購買対象の品目が、特定の要注意品目リストに入っている場合は、本当にそれを発注してもいいのかどうかを責任者が確認するために承認ワークフローを起動する、というものだとします。
このとき、Workflowのトリガーと、その後の処理内容は以下のように記述します。
実際にはもっと丁寧に細かく記載していきますが、イメージとしてはこのように記述するのだな、と思ってください。
- 処理内容（サンプル）
- 発注伝票が新規に作成され、保存されたときにWorkflowプログラムを実行する
- 発注伝票タイプが事前に定義した伝票タイプXXXX、YYYY、ZZZZの時に限り本プログラムを実行する
- Workflowプログラムを実行した発注伝票に含まれる個別明細情報をすべて取得し、品目番号を取得する
- 取得した品目番号の全てに対して、事前に定義しておいた要注意品目リスト上の品目番号と合致するかどうかを調べる
- 取得した品目番号の全てに対して、要注意品目リスト上の品目番号と合致するかどうかを調べた後、一つでも要注意品目リスト上の品目番号と合致した品目番号があった場合は、承認ステータスを未承認の状態とし、事前に定義しておいた承認担当者へメール通知を行い、処理を完了する
- 取得した品目番号の全てに対して、要注意品目リスト上の品目番号と合致するかどうかを調べた後、一つも要注意品目リスト上の品目番号と合致した品目番号がなかった場合は、処理を完了する
Report
Reportプログラムを記述するときは、レポート作成時の参照テーブル、参照項目、レポート作成時の抽出条件、レポートのレイアウトとフィルター機能を記述します。
Reportとは、マスターデータやトランザクションデータをデータベースから抽出し、一つのレポートにまとめて出力する機能の開発のことでした。当然ながら、どのデータを取得すればいいのか、という情報としてテ－ブル情報、項目情報が必要になりますし、抽出の条件、また抽出後に絞り込みを行うためのフィルター機能について記述していく必要があります。
ここで、テーブルと項目名について補足します。SAPでは、マスターデータもトランザクションデータも個別に名前が付けられたテーブル上に格納されています。
例えば、発注伝票（Purchase Order）についての情報は、EKKO、EKPO、EKBE、EKKNといった複数のテーブルに格納されています。EKKOテーブルは発注伝票のHeader、つまり全体に関係する情報である発注先、合計金額、支払い条件、等の情報を持っていて、EKPOテーブルは発注伝票のItem、つまり個別明細の情報である発注する品目、数量、単価等の情報を持ちます。
そして、各テーブル上に発注先、合計金額、支払い条件、発注する品目、数量、単価といった項目を持っています。
Reportのプログラムを設計するのであれば、こうした複数存在するテーブルのうち、どのテーブルから、どの項目を取得してあげる必要があるのか、という点をFSの中では整理してあげる必要があります。
次に抽出条件ですが、これはここではレポート機能が出力したくないものを整理します。
例えば、過去に作成された発注伝票に入荷伝票の情報、そして受領実績の情報を付け加えて一覧で確認するというレポート機能を作るとしたとき、発注伝票を作成したもののキャンセルをしていた場合は、このReportプログラムでは処理を掛けなくて良いものとする、という整理が出来ます。
Report機能に余計な負荷をかけることを防ぐ効果もありますので、抽出条件の設定も忘れずに記載しましょう。
最後にレポートのレイアウトとフィルター機能ですが、レイアウトはレポートがどのように出力を行うべきか、というものを指します。レイアウト上に存在する項目を用いてフィルター機能を設定したい場合は、一致するかしないかでフィルターを掛けられるようにする、または番号や日付の範囲を指定してフィルターを掛けられるようにする、といった要望をFSに記述することになります。
Report機能のFSを作成するときは、どのテーブルからどの項目を取得し、そしてどういったレイアウトに仕上げるのか、という点を明確にする必要があります。したがって、Excelファイルを用いた表で参照するテーブル、項目とレポート上に出力する項目を一覧で整理するのが一般的となります。
処理に関する記述についてサンプルをお見せすると、以下のようになります。
機能としては、発注伝票と入荷伝票の情報を取得してレポートに出力するというものだとしましょう。
- 処理内容（サンプル）
- 本Reportプログラムは専用のTransaction codeを介して実行される
- 専用のTransaction codeの実行後、本レポートプログラムの初期画面が表示され、ユーザーはレポート出力時のフィルター設定を実施する。フィルター設定の実施後、ユーザーによってレポートの出力を実行されることで発注伝票、入荷伝票の各種テーブルからレポート出力に用いる項目を取得する
- 発注伝票、入荷伝票のデータ取得時の参照テーブル、参照項目は別添のスプレッドシートにて定義する（機能設計図書内にExcelファイル等を添付しておく）
- レポート出力時のレイアウトは別添のスプレッドシートにて定義する
（機能設計図書内にExcelファイル等を添付しておく）
ほとんどの内容をスプレッドシートで書いているのでそれを見てください、という内容にしているのがお分かりになると思います。
Interface
Interfaceのプログラムは、SAPとその他のシステムの間で情報のやり取りを出来るようにする機能でした。
FSに含めるべきは、データ連携対象項目のマッピング（テーブル、項目）、データ連携時の処理ロジック、そしてデータ連携の頻度、トリガー、手法です。
テーブルと項目についてはReportプログラムの箇所で既に説明していますので、なんとなくご理解いただけるかと思いますが、InterfaceプログラムのFSでも同様に、SAP内ではどのテーブルからどの項目を取得して外の別システムに対して送る必要があるのか、逆に外から送られてきたデータをSAP側ではどのテーブル、どの項目に割り当てる必要があるのか、という点を整理します。
ここでも、Excelファイルを活用してテーブル、項目名を整理していきます。とくにInterfaceの場合は、送る側と受け取る側で違う項目名称を持っているので、それらの関係性を整理するために作成する表形式の情報をマッピングシートと呼びます。
単純に項目を一方のシステムからもう一方のシステムに送るだけで済むのであればよいのですが、時には送る側で何かしらのデータの変換を行う必要があるケースもあります。
しょうもない例ですが、SAPでは発注伝票の明細は標準の状態ですと10、20・・・と増えていきますが、これがInterfaceの受け手側の方は1，2・・・と増えていくとすると、そのままではInterfaceを受け取ることが出来ないので、Interfaceプログラムを実行するときに桁を１つ、ずらしてあげるということもあります。
こうした特殊な変換などが必要な時は、それも併せてマッピングシートと呼ぶExcelファイルなどの表形式のファイルに整理して、機能設計図書に添付するようにしましょう。
マッピングシートのほかに、データ連携を行う頻度、トリガー、手法も整理が必要です。
頻度については、毎日決まった時間で実施するのか、毎週か、それとも人の手によって実行されたときにInterfaceが動くのか、という点を記述します。
トリガーは、人の手によって実行する場合はTransaction Codeの実行ということになりますが、何かのイベントを基に実行される場合はそのイベントについて記載します。
データ連携の手法としては、様々ありますが、例えばファイル連携、オンラインでのデータベース連携、等があります。この辺りは機能設計図書に含める内容であっても結構テクニカルで開発チームの知識も必要になってくる部分なので、Functional Consultantと開発チームのメンバーが議論して設計するということにして、あとで追記するということも多いです。
それでは、Interfaceプログラムの処理のサンプルを以下にて共有します。
発注伝票がSAPで作成されたら、それを外部の倉庫管理システム（WMS：Warehouse Management System）で入庫の予定情報として連携するためのInterfaceプログラムだとしましょう。
- 処理内容（サンプル）
- 本Interfaceプログラムは発注伝票の新規作成と保存をトリガーとして実行される
- 本Interfaceプログラムを実行する際の条件は以下の通り
- 発注伝票の伝票タイプがXXXX、YYYY、ZZZZのいずれかに該当するとき
- 発注伝票の明細カテゴリーにAA、BBが含まれるとき
- これ等に該当しない場合、本Interfaceプログラムは以降の処理を実施しない
- 発注伝票から各種項目を取得し、WMSにて処理するCSVファイルを出力する。発注伝票から取得する項目は別添のスプレッドシートにて定義する（機能設計図書内にExcelファイル等を添付しておく）
- CSVファイルは指定のフォルダーパスに格納を行い、その際のファイル名称はタイムスタンプを用いたものとする。（例：YYYY_MM_DD_HH:MM:SS_PO_OBD）
Interfaceプログラムの機能設計図書を書くときは、Interfaceがうまく動かなかったときの異常終了の方法や、エラーをどのように管理するのか、といった内容も記述が必要になります。
SAP導入初心者の方ですと記述するのが結構難しい内容になりますが、そうしたときは開発チームのメンバーと相談しながら、どういった方法がオプションとして考えられるのか、一緒に考えていくアプローチをとることも一般的です。
Conversion
Conversionは、旧システムから新しく導入するシステムへマスターデータなどを移行するときに使用するプログラムでした。
機能設計図書に含める内容は、結構Interfaceプログラムの時と似ていて、データ移行時のInput/Outputのマッピング、データ移行時の処理ロジック、そしてデータ移行の頻度、トリガーとなります。
Interfaceプログラムは、SAPと外部のシステムを日常的に連携させるためのモノでしたが、Conversionはそれの頻度が1回だけになる、そして古いシステムから新しいシステムへの連携になる、というイメージです。
したがって、頻度と連携を行うシステム同士が違うだけで、データを一方のシステムからもう一方のシステムに送る、あるいは移すという点では非常に似ています。
したがって、Interfaceプログラムの時に解説したものと同じようなイメージで、Conversionのときもデータのマッピングシートを作成することになります。子のマッピングシートの中ではInputとOutputの関係性が整理され、また単純なデータの移し替えではなくロジックを用いた変換が必要な場合に対する処理内容も記載することになります。
頻度、トリガーについてはInterfaceの時と同様ですが、基本的にはシステム導入/移行時の1回のみ、プログラムを手動で実行する、という内容となります。
以下、サンプルです。古いシステムの品目マスターデータを新しいシステムのマスターデータに移行するというプログラムだとしましょう。
- 処理内容（サンプル）
- 本Conversionプログラムは専用のTransaction Codeを介して実行され、品目マスターの情報を持つCSVファイルを読み込み、品目マスターを新規作成する
- 本Conversion プログラムを実行すると、CSVファイルの指定を行う初期画面を表示する
- ユーザーが品目マスター情報を持つCSVファイルのフォルダーパスを指定し、ファイルの読み込みを実行すると、本ConversionプログラムはCSVファイルを読み込み、登録される品目マスター情報を次の画面で一覧表示する。品目マスター情報には“Ready to be Uploaded”とステータス情報を付与する
- このとき、指定されたCSVファイルが指定のテンプレートに準じていない場合は読み込みエラーを発生させる
- 品目マスター情報を一覧表示し、ユーザーは内容を確認したうえで新規作成を行う場合は新規作成を実行する
- 品目マスターの新規作成実行後、品目マスター情報の一覧表示画面に戻り、正常に新規作成された品目マスターには“Succeeded”、新規作成が失敗した品目マスターには“Error Occurred”とステータス情報を付与する
Enhancement
Enhancementは、SAP標準には存在しない項目を追加する、あるいはプログラムの処理を自動化するといった機能になります。
項目の拡張をするときは、拡張項目を付けるテーブル名、項目名を記述し、自動化プログラムを作るときはプログラム実行のトリガーについて記述します。
項目拡張の時は、例えば発注伝票上に存在しない項目を新規に作成するときは、発注伝票のどのテーブルに対して、どんな名称の項目を作るのか、という点を整理します。
何度かすでに出てきていますが、発注伝票と言ってもEKKO、EKPO、EKEBなどなど複数のテーブルが存在し、それぞれ役割が違います。項目拡張を発注伝票のHeaderに対して実施したいのであれば、テーブル名はEKKOだと指定してあげて、そして項目名称も付ける必要があります。
項目名称には、画面上に表示されるBusiness目的の項目名と、システム内部の処理のために使用するTechnical Nameの2つがあるので、それぞれ定義してあげましょう。
処理を自動化するというEnhancementプログラムを作成するときは、そのプログラムがどんな時に動いてほしいのか、という点をトリガーとしてきちんと記述する必要があります。
例えば、結構大変そうですが、発注伝票を作成したときに、購入する対象の大きさや重さ、数量などを総合的に考えてどれだけの輸送費がかかるのかを自動で計算するというプログラムを作るとしましょう。
そうしたときは、プログラムのトリガーは、発注伝票が新規作成され、保存されるときとする、または、発注伝票に品目情報を入力した後に、ユーザーが自ら発注伝票の作成画面上に作ったプログラム実行ボタンを押すことでこの計算処理が行われるようにする、といった複数のパターンが考えられます。
したがって、何がトリガーになるのか、という点を明確にする必要があります。
以下、こちらのプログラムの処理内容のサンプルとなります。
- 処理内容（サンプル）
- 本Enhancementプログラムは発注伝票の新規作成、保存をトリガーに実行される
- 本Enhancementプログラムが実行される条件は以下の通り
- 発注伝票の伝票タイプがXXXX、YYYY、ZZZZのいずれかであるとき
- 発注伝票で指定されたSupplierとの契約では輸送費の負担が自社となっている場合
（別テーブル上で一覧化しているSupplierと合致する場合）
- これ等の条件に合致しない場合は以降の処理は実施しない
- 発注伝票の明細上の品目番号、数量を取得し、品目マスターから荷姿情報、重量、サイズを取得する
- 発注伝票および品目マスターから取得した情報を基に輸送費を算出し、発注伝票のHeaderへ追記する（輸送費算出のロジックは別添資料を参照）
Enhancementプログラムは、項目拡張の場合は簡単なのですが、処理の自動化を目的とするプログラムの場合は機能設計図書の作成難易度が最も高くなる傾向があります。
一言で自動化と言っても、Aの場合は、Bの場合は、Cの場合はどうするのか、という条件分岐を整理して、それぞれの条件をどう判定するのか、どういった処理を実行していくのか、という点を明確に記述する必要がありますので、書き始める前にどんなシナリオが自動化の対象になるのかを整理する様にしましょう。
Form
Formは、システムから帳票を出力する必要があるときに使用されます。
帳票を出力する際は、もちろんレイアウト、どの項目をSAP内のどのテーブル、どの項目を使って埋めるのか、という点を整理する必要があります。
帳票のイメージを機能石器図書に残すときは、Excelファイルを使い、帳票を再現する様にするのが一般的です。その際、帳票上の各項目の上下の幅、横幅、項目と項目の間の間隔といった情報を事細かに定義していきます。
処理内容については、Formプログラムの場合はExcelで定義した通りに帳票を出力する、というものになるので割愛させて頂きます。
機能設計図書は特に重要、レビューを慎重に
少し長くなりましたが、WRICEFのタイプごとにどんな内容を機能設計図書に書いていくのかを解説しました。ここまでで説明してきたい内容を機能設計図書に盛り込んだら、次はレビューのプロセスです。
機能設計図書のレビューは特に重要になるので、レビューは慎重に行うようにしましょう。1回でレビューが完了するということは基本的にないものと考え、1回目は対面レビュー（Walkthrough）、2回目はOn-line レビュー（メール等で送付して確認しあう）という手順を踏むことを前提にしてスケジュールを作るようにしておくことをおススメします。
開発チームとの機能設計図書の内容確認
機能設計図書のレビューが終わったら、次は開発チームと認識合わせを行います。
SAP導入に関わる開発チームは、要件定義のワークショップに参加していないメンバーになるので、要件の背景や、求められている機能の背景などを全く知らない状況にいることも少なくありません。
そういった状態で、仮に機能設計図書はこれだから、あとはこれに従って開発しておいてね、とお願いしても、思い違いや認識違いが生まれてしまうことが多々あります。
したがって、開発チームとプロセスチームとの間で機能設計図書を対面で確認するということは必須の作業と言えるでしょう。
場合によっては、プロセスチーム側で機能設計図書のレビューを終える前から開発チームにも相談に乗ってもらうということも良いでしょう。その場合、これ以上は大幅に設計に変更が加わらないであろう、という点まで予想できている状態で開発チームと会話をすることをおススメします。
せっかく開発チームと認識合わせをしたのに、機能設計図書に変更が加わったら開発チームとしてはどういうものを開発すればいいのかうまくつかめなくなってしまう危険性もあるからですね。
開発チームによる詳細設計（TSの作成）
機能設計図書について、プロセスチームと開発チームの間で認識合わせが出来たら、次は開発チームが詳細設計を行ってくれます。詳細設計によって作成される文書が詳細設計図書（TS：Technical Specification）です。
開発者との間で適宜コミュニケーション
本投稿はプロセスチーム所属の方向けの内容にしており、開発担当者の方は対象としておりませんので、詳細は省かせて頂きますが、詳細設計の最中に開発者の方から「こういう時はどういう処理をすればいいのか」という質問がプロセスチーム側に出されることがあります。
私はこれまで、開発者は中国かインドにいるという体制でSAP導入プロジェクトをしてきていたのですが、彼らからメッセージが飛んできて、「今から電話できるか」とよく聞かれたものです。
開発が進んでくると、1時間や30分の打ち合わせは必要なくても1－2分の会話が必要、という状況が多く発生しますので、こうした開発者からの質問にも対応する必要があることを認識しておくようにしましょう。
あまりに他の作業が忙しくて開発者の質問に回答することが出来ずにいると、自分が回答を出来ないせいで開発スケジュールに遅延が発生する、ということが起きてしまうこともありますのでご注意下さい。開発者からの質問にはクイックに対応することをおススメします。
詳細設計図書のレビュー
詳細設計図書も機能設計図書と同様にレビューをする必要があるのですが、プロジェクトによっては開発が完了し、単体テストも完了してから実施されるというケースが一般的です。
詳細設計図書を作成したら、そのレビューが完了するまでは開発に着手してはいけない、となってしまうと作業が遅れてしまうリスクもあり、また開発を実際に進めていく最中に開発者が「あれもやらなきゃ」というように追加の処理を設計に盛り込む必要があると思いつくというケースもあります。
したがって、実際には詳細設計図書の作成、開発の実施、そして単体テストの実施は並行するものだとご認識ください。
開発実施、単体テストの実施（TuT、FuT）
開発チームが開発を行ってくれたら、まずは開発チーム側でプログラムの動作を確認してくれます。これが、単体詳細テスト（TuT：Technical Unit Test）です。
その後、開発チームからプロセスチームに対して「プログラム出来ましたよ」と連絡がされると、プロセスチームは単体機能テスト（FuT：Functional Unit Test）を実施します。
単体機能テストでバグがないかを確認する
単体詳細テストについては割愛させて頂き、単体機能テストについて解説をしますと、ここで行うテストは機能設計図書にあらかじめ記述しておいたテストケースに準拠します。
テストを実施する際には、カスタマイズテストのセクションで解説した内容と同じように、テストケースをより詳細なテストステップに分解して結果を記録していきます。
開発チームは、ビジネス要件やカスタマイズの内容を把握せずに技術的に動くかどうかという観点で探知ア詳細テストを実施しているので、単体機能テストを実施する際にはビジネス的に実際に使用される可能性のあるデータを用いてテストを行います。
そうすると、単体詳細テストではＯＫとなっていたものが、単体機能テストではＮＧとなり、機能設計図書に記載した通りに動いていない、というバグを見つけることもあります。
バグが見つかった場合は開発者にフィードバックを行い、修正対応をしてもらいます。このとき、バグが発生したのはそもそも機能設計図書にきちんと記述がされていないから、という可能性もありますので、そうした場合には機能設計図書の修正からやり直すことになります。
また、少し面倒ですが機能設計図書に修正が加わったということはその修正内容についても責任者がレビューを行う必要があるので、レビューも実施することになります。
単体機能テスト完了後、検証環境へ移送し検証実施
単体機能テストでは問題がないことが確認出来たら、次は開発環境から検証環境へ開発プログラムを移送します。
カスタマイズについての説明の時と同様に、WRICEFの開発も同様に開発環境から検証環境へ移送を行い、検証環境で最終チェックを行います。
検証環境でも問題がないことを確認出来たら、晴れてプログラム開発は完了となります。 次のプログラム開発の作業もどんどん進めていきましょう。
終わりに
本投稿では、SAP導入プロジェクトの基本としてWaterfallアプローチにおける開発フェーズの作業内容と成果物について解説してきました。
今後も、SAP導入プロジェクトの基本について少しずつ解説をしていきたいと思いますので、ご参考になれば幸いです。