皆さん、こんにちは。本投稿では、最近日本企業の中で盛り上がりを見せている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リスト（更新）
- 結合テストケース、統合テストケース
馴染みのない用語がいくつか出てきたと思いますが、あとでしっかり解説していきます。
本投稿では、以下を対象に解説していきます。
- 結合、統合テストケースの作成
結合、統合テストケースの作成
開発フェーズが終わると、次に待つのはテストフェーズです。
開発フェーズではカスタマイズあるいはプログラム開発を行い、カスタマイズまたはプログラム単体レベルでのテストを行うということを説明してきましたが、テストフェーズでは一連の業務プロセスが最初から最後までつながるかどうか、という観点でカスタマイズや開発したプログラムをテストします。
そのため、開発フェーズの間にテストフェーズではどのようなテストを行うことにするか、という検討を行います。
こうしたテストのことを、結合テスト、統合テストと言い、ここで作るのが、結合テストケース、または統合テストケースです。
まず、単体テストとの違いも含めて結合テストと統合テストについてご紹介します。
単体テスト、結合テスト、統合テストとは
SAP導入に限らず、システム導入プロジェクトには単体テスト、結合テスト、統合テストという3つのテストがあります。（もっと言えば受入テストといったものもありますが、ユーザーに最終的にシステムの受け入れをしてもらうという意味合いのテストであり、ここでご紹介する3つのテストのうち、統合テストと同じ内容を用いることもあるので割愛します）
単体テストは、開発した、またはカスタマイズした機能そのもの、つまり機能単体に絞ってテストを行うものです。
例えば、SAPの顧客マスター上に重要顧客であることを示す項目を設定したとしましょう。
単体テストでは、設定した通りに顧客マスター上に新たに項目が追加されているかどうか、を確認します。
結合テストは、機能単体を見るのではなく、業務が流れるかを見ます。業務同士のつながりがうまくいくかをチェックするというテストになるのですが、同じシステムの中でのつながりをテストするものを特に内部結合テスト、システム同士の間のつながりのテストを外部結合テストと言います。
例えば、SAPの顧客マスター上に重要顧客であることがわかるフラグが設定されていたとして、それが受注伝票や出荷伝票上にも引き継がれることが要件であった場合、SAPで実際に受注伝票や出荷伝票も作ってみて、重要顧客のフラグが引き継がれるかをテストするのは内部結合テストです。
また、出荷完了後にSAPと接続しているSalesforceなどで、重要顧客への販売がされたことがわかるようにダッシュボードが更新されることが要件であった場合は、こちらをテストするのは異なるシステム同士の結合をテストしているので外部結合テストに相当します。
最後に統合テストですが、これは部門や責任範囲を横断する一連の業務を、初めから終わりまで実行するというテストです。複数のチームが関係するため最も工数がかかるテストとなります。
例えば、Salesforceで引き合い登録を行い、商談情報が更新されてきたら受注し、その受注情報をSAPに伝達し、自動で受注伝票を作成する。このとき、重要顧客フラグを顧客マスターから取得した状態とし、以降の出荷伝票や請求伝票まで作成し、SAPからSalesforceへ重要顧客への販売実績を送り返す。
請求伝票作成後は、売掛金の計上を行い、ここでも重要顧客のフラグを用いて重要顧客からの支払いがあとどの程度存在するのか、というレポートが確認できるようにしておく。
そして、支払いが行われたら売掛金を消込、重要顧客からの支払い確認レポートも更新が入ることを確認する。
このような一連の部門横断の業務プロセス全体をテストします。
プロジェクトによっては、単体テストと結合テストは開発フェーズのうちに完了させ、統合テストをテストフェーズで実施するというケースもあれば、単体テストを開発フェーズで完了し、テストフェーズでは結合テストを実施し、その後統合テストを実施するというように分けるケースもあります。
本書籍では、どこからどこまでの業務プロセスをテストケースに含めるか、という点が結合テストと統合テストの違いなので、一緒にしてご説明します。
テストフェーズ向けのテストケースの作り方
要件一覧、カスタマイズ一覧、プロセスフローを基に作成
テストフェーズにおける結合テスト、統合テストのテストケースは、Designフェーズの間に作成した要件一覧とプロセスフロー、そして開発フェーズで作成しているカスタマイズ一覧を基に作成します。
開発している最中のプログラムや、カスタマイズはいずれも要件一覧に紐づいており、要件一覧には業務プロセスＩＤが付与されています。したがって、WRICEFやカスタマイズのテストを行い、要件一覧に記載されている要件が全て期待通りに実装されているかをテストしようと思ったとき、まず要件一覧を確認することでどの業務プロセスを実行すればテストできるのかがわかります。
要件一覧上でWRICEF IDが確認出来れば、その要件に対して開発したWRICEFオブジェクトは要件一覧上の業務プロセスIDを実行してみることで確認が出来ることになります。
要件一覧上にWRICEF IDが無い場合は、カスタマイズ等で対処していることになりますので、そのときはカスタマイズ一覧を確認します。カスタマイズ一覧上のカスタマイズにも同様に、業務プロセスIDが紐づいているので、カスタマイズ一覧を確認することでどの業務プロセスIDを実行するとカスタマイズがテストできるのかがわかることになります。
そして、設計フェーズで作成したプロセスフローはそれぞれに対してプロセスIDが付与されているので、プロセスフローを実行することでどの要件が、そしてどのカスタマイズ、WRICEFの機能がテストできるのかがわかるのです。
こうして要件一覧に記載されている要件、つまりカスタマイズまたはWRICEFで対応することになっている要件が全てプロセスフローの実行によって検証されれば、要件は満たせることが確認できるわけですが、要件一覧に記載されている要件、カスタマイズ、WRICEFの機能が網羅的に検証できるようにテストケースが抜けもれなく整理されているかを確認する必要があります。
よって、要件一覧、プロセスフロー、カスタマイズ一覧を基にテストケース一覧を作成します。
テストケースをExcelなどの表形式のファイルにまとめたものをテストケース一覧と呼びますが、これを作るときには各テストケースに関連する要件、WRICEF ID、そしてカスタマイズの内容も併せて整理します。
カスタマイズ設計図書を細かく分けている場合はカスタマイズ設計図書の名称をカスタマイズの内容としてテストケース一覧上に記載するとよいでしょう。
このようにテストケース一覧を作成することで、要件、WRICEF ID、そしてこれまでに行ってきたカスタマイズの全てがもれなくテストされるようになっているかどうかを確認できます。もし、要件一覧にはあるのにテストケース一覧上には記載がないものがあれば、その要件をテストするためのテストケースを追加する必要があります。
派生パターンも漏れなく整理することが重要
ここで注意したいのが、要件一覧とプロセスフローをもとにテストケースの一覧を作成する際、WRICEFの内容によっては派生したパターンを追加しなくてはいけないという点です。
WRICEFプログラムの中には複数の機能や複数の条件分岐を持っているケースがあり、また業務オペレーションも特定の条件によっては分岐があるケースも存在しますので、それら全てが検証できるように同じプロセスフローの実行であってもパターン分けする、という作業を行います。
少し例を取り上げて、派生パターンがどのように生まれるかをご紹介しましょう。
在庫転送のパターン分け
- 在庫転送要求がマニュアルで作成された場合
- マニュアルで作成した在庫転送要求に対しては承認行為が必要になる
- 在庫転送要求がシステムによって自動で作成された場合
- システムによって作成された在庫転送要求に対しては承認行為を行わない
在庫転送というのは、とある拠点から別の拠点に対して在庫を送るという業務プロセスです。仮に、今回のケースではこの在庫転送をマニュアルで実施するケースと、システムが在庫の不足を検知して自動で在庫転送を始める場合の2つがあるとしましょう。
そうすると、同じ在庫転送のプロセスであっても、人がマニュアルで在庫転送を実施した場合は承認行為を必要とし、システムが自動で実施する場合は承認行為を不要とする、というように処理を分ける場合がります。
こうした要件が存在した場合は、同じ在庫転送プロセスであっても、マニュアルで実施された場合とシステムによって自動で実施された場合の2つのパターンをテストする必要があります。
これ等の違いが既にプロセスフローの作成の時点で理解されており、別々のプロセスフローが作成されている場合はテストケースを作成する労力もそこまで大きくはならないのですが、プロセスフローが１つしかないものの、実際にシステムが動くときは異なる動作をする、というケースが見つかった場合は異なるテストケースとして整理をするようにしましょう。
単体テストの時とは違い、あらかじめステップを作る必要がある
テストケースの一覧が出来たら、それをステップに分解していきます。
単体テストのときはテストケースを作っただけで、テストを実行するときにステップに分けていきましたが、結合テスト、統合テストの場合は最初からステップまで含めて作り上げます。
理由は、テストステップまで詳細に分解しておいて、どのステップでどのカスタマイズが、そしてどのWRICEFプログラムが検証されるのかという点を抜けもれなく計画することが重要だからです。
行き当たりばったりでテストシナリオを作って実行してみた結果、プロセスフローは確かに実行したものの、とあるプログラムが一度も実行されずにテストが完了してしまった、という事態は避けたいですよね。
したがって、どのステップでどのプログラムのどのパターンを実行するのか、という点まで整理が必要になるので、テストの実行前の段階でステップまで詳細化しておく必要があるのです。
結構大変に作業のように思えるかもしれませんが、テストフェーズの前の段階でプロジェクト内ではカスタマイズ、そしてWRICEFの単体テストケースの実行結果が作成されているので、これを使用することでほとんどの作業は単体テストケースを結合、統合テストケース用にコピーペーストして少し修正を加える、といった程度の作業で終えることが出来ます。
テストケース一覧とテストステップはレビューの対象
テストケースとテストステップが作成出来たら、それをレビューします。
ビジネス側のユーザーに確認をして頂き、要件、WRICEFのテスト、カスタマイズのテスト以外の抜け漏れなどを確認してもらいましょう。
レビューにおいては、ビジネス側のユーザーから「このパターンは含まれていないのか」といったコメントが上がることが多々あります。そうしたときは、システムの処理としてはパターン分けの必要が無いのでパターンとして含めていないと説明する、あるいは指摘された通り追加する、といった対応をとることになります。 いずれにせよ、テスト実行前の段階で抜け漏れを確認することが非常に重要になります。
終わりに
本投稿では、SAP導入プロジェクトの基本としてWaterfallアプローチにおける開発フェーズの作業内容と成果物について解説してきました。
今後も、SAP導入プロジェクトの基本について少しずつ解説をしていきたいと思いますので、ご参考になれば幸いです。