クラウド型のERPシステムを導入するときに悩むことの1つが、「非機能要件として、具体的に何を決めれば良いか」という点です。システムの安定稼働や、障害復旧などに関わる重要な要件なので、詳しく見ていきましょう。今回は、ERPのクラウド化に求められる非機能要件について解説します。
ERPの開発要件とは
まずは、2つの開発要件について解説します。
機能要件
1つ目は、「機能要件」です。機能要件とは、業務を遂行する上で必要となる機能のことです。
通常、システムを開発する場合、要件定義で必要な機能を洗い出します。システムを利用する顧客と、システムを開発するベンダーで打ち合わせを行い、システムを利用する業務や、具体的に必要な機能などを決めていきます。
クラウド型のERPシステムの場合は、ゼロからシステムを開発するケースは多くありません。基本的にはERPシステムの標準機能で自社の業務プロセスが実現できるかどうかを確認し、足りない機能を追加開発する流れとなります。
そのため、アドオンプログラムとして追加機能を開発するために、機能要件が必要となります。
非機能要件
2つ目は、「非機能要件」です。非機能要件とは、業務を遂行する上で直接的な機能ではなく、安定的にシステムを稼働・運用するために必要な機能のことです。
非機能要件では、システムの応答時間、品質、セキュリティ、サポートレベルなどの要求を決めます。たとえばサポートレベルを考えてみましょう。
クラウド型のERPシステムを利用する場合、障害が発生したときはERPシステムの担当者に問い合わせるのが最初のステップです。しかし、サポート対応時間が定時までと決まっていると、夜間に発生した障害に対応できなくなってしまいます。
このようなサポートの対応時間なども、ERPシステムを安定して使うための要求の1つです。ほかにも、ERPシステムで重視すべき非機能要件はいろいろあります。
続いて、ERPの非機能要件のカテゴリーを見ていきましょう。
ERPの非機能要件カテゴリー
クラウド型のERPシステムが一般的に利用されるようになり、オンプレミス型の非機能要件だけでは対応しきれないケースも増えています。
IPA（独立行政法人 情報処理推進機構）では、クラウドにも対応できる非機能要件「非機能要求グレード」を、2018年に公表しています。非機能要求グレードでは6つの項目について書かれているため、1つずつ詳しく見ていきましょう。
可用性
可用性とは、システムが安定的に稼働し続けるために必要な要求のことです。
システムはセキュリティ対策によるアップデートが必要になったり、障害が発生したりして、一時的に止まることもあります。そのため、どの程度稼働を維持できるかを示す目安が必要となります。
具体的には、次のような項目があります。
- 稼働率
→1年間で数日程度の停止まで許容できる（稼働率99%） - 目標復旧水準
→週次のバックアップからの復旧が目標水準
これらを定義しつつ、システムが安定稼働するための要件を決めなければなりません。
性能・拡張性
性能は、たとえばシステムの応答速度などがあげられます。いくら機能が豊富でも、クリックしてから次の画面に移動するまでに時間がかかってしまうと、業務に支障をきたしてしまいます。
数秒程度であれば問題ないかもしれませんが、20秒、30秒と1つの操作で時間がかかってしまうのは問題です。遅くて実用に耐えないシステムを導入しないためにも、定義が必要です。
- 通常利用する場合
- 月末や月初などに負荷が高まる場合
に分けて、許容できるシステム応答時間を決めておくのがベストです。システム応答時間は3秒～5秒程度が一般的で、10秒を超えると操作に支障が出るレベルとなります。
拡張性は、システム拡張に関する要求のことです。システムは、一度構築すると長い間利用することが多く、データ量が増加してリソース不足に陥ってしまう可能性があります。
そのため、既存のリソースをスケールアップ・スケールアウトできることも重要です。特にクラウド型のERPシステムの場合は、リソースの追加にかかる費用なども確認しておくことが重要となります。
運用・保守性
運用・保守性とは、システムの運用と保守に関わる要求のことです。「バックアップがなく、障害が発生したときに対応できない」といった問題を防ぐためにも、定義しておくことが重要です。
たとえば、次のような項目があります。
- 運用時間
例：常時サービス提供が前提であり、24時間365日の運用を行う - バックアップ
例：システム全体のバックアップを、日次で自動取得する - メンテナンス
例：日中の運用に問題なければ、システム停止してメンテナンス作業を行っても良い - 運用監視
例：性能やリソース使用状況まで監視し、障害の予兆検出を行う
これらを定義しつつ、運用・保守にも耐え得る要件を決めなければなりません。
移行性
移行性とは、システムの移行に関する要求のことです。ERPシステムを導入するときは、既存のデータの移行が必要となるケースが多くあります。
具体的に言うと、次のような項目があります。
- 移行方式の規定
例：移行リスクを少なくするため、段階的に移行する - 移行スケジュール
例：移行のためのシステム停止は可能である - 設備・データ
例：設備やデータの移行があるが、データベース構造は変更しない
特に移行スケジュールでは、移行リハーサルがあるかどうかも確認しておくことが重要です。なぜなら、データの移行は基本的に1回ではうまくいかないことが多いからです。
1回目の移行で起こる問題を確認し、対応策を練ってから本番移行が必要となります。この点を詳しく確認しておきましょう。
セキュリティ
セキュリティとは、構築するシステムの安全性の確保に関する要求のことです。不正アクセスや情報漏えいなどを防ぐためにも、定義しておくことが重要です。
特にERPシステムの場合は基幹業務のデータを扱うため、セキュリティについて気になる方も多いでしょう。
- 不正アクセスがないか
- 常にサーバがアップデートされてセキュリティは担保されているか
- 不正が起きた場合の追跡は可能か
- ログインには安全な2段階認証があるか
など、セキュリティ対策について確認しておきましょう。
システム環境
システム環境とは、システムの設置環境による要求のことです。システム構築や運用時に、制約条件となるような法令などがある場合は、それに準拠する必要があります。
また、利用拠点数、ユーザ数などについても事前に共有しておくことで、運用後にサーバのリソース不足で悩まされる心配も減ります。ちなみにエコロジーに関する項目もありますが、これはクラウド型のERPシステムを選ぶ場合、問題にはなりません。
以上6つが、ERPの非機能要件カテゴリーに関するポイントでした。続いて、ERPの非機能要件を設定する際のポイントを見ていきましょう。
ERPの非機能要件を設定する際のポイント
次に、ERPの非機能要件を設定する際のポイントについて、それぞれ詳しく解説します。
モデルシステムの選定
非機能要件のKPIを決めるときに重要となるのが、基準となるモデルシステムの選定です。モデルシステムには、3つの種類があります。
これまでお伝えした6つのカテゴリーごとに、3つのシステムの水準があります。たとえば可用性の場合は、以下のようなイメージです。
社会的影響がほとんど無いシステム
- 稼働率：1年間で数日程度の停止まで許容できる（稼働率99%）
- 目標復旧水準：週次のバックアップからの復旧が目標水準
社会的影響が限定されるシステム
- 稼働率：1年間で1時間程度の停止まで許容できる（稼働率99.99%）
- 目標復旧水準：1営業日以内での復旧が目標水準
社会的影響が極めて大きいシステム
- 稼働率：1年間で数分程度の停止まで許容できる（稼働率99.999%）
- 目標復旧水準：数時間で障害発生時点までの復旧が目標水準
水準を正しく決めるためにも、まずはモデルシステムを決めましょう。モデルシステムを選ぶときは、「非機能要件グレード」の「利用ガイド利用編」も参考にしてください。
重要項目の自社基準の設定
モデルシステムの選定ができたら、重要項目の自社における基準を決める流れとなります。「非機能要求グレード」では、これまでお伝えした6つのカテゴリーで重要項目を決めており、約100項目あります。
- 選定したモデルシステムの水準を確認する
- 自社でシステム導入する際に、その要件が必要かどうかを確認する
といった流れで、基準値から実際に必要なレベルに変更し、それぞれ項目を整理していきましょう。
このときに、「なるべくこのくらいあった方がいい」という曖昧な理由で基準設定をするのはおすすめできません。なぜなら、非機能要件は良くすればするほど、システム導入費用が高くなるからです。
たとえば、障害発生から復旧までにかかる時間を数分程度で抑えるとした場合、単純にバックアップを取るだけでは実現は難しいでしょう。バックアップデータを使って動くバックアップサイトなどを作り、障害発生時に切り替えて対応する必要があります。
この場合、バックアップサイトを運用するためのコストも、別途かかります。無駄に高額な費用とならないよう、自社に必要なレベルに抑えた非機能要件を設定しましょう。
重要項目以外の自社基準の設定
重要項目以外にも、約200個程度の項目があります。重要項目と同様、こちらもレベルを設定していきましょう。
なお、数が多いので打ち合わせなどで一気に終わらせるのがおすすめです。このとき、打ち合わせの際にそのままレベルの確定ができるよう、承認権限のある人が同席することも重要です。
まとめ
非機能要件はシステムの安定稼働、障害復旧などに関わる重要な要件です。しかし決めるべき項目が多く、自社だけで決められるかどうか、不安に思った方もいるのではないでしょうか。
MKIでは、Microsoft Azure（以下Azure）上でSAP ERP の開発環境、検証環境、本番環境のOS/DB/SAP Basis運用を行うサービスを提供しています。Azure上での最新の運用管理サービスを使用し提供することで、SAPシステム担当者の運用負荷を大幅に軽減します。
