DX時代に求められる新しい「サービス品質」の考え方と品質確保のプロセス

本連載では、企業がDX（デジタルトランスフォーメーション）へ取り組むにあたり、課題解決の助けとなる新しいテクノロジーやプロセスについて解説しています。近年では、過去の記事で紹介してきたような最新のテクノロジーや手法を用いたシステムの開発、運用に取り組もうとする企業が増えてきています。しかし、そうした企業の多くで課題となるのが、システムがユーザーに提供するサービスの「品質」をどのように評価し、確保するかという点です。

自社でインフラ、ハードウェア、ソフトウェアを所有してシステムを作り上げる従来型のシステム構築では、最初にユーザーが求める性能、可用性、堅牢性、セキュリティなどの要件を定め、それを満たす「品質」を備える構成を自分たちで設計、実装することができました。

しかし近年では、クラウド上で提供されているIaaS、PaaS、SaaSなどを必要に応じて組み合わせながら、業務に必要な機能をスピーディーに実現するという方法論が主流になってきています。

この場合、従来と同じやり方で「品質」を評価したり、確保したりすることは難しくなります。新たなシステム構築のスタイルに合った「品質」に対する考え方と、それを確保するためのプロセスが必要です。

今回は、特にシステムがユーザーに提供する「サービス品質」に注目し、DX時代のシステム構築における「品質」の捉え方と、品質確保のプロセスがどうあるべきかについて考えてみましょう。

主流は「自社で作り込む開発」から「サービスを活用する開発」に

まず、従来型のシステム開発と近年増えてきているシステム開発の進め方について簡単に整理しておきましょう。従来型のシステム開発は、業種共通の機能に加え、個別企業の商習慣に準じたプロセスを機能として独自に作り込んでいくもので、特に基幹システムの領域では、一昔前まで主流でした。

近年、急速な市場変化に追従できるよう、業務プロセスの改善や意思決定を高速化したいというニーズが高まっています。そこで、現在SoR（System of Records）とも呼ばれている基幹システムと、SoE（System of Engagement）やSoI（System of Insight）と呼ばれるような周辺システムとの柔軟な連携が求められるようになりました。

周辺システムの構築時には、構築や改善のスピードが重要になります。そこで、これまでのように機能のすべてを自分たちで作りこむのではなく、既存のSaaSのようなクラウドサービスが提供している機能を組み合わせて活用するケースが増えています。

ここでは、自社業務に合わせてシステムを作り込む従来のやり方を「個別開発型」、自社の強みとなる業務ロジックは作り込む一方で、標準的な機能については既存のクラウドサービスを組み合わせて構築する方法を「サービス活用型」と呼ぶことにします。

「品質のコントローラビリティ」に対する考え方を変える

「個別開発型」では、システムを導入する企業が独自に「品質基準」を設定することができます。しかし「サービス活用型」では、利用するクラウドサービスが提供している標準の品質基準に依存する部分が出てきます。そのサービスがいわゆる“パブリッククラウド”であれば、複数の利用者が共有するという特性上「サービス品質についての個別対応はない」というのが原則です。

「個別開発型」では、動作環境や利用環境などをあらかじめ決めておき、事前に検証することで品質を確保してきました。同時に、自社で開発をしないOSやミドルウェアについては、設計時から詳細な仕様や、サポートの内容、期間を確認して、開発完了時の「品質」が一定の期間、外的要因によって劣化しないような施策を実施してきました。

「品質に対するコントローラビリティが高い」というのは、「個別開発型」のメリットのひとつです。しかし一方で、設計時に予測できなかった要因、例えばユーザー数や利用頻度の急激な増加、データ量の増加などでサービス品質が低下した場合には、設計の変更やハードウェアの追加などが必要になるケースが多く、対応が困難だったり、多大な手間やコストが掛かったりするというデメリットもあります。

そもそも市場や技術の変化が激しい現在、5年以上先の状況を予測してシステムを設計すること自体が不可能だという見方もあります。その点で“必要なときに、必要な量のリソースを調達し、使った分だけコストを支払う”というクラウドの特性が生かせる「サービス活用型」の開発を取り入れていくことにはメリットがあります。ただし、その際には「サービス活用型」ならではの「品質」の考え方を受け入れる必要があります。

すでに「サービス活用型」のシステム構築を推進している企業においても、サービス品質については「個別開発型」時代の評価軸を変えることができず、それが足かせとなっている状況が少なからず見受けられます。

• 

  図1：「個別開発型」と「サービス活用型」の品質保証・管理の違い　出典：Ridgelinez

クラウドサービスの品質評価に「SLA」を活用する

では、「サービス活用型」でシステムを作るにあたり、その品質はどのように確保できるのでしょうか。その代表的な指標になるのが「SLA：Service Level Agreement」です。

SLAは、クラウド事業者が利用者に対し、サービスの範囲、内容、前提事項やサービスレベルの水準を明確化するものです。SLAには一般的に、可用性や性能の定量的な指標、バックアップなどのデータ保護体制、障害時の対応を含むサポートのプロセス、公的なセキュリティ認証の取得状況などが示されています。また、提示しているサービスレベルを達成できなかった場合の対応方法（補償内容）も併せて規定されています。

「サービス活用型」のシステム構築においては、ユーザーの求めるサービス品質を実現するため、このSLAを軸に利用するサービスの選定やアーキテクチャを検討していくことになります。

標準的なSLAよりも高いサービスレベルを求める利用者に対しては、多くのクラウド事業者が主にオプションの形で、その対応策を用意しています。例えば、より高い可用性が必要な場合に、クラウド上に用意された専用領域（「可用性ゾーン」などと呼ばれます）を割り当てて高可用構成を可能にするといった対応を行っています。

こうしたオプションを利用する場合には相応の追加コストが必要ですが、検討にあたっては「そのサービスが提供している品質と同等レベルの品質を、自社で確保する場合のコスト」と比較検討を行いましょう。ほとんどの場合において、クラウドを利用した方がトータルでのコストや負荷は低減できるはずです。

また、SLAは利用者の導入決定にあたり重要な判断材料であるため、多くの事業者でサービスレベルの向上に取り組んでいます。SLAの内容や数値も継続的に見直されていますので、最新の情報を収集しましょう。