SaaSに関して考える

あけましておめでとうございます

私はといえば、技術士口答試験に向けて、自宅に篭って悶々と準備中の毎日でございます。
この不景気の中、纏めて休みを取ったものだから、家の奥さんは会社をクビになったんじゃないのかと心配しております。　そして、こうやってブログを書いていることを話したところ、「他の受験生に見られたら自分が不利になるんじゃない？」と。　いや、技術士の試験は絶対評価の筈だから関係ないはずなんだが．．．　（そもそもこのブログ、Googleもヤフーも検索にかかってこないぞ。）　そういや大学の時、レポートを書く際に同期にノートをコピーさせてあげたら、同期の方が点数良かったことがあったっけ．．．

今夜は2008年度技術士二次試験見直し中です。
（もちろん、このブログは模範解答を書いているつもりはなく、自分の考えを纏めるために書いているだけです．．．）
今日のお題は情報工学部門（午後）　情報システムデータ工学のI-1-1

I-1-1　SaaS（Software as a Service）とは何かを説明し、SaaSを導入することによって企業が得られるメリットと課題を述べよ。

割と興味のある分野なので、書きやすいです。
2008年12月31日に書いたブログに一部僕の考えを書きましたが、ここではASPとの対比で考えてみようと思います。
（ところで、ASPってActive Server PageとApplication Service ProviderでTrigramだぶってますね．．．同じIT業界の中でなんと言うセンスの無い．．．　もちろんここではApplication Service Providerのことです。）

SaaSとASPの技術的相違
他にも、色々と要素はあるのかも知れませんが、僕が着目したのは以下の点です。

シングルシステム・マルチテナント
Google appsやGmailのようなオフィスアプリケーションでは問題にならないのでしょうけれど、業務システムにおいては、程度の大小はあってもユーザー企業ごとの要件の違いは不可避です。　ASPにおいてはユーザー企業（テナント）ごとの要件の違いはテナントごとにシステムリソースを個別に割り当てることで対応していましたが、結果として利用コストが高くなっていました。　SaaSでは、カスタマイズ要素をアプリケーションから分離することで、シングルシステムマルチテナントでありながら、柔軟なカスタマイズ性を実現しています。　代表的なのはSalesforceでしょう。　2008年12月31日にも予告しましたが、近日中に勝手に技術解説（公知の技術を営業妨害にならない範囲で）したいと思いますのでご期待を。


リッチクライアント
ASPが登場した時点でWebアプリケーションのユーザーインターフェースで使用できる技術は静的HTMLが殆どでした。　静的HTMLは表現力の面でWindowsアプリケーションと比較すると大きく劣るものでした。（だから、僕はWindowsアプリが好き）　もう少し具体的に言えば、Webアプリケーション上に何かボタンがあったとして、そのクリックイベントに対して一々サーバーと通信し、結果として画面を再描画するため、レスポンスが遅く、しかも画面がちらつくというものでした。
が、JAVA ScriptとWebサービスによる非同期通信の組み合わせである、AJAX等リッチクライアント技術の登場により、WebアプリケーションであってもWindowsアプリケーションと同等の表現力を実現することが可能となりました。　このAJAXですが、具体的には以下のようなHTMLで実現されています。 　分かりやすいように、重要な部分だけを抜き出してみました。



そして、これがAJAXの動きです。






①Button Aがクリックされるとイベントハンドリング関数aaaがコールされる


②aaa内では非同期通信用のオブジェクトxmlReqを生成する。 Internet Explorerの場合は、ActiveX ObjectのMicrosoft.XMLHTTPを、その他のブラウザではXMLHttpRequestというオブジェクトを使用する。　このxmlReqがサーバと通信を開始するが、ブラウザ上でユーザーがこの通信を感知することは無いし、HTMLページに対する更新も起こらない。（これがサーバーのレスポンスを待つことを不要とする操作性を実現しているわけであるが、同時にセキュリティ上のリスクにもなり得る。）


③xmlReq内にonreadystatechangeとしてコールバック関数を定義しておく、サーバーからの応答はここで定義された関数内でハンドリングする。


④コールバック関数からHTML内で更新すべき要素に対して更新処理をかける。　この処理はHTML全体のリフレッシュではなく、HTML内の一部に対するものであるため、画面のチラつきは起こらない。

Webサービス
以前、某学会でSalesforceの社長が言っていたのは、Salesforceの提供するWebサービスを利用することで、ユーザーはマッシュアップにより独自のアプリケーションを創造することができるという。

なるほどー

SaaSの導入によって企業が得られるメリット
1)初期投資の抑制
パッケージソフトウェアの導入では、システム導入に踏み切る際の初期導入コストが大きく、投資対効果を明確にしづらい場合、導入が難しかったわけですが、SaaSはハードウェアを含めて従量制を取ることが出来るため、初期導入コストを抑えることができ、開発リスクを抑えることが出来ます。
2)管理コストの削減
SaaSにおいては、サーバハードウェアのメンテナンス、データのバックアップ、ソフトウェアのパッチ対応等の管理業務がサービス提供側の責務となります。　サービス利用企業毎に専門の管理者を常駐させる場合、定常的に業務量が確保できなければ管理コストが高くつくことになりますが、SaaSの提供者側にとっては、専門の管理者が複数のサービス利用企業を管理することが可能であるため、業務量の平準化とノウハウの蓄積により効率の良い管理が可能であり、結果として質の良いサービスを低コストで提供できると言えるのではないでしょうか。
3)セキュリティの向上
管理コストと同様、セキュリティにおいても管理者の教育等、複数のサービス利用企業を一括で管理する場合、効率が良いと言えるのではないでしょうか。
（AJAXの場合、JAVAスクリプトの使用等、セキュリティ上のリスクが増す面もありますが．．．）

SaaS導入における課題
SaaS導入における最大の課題は、データや企業の業務プロセスの投影とも言えるアプリケーションが場所的にSaaS提供者側にあることに対する抵抗感の問題でしょう。　特にサービスが取り扱うデータがサービス利用企業の競争力の源泉であれば、その管理を第三者に委ねることに抵抗があるのは当然でしょう。　また、企業活動の根幹に関わる高い可用性を要求されるサービスであれば、そういったサービスを第三者に委ねることにも抵抗があるでしょう。　これらの問題は、技術的にはセキュリティと高可用性の問題であり、SaaS利用の拡大と共に実績によりユーザーの抵抗感が薄れていくことでしょう。　


これって、分譲マンションと賃貸マンションの話と似てるなぁ．．．
キャッシュフロー的には賃貸の方が得な筈なんだが、それでもやっぱりマンションが欲しい。