連載　構図が変わる

第2章　ASPフィーバー in Japan(2)

吉田育代
2000/06/28

なぜこんなに盛り上がっているのか

　なぜ、ASPはこんなに短い間に日本で盛りあがったのだろう。なにがITベンダーたちをASPへと駆り立てるのだろう。私は大きく4つの理由があるのではないかと考える。

●理由その1〜米国での一大ムーブメント

　1つには、宇治や岡田が言及しているように、米国で一大ムーブメントになったからだ。それも、提唱者のシトリックス・システムズだけではなく、オラクルや、サン・マイクロシステムズ、シスコ・システムズ、マイクロソフトなどIT業界のキープレーヤーたちが、「これからはASPだ」と本気で体制を整え動き始めた。その姿を見れば、誰しもこれは一過性のブームではないと腰を上げざるを得ないだろう。では、その米国でこれほどまでに火がついたのはなぜか。

　もともとは、大企業への導入が一巡したERPパッケージベンダーが、中堅企業に製品を売り込む手段としてASPに飛びついたのがきっかけだったという。一般的に、ERPパッケージは製品自体の価格が高く、そのうえにカスタマイズのためのコンサルティングも必要になる。企業も中堅規模になるとおいそれとは手が出せなかった。だが、それはERPパッケージベンダーにとっても困ったことだった。販売する相手がなくなってしまうからだ。だからといって、同じ製品を中堅企業向けに安い価格で売るわけにもいかない。ジレンマに陥っていたところへ、ペイ・パー・ユースによる共同利用という発想が登場したのだ。これなら根本的に価格体系を変えても、今までの顧客からクレームが来ることはない。

　そのようにしてERPパッケージベンダーたちがこのアイデアに乗ったのだが、顧客として適していたのは中堅企業だけではなかった。米国では続々と誕生するドットコム・カンパニーもASPを歓迎した。彼らは既存のIT設備を何も持たない。社員は本業のための最少の人数しかいない。しかし、明日は100倍に成長するかもしれないから、中小企業向けではない本格的なERPパッケージを始めから使いたい。それも今すぐ使いたい。そういうニーズを満たすのにASPはぴったりだったのだ。そのうちに、必要なのはERPパッケージだけではない、ECも要る、CRMも要る、メッセージアプリケーションも、オフィスソフトも、ということになってきて、しまいには“アプリケーションを早く導入して、運用管理のわずらわしさから解放されたいのは大企業も同じ”、と大企業までがASPトレンドに乗ったのである。

図1　ユーザーにとって魅力あるASP

　ユーザー企業のメリットが多大であるという点で、ASPはITベンダーたちにとって無視できないコンピューティングモデルだった。なにしろ、システムを買わなくていい。今は選択肢がいろいろあるといっても、サーバマシンもソフトウェアも自前で一式揃えようとすれば決して安い買い物ではない。購入するなら、その費用を最初に全額用意しなければならない。次に、お金は使う分だけ、あるいは使った分だけ払えばいい。パッケージなら、いらない機能があってもすべてを購入するしかないが、ASPモデルなら利用する側で取捨選択することができる。そしてその次に、本業ではないシステムの世話をしなくていい。ASPの窓口となる人間は必要だが、ほとんどのスタッフが自社のコアコンピタンスに専念することができる。そのうえ、すでにアプリケーションはサービスとして存在するから、すぐにスタートできる。要件定義をして、基本設計をしてといった手順を踏んでいたら数ヶ月から半年はかかる。インターネットタイムを生きる現代の企業には、それではもう遅いのだ。まだある。ASPで導入したアプリケーションは、使ってみて気にいらなければやめるという選択肢を持てる。パッケージやカスタム開発のアプリケーションは、お金を払わなければ利用することができないし、利用してみて気にいらなかったとしても、一度使ってしまったものは文句はいえても返金は不可能だ。

　競争力の源泉となるコアのアプリケーションを、他社と共同利用しようという企業は少ないかもしれない。しかし、展開するアプリケーションのすべてがコアのアプリケーションというわけではない。その初期投資、運用管理の手間、コストを検討すると、ある種のアプリケーション導入はどう考えてもASPを選ぶ方が合理的である。スマートなITベンダーたちはユーザー企業の思考ロジックを一瞬にして悟り、これは避けるより乗った方が賢明と一斉にASP支持にまわったのだ。そして、そのまなじりを決する姿が日本のITベンダーたちにも伝わったというわけだ（図1）。

●理由その2〜従来からあるシステムモデル

　しかし、これが初めて登場した、まったく新しい概念だったら、日本でもこれほど早くASP市場が形成されなかったかもしれない。ASPにここまで注目が集まるのは、それがすでに存在したコンピューティングモデルのリメイク版だったからである。「ああ、今までやってきたあのシステム運用をASPと呼ぶの。それなら知っている。われわれにもできる」と思わせるものがあったのだ。それが2つめの理由だ。

　NTTデータの場合、共同利用型のITサービスというのは1960年代後半からすでに提供の経験がある。DIALS、DRESS、DEMOSなどといったアプリケーションがそれらだ。もちろん、この時代、サーバはメインフレームである。それらが、NTTデータのデータセンターで運用されていたのだ。DIALS（Dendenkosha Immediate Arithmetic and Library System）というのは、電話のプッシュホンを利用した電卓である。1970年代、電卓は1台10万円もして、とても個人で買える代物ではなかった。そこで、まだ電電公社と呼ばれていたNTTデータが、メインフレームと電話を使ってその機能を提供したのである。

　DRESS（Dendenkosha REal time Service System）は、企業向けの販売在庫管理システムである。DRESSで特筆すべきは共同利用型といいながらユーザー企業ごとにかなりのカスタマイズを施したということである。これも、当時何十億円もしたコンピュータを購入する体力を持たない中堅企業に好評を博し、ピーク時には全国で6センターで運用され、利用ユーザー数は1000件を越えた。

　DEMOS（DEndenkosha Multiaccess Online System）は、タイムシェアリングシステム型の科学技術計算システムである。ユーザー企業が作成したプログラムやデータの蓄積・保管ファイルを提供したり、FORTRAN言語によるプログラムの作成と実行を行ったり。DEMOSの用意するライブラリープログラムを提供したりといったことをした。こちらもピーク時には全国で5センター、約6000のユーザー企業数を数えた。

　しかし、いずれもハードウェアの低価格化につれて、ユーザー企業が独自にコンピュータを所有するようになると、ニーズはしだいに減少し、“手がかかる割に収益が上がらない”とDIALSは1982年、DRESSは1996年、DEMOSは1995年でそのサービスを終える。実は、NTTデータにとってASPというのは、つい最近に撤退したばかりのITサービスだったのである。それにもかかわらず再びチャレンジする理由を、宇治は次のように語る。

「これがDRESSなどを手がけた産業システム事業本部だったら、確かに乗り出さなかったかもしれない。しかし、われわれは新世代情報サービス事業本部で事業主体が異なるし、テクノロジーモデルも細部で違うから、別の視点でASPを見られる。それに今回は、一度ユーザー企業でアプリケーション運用を試して、やはりいろいろ面倒だということがわかった上でのトレンドだから、前回とは明らかに違う流れになるだろう。一度苦杯をなめていることも、ヘビーなカスタマイズはすべきではないといった教訓を今回のビジネスに活かすことができて、結果としてプラス。懲りて手を出さない法はない」

　こうしたメインフレームの共同利用はNTTばかりではなく、受託計算サービスという形で他にも多数存在した。たとえば、ユーザー企業の給与計算を、受託計算センターが引きうけて結果を返すというようなことは、きわめて一般的なサービスだった。今日でも、ある企業グループのアプリケーション運用を、グループ内の情報子会社が課金をしながら一手に引き受けているケースは多い。インターネットを利用していたかどうかは別として、1対Nのペイ・パー・ユースのITサービスはすでに存在した。それにASPという名前が正式に与えられたことが、一気に市場が形成される起爆剤の役目を果たしたのである。米国でもASPを“先祖がえり”とみなす傾向はあって、ASP事業者がユーザー企業に初めて説明に出向くと“これってタイムシェアリングのこと？”と聞かれるのだという。

●理由その3〜変革への危機感

図2　ASPはIT業界の構図を変える

　3つめは、IT業界の構図が根本からくつがえってしまうという危機感だ。これまではITベンダーという食料品店が素材を提供し、システム・インテグレータという宮廷料理人がそれを料理して、ユーザー企業という名の王様に供するという暗黙の不文律があった。何か食べたいものがあると、王様は宮廷料理人に作ってくれるよう頼むしかなかった。この宮廷料理人は何でも上手に作るが、一から用意するため時間がかかるのがネックだった。そして、素材のコストも、宮廷料理人の給料も、王様がすべて負担しなければならなかった。ところが、王様は宅配レストランという存在を発見する。あらかじめメニューが用意されていて、食べたいものをすぐに配達してくれ、食べた分だけ代金を払えばいい。経済感覚のある王様は“これからはレストランから出前をとる”と宣言した。そうなると繁盛するのは宅配レストランだ。宮廷料理人にとって都合の悪いことに、レストランを作るのは食料品店を筆頭に誰にでもできた。インターネットというデリバリーシステムを利用すれば、王様のそばにいる必要などまったくない。米国のレストランに料理を注文することすら可能だ。今まで思ってもみなかった業種の企業が、思ってもみなかった国から、日本の市場を虎視眈々と狙っている。仕事を失いたくなければ、今自らがレストランをオープンして一刻も早くシェアを獲得するしかない（図2）。

●理由その4〜IT技術者の不足

　そして、これは明確には認識されていないかもしれないが、IT技術者の数の不足という問題がある。企業の中で日増しに高まっていくITの重要性のスピードに、要求される技能を持った技術者の育成スピードが追いついていない。この先、ユーザー企業がそれを望んだとしても、優秀なIT技術者を十分確保し続けることは難しくなる。それはシステム開発をサポートするベンダー側でも事情は同じで、日本電子開発の岡田の言葉も技術者の量に依存したビジネスの限界を指摘したものだ。そうなれば、少ない人数で増加するニーズを満たすことを考えなくてはならない。ユーザー企業は自社でできること、できないことを見極め、外部に委託できるものは委託せざるを得ないであろうし、システム開発をサポートする側も、1チームでできるだけ多くのユーザー企業の面倒を見ようとするだろう。IT技術者の人口という観点からすると、ASPの登場はもはや必然なのだ。

内外から狙われる日本のASP市場

　仕事を失いたくなければ、今ASPをめざすしかない。そう、その危機感は正しい。世界第二位のIT市場を持つ日本は、ASP分野においても格好のターゲットとなっている。今年1月に行われたASP Summit Tokyo Previewの参加者リストの中に、アジアのASP事業候補者の名が多数あったという。米国でASP向けデータセンターをいちはやく立ち上げ、ヤフーやアマゾン・ドット・コムのシステム運用を請け負ってその名をとどろかせたExodusが、野村総合研究所と組んですでに日本でインターネット・データセンター事業に乗り出している。6月中旬に私が参加した米国のASPカンファレンス「Business Technology Solutions for The Internet Age」でも、すでに体制を確立したいくつかのASPが“日本への進出は必須”と明言していた。このあたりの米国最新動向は、次回で詳しくレポートする。ASPは、今まさにグルーブしている真っ最中の市場だった。

（文中敬称略）

第3章へ

Index 連載　構図が変わる 　 序章　今そこにあるIT革命 　 第1章　ASP was born 第2章　ASPフィーバー in Japan 　 第3章　米国ASP業界の新しい動向 　 第4章　ユーザー事例から見るASPの現在