update it, Inc.社長のブログ

言うまでもない話ですが、今、ものすごい勢いでいろいろなシステムがWebベースに置き換わってきています。企業内の業務用アプリでも同様です。約１０年ぐらい前に作られたVisual Basicで書かれたデスクトップアプリケーションをWebベースのアプリケーションにリプレースするという流れはどんどん加速していて、止められないように思えます。

さて、なぜ皆がこぞってWebに移行しているのでしょうか？　主な理由を３点挙げてみます。

１．保守が簡単だから。
２．別なマシンからでも同じ環境で使うことができるから
３．インストールが要らず、すぐに使えるから。

１番目の理由はシステムを運用する人にとってのメリットです。メンテナンスは基本的にサーバ側に集中するので、保守が簡単だ、ということです。そして２番目は、Webブラウザさえあればどこでも同じ環境で使えるようにできるということ。Webメールなどを使っていると、このありがたみが良くわかります。

３番目の理由が、今回着目するポイントです。今日、Webアプリというタイトルで記事を書いたのは、このインストールが要らないという観点に着目したかったからです。（３つの理由と書いておきながら、ちょっと強引ですね  :grin:）

最近、私のノートPCのアンチウィルスソフトが更新されたのですが、そのバージョンアップには20分近くかかりました。その間、ノートPCでは何も作業ができなくなります。しかも途中でリブートしなければならない上、バージョンアップが終わった後にもハードディスクのフル・スキャンを要求され、それを完了させるのに数時間かかりました。フル・スキャン中は使えないことはないのですが、動作がかなり緩慢になって使いづらくなります。

これはちょっと極端な例かもしれませんが、今までのディスクトップアプリケーションには必ずインストールが必要でした。このインストールという作業が行われている間は、ユーザが本来やりたい作業が行えません。最近のPCではバージョンアップが自動的に行われるアプリケーションが多くありますが、たとえ自動的であろうと、そのバージョンアップ（インストール）の間はアプリケーションが使えないのは一緒です。

ちょっと考えてみてください。あなたはPCで仕事をしているうち、OSも含めてどの程度をインストールやバージョンアップなど、本来の仕事とは関係のない作業に時間を費やしていますか？　使っているアプリケーションにもよりますが、無駄に時間を使っている人も多いのではないでしょうか？

一方、Webのアプリケーションはインストールやバージョンアップすることなしに、いつでもすぐに、最新のバージョンで利用することができます。そもそも使う側はWebのアプリケーションが最新版にバージョンアップされているなんてことは気にしませんよね。なんか、いつの間にか画面が変わっている、ぐらいの意識だと思います。この待たずに使える、というのも、デスクトップアプリに対するWebアプリの大きなアドバンテージの１つだと思います。

Javaで組んだプログラムの場合、実行中に例外が発生したときに適切に処理していると、プログラムを中断することなしに簡単にStackTraceを見ることができます。私がJavaを使い出したときに、非常に良いなと思った仕組みのひとつが、この例外処理の仕組みです。Javaに限らずに、既に他の言語でもあったのかもしれませんが、少なくとも私がそのときまでやってきたC/C++の世界にはなかった仕組みでした。

もう10年以上も前の話ですが、金融商品の理論価格をリアルタイムで計算するシステムを開発したことがありました。UNIXマシン+C言語で計算エンジン（今でいうアプリケーションサーバ）を開発し、LAN上のPCに計算結果を配信するような仕組みです。計算ロジックにはだいぶ複雑な計算モデルが使われていました。

こいつは日中マーケットが動いている間、計算をし続けるのですが、複雑な仕組みを用いているがために、たまにバグのためにメモリアクセスエラーで落ちる（止まる）ことがありました。当然のことですが、落ちると大変です。いつどこにいても呼び出されて対応に追われることになります。このシステムを担当している間は、マーケットの開いている時間帯は気の休まることがありませんでした。

さらに、メモリアクセスエラーが発生すると作成されるcoreファイルを元に解析するのですが、この解析が大変です、strip（リンク時に使ったシンボル情報を消すこと）していたりすると、もうお手上げ、ほぼ解析不能になってしまいます。

Javaで本格的なシステムを作り始めたのはJDK1.1の時代(1998年頃)からになります。その当時、24時間動き続けるサーバサイドのアプリケーションを作ったことがあったのですが、Javaの例外処理の仕組の恩恵を十分に受けました。まず例外が発生してもアプリケーションがストップしないように作ることができます。さらに不具合時の状態をStackTraceとして簡単に見ることができる。問題のかなりの割合がこのStackTraceを見るだけで一目瞭然に原因がわかってしまいます。おかげでアプリケーションの品質を上げる作業が非常にやりやすかったのです。実際これらの仕組みのおかげで、その当時、何ヶ月もの間ノンストップで動き続けるアプリケーションを作れたときに、Javaってすごい、と感じました。

さて、現代のJavaプログラミングの鉄則のひとつに、例外を握りつぶすな、という言葉があります。なぜ重要かわかりますよね。握りつぶしてしまうということ、イコール、起こっている問題から目を背けるという行為です。これをやってしまうと、アプリケーションをきちんとした品質にするのに余計に大変な思いをすることになるのです。せっかくの優れた仕組みなのですから、最大限、その恩恵に預かりましょう。

さて、一連のSaaSシリーズの締めくくりは、SaaSと従来のパッケージとの対比をしてみたいと思います。

SaaSとパッケージを比較した場合、どちらも「既製品を提供する」という部分は同じです。どちらも受託開発ではなく、自社のノウハウをベースに自社がリスクをとる形で開発を進め、売るという部分は同じです。そういった提供者側の経済的な効果ではSaaSはパッケージ開発・販売の1形態と考えることができると思います。パッケージソフトは提供者側の立場で見た場合、自分でリスクを負う分、粗利を大きく稼げる可能性があるというメリットがありますが、その部分に関してはパッケージもSaaSも同じといえます。

ではサービスの提供形態の違いという点ではどうでしょうか？　最近ではパッケージ型についても売り切りではなく、期間契約型のものがでてきています。例えばアンチウィルスソフトなどでは1年毎に契約を更新しないと利用し続けることができないものがありますが、こういった形態の場合、実質的にユーザ側の経済的な効果の違いはないと言えます。

そのような場合には、SaaSとパッケージの違いは単に技術的な違いだけなのでしょうか？　いや、１つ忘れてはならない部分があります。それはSaaSではシステムの運用の大部分をシステム提供会社が行う、という点です。

つまり各種インフラ（通信環境、設置場所、バックアップの仕組みなど）およびハードウェア、ソフトウェア一式をすべてシステム提供会社側が提供するという点が大きく異なります。こういった設備をマルチテナント方式（複数のユーザが相乗りして利用すること）で利用することにより、コストの最適化が図れることになります。

まとめると、SaaSは期間契約タイプのパッケージソフトと似ていて、さらにその運用をマルチテナント方式でアウトソースしている形態、ということができます。

SaaSというと従来との技術的な違いばかりが強調されがちですが、サービスという視点で考えたときに、実はたとえ従来の技術をベースにしたとしても同じような効果を出せることがわかると思います。重要なのは利用する技術の違いではなく、システムの提供者、ユーザそれぞれにどのようなメリットを提供できるか、です。私がSaaSが優れていると感じるのは、技術的な面の違いよりも提供できるメリットの違いです。単なる技術論で終わることなく、その優れたメリット・可能性を考え、このモデルに移行する時期が来たのではないかと考えています。

昨日までは技術者の立場から見たSaaSというテーマで書いていましたが、今日は自分が経営者になったつもりで見てください。以降では受託開発をベースとしたシステム開発型モデルとSaaSを利用したシステム提供型モデルの対比として話を進めます。

昨日の技術者の立場から見たSaaS その２で「改善」という観点の話を書いたのですが、このことは経営者の立場から見た場合、大きな強みになります。

例えば今、Salesforce.comに対抗するようなシステムを受託によるシステム開発型モデルで作り上げることができるでしょうか？　SaaSを利用したシステム提供型モデルのシステムはマーケットの要求に応じてどんどん改善＝進化していきます。一方でシステムが進化しても価格が上昇するわけではありません。それらはすべて、サービス料の中に含まれているのです。最初は受託でもあまり差がなかったとしても、システム提供型モデルのシステムは徐々に改善を続けた結果、いずれ受託開発では追いつけない高みにいってしまうことになります。

こういうとERPの例を出して否定する人もいるかもしれません。つまり、ERP導入がさかんだったころ、パッケージをベースにしても対象顧客向けの作りこみ（アドイン）が大量に必要になることが多く、かつそのアドインを開発するにはそのERPの専門の技術者でないと対応できないということがありました。このためパッケージを導入してもあまりメリットがなかったじゃないか、SaaSにしてもこれは同じではないの？という意見です。

しかしSaaS時代のシステムの場合、システム間連携のためのインターフェース（API）はWebサービスという標準的な技術で提供されます。これは対象のシステムの専門の技術者でなくてもシステムへのアドインが開発できることを意味し、システムのコンポーネント化、すなわち水平分業化が可能になることを意味します。

継続的な改善は大きな力となります。継続的な改善が可能なSaaSを利用したシステム提供型モデルは受託開発をベースとしたシステム開発型モデルを徐々に駆逐していくことになると考えます。

さて今日は昨日の「技術者の立場から見たSaaS」の続きです。

技術者の立場で考えた場合、SaaSにはもうひとつの大きな違いがあります。それは1度作ったら終わりなのか、何度も改善を積み重ねていくものなのか、という違いです。

システム開発会社の受託したシステムの場合、基本的には作って納品してしまえばおしまいです。もちろん保守もあるにはありますが、エンハンスが続く場合は別として、通常の保守の場合システムの障害対応がメインであり、中身を改善して作りかえるということはあまりしないと思います。

一方のSaaSによるシステム提供会社の場合には、そのシステムは大切な商売道具であり、絶えず改善が求められることになります。作ったらおしまいではなく、中身をどんどん改善していかなければ他の競合他社に負けてしまうのです。

この特徴はパッケージ製品を提供している場合でも同じはずです。つまりパッケージ製品の場合でも、通常は何度も改訂を重ねて改善していきます。ただしパッケージ製品の場合には見た目を華やかにする「売る」ための機能追加がメインになっているとおもいます。一方のSaaSの場合、自社で運用するために実際に「使える」製品にすることにも自然と注力せざるをえません。つまりセールストークのための機能追加よりはシステムの安定性や通常の使いやすさの改善に力をいれなければならないということです。

システムを受託開発するとき、きちんと動きはするものの技術者としては納得のいかないレベルでの納品が必要になる場合があります。そして一旦納めてしまうとそのシステムはそうそう改善するチャンスはありません。しかしシステム提供会社の場合には保守をしやすくするための改善をやるチャンスがあります。もちろんマーケットの要求に応じることが最重要ですが、それをやりつつ、既存のコードのリファクタリングも行うことが当たり前になるのです。

さて、あなたはどちらの技術者のほうが幸せだと思いますか？

最近、日経新聞とかにもSaaSという言葉が踊っていて驚かされることがあります。NBOnlineでもつい先日、SaaSでもっとも成功している企業の例としてSalesforce.comの話を取り上げていますね。

以前のブログでシステム開発会社とシステム提供会社というテーマでSaaSの進展に従ってシステム会社の「製造業」から「サービス業」への転換が始まるという話を書きました。SaaSの本質は、技術的な面よりもむしろ、今までオーダーメイドで作っていたのを止めて、既製品を提供する商売へ転換するということだと思います。

その意味ではパッケージ商売と近い部分があります。ただしパッケージ商売の場合、ソフトウェアだけを売り物（正確には使用許諾権ですが）にしていたのに対し、SaaSではもっと広く、利用するためのバックエンドの仕組みを含めて全体をサービスとして提供します。つまり、作っては売る「製造業」の世界から、継続して様々なサポートを提供するサービス業への転換を意味することになります。

システム開発会社の世界では製造力、すなわち技術力（と体力？）の勝負ですが、システム提供会社の世界では技術力もさることながら、他にも企画力や運営能力など、総合的な能力が問われるようになります。

ではシステム開発会社の技術者とシステム提供会社の技術者では違いがあるのでしょうか？　技術者という立場からみれば、作るのは同じじゃんと思うかもしれませんが、実は大きな違いがあります。それは顧客との関係という点です。

オーダーメイドでシステムを作る場合、顧客と開発会社の関係は主従の関係になります。つまり顧客のほうが開発会社よりも圧倒的に強い立場になります。顧客の言うことには従わなければなりません。

一方のシステムを提供する立場の場合、システム・オーナは自分自身（の会社）なのです。もちろん多くの顧客に使ってもらうために様々なサービスを顧客に提供していかなければなりませんが、システムがどうあるべきかは自分達が決めることになるのです。もちろん会社の内側を見ると企画側と開発側での綱引きとなるのですが、そうは言っても自分の会社自身がシステム・オーナであり、どういうシステムとすべきかという部分に技術者がより主体的に関与できるという点で、大きな違いがあるといえます。

自分達のシステムであれば、作るシステムへの愛着も格別かもしれませんね。

自分が普段使っているPCの裏で、どんなプロセスが裏で動いているか把握している人っていますか？　最近のPCにはいろんなものがてんこ盛りになっていて、知らないプロセスが一杯動いていて、わけがわかりません。Windows95のころまでは、どんなプロセスが動いているかぐらいはだいたいというか、なんとなくは把握できていたのですが…

先日、使っているPCが突然ウィーンとうなりを上げて冷却ファンが回り始めました。CPU負荷の高いようなことは何もやっていません。なので、気になってタスクマネージャを開いてみてみたのですが、CPUの%が高いのはSystem Idle Processだけです。でもCPU使用率の履歴グラフにはなんかのプロセスがCPUを使っているように表示されています。System Idle Processっていうのは、CPUの空きを示しているんじゃなかったでしたっけ！？　まあそれは置いておいて、改めてそこに並んでいるプロセスを眺めてみて思ったのは、ほとんどが知らないものばかりだということでした。（あの、一応ウイルスチェックはちゃんとやっていますよ）

裏で何か知らないプロセスがうじゃうじゃ動いているというのは気持ちのいいものではありません。メモリを食いますし、遅くなる可能性もあります。また「よくわからないものが動いている」という状態はセキュリティ的にも問題があるといえます。

しかし、最近のPCには実にわけのわからないプログラムが一杯プリインストールされてしまっています。また必要なプログラムをインストールする場合でも、そのプログラムがおまけのプログラムをいろいろ一杯インストールしてしまったり、更新をチェックしたり起動をスピードアップさせる常駐プログラムを裏に仕込んいる、なんてことはよくありますよね。

一方で、どのプロセスは必要で、どのプロセスは必要のないものなのかがよくわかりません。私は勝手にPCにインストールされている必要のないプログラムはさっさとアンインストールしてしまう派なのですが、果たして本当にそのプログラムをアンインストールしてしまって問題がないのか、いつも悩まされています。

食品の分野では消費者に対して使っている原材料を明記することが義務付けられていますが、システムの分野でも同じようにすべきではないでしょうか？　つまり、せめてアプリケーションをインストールすることによって、どんなものが追加されるのか、またどういう場合に必要で、逆にどんな場合には必要のないものなのかをユーザがわかるようにする、ということです。セキュリティの観点からは結構重要なことのように思えます。みなさんはどう思いますか？

先週の金曜日にデモ用に買ったノートPCが届きました。Core 2 Duoで2GByteメモリーがのったVistaマシンです。で、おもむろにセットアップを開始したのですが、いやー、半日くらいかかっても終わらない。いい加減、いやになってきました。

時間がかかるのは、1つ目の理由は、まだVistaマシンの使い方の良くわかっていないから。何かいろんなものがいろいろ変わっています。Windows 2000からWindows XPに変わったときもずいぶんメニュー体系などが変わってしまって覚えるのに苦労したのですが、今回も同様に、「そう簡単には使わせないよ」戦法によってかく乱されてしまいました。

2つ目の理由はインストールの嵐！　インストールしてはパッチを更新してセッティングして、さらにインストールして…の繰り返しです。誰かがこれをインストール・マーチと呼んでいたのを思い出します。ほんと、延々と終わりのない行進曲のようです。

さて、一通りセットアップした後で、アプリケーションが起動していない状態でタスクマネージャーを見たら、1GByteぐらい食っていました。こりゃ、推奨メモリが1GByteという意味がわかります。偉大なり、Vista君。（ちなみにその後で再起動後に確認したときには780MByteぐらいだったので、1GByte食っていたのは何かが裏で動いていたからだとは思います。でも、780MByteって何？）

建築の世界でもシステムの世界でもモデル（模型）をよく作成します。でも建築の世界では作った模型を元にして実際に建築物を作ろう、などという無謀なことを考える人はいませんが、なぜかシステムの世界ではこのようなことを考える人たちが多くいます。建築の世界で模型を作る場合にはスケール（大きさ）が違うので一目瞭然、誰もそんなことは考えないわけですが、システムの世界ではモデルとして作るものと実装物の違いがはっきりしない（と思っている）ので、そんなことを考えるのでしょう。でもよくよく考えてみると、ちょっと不思議な気がしませんか？

先に断っておきますが、ここでいうモデルとはMVCのModelではなく、UMLで指すところのModelを指しています。MVCのModelは現実世界との対比（抽象化）という意味でModelという言葉が使われていますが、そこではシステムに必要な実際のデータとビジネスロジックが扱われますので、いわゆる模型という意味ではありませんね。

え、UMLのModelも抽象化という意味も含んでいるって？　まあ、確かにその通りですが、ここで議論したいのは、みんなの理解を深めるためのモデルという観点の話です。

モデルと実際の実装物との違いは何でしょうか？　モデルは必ずしも最終的な実装物そのものを表す必要はありません。モデルを作成する目的は、実装物がどんなものであるかをイメージしやすくすること、そしてその段階でわかる設計上の不具合を予めつぶしておくことだと思います。

逆にいうと、この目的を満たさないモデルは、モデルではないのです。モデルを見て、あ、これはこういうことね、と簡単にわかるようになっていなければ、本来のモデルとしての意味を成していないということになります。

イメージがしやすく、わかりやすいモデルというのは、実際の実装物に比べるとだいぶシンプルで、あまり重要ではない部分や例外的な部分などをばっさりそぎ落としたものであるべきです。本質的な、ごく重要なことだけをモデルとして表現することによって、誰が見ても何をやろうとしているのかがわかりやすくなります。また最終的なインプリメンテーションと多少異なっていても構わないんです。重要なのは厳密であることよりも、おおよそが合っていることが重要なんです。

システムの世界ではモデリングの表記法としてUMLが一般的になりましたが、UMLはどんどん「厳密に」定義できるように複雑化してきました。でもこの流れは本来の目的から外れているのではないでしょうか？　私はUMLとは単なるスケッチだと思っています。(Martin FlowのBlikiにもそんな記事がありますね）　もっとラフに、部分部分の局面でうまく利用するツールとして利用したいものです。

ちょっと前ですが、シマンテックがアンケート調査した「PCは遅い！」、ユーザーの6割がストレスという記事が@ITに載っていました。PCそのものは処理能力が年々向上しているはずなのですが、使っている人たちはその恩恵をほとんど感じていない、ということになります。なんとも不思議な話です。

実際、私のPC(Window XP, Pentium D 3.2GHz, 2GByte Memoryのマシン）も朝立ち上げてログインした直後はしばらくまったく使えません。一応画面上、ディスクトップは表示されるのですが、右下の常駐アプリケーションのところが一通り出揃うまでは裏でCPUやハードディスクなどががりがり動いていて、その状態で何かアプリケーションを起動してもなかなか立ち上がってきません。試しにその状態で起動してみると1分ぐらい平気で待たされてしまいます。

でもしばらくして（数分後）落ち着いてからは、すんなりと待つこともなくアプリケーションが起動されます。また通常に使っているときには特に遅いと感じることは少ないです。

上記の記事で皆がPCが遅いと感じているのが、この起動直後の状態を指しているのかははっきりしないのですが、私はかなり関連しているのではないかと考えています。もしそうだとすると、これは何が悪いということになるのでしょうか？　もしかしてアンチウィルスソフト？　そういえば私のPCのアンチウィルスソフトはXXXXxX製ですね。  😎

PCの起動直後というのは、まさにそのPCを使いたいと思って使い始めた直後のことなので、そこで待たされてしまうと、ことさら遅さを感じてしまう気がしています。

突き詰めて考えてみると、ユーザが求めているのは、動かし始めたときの起動の速さなのかもしれません。使い始めたときにさくさくと動けば早いと感じ、なかなか立ち上がらないと重いと感じる。例えばJavaのアプレットが人気が出なかったのに対し、AjaxやFlashがなぜに人気があるのか？　なんてことも、その仮定を裏付ける１つの事例のように思えます。またYouTubeがWindowsのMedia Playerではなく、Flashベースなのも、Google MapやGoogleブック検索がPDFなどではなく、GIFベースなのも、さくっと動きはじめることを重視しての選択のように思えます。