【解説】
失敗しないSaaS運用の極意――カギを握るのは「SLA」

新時代アプリケーションの運用管理を学ぶ

（2008年07月17日）

　しかし、それでも、Google Appsに深刻な障害が発生した場合は、Abraham Harrisonの業務に影響を与える可能性がある。

　そもそも同社がGoogle Appsの導入を決めたのは、同スイートで提供されているアプリケーションを利用し、世界各国の拠点で働く社員とのコミュニケーション／コラボレーションを実現するためだった。同社は世界4大陸、6カ国に社員22名を擁し、14の異なるタイムゾーン（時差）で稼働している。そして彼らの仕事は、コラボレーション作業が大半を占める。

　「MicrosoftのOfficeドキュメントを電子メールに添付してやり取りするよりも、中央のサーバに保管されたGoogle Appsを利用し、共同でドキュメントを編集するほうが、われわれの業務形態には適していると判断した」（Harrison氏）

　実は、Abraham HarrisonはGoogle Appsのモデル・ユーザー（小規模企業部門）で、Google Appsの開発チームに定期的にフィードバックを行っている。ただし、Google Appsのメリットを言いはやすことでGoogleから何らかの報奨金を受け取っているわけではない。強いてメリットを挙げるとすれば、Harrison氏がGoogle Appsチームと頻繁に連絡を取り合う仲にあることぐらいだ。

万が一に備えデータの保証も明確にする

　では、ビジネス・マネジャーは、どんな条件をSLAに盛り込むべきなのだろうか。最も基本的な項目は、アプリケーション稼働のアップタイム保証だろう。理想的には99.9％、あるいはそれ以上の保証値が望ましい。また、メンテナンス目的のダウンタイムも、契約前に明確にしておきたい。あまりに頻繁に行われると、偶発的な障害よりも業務に支障を来す要因となる。

　契約する前には、SaaSプロバイダーが独自にデータセンターを所有しているかどうかも確認しよう。もし、データセンターをアウトソーシングしているのであれば、そのベンダー名とデータセンターのロケーション、そしてデータセンターのインフラ状況も調査したい。また、SaaSプロバイダーが公認会計士協会（AICPA）の監査標準である「SAS 70 Type II」などの監査を受けているかどうかも確認しておく必要がある。

　SLAには、ユーザー企業とSaaSプロバイダーの双方が合意したパフォーマンス・レベルも、具体的に明記すべきである。動作が遅すぎるアプリケーションでは企業の業務に悪影響を及ぼす。さらにアプリケーションで生成したデータの保証に関する条項も盛り込む必要がある。SaaSプロバイダー側の過失でデータが破壊されたり、盗難されたりした場合についての責任も明確にする必要がある。

　前出のKaplan氏はユーザー企業に対し、「SaaSプロバイダーの倒産」という最悪のケースを想定してSLAを取り交わすことを勧めている。「SaaSプロバイダーが倒産した場合を想定し、ユーザー企業はアプリケーションのソースコードとデータを『エスクロー・プロバイダー』（第三者の企業機関など）の元に保管するよう要求すべきだ」（Kaplan氏）

　表1に、SLAを締結する際に最低限確認したい項目を挙げた。

表1：SLAを作成する際にユーザー企業が（最低限）確認したい項目

　もっとも、満足できるSLAを取り付けるには、ビジネス・マネジャーが積極的に行動しなければならない。当然のことだが、SaaSプロバイダーから、“気前のよい”サービス保証が提示されることはない。「SLAを結びたいと顧客から申し出れば、それを拒むSaaSプロバイダーはいない。しかし、SLAがカバーする内容は、あくまでプロバイダーの管理が及ぶ範囲に限られる」と、Burton GroupのMaiwald氏はクギを刺す。

　実際、SaaSプロバイダーのコントロールが及ばない外部要因が、アプリケーションのパフォーマンスに影響を及ぼすことはある。例えば、ユーザー企業側のPCで利用しているセキュリティ・ソフトウェアの動作や、ローカル・ネットワークの状況によって、アプリケーションのパフォーマンスが低下する場合がある。

　とはいえSLAが重要であることは、ユーザー企業とSaaSプロバイダーとの間で（少しずつではあるが）浸透しつつあるという。専門家らは、「SLAが認知されることで、SaaSの導入を考えている企業のIT管理者やビジネス・マネジャーが抱く不安は取り除かれる方向に向かうだろう」と見ている。

前のページへ < ｜1｜2｜3｜4｜5｜ > 次のページへ