皆さん、こんにちは。本投稿では、最近日本企業の中で盛り上がりを見せている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初心者向けの投稿記事のまとめをこちらでご紹介しておきます。もしご興味がある投稿がありましたら、ぜひ見て頂ければと思います。
テスト/Testフェーズの作業内容、成果物
SAP導入プロジェクトの開発/Buildフェーズが終わったら、テスト/Testフェーズが始まります。
このフェーズでは、開発/Buildフェーズで作成したテストケースを実際に実行に移していきます。
このテストフェーズでテストケースの全てを問題なく実行できる状態に至ると、カスタマイズ、開発した機能がきちんと業務全体を実行できるものとして動くということが確認できるというわけです。
実施する作業と、このフェーズで作成する成果物は以下の通りとなります。
実施する作業
- テストスケジュールの作成
- テストケースの実行、バグ修正対応、テストケース再実行
成果物
- 結合テスト、統合テスト実行結果
- バグ修正対応一覧
それでは、一つ一つご紹介していきましょう。
テストスケジュールの作成
開発/Buildフェーズの最後に、テストフェーズで実行するテストケースの一覧とそれらのテストケース一つ一つに対応するテストステップを作成しました。
まず、テストフェーズの最初にそれらのテストケースを実行するスケジュールを決めていきます。
基本はシンプルなテストケースから順番に実施していく
テストフェーズに入っている状況で、既にすべての開発、カスタマイズが完了しているのであればどのテストケースから実行しても問題ないのですが、End to Endの業務プロセスを通して実行するというときはやはり難易度、複雑度合いの高いテストケースから実行していくようにスケジュールを組むのが一般的です。
仮にいきなりもっとも複雑で多種多様なWRICEFが関係するテストケースを実行していった場合、バグが見つかる可能性も高く、バグの原因がまだテストされていない他のプログラムのバグであったり、原因を特定することが難しい状況に陥ることがあります。
そのため、比較的シンプルで関係してくるWRICEFの数も少ないテストケースを実行していくのが良いでしょう。
また、テストステップの数を集計しておき、どのテストケースのステップ数が少ないのか、という点を整理しておくこともシンプルなテストケースを把握するうえでは重要になります。
または、一つのテストケースを実行するにあたって、複数のプロセス/Processチームが関与しなくてはいけないものは複雑さが高いので、後回しにするという考えもあります。
開発、カスタマイズが完了していないときは出来るものから取り掛かるスケジュールを作る
もし、開発フェーズの間に本来であればすべて終えている状況であるはずのカスタマイズ、WRICEF開発が完了していないというケースであれば、現実的な話としてテストを始めることが出来るテストケースから始めるようにスケジュールを組むことになります。
カスタマイズ、WRICEF開発がすべて終わっていないのにテストフェーズに移っていいのか、という質問があるかもしれませんが、実際問題、こういう対応は良くとられます。
例えば100件あるWRICEFのうち、99本は完了していて残るは特定のシステムとの間でデータ連携をするInterface プログラムだけが開発中の状況だとします。この状況で、プロジェクト計画書上ではテストフェーズに移っているべき時期になってしまいました。
このInterfaceプログラムが開発され、単体テストが完了するまで他のチームのみんなは作業を止めるべきなのでしょうか。答えは、Noという方が大半でしょう。
この例では開発未完了のWRICEFはInterfaceプログラムなので、このInterfaceプログラムを使用しないテストケースはどんどん着手してしまうということでテストフェーズは始めてしまって問題ないはずです。
したがって、このような状況下にある場合は、開発が完了しているものから順番にテストケースを実行するスケジュールを作るということになります。
テストケースの実行、バグ修正対応、テストケース再実行
さて、それではテストケースの実行スケジュールが作成されました。あとは、実行していくのみです。
テストケースは、事前にテストステップに分解されていましたので、これに従って実施していくというものが主な作業になります。
単体テストを実行していたときと同じように、テストステップを実行していき、期待結果の隣に実行結果を記録していきます。テストステップ実行の結果、伝票などのオブジェクトをSAPに作成することになった場合は証拠としてその伝票番号を記録します。
また、テストステップ実行時に期待結果と異なる結果が発生した場合はバグなのかどうかを確認し、バグだと判定された場合にはバグ一覧と呼ばれるドキュメントに記録を行います。
このとき、バグには固有のID番号（バグ番号）を付けるとよいでしょう。
バグ一覧は内容を整理し、単純なプログラムのバグなのか、それとも設計図書作成時の考慮もれなのか、といった点を整理します。これを整理することで、プロジェクト内の誰が対応をするべきなのか、誰が対応をすることになっているのか、という点を明らかに出来ます。
テストフェーズは、プロジェクト内の全てのプロセスチームがテストステップ実行をしており、開発チームはバグ修正対応を進めています。そのため、バグ修正対応を今誰が何をすることになっているのか、という情報を管理しないでいるとだれも自分が作業をすることになっていると理解できていない、いわゆるボールが落ちている状況になる危険性があるのです。
そのため、今誰が担当してくれていて、そして次のステータスに進められるのはいつになるのか、という見込みも情報として管理しておくようにしましょう。
バグが修正されるとバグの発生していたテストケースは再実行することになるのですが、バグ一覧上で次のステータスに進められる日付を記録しておくことで、いつからテストケースの再実行が出来そうなのか、という点を見積もることが出来ます。 なお、テストフェーズになってようやくバグ一覧をご紹介しておりますが、このようにバグを一覧管理する必要性があるのは開発フェーズの単体テストのときも同様なので、プロジェクトによっては開発フェーズのうちからバグ一覧をきちんと整理しておくケースもあります。
終わりに
本投稿では、SAP導入プロジェクトの基本としてWaterfallアプローチにおけるテストフェーズの作業内容と成果物について解説してきました。
今後も、SAP導入プロジェクトの基本について少しずつ解説をしていきたいと思いますので、ご参考になれば幸いです。