それは“クラウド・サービス”ですか？それとも“クラウドを使ったサービス”ですか？
「うちもクラウド・サービスをはじめることにしました。」
あるSIerの経営者からこんな話を伺った。どのようなサービスかと尋ねると、この会社が既にパッケージとして提供しているソフトウエアを“クラウド・サービス”として提供することにしたそうだ。
しかし、話を聞けば、AWS上に、お客様毎に仮想サーバーを起ち上げ、そこにこれまでと同じパッケージを稼働させ、その運用を代行するというものだ。
このサービスが何も悪いわけではない。そのパッケージを使いたいお客様の設備投資を経費に変え、運用管理を任せることができるメリットはある。しかし、これがすなわち、“クラウド・サービス”かとなると、いささか疑問だ。
クラウドの定義をここで云々するつもりはないが、クラウドであることの価値を最大限に享受できるサービスとはなっていない。また、契約上も課題がありそうだ。気になるところを3つほど挙げてみよう。
まず、気になるのは、運用管理負担が低減できないことだ。ユーザー企業、すなわちテナント毎にサーバーを起ち上げ、個別にアプリケーションを立ち上げようとすると、ユーザーの数が増えるとともに管理対象が増え、運用管理負担が増加する。システム・リソースに関わる監視や管理はAWSに任せられるにしても、様々な運用設定や構成変更への対応は個別だ。また、アプリケーションの運用は、テナント毎の個別負担となる。つまり、「収穫逓増」が期待できない。
ふたつ目は、リソース効率の悪さだ。アプリケーションをサービスとして提供する場合、この会社のようにテナント個別に仮想サーバーを立ち上げる場合と、ひとつのプログラム実行環境、つまりひとつインスタンスが複数のテナントをサポートする方法だ。この場合は、プログラムだけではなく、データベースもマルチ・テナント対応にするのが一般的だ。
後者の場合、前者に比べて1/1000分のリソースでまかなえるという報告もある。当然、それはサービスの単価にも跳ね返る。
パッケージでは、テナント毎に導入するので、マルチ・テナントを想定したデータベース設計やアカウントの管理、課金などは考えていない。これは、そう簡単に対応できるものではない。従って、ユーザー毎に個別にサーバーを立ち上げるという選択になるのだろうが、これでは、運用や管理に関わる効率だけではなく、リソース効率も悪く、厳しい価格競争に勝ち抜くことは難しい。
最後に気になったのが、契約上の責任分界点の曖昧さだ。契約上のサービス提供者は、この会社となるが、それを動かすインフラはAWSに依存する。確かに、基幹業務に耐えうる可用性や信頼性が担保されるレベルにはあるとはいわれているが、万が一にもここでトラブルが生じた場合、責任は終えないだろう。また、AWSが提供する物理サーバーの構成や性能、サービスや機能、サポート内容などが変更された場合、自社が提供するサービス上に影響はないのだろうか。また、インフラの問題でデータがなくなるといった事態が生じた場合、それは誰の責任になるのだろうか。
もちろん、技術的な対応でカバーできることも少なくはないだろうが、契約は別の話であり、想定しうる事態を考慮しなければならない。そのためには、自社のサービスとAWSの責任分界点を明確に定義し、それを契約上に盛り込むことが不可欠だ。
“クラウドを使ったサービス”も必要な場合はあるだろう。しかし、より大きなビジネス価値を得たいと望むならば、クラウドの持つメリットを最大限に引き出せるよう技術を磨かなければならない。また、契約上の問題も研究すべきだ。ここを曖昧なままにしてサービスを提供すれば、とんだトラブルに巻き込まれるかも知れない。
これまでの人月積算型ビジネスが難しさを増す中、クラウド・サービスを模索するSIerも多い。また、アプリケーション領域でのクラウド・サービスが成長するとも言われている。そうなれば、品質と価格の両面で競争は激しくなるだろう。そのとき、スケーラブルで効率的なシステム構造であることは、競争力の源泉となる。
「システムインテグレーション崩壊」
〜これからSIerはどう生き残ればいいか？
- 国内の需要は先行き不透明。
- 案件の規模は縮小の一途。
- 単価が下落するばかり。
- クラウドの登場で迫られるビジネスモデルの変革。
＊更新しました＊ 今週のブログ
営業の動機付けを支える３つの根拠と営業組織の能力
「最近、優秀な営業が、よく辞めてゆくんですよ。どうすれば良いでしょうか。」
そんな相談を受けることがあります。事情はひとつではないでしょうが、営業組織の能力の低さが、原因になっている場合もあるようです。
今週のブログは、こんな話題をテーマにしてみました。
Facebookページを開設しています。「いいね！」やご意見など頂ければ幸いです。