進化するERP、今こそ押さえたいテストの要点――導入編

皆様もご存じのとおり、ここ数年のIT分野の発展は、目を見張るものがあります。
クラウドやAIなど、ERPにも新しい技術や機能が次々と取り込まれ、製品自体は年々進化し続けています。

一方で、その進化のスピードとは裏腹に、ERP導入プロジェクトの“しんどさ”はあまり変わっていない、というのが複数の現場で導入を支援してきた立場からの実感です。

例えば、立ち上げから要件定義、基本設計といった序盤はオンスケジュールで進んでいたのに、後半に差しかかると状況が一変。
総合テストやユーザー受入テスト(UAT)に入った途端、想定外の不具合が次々と顕在化し、業務シナリオがうまく通らない、データが整合しない、といった問題が噴出し、開発品質の低さが一気に露呈する——そんなケースは、今もなお珍しくありません。

なぜ、これだけ技術が進化しているにもかかわらず、同じような問題が繰り返されるのでしょうか。
その答えはシンプルです。システム導入において押さえるべき「基本」は、昔からほとんど変わっておらず、その「基本」が十分に押さえられないままプロジェクトが進んでしまっていることが、品質問題の根本的な原因です。

本コラムでは、ERP導入プロジェクトの“関所”ともいえるテスト工程にフォーカスします。
連載形式で、各テストフェーズにありがちなNGパターンを整理しつつ、実務で押さえておくべきポイントを具体的に解説していきます。
これから導入を控えている方にも、今まさにプロジェクトの真っ只中にいる方にも、現場で役立つヒントをお届けできれば幸いです。

以下は、筆者がこれまで多く支援してきたSAP導入プロジェクトにおけるテストの概略です。テストの呼称、検証内容はプロジェクトによってある程度差異がありますので一例としてご参照ください。

テスト名 定義 やってしまいがちなNG対応 弊害
1.単体テスト
  • アドオン開発対象に対して仕様どおりの機能が実現できていることを検証する
  • 基本設計者による受入テストもこの工程に含める
  • 正常終了したことのみをもってOKと判定してしまい、結果データの内容は未確認
  • 複数の処理パターンがある場合にそれを網羅していない
  • (設計時点で)異常ケースが洗い出されていない、または検証されていない
  • 後工程で障害が多発
  • 後工程での不具合原因の切り分けが煩雑化
  • 「想定外」が多発し、スケジュールが逼迫
2.結合テスト
  • モジュール間(販売、在庫、会計など)のデータ連携を確認する
  • 業務フロー上、ERPで実施する処理は完全に網羅することが鉄則
  • クリーンコア対応で従来のERP内で開発していた機能を外出しで開発した場合、とくにERPへのデータの書き戻しがある場合はこの工程で検証する
  • 業務フローで分岐していないバリエーションもこの工程で消化するのが原則。残件は整理して総合テストにて検証する
  • テストのパターン出しが不足している
  • 業務フローをまたいだ検証を考慮していない
  • モジュール間でのすり合わせをしておらず、データパターンを十分に洗い出していない
  • 後工程でモジュール間連携、パターンの検証漏れによる停止が多発
  • 総合テストで外部パッケージ、周辺システムとの検証ができない
3.総合テスト
  • 業務シナリオベースで開始~終了までを通しで検証する
  • 周辺システムを含めた業務フローの処理を網羅する
  • 権限、承認フローを確認する
  • 結合までの品質が悪く、外部パッケージ、周辺システム連携の検証が不十分
  • 複数製品を組み合わせた導入において、開発スケジュールの足並みが揃わずテストが形骸化
  • データボリュームの軽視
  • 権限の確認を後回しにしてしまう
  • システム間での想定外パターンが本番運用の段階で多発
  • 本番運用でパフォーマンス課題が噴出
  • ユーザー受入テストが不具合対応で浪費され、ユーザー観点での検証を阻害
4.ユーザー受入テスト
  • 実務に即したシナリオとデータで、ユーザー主体で実施する
  • 現場フィット(操作性・教育観点)評価を実施する
  • Go/No-Go判断の最終材料になる
  • ユーザーがシナリオを作成しておらず、ユーザー観点が欠落
  • 業務繁忙で時間を確保できずテストが形骸化
  • 品質が悪く、ユーザー観点での検証に至らない
  • 対策のめどが立たない問題は運用で回避するとしてOK判定
  • 本番運用で障害が多発
  • 運用で回避するとしたが、手順を決められない
  • 本番運用で現場から大きな反発が起こる
テスト名 定義
やってしまいがちなNG対応
弊害
1.単体テスト
  • アドオン開発対象に対して仕様どおりの機能が実現できていることを検証する
  • 基本設計者による受入テストもこの工程に含める
  • 正常終了したことのみをもってOKと判定してしまい、結果データの内容は未確認
  • 複数の処理パターンがある場合にそれを網羅していない
  • (設計時点で)異常ケースが洗い出されていない、または検証されていない
  • 後工程で障害が多発
  • 後工程での不具合原因の切り分けが煩雑化
  • 「想定外」が多発し、スケジュールが逼迫
2.結合テスト
  • モジュール間(販売、在庫、会計など)のデータ連携を確認する
  • 業務フロー上、ERPで実施する処理は完全に網羅することが鉄則
  • クリーンコア対応で従来のERP内で開発していた機能を外出しで開発した場合、とくにERPへのデータの書き戻しがある場合はこの工程で検証する
  • 業務フローで分岐していないバリエーションもこの工程で消化するのが原則。残件は整理して総合テストにて検証する
  • テストのパターン出しが不足している
  • 業務フローをまたいだ検証を考慮していない
  • モジュール間でのすり合わせをしておらず、データパターンを十分に洗い出していない
  • 後工程でモジュール間連携、パターンの検証漏れによる停止が多発
  • 総合テストで外部パッケージ、周辺システムとの検証ができない
3.総合テスト
  • 業務シナリオベースで開始~終了までを通しで検証する
  • 周辺システムを含めた業務フローの処理を網羅する
  • 権限、承認フローを確認する
  • 結合までの品質が悪く、外部パッケージ、周辺システム連携の検証が不十分
  • 複数製品を組み合わせた導入において、開発スケジュールの足並みが揃わずテストが形骸化
  • データボリュームの軽視
  • 権限の確認を後回しにしてしまう
  • システム間での想定外パターンが本番運用の段階で多発
  • 本番運用でパフォーマンス課題が噴出
  • ユーザー受入テストが不具合対応で浪費され、ユーザー観点での検証を阻害
4.ユーザー受入テスト
  • 実務に即したシナリオとデータで、ユーザー主体で実施する
  • 現場フィット(操作性・教育観点)評価を実施する
  • Go/No-Go判断の最終材料になる
  • ユーザーがシナリオを作成しておらず、ユーザー観点が欠落
  • 業務繁忙で時間を確保できずテストが形骸化
  • 品質が悪く、ユーザー観点での検証に至らない
  • 対策のめどが立たない問題は運用で回避するとしてOK判定
  • 本番運用で障害が多発
  • 運用で回避するとしたが、手順を決められない
  • 本番運用で現場から大きな反発が起こる

上記のほかには、パフォーマンステスト、IF連携テスト、移行リハーサルといった検証の目的に特化したテストを実施します。

NG対応をしてしまうケースの多くは、スケジュールを優先してフェーズを「終わらせる」ことを優先するあまり、検証の内容を二の次になってしまうものです。
しかしながら、中身をともなわず「終わらせる」ことは何の意味もありません。結果、上表の「弊害」で記載したような負債を次工程に持ち越すことになり、最終的に稼働直前、あるいは稼働後に取り返しのつかない事態になる例が後を絶ちません。

BBSでは、SAP FIモジュールの導入をはじめ、テスト工程の改善やプロジェクト管理の強化を支援しています。また、会計システム導入でお悩みの経理部門や情報システム部門の方のご相談も承っております。
本コラムに関し、より詳細な情報をお求めの場合は、ぜひ当社にお問い合わせください。

次回は、ERPと外部パッケージを組み合わせた「次世代ERP」におけるテスト工程について解説します。
進化するERP、今こそ押さえたいテストの要点――次世代ERP編

著者:川島 靖大、黒木 仁