【EC開発体験記-SaaS2-】 リスクをどう考えるか

　今回は、前記事で説明できなかった、SaaS利用における安全性・信頼性の話をしたい。SaaSは、以下のように、提供者、利用者の両方に大きなメリットがある、すばらしいモデルである。（太字が重要なキーワード）
　サーバやソフトウェアへの初期投資は必要なく、トランザクションが増大してもシステムリソースの心配はない。また、必要なサービスだけに絞って開発することで初期投資を抑えることができる。

　１）個々のユーザが本当に必要な機能のみオンデマンドにカストマイズして利用できる
　２）クラウドコンピューティングを利用することで、スケーラビリティのあるコンピューティングリソースを使うことができる
　３）利用した分だけを支払う従量課金により投資リスクを軽減できる

　こんな魅力的な概念ではある一方で、カストマイズがどれだけ可能かという話や安全性・信頼性の問題があるのは周知の事実である。カストマイズの話は前記事でも触れたのでここでは省略する。
　安全性・信頼性の問題は、主にはサービスレベルの保証と情報漏えいリスクの問題だ。
　サービスレベルの保証については、実際にAmazon S3の障害事例が起きたときのことを考えてみるとよい。Amazon S3、何も日曜に落ちなくてもいいのに！
　とにかく、サーバがダウンしたときに自分たちで復旧できないことが一番痛い。アマゾンEC2などのクラウドコンピューティング利用を考えるのであれば、サーバのサービスレベルはアマゾンに依存することになるが、それはつまり、アマゾンが止まればサービス提供者でさえ何もできず「ただ復旧を祈るだけ」となることを意味する。
　私たちのプロジェクトにおけるサーバ利用はどうだったかというと、１．自社サーバルーム内、２．都内S社ハウジング、３．都内P社（セミ）ハウジング、４．都内P社ホスティング、５．関西S社ホスティングの5箇所で、家具や家電、DVDサイトをそれぞれの場所で運用したのだが、やはり運用上一番安心なのは自社サーバルーム内であった。（運用上安心というのは、サーバがダウンした際にすぐにリカバリーできるかということであり、セキュリティが確保されているという意味ではない。）安心な順でいえば、１＞２＞３＞４＞５といった感じだ。
　システムはトラブルがつきものであり、すばやくリカバリーできるかどうかは運用上とても重要なことである。実はこんな苦い経験もあった。
　ドロップシッピングサイトは５．関西S社ホスティングで運用していたのだが、トラブルでシステムダウンしたことがあった。再起動しても復旧しないし、最悪なことにログインすらできなくなった。その日受けた千件の受注を処理できないどころか、データを取り出すことさえできないのである。ホスティング会社に連絡してなんとか対応してくれるように頼んだものの「不可能です」の回答。私はとても後悔した。そもそも、月額数千円のホスティングサーバをクリティカルな業務に使用してはいけない。しかも千件/日という多くの受注を処理するなんて無謀である。その後、単なるパスワード間違いでログインできなかったことがわかり復旧できたのだが、本当に顔面蒼白事件であった。同様のことが４．都内P社ホスティングで起きたのだが、このときはサーバ管理しているビルまで上がりこんで責任者に懇願して事なきをえた。こんな事件が頻発したこともあり、ホスティングはだめだなと思い新規に契約したのが２．都内S社ハウジングであった。ここは自由に入管可能であり、都内なので直ぐいくことができる。しかし、サーバやルータは自前で用意しなければならず、家賃も高いのが問題だ。今のところ、コスト面、運用面で優れていると思っているのが、３．都内P社（セミ）ハウジングである。サーバはP社製のものを購入する必要はあるものの、サーバ費用も家賃も安い。入管も可能なので安心である。一方、クラウドコンピューティングはどうかというと、安心度は５．以下というところが実情だろう。最低でも冗長構成の仕組みを導入してトラブルがあっても止まらないようにするか、あるいは、別のサーバを使ってすぐに復旧できる仕組み作りは必須だと思う。

　次にデータの安全性確保について。

　Gmailを会社の標準にしたいが情報漏えいした場合に保証がないのでできないという話もよく聞く。ある大手の会社では、社内基幹サーバを大手ベンダーのアウトソースしており、情報漏えいがあった際には、アウトソーサーが賠償責任を負うことになっている。こういった契約をGoogleと結ぶことはまず無理である。なので、大手の会社は自分たちのリスクとして負わないかぎり、Gmailを利用することはできない。実際のところアウトソーサーよりGmailの方が安全なのかもしれないが自社へのリスク回避ということで考えると賠償責任を求めることができないと採用されないだろう。でもまあ、これは現在がこのような状況であるというだけで、将来的は賠償責任がなくても、もっと利用されていくだろうと楽観的に考えている。それは確信はまだ持てないが、SaaSを利用した企業の競争力は無視できないほど高まると思うからである。
　一方のSaaSの提供者は、賠償責任までとはいわないまでも、以下のような認定をとるなど、安全対策についてはかなり努力しないといけないだろう。

ASP・SaaS安全・信頼性に係る情報開示認定制度

　最後に、実際に事故が起きたときのために賠償保険に入るのはよいことだと思うのでちょっと紹介したい。

法人/企業向け賠償責任保険

　当社のような小さな会社は特にいえることだが、大手の責任転嫁を簡単に受け入れてはいけない。個人情報保護は多くのところが無限責任を要求してくるが、契約したいからといって簡単にサインしてしまってはだめだ。事故は絶対に起こらないとは限らないので、お客様にきちんと説明して賠償責任保険に入るようにしよう。小さな会社に無限責任を押し付けたって実際に責任を取れるわけではないので、保険に入ることが結果的にお客様への利益にもなるのだ。「いやいや、うちの会社は無限責任を要求することはまずないから、入る必要はないよ」とお客様がおっしゃるのであれば、契約書の無限責任の条項を削ってもらうようにしよう。