非機能要求とSLA
この非機能要求の見直しの際には、非機能要求グレードを活用することを推奨したい。
たとえば当初選択した要求レベルを変更する場合、選択肢として何があるのか、またレベルを変更すると影響を受ける他の非機能要求がないか、などを具体的なイメージを描きながらチェックすることが容易になる。
ここでもう一度、非機能要求グレードにある6大項目を挙げておこう。
- 可用性…システムサービスを継続的に利用可能とするための機能
- 性能・拡張性…システムの性能および将来のシステム拡張に関する要求
- 運用・保守性…システムの運用と保守のサービスに関する要求
- 移行性…現行システム資産の移行に関する要求
- セキュリティ…情報システムの安全性の確保に関する要求
- システム環境・エコロジー…システムの設置環境やエコロジーに関する要求
とくに可用性やセキュリティに関してはそれぞれの業務に求められる“適正なレベル”を見極めることが非常に重要になる。その見極めに際し、非機能要求グレードの項目を利用すれば、適正なサービスレベルを判断しやすくなる。ここで留意したいのは、冒頭でも挙げたように“適正なレベル”は社会要請の変化、企業の事業状況の変化とともに変わっていくものであるという点だ。したがって、非機能要求は定期的に見直すことを前提にしないと、サービスが時間とともに過剰/過小になる可能性が非常に高くなる。情報システムの重要度にもよるが、少なくとも年に一度の非機能要求の見直しは、保守/運用の面でも欠かせないだろう。
非機能要求で提示した項目やそのレベルについて定期的に見直す場合、サービスレベルに対する合意(SLA:Service Level Agreement)やそのマネジメント(SLM:Service Level Management)が活用できる。必要なサービスレベルを明示することで費用対効果を明確にし、さらに定期的に見直すことで社会要請の変化に対応したシステムを維持していくことがきるのではないだろうか。
クラウドサービスのSLA
前述したとおり、震災以降、コスト削減や導入期間の短縮といった視点からメリットが語られがちだったクラウドサービスが、可用性やセキュリティ、運用性の面からも評価される機会が確実に増えてきている。ユーザー企業がクラウドサービスへ移行/導入を検討する際、クラウド事業者にダウンタイムや稼働率などを明記した「SLA」の提示を求める場合が多い。これはシステムの運用をアウトソーシングする際、サービス事業者にSLAの提示を求めるのと同様の商習慣である。
基本的にクラウドサービスのSLAは“選択する”という考え方の下にある。クラウドサービスのインフラ部分(ハードウェア、OS、ミドルウェア、実行基盤)は各クラウド事業者が決定し、ユーザー企業は事業者が提供するいくつかのサービスメニューから提供されるクラウドサービスのサービスレベルを選択することはできるが、自分でインフラを構築することはできない。
これは非機能要求の多くがインフラに対する要求であることを考えると非常に興味深い。実際、クラウドサービスのSLAと非機能要求のSLAを検討/見直しする過程においては、多くの共通点が存在することがわかる。サービスレベルは「作る」から「選ぶ」ものへと変化してきているのだとすれば、非機能要求グレードを活用してサービスレベルを選択していくことは、時代の流れに適したアプローチだといえる。