update it, Inc.社長のブログ

ちょっと前のブログのタイトル、SaaSモデルの安全性に似ているのですが、今日はリライアビリティ、日本語では「信頼性」の話です。

昨日、Amazonのオンラインストレージサービス「S3」で障害があったというニュースが流れていました。そのちょっと前の2月11日にはSalesforce.comの障害のニュースが流れていました。どちらもSaaSモデルの信頼性に疑問を投げかける内容のニュースです。

数日前の私の書いたブログ「NTTがNGNでSaaS?」で、bridgeさんから以下のようなコメントを頂きました。（こちらに転記させていただきます）

—
米国では「基幹系」「ミッションクリティカル」分野ではデータを預ける信頼性に欠けるためいまひとつ盛り上がりに欠け、セールスフォースドットコムのような基幹やミッションクリティカルじゃないアプリケーションが台頭しつつあります。
日本もそうなるのでは？
—

SaaSモデルが基幹系やミッションクリティカルな世界では使えないモデルだとしたら、非常に適用範囲の狭いモデルになってしまいます。可能であるならば基幹系やミッションクリティカルな世界もSaaSでいけるようにしたいものです。しかし現実問題として信頼度が十分でないとなると、上記のような話になってしまうことでしょう。

SaaSモデルが信頼性の面で疑問符がつきやすいのは、センター一箇所にデータが集まるモデルの場合、それがこけたり、途中の通信回線が不通になると、すべてダウンしてしまうということだと思います。Salesforce.comなどはセンターがダウンしたときに備えて大規模にお金をかけてデータセンターの二重化などを進めているようですが（いわゆるディザスタ・リカバリ、災対センター）、それでも（昨日のブログの話ではないですが）100%大丈夫ということはありえないわけです。

ただ一方で、通常自分のところでシステムを運用している場合と上記のような大手のSaaSベンダーに運用してもらう場合を比較したときに、実際どちらのほうがリライアビリティが高いのか、比較してみないとわからない、という部分もあると思います。正直なところ、自前で運用していても障害は発生しうるわけで、どちらのほうがより起こりにくく、かつ起こってもすぐに回復できるのか、という話だと思います。

先日SaaSの安全性に触れた中で、「経済産業省のほうからSaaS向けSLAガイドラインというのが公表された」という話を書きましたが、難しい側面はあるものの、SaaSをやっていく業界全体として、信頼性を数値で表し、それを保証していく、ということが求められるのでしょう。それと比較して、そのレベルでは耐えられない基幹系やミッションクリティカルなシステムは、自前でがんばって運用する、という話なのだと思います。

とはいっても、上記の信頼性の数値がどの程度信用のおけるものなのか、という話はありますけどね。（数字上はやたら安全に見える原発の話と同じことになるかもしれませんね）

最後に、長くなりましたが、crossnoteはどうか？　というのをちょっとだけ触れておきますと、crossnoteは最悪サーバーがダウンしていても、オフラインモードでドキュメントを参照したり、修正したりすることができます。Webを使わない、Eclipse RCPを使ったSaaSモデルなので、その分対障害性は高いんです。（ちょっと自慢）

最近、私の知っている小学校で、誤って個人情報が書かれた書類をそのまま捨ててしまっていて、問題になったという話しを聞きました。あまり詳しくは知りませんが、ちょっとした騒ぎだったようです。

これは個人情報保護法関連の話題ですが、この手のセキュリティ上の問題がニュースになることがここ最近増えたのではないでしょうか。昔はセキュリティに関して日本人はあまりに無防備すぎたと思いますが、今は逆にだいぶ過敏になってきているようにも思えます。そして行き過ぎると、完璧さを求められることになります。

セキュリティとは何らかのリスクに対して予防的な処置をとることです。リスクは広範囲に渡り存在します。それらを網羅的に、かつ効果的に予防することが求められます。ポイントは「効果的に」予防することであり、そうしたからといってリスクに完璧に除去することはできません。また完璧さを求めることは経済的にも意味を成さないことがほとんどです。

リスクにはいろんなリスクがあり、また予防方法にもいろいろな方法があります。絶対あってはならない生命に関わるリスクには最大限の対処を行うにせよ、そうではないリスクについては、発生しうる経済的な損失額と発生する確率を目安に、リスクの予防策に対してかけるべき額のバランスをとるべきです。そうすることで、本当にリスクが存在する部分がはっきりし、適切な対処が可能になってくるからです。

でも世の中には「絶対大丈夫なんだな？」って念押しされるケースがよくありますよね。絶対大丈夫なんてことは、普通存在しません。そこには何らかのリスクが存在しているはずです。「絶対大丈夫なんだな？」って聞いている側は、それでリスクを転嫁しているわけで、そういう聞き方をしている時点で非常に無責任なことをしているわけですが、単純に「絶対大丈夫です」なんて答える人がいたら、その人もかなり無責任だと思います。

では、「絶対大丈夫なんだな？」って念押しされたらどうするか？　おそらくリスク・マトリクスを用意して、各リスクに対してどのように対処するかを検討した結果を提示する、というのが教科書的な答えだと思います。

でも実際問題として、それでは納得してもらえない場合もあるでしょう。結局のところ、誰かにリスクを押しつけることができるまで、この問題は解決しないのです。言い換えると、リスクテイクができる人（金を握っている人とか、決定権のある人）だけが、「大丈夫です」と答えることができるのだと思います。

え、それでは自分にとっては何の解決にもならない？　あきらめましょう。 🙁

（2014/12 加筆）

通常、プロジェクトにはいろんな会社の人が集まります。協力会社やユーザ企業、コンサルタント、いろいろなバックグラウンドを持った人達の集まりです。そういった人達が一緒になって1つの仕事をしているわけですが、なぜか昼飯時になると「同じ会社」同士で飯を食べに行く、なんて傾向が強くありませんか？

もちろんそうではない人もいます。でも経験的に、一緒に飯を食べる相手に同じ会社の人を選ぶ傾向が強いと思いませんか？

飯を食べに行くだけの話ではなく、何かある毎に会社単位でまとまってしまう、というのは実はプロジェクトに対する所属という感覚があまり無いためではないでしょうか？　つまり所属とは会社に所属するものであって、プロジェクトに所属するものではない、という意識が自然に出来上がっている場合が多いように思えます。

しかしなんでプロジェクトではなく、会社なのでしょうか？　確かに社外秘の情報があるような場合には、同じ会社の人だけで、というのはわかりますが、普通に話しているときには同じ会社かそうでないかはあまり関係ありませんね。会社に所属しているという結びつきよりも、一緒に仕事をしている、という関係のほうがよっぽど強い関係のはずです。

会社というよりはプロジェクトに所属している、という感覚が出てくることがプロジェクトを成功させる上では重要ではないかと私は考えます。

時間が取れないので、今日はブログを休みます。

何事にも先人の知恵をうまく生かすことは重要です。ただ、先人の知恵を本当に理解するのがたやすくない場合も多々あります。そんな場合には、先人のたどった軌跡と同じ軌跡をあえて辿ってみることも有効なのだと思います。そうすることで、深い理解が得られ、さらにその上の世界が開けてくるからです。単にうわべだけの理解では得られない世界です。

アジャイルの世界で一時「守破離」という言葉が有名になっていました。

「守」とは師匠の教えを正確に、忠実に守る、学びの段階。

「破」とは、それをさらに洗練させ、自分なりのものを創造する段階。

「離」とは、独自の道を確立する段階。

フレームワークやライブラリーを扱う場合、通常は先人（作った人達）の教えに従い、それを使います。これは「守」の段階です。それを使いこなしていくうちに、徐々にその足りない部分を自分で改良して使うようになってきます。これは「破」の段階ですね。そしてそういった経験を経て、見えてきた問題点などを解決するための全く新しい仕組みを新たに創造する、それが「離」の段階なのだと思います。

早く「離」の境地にたどり着きたいものですが、でも「守」や「破」を経て、本当の問題点を良く理解しないことには「離」はできないのだと思います。そういった意味ではあえて先人の軌跡を辿ってみるのも、遠回りのようでいて、実はその道を極めるための最短コースなのかもしれません。

最近個人持ちのノートPCのセキュリティソフトを、広告の入る無料タイプのものに切り替えました。PCを起動すると、そのたびに広告が表示されるのですが、それ以外は普通のセキュリティソフトとして使用できるものです。セキュリティソフトとしての出来はそんなに悪くなく、使用感も上々です。

それまでは年額5,000円程度の金額を払ってセキュリティソフトを買っていたのですが、広告を見るという条件だけでそのコストを払わずに済む、というのはうれしい気がします。使い始めた頃に比べ、表示される広告の内容が増えているようにも思えます。ビジネスとしてはそれなりに順調に伸びているのかもしれません。

ただ、ふと、このビジネスモデルは本当に継続可能なのか？という疑問が沸いてきました。というのは、広告業は広告主がいて成り立つ商売です。もしいくつもの会社がおなじビジネスモデルで参入したとしたら、広告代金を払う側の広告主は増えないので、必然的に1社辺りの取り分は減ることになります。でももしこれが優れたビジネスモデルならば、皆が参入してくることでしょう。

これって、Consumer向けのIT産業のビジネスモデルのジレンマなのかもしれません。

最近の流れで、Consumer向けのITビジネスはいずれも広告モデルが主体となってきており、Consumerから直接お金を徴収するビジネスというのはあまり流行らなくなってきています。Consumerは当然安いほうがいいに決まっているので、自然にそちらに流れるのは理解できますが、全てがその方向の流れてしまうと、そもそもビジネスが成り立たなくなる場合が増えてしまうのではないでしょうか？

次の「新しい」ビジネス・モデルに期待、ということでしょうか？

今朝の日経新聞の1面に「ITシステム　ネットで提供　NTT、次世代網で」「安全性高く　企業向け年内参入」という記事がでかでかとでています。

「ITシステム　ネットで提供」とあるのは言わずもがなSaaSのことです。NTTではSaaSを事業として開始し、サーバーを置くデータセンターや認証・決済機能を整備するとのこと。国内外のソフト会社に呼びかけて…云々と書いてあります。NTTが乗り出すということであれば、SaaSの時代に一気に突入しそうですね。

ただちょっと解せなかったのが、なぜNGN（次世代網）でなければならないのか？という点です。まあ戦略上はわかりますが、NGNの場合、どこでも使えるというユキビタス性が確保できるのはいつになるのでしょうか？　また海外とのやり取りには使いにくい？　結局はインターネット経由になる？　疑問は尽きません。

昨日、車輪の再発明というブログを書きましたが、果たしてNGNは車輪なのでしょうか？　キャタピラなのでしょうか？
いずれにせよ非常に気になるニュースでした。

システムの世界では、既に存在するものを利用せずに、別途作ってしまうことを「車輪の再発明」と呼ぶことがあります。そんなの無駄だよね、という意味を込めて使います。過去の偉大なる発明をうまくりようすべきではないか、と。

確かに既にある機能を使ったほうがよいことが多いのは確かです。ですので、この言葉は良く肝に銘じておくべき言葉だと思います。しかし現実問題として、車輪の代わりにキャタピラが必要になるようなケースが多々あることが事態をややこしくします。

車輪を発明した時点ではそれでどこまでも行ける、と人々は思い込んでいるのですが、実際には舗装路しか走れないことにいずれ気づきます。ま、4WDにすれば悪路もへっちゃら、という話もありますが、さらに重いものを運ばなければならないとなると、いよいよ車輪では限界がきますよね。こうなると、ものを移動させるための方法としては車輪から離れなければならず、キャタピラが必要になってきます。

これは「車輪の再発明」ではなく、車輪では役に立たない場合に対する発明なので、意味があるのです。しかしこの見極めが非常に難しい。車輪を使いこなしている人であれば、「うーん、この目的であれば車輪でいけるけど、これ以上の場合には無理だな」ぐらいのことがすぐにわかりますが、普段車輪にあまり接していない人が同じような場面に遭遇した場合、簡単には判断が付きません。

おそらく「車輪の再発明」されるのは、こういう場合なのではないでしょうか？　結局のところ、「車輪の再発明」なのか、「キャタピラを創造したのか」はある程度後になって振り返ってみてから判明することがほとんどなのだと思います。

SaaS型のアプリケーションの運用において、データを運用者側に預けることがセキュリティ・ポリシー上問題になる、というお客様は結構います。アウトソーシングモデルでも同じような問題があるとはいえますが、アプリケーション毎に契約先が異なるSaaSの場合、一括して運用を任せるアウトソーシングに比べ、問題にされやすい傾向があります。

これはデータを預けるという行為が、相手を信頼しなければ成り立たない部分があるからだと思います。アウトソーシングの際には１対１の関係で、相手のことを十分に理解したうえで依頼するわけですが、SaaSの場合のように、このアプリケーションはここ、このアプリケーションはこちら、のようにアプリケーション毎に依頼先が異なると、個別にまかせられるのかどうかのチェックが必要になると大変なわけです。

先日、経済産業省のほうからSaaS向けSLAガイドラインというのが公表されました。その中ではインターネット経由で利用する場合に、障害が発生した場合の使えなくなる期間の長さや、データ保管に関するサービス内容、範囲、品質などを保証するためのガイドラインが含まれています。

内容を見ると、自社所有のスタイルに比べSaaSのモデルがいろいろな面で優れていることがわかるのですが、安全性の面からいろいろと検討事項があることもわかります。預けるデータの質やコストとの見合いもあると思いますが、できる限り安全なものを提供していくことがサービスを提供する側の努めだと思います。

当社としても、SaaS型でのサービスを提供するものとして、できるだけ早くSLAをお客様にご提示できるよう準備を進めて行きたいと思います。

@ITに取り上げていただきました。

アップデイティットがEclipse RCPで開発
開発者向けコラボワープロをOSSコミュニティに無償提供

ぜひご覧ください。

— 追加です(20:14) —
Open Tech Pressにも載せていただきました。
アップデイティット、ドキュメント共有管理システムをOSSコミュニティに無償提供