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