HOME > 経営をよくする > SaaS & ASP 活用術

SaaS & ASP 活用術

実践事例!中小企業のIT調達はコレだ―「サービスソーシング」

09.インフラをサービスソーシングする −既存のシステムや独自アプリまでソーシングできる環境の構築

前回は「データ」という形でハードウェアの一部をサービスソーシングする方法をみました。これをもっと推し進めるとどうなるでしょう? そうですね、ストレージだけではなくコンピュータそのものをサービスソーシングしてしまえば、社内から一切のハードウェア/ソフトウェア資源を追放できる、ということになります。

もっともWebにアクセスするためにそれぞれの手元のPCをなくすことはできませんが、そのためだけのPCならば、Webブラウザさえ動けばよく、最低限の性能のPCで十分です。壊れやすいハードディスクなどもほとんど不要ですから、ハードウェアやソフトウェア、データの保守/管理の手間やコストを大きく削減することができます。

今回は、どうしても独自開発したアプリケーションやシステムが必要だったり、サービスソーシングではできない既存のパッケージを利用せざるを得ないという場合に、それを自社内のサーバーやデータ・センタに設置したサーバーを使わなくても動かせるようにする、つまりコンピュータや記憶装置、ネットワーク、オペレーティング・システムなどのインフラそのものをサービスソーシングする方法を見てみます。

レベル 上級
対象 独自開発アプリケーション/システムを持っており、それらについてもサービスソーシングの利点を得たいと考える組織
目的 独自開発アプリケーション/システムをサービスソーシングすることによって、所有/運用コストを最小化する

9.1. 仮想コンピュータのサービスソーシング

インフラのサービスソーシングには、現在、大きく分けて二つの種類があります。一つはコンピュータのハードウェアそのものを提供するもの。もう一つはその上にソフトウェアの開発/実行環境を載せたものを提供するものです。

前者をIaaS(Infrastructure as a Service:サービスとしてのインフラ)やHaaS(Hardware as a Service:ハードウェアとしてのサービス)、そして後者を PaaS(Platform as a Service、プラットフォームとしてのサービス)と呼ぶこともあります。

ここではまず、前者の代表例である Amazon EC2(Elastic Compute Cloud =伸縮自在な計算クラウド)、S3(Simple Storage Service =簡易記憶領域サービス)について説明します。

拡大する
Amazon Elastic Compute Cloud (Amazon EC2) 図9-1 Amazon Elastic Compute Cloud (Amazon EC2)

拡大する
Amazon Simple Storage Service (Amazon S3)図9-2 Amazon Simple Storage Service (Amazon S3)

Amazon EC2/S3は巨大オンライン・ストアであるアマゾンが、自社で使っているインフラストラクチャ(巨大データ・センタ)の一部を低料金で、簡便に提供するものです。実際にAmazon EC2を申し込むと、アマゾンの巨大データ・センタ(クラウドとも呼ばれる)上に、仮想的なコンピュータ(最小構成は 1.7GBメモリを積んだインテルの32ビット・1コアCPU相当マシン)を自分の思い通りに使うことができます。

ここで「仮想的な」というのは、実際に一台の計算機がアマゾンのデータ・センタ内に用意されるわけではなく、一台の現実の計算機の中で複数のユーザー用計算機を動かすからです(本当の対応関係は不明です)。これはSaaSの「マルチテナント」に似ています。EC2にはハードディスクに相当する記憶領域は含まれませんから、通常はS3という仮想的な記憶領域も必要になります。どちらもオンラインで、クレジット・カードで簡単に申し込むことができます(http://aws.amazon.com/ec2/)。

いくら仮想的とはいえ、マシンだけあっても意味はありません。そこで、この仮想的な計算機に WindowsやLinux、Solarisなどのオペレーティング・システムをインストールします。UnixやWindows のシェルのような専用ツールを用いて自分でインストールすることもできますが、代表的なオペレーティング・システム(OS)のイメージはすでに用意されています。また最近ではWebブラウザを使う操作ツールもいくつか出てきていますので多少は簡単になったとはいえますが、それでもやはりITに関する専門的な知識と経験が必要です。

さて、いったん仮想的な計算機上でOSが動き始めれば、後は社内やデータ・センタ内に設置したサーバーと同じです。データベースやアプリケーションをインストールして動かすことができます。仮想的な計算機に対して固定的なインターネット・アドレスを与えることもできますから、アクセスする側から見れば、通常のサーバーと何ら変わりません。

このようにAmazon EC2/S3を利用すれば、今まで社内やデータ・センタ内で動かしてきた独自開発アプリケーション/システムをサービスソーシングすることができることが分かると思います。独自開発したソフトウェアの所有権は残り、保守も必要ですが、それを動かすハードウェアは所有する必要はなく、保守も不要になります。

このことは、特にどれだけの規模の計算パワーや記憶領域が必要になるか、予測できない場合に大きな効果を発揮します。最初は最小構成から始めて、必要に応じて契約内容を調整していけばよいからです。最初から無理な見積もりを立てて、時間と手間を掛けて高価なマシンを用意したり、それでも足りなくなった場合に新たにマシンをさらに用意し、アプリケーション/システムを移行する必要がなくなります。

EC2の利用にかかる費用は最小構成で1時間当たり10セントからです。また外部とのデータのやり取りには、1GB当たりそれぞれ10セント(受信)、17セント(送信)が掛かります。そしてS3によるデータの保存については1GB当たり月額15セントが掛かります(データのやり取りと保存に関しては実際にはさらに細かい規則があり、もう少し面倒な計算が必要です)。

セントという単位でいわれても実感が湧かないでしょうから、モデルケースを考えてみます。例えば、最小構成のマシンを一ヶ月動かして、毎回100KBのデータを1日に500 回、それぞれ送受信すると考えます(比較的シンプルなアプリケーションを毎日24時間動かし続けた場合に相当します)。これはごく単純に考えて月額数千円程度です。もちろん使い方次第ではありますが、安価な法人向けレンタル・サーバーとほぼ同じ程度と考えていいでしょう。

運用の仕方を工夫すれば(自働化ツールを使って運用時間を限定するなど)、もっとコストを下げることも可能です。したがって直接的な運用コストに関しては、非常におおざっぱには、レンタル・サーバと同じか、もしくは少し安いくらいというのが一つの目安になります。

一方、リスクはどうでしょうか?Amazon EC2では稼働率99.95%のサービス・レベルを約束しています。アマゾンの場合、たまに(せいぜい1〜2年に一度程度)不具合の噂を聞くこともありますが、自社サービスも同じクラウド上で動かしているとすれば、大いに信用できるものです。

また機密性に関しては、今までのところ特に大きな問題を発生していません。アマゾンは多くの注目を浴びているサービスですから、何か問題が起これば広く周知されることが期待されます。多くのレンタル・サーバーと少なくとも同程度の信頼性は期待できる可能性があります。

9.2. プラットフォームのサービスソーシング

拡大する
Google App Engine 図9-3 Google App Engine

先述した仮想コンピュータは、ハードウェアとせいぜいその上のオペレーティング・システム程度を含むだけのものでした。それに加えてソフトウェアの開発/実行環境まで含んだインフラをここではプラットフォームと呼ぶことにします。

前に紹介したSales Forceも実は、Force.comというプラットフォーム・サービスの上に構築されています。Force.comはプログラミング言語/環境として、APEXという独自言語/環境を提供しています。これは現在、広く一般的に利用されているJavaとよく似てはいますが、環境も含めて開発には独自の学習や調査、経験が必要になります。もし今、社内でJavaで開発された独自アプリケーションがあったとしても、それをAPEX上で動かすようにするためにはそれなりの移植作業が必要になります。

ただしForce.comの場合には、Sales Force を使っていれば、APEXを使うためにそれ以上の費用は必要ありません。この点においてはAmazon EC2/S3に較べて費用計算が明確です。すでにSales Force を使っていてさらに独自アプリケーションを開発したい場合や、Sales Force と既存の独自アプリケーション/システムとを結合させたい場合には有効な選択肢となるでしょう。

一方、グーグルも、同じようなプラットフォームをサービスとして提供しています (http://appengine.google.com)。グーグルの提供するGoogle App Engineは、Djangoというオープン・ソースのアプリケーション開発/実行環境をベースにしています。Google App EngineのDjango は、Pythonというプログラミング言語と MapReduce/BigTable/Google File Systemというグーグル独自のデータベースの上に構築されているため、Force.comよりも汎用性は低くなりますし、既存の独自アプリケーション/システム移植の手間はかなり大きくなります。

Google App Engineは500MBの記憶領域、月間500万ページビューまでは無料で利用することができます。この「最初はただで簡単に使い始めることができる」のは、マーケティング上、サービスソーシングの大きな利点です。それ以上を利用する場合、1時間10 セント、外部とのデータのやり取りには帯域幅1GB当たり10セント(受信)、12セント(送信)、記憶領域1 GB当たり月額15セントが掛かります。非常におおざっぱではありますが、Amazon EC2/S3と同程度の料金体系といえます。

なお、Google App EngineはForce.comやAmazon EC2と同様に、自らのアプリケーション(グーグル検索エンジン、SalesForce、アマゾン)の提供基盤の一部を整備して公開したものです。ただし現時点では、まだベータ・サービスであり、サービス・レベルは保証されていません。

この連載では、サービスソーシングという考え方にもとづいて、中小企業が自社のITをどのようにして調達、展開できるかについて、9つの事例を見てきました。一年前の連載掲載時に較べても、非常に多様なサービスが、より多くのソーシング先から提供されていることが分かると思います。

サービスソーシングの考え方は今、大きなブームといっていい状況にありますが、かといって単なる一過性のブームではなく、IT調達の重要な方法の一つとして今後数年から十数年にわたって使われ続けられるだろうことが明らかになりつつあります。ここで、この連載で取り上げた事例を基に、サービスソーシングの重要なポイントをまとめておきます。

  • もはやサービスソーシングが技術的に可能なのは明らかになったので、導入に当たってはむしろその目的と効用を明確にしなければならない
  • 中小企業では、サービスソーシングにおいても必要以上に高品質であったり高価であったりするサービスだけではなく、コンシューマ向けの安価なサービスも有効に活用すべきである
  • サービスソーシングにおいても、もっとも重要なのはIT技術そのものではなく、それを受け入れ、活用する人と組織の問題である
  • 今までのように自社のITをいわゆるSIerに丸投げするのではなく、自分たちの智慧と工夫を活かして手作りすることによって、コストを削減し、効果を増大させる
  • 自分たちで自社ITを手作りすることによって、独自ノウハウや核になる競争力を明確にし、収益や生き残りにつなげる
  • 自分たちでできる範囲では手作りし、自分たちの手に余る部分については専門家の手を借りることによって、自分たちのノウハウを蓄積する
  • サービスソーシングによるリスクと、それによるコスト削減、競争力増強などとのバランスをとることが重要である(必要以上の品質、低リスクを追求しすぎない)

今後とも中小企業ならではの利点を勇気を持ってサービスソーシングに活かすことによって、イノベーションと成長をもたらすことができることでしょう。

実践事例!中小企業のIT調達はコレだ―「サービスソーシング」

  1. 中小企業が実践するSaaS―サービスソーシング(調達)[2009年4月3日]
  2. 活用事例01.メール環境のサービスソーシング −電子メールシステムの構築[2009年4月3日]
  3. 活用事例02.情報系システムのサービスソーシング −ドキュメント作成・管理システムの構築[2009年4月3日]
  4. 活用事例03.外部向け情報発信をサービスソーシングする −webサーバーの構築[2009年4月3日]
  5. 活用事例04.基幹系システムをサービスソーシングする −財務、在庫、購買、人事/給与管理システムの構築[2009年4月3日]
  6. 活用事例05.業務系システムをサービスソーシングする −営業支援系システムの構築[2009年4月3日]
  7. 活用事例06.サービスソーシングした業務系システムをカスタマイズする(1) −SaaSの技術的優位性[2009年4月3日]
  8. 活用事例07.サービスソーシングした業務系システムをカスタマイズする(2) −SalesForceを使ったアプリケーションの追加[2009年4月3日]
  9. 活用事例08. データをサービスソーシングする −データの安全とコスト低減の両立[2009年4月3日]
  10. 活用事例09.インフラをサービスソーシングする −既存のシステムや独自アプリまでソーシングできる環境の構築[2009年4月3日]
Copyright(c) Metabolics,ltd. このコンテンツの著作権は、(有)メタボリックスに帰属します。著作権者の承諾なしに無断で転用することはできません。