タグアーカイブ | business

Azure日本データセンターの価格体系

2014年2月26日、ついにAzureの日本データセンターが稼働を開始しました! 現在私は製品マーケティング担当をしているため、当日は公式のあれやこれやで忙しくこちらに投稿ができませんでしたが、Blogでもこの記念すべきイベントを盛り上げよう!とAzureアドベントカレンダーを実施しているので3月6日分として個人ブログでも参加することにしました。

今回、Azureは初めて「リージョン価格」という概念を導入しました。これは、各地域の市場状況に合わせた価格を設定するというものです。ちなみに「市場状況」には競争状況も含まれます。 さて、日本データセンターでの「リージョン価格」が設定されたのは下記のサービスです。

* 仮想マシンの価格がリージョン価格になるので、料金詳細ページに記載されている SQL ServerBizTalk Server の価格もリージョン価格になっているように見えますが、ソフトウェア部分はグローバル価格と同じです(差が出ているのは利用している仮想マシンの料金分のみです)。

SQL データベースと Webサイトについては、5月末までプロモーション価格としてグローバル価格が適用されています。6月1日よりリージョン価格となります。 また、クラウドサービスと仮想マシンのリージョン価格は東日本と西日本でも異なります。西日本の方が東日本の10%ほど安くなっています。

いまはリージョン価格適用が日本だけですが、今後の新しいデータセンターではリージョン価格が適用されていくことになる方針のようです。

Windows Azureショートビデオコンテンツ

Microsoft Virtual Academy (MVA)というオンライントレーニングコンテンツサイトで

Windows Azureのショートコンテンツを公開し始めました。

今回公開しているのはごく基本的な「クラウド概要」と「Windows Azure概要」の2本のコンテンツで、
私が直接お話しています。ビジネス系の方、初めてWindows Azureに触れる方を対象としています。

入門編コンテンツとしてご利用下さい。

Windows Azure ショートコンテンツ
http://www.microsoftvirtualacademy.com/training-courses/windows-azure-short
 
今後、MVAのWindows Azureセクションには技術系のコンテンツも順次追加されて行く予定です。お楽しみに。
 

クラウドと輸出管理規制 – 経産省通達で解釈が明確に

クラウドと輸出管理規制に関して新しい通達が出ました。

これまで、国外のクラウドサービス利用による情報の保管が外為法上の輸出管理規制の対象になるのかどうかの解釈が、必ずしも明確ではありませんでした。つまり、特定技術情報を保存することが外為法上の「輸出」にあたるのかどうか、というところが曖昧だったのです。

6月21日付けで経済産業省が出した通達(施行は9月1日から)で、この部分の解釈が明確化されました。

「輸出注意事項25第14号 外国為替及び外国貿易法第25条第1項及び外国為替令第17条第2項の規定に基づき許可を要する技術を提供する取引又は行為についての一部を改正する通達 (日本)」
http://www.jetro.go.jp/notice/announcement/51babdbc01f40

添付ファイル(PDF)
http://www.jetro.go.jp/biznews/attachment/51babdbc01f40.pdf

「情報を保管し利用するためのサーバーを提供するサービス(ストレージサービス)においては、当該サービス利用者が意図するとしないとにかかわらず、国外に設置されたサーバーに情報が保管される可能性がある。
他方で、ストレージサービスを利用するための契約は、サービス利用者が自らが使用するためにサービス提供者のサーバーに情報を保管することのみを目的とする契約である限りにおいて、サービス利用者からサービス提供者等に情報を提供することを目的とする取引にあたらないため、外国に設置されたサーバーに特定技術が保管される場合であっても、原則として外為法第25条第1項に規定する役務取引に該当せず、同条に基づく許可を要しない。したがって、外為法第25条第3項の対象にも該当しない。」

「サーバー上に存在するプログラム(アプリケーションソフトウェア等)を、インターネットを介して、他者がダウンロードすることなく利用できる状態にするサービス(SaaS等)を提供することは、プログラムをサービス利用者にとって利用できる状態に置くことを目的とする取引であり、提供を目的とする取引にあたるため、当該プログラムが特定技術であれば、外為法第25条
第1項に定める役務取引に該当する。」

詳しくは全文を参照いただきたいですが誤解を恐れずに要約すると、

  • PaaS や IaaS を利用する場合は、データの保存先が国外であってもサービス提供者に対する輸出にはあたらない
  • 特定技術にあたるプログラムをSaaS提供する場合は、 役務取引に該当することがある

ということになります。

パブリッククラウドのサービスを利用するに際して、輸出管理規制が気になっていた方もいらっしゃるかもしれませんが、この通達によって解釈が明確になりましたね。

また、Windows Azureは日本リージョンの開設も今後予定されています(こちらご参照)。併せてご検討の上でご利用ください。

米国愛国者法とWindows Azure

クラウドの利用にあたって米国愛国者法(パトリオット法)の影響と懸念は、よく話題に上がります。

先日(5月23日)、Windows Azureの日本リージョンデータセンター開設計画が発表されましたが

日本にデータセンターがあっても米国愛国者法の影響下にあるから…と懸念されるコメントも聞きました。

そこで、今回は米国愛国者法に対する誤解について重要なふたつのポイントをとりあげます。

#詳細な情報は、最後にご紹介している文献などをご参照下さい。ここではBusiness面からWindows Azure利用を検討される方のために、ふたつのポイントに絞って記載しています。

  1. マイクロソフトは米国系企業だから、データセンターがどこにあっても米国愛国者法の対象になる。ー 誤解があります

      • 「米国系企業」または「米国に本社がある企業」が対象、と誤解されがちですが、米国に「存在がある」企業であれば、データの管理や保持をしている限りは米国愛国者法の対象にはなります。情報の存在場所には関わりません。
      • Microsoftは、もちろん米国に存在がある企業ですので、その意味で米国愛国者法の対象にはなります。「米国系企業だから」ではありません。そして、米国に存在がある企業であれば、日本企業でも対象にはなり得ます。

     

  2. 米国愛国者法はクラウド事業者に顧客の情報の開示を強制できる。 ー 誤解があります

      • 米国愛国者法は、テロ行為などの阻止を目的とした法律です。テロ活動にまったく関わりのない一般企業の情報の開示を、この法律があるからと米国政府がクラウド事業者に求めることはありません。
      • この法律は、捜査上の手続きを簡略化するためのものであり、この法律だけで新たにオンラインデータに米国政府がアクセスできるようになったわけではありません。
      • 政府は、事業者に情報提供を請求する際に、顧客にそのことを通知することを基本的に許しています。Microsoftを含むどの事業者でも、請求を受けた場合にはまずお客様に連絡をして許可を求めるように対応するのが一般的です。
      • 日本の国内のデータセンターに対しては、米国政府はきちんと日本の当局と相談の上でプロセスを進めるであろうことは、米国大使館で行われたセミナー参加者による記録でも記載されています(このセミナー、当初参加予定だったのですが、急な日程変更で参加できなかったのです。残念でした)。米国政府が勝手な強制力を持って操作を進めるようなことは、実際にはないものと解釈できます。
参考文献

USA PATRIOT Act and the Use of Cloud Services (Covington & Burling LLP) :

http://www.insideprivacy.com/cloud-computing/usa-patriot-act-and-the-use-of-cloud-services/

USAパトリオット法とクラウド・サービスの利用  質疑応答(上記記事の日本語訳):

http://www.insideprivacy.com/resource_center/Covington%20Cloud%20Info%20and%20Patriot%20Act_Japanese.pdf

インターネット新時代の法律実務Q&A(日本加除出版):

http://www.kajo.co.jp/book/40475000001.html

海外展開時に誤解しがちなクラウドの課題を再考する(マイクロソフト Enterprise Customer Careサイト スペシャルコンテンツ):

http://www.microsoft.com/ja-jp/business/enterprise/ecc/article/cxo1303_global-it-infra.aspx

 

なお、Windows Azureのセキュリティーやコンプライアンスの情報については、Windows Azure トラストセンターのページ(http://www.windowsazure.com/ja-jp/support/trust-center/)をご参照下さい。

 

SaaSがISVのビジネスに起こす変化:マーケティング、ソフトウェア開発、その他(Webinar抄訳)

Windows Azureの製品サイトにpartnersページがあります。

http://www.windowsazure.com/en-us/community/partners/

英語表記/日本語表記の切り替えは左下の言語設定で選択可能です。

このなかの”Learn about it”というセクション(日本語では「詳細情報」セクション)に
“How SaaS Changes an ISV’s Business”というシリーズのWebinarが6本リンクされています。

いずれもビジネス系の方に向けた内容です。今回は最後の6番目、”Marketing, Software Development, and More”の簡単な訳です。

(日本語訳の各セクション末にある数字は、ビデオの経過時間目安です。赤太字は特に関心を持っていただきたい部分です)

以下抄訳

あなたの会社が既存ISVの中でリーダーの位置にいるのなら、製品をどのようにマーケティングするかについはよくご存知でしょう。そうでなければビジネスを維持していけないはずですから。

しかし、Software as a Serviceを売り始めると、SaaS製品のマーケティングは違うということに気付くでしょう。そして、違うのはそれだけではないのです。

製品サポートが変わり、業務オペレーションが変わり、ソフトウェアの開発方法すら変わるのです。これから私は、こういったことについて少しお話します。(0.28)

まずSaaS製品のマーケティングについての話から始めましょう。オンプレミスの世界との明確な違いの一つは、あなたの顧客はオンラインにいること(顧客はSaaSソリューションを探していること)、ですからオンラインマーケティングにより力をいれることは理に適っています。

すなわち、Google AdWordsやBing adCenterのようなサーチエンジンマーケティング(SEM)に注意を払うことになります。また、SEO(Search Engine Optimization)ー あなたの製品が該当分野の検索結果で上位に表示されるように工夫することーにも注意を払うことになります。(1.02)

こういったことは、オンプレミスのソフトウェアにおいても意味があるのですが、オンラインに集中するSaaSの世界では、より重要性が増すのです。(1.11)

もうひとつ覚えておいた方が良いのは、SaaSの世界においてはWebサイトがあなたの企業そのものになるということです。営業リソースを確保できない低価格のSaaS製品の場合は特にそうなります。

質の高いWebサイトを作るために時間とお金をかけることは、大変重要です。(1.30)

あなたのサイトは、潜在顧客がアプリケーションの価値をできるだけ早く感じられるようになっていなければなりません。

ほとんどのSaaSアプリケーションにとって、最初のゴールは無償試用版にサインアップしてもらうことです。そのプロセスはできるだけ簡素であることが必要ですし、潜在顧客に製品の価値をできるだけ簡単に見せられるものでなければなりません。

オンプレミスソフトウェアではうまいデモが必要不可欠であるように、SaaSアプリケーションでは無償試用版で迅速に明確なユーザ価値を提供することが必要不可欠です。(2.05)

これをうまく実施することが、試用版を商談に変えるために大きな役割を果たします。言うまでもありませんが、試用版のユーザのうちのどれだけが有償顧客に変わるのか、がマーケティングと営業のプロセスがどれぐらいうまく回っているのかを測る指標になります。(2.22)

SaaS製品をひとたび販売したら、次はサポートをしなければなりません。SaaSアプリケーションにおける上質の顧客サポートはオンプレミスアプリケーションにおける良いサポートと非常によく似ています。(2.35)

たとえ顧客が、アプリケーションを見つけるところからサブスクリプション購入まですべてをWeb経由で済ませたとしても、問題が起きたときには人と話したいと思うはずです。ですからWebベースのみのサポートでは十分とは言えないでしょう。(2.50)

顧客サポートのもう一つの側面は、アプリケーションがダウンしたときの対応です。すべてのSaaSプロバイダーには障害が起きますー誰も完璧ではありませんーそして、顧客にとっては嬉しくないことですが、たまに起きるダウンタイムは避けがたい事実であるということをたいていの顧客は知っています。

公開しているSLAを守ることはもちろん大事ですが、障害の起きている間、およびその後に顧客とどのようにコミュニケーションをとるか、も重要です。(3.20)

障害の原因と、サービスの復帰がいつになるのかについてオープンかつ透明性を持って顧客にリアルタイムに知らせることが大切です。

あなた自身が顧客だったら何を望むか、を考えてみるのはあなたが顧客に何を提供すべきなのか、を考える際にとても有効なガイドになります。(3.37)

SaaSへの移行は、あなたのビジネスのオペレーション面にも影響があるでしょう – 時には目に見えた形ではないかもしれません。

たとえば、もしあなたがこれまでライセンスを売ってきたISVであるなら、ユーザ単位、月額単位での請求ができるように請求システムを変更しなければいけないかもしれません

そして、顧客が異なれば要望も異なるので、そのシステムには多少の柔軟性が必要かもしれません。請求書を毎月欲しい顧客もいれば、半年ごとに欲しい顧客もいるでしょう。(4.07)

あなたは、SaaSアプリケーションを運用していくための経常費用も負担しなければなりません

従量課金制のプラットフォームでアプリケーションを構築するのは理に適っているといえるでしょう。なぜなら、よりたくさんの費用を負担しなければならない時は、成長によって収入も増えている時ということになるからです。

それでも、運用コストをカバーするのに十分なだけの顧客をまだ確保できない新しいSaaSアプリケーションでも、この費用については計画しておかなければなりません。(4.32)

SaaSがもたらす、その他の大きな変化としては、あなた自身がアプリケーションの稼働に対して責任を持つということがあります。

従来のオンプレミスの製品では、顧客が、自社のデータセンターであなたのソフトウェアを動かしていました。

SaaSの場合は、あなたが外部の複数のデータセンターを使ってソフトウェアを運用することになります。(4.53)

また、ダウンタイムのコストは上昇します。

オンプレミスアプリケーションの場合は、顧客のデータセンターで障害を起こしても、影響するのはその顧客のユーザだけでした。SaaSアプリケーションで障害が起きると、その影響はすべての顧客のすべてのユーザに及びます。

あなた自身がSaaSアプリケーションの運用に精通することがとても重要なのです。(6.18)

根本的には、スキルを持つスタッフと、常に稼働させるべきアプリケーションに求められる可用性への意識を醸成することです。

従来型のISVのほとんどにおいては、このスキルセットは現在の組織にあるものとはかなり異なるものです。つまり変化が必要なのです。(5.39)

SaaSへの移行はさらに既存のISVに対して大きなインパクトを与えます。SaaSを取り入れることは、ISVがどのようにソフトウェア開発をするかという部分も変えるのです。

このインパクトは、SaaSアプリケーションが、自身の管理下にある少数のインスタンス(マシン)で運用されていて、更新が容易であるということに起因します。それぞれの顧客のサイトでインストール済みのコードを変更しなければならない、オンプレミスのアプリケーションの場合とは異なります。

SaaSアプリケーションの更新は、自身が走らせている唯一のコードを変更するだけです。(6.19)

このことはいくつかの重要なことを示唆しています。

最初に、SaaSアプリケーションはほとんどの場合、オンプレミスアプリケーションよりも頻繁に更新がされるということです。比較的容易に更新ができるのですから、新機能を顧客により早く提供しない手はありません。

新バージョンを1-2年ごとに出すオンプレミスのアプリケーションと違って、SaaSアプリケーションは毎月、もしくはもっと頻繁に更新ができるのです。(6.47)

ここから自然に引き出される結論として、ウォーターフォール開発のプロセスはSaaSにはうまく当てはまらず、アジャイルプロセスの方が適合する、ということです。

SaaSが提供する迅速な更新を考えると、長期間にわたる計画と開発というサイクルは適合しないのです。

これまでアジャイル開発を採用してこなかった場合は、SaaSに移行することがきっかけでその方向に向かうことを避けられないでしょう。(7.15)

SaaSを採り入れることは、ISVのビジネスに数多くの面で変化を起こします。

時には、こういった変化が大きすぎて、組織構造を考え直さざるを得ないということもあるかもしれません。(7.31)

その点については、3つの選択肢が考えられます。

最初の選択肢は、SaaSを自社の既存の組織のままで採り入れるケースです。これなら最小限の変化しかありませんので、たいていの企業はここからスタートします。(7.46)

しかし、既存のオンプレミスビジネスと並行して新しいSaaSビジネスを運用していくのは困難でしょう。

オンプレミス製品の方が当面のコミッションをより大きく生むとわかっているのに、どうやって同じ営業担当者に、SaaSも並行して販売させることができるでしょうか?

リリーススケジュールが大きく異なる別々の開発グループをどうやって管理していくのでしょうか?やっていくことは可能です。でも大変です。(8.11)

2番目の選択肢は、SaaSグループを組織の中に新しくつくるものです。(8.17)

SaaSだけに注力した独立グループであれば、このモデルにふさわしいプロセスや評価指標を持つことができるので、1番目の選択肢であげた様々な困難を避けることができます。

それでも、新しくクールな製品を売る新しいグループを組織することで、課題も生まれます。

たとえば、このグループに属する人たちと他の組織に属する人たちとの間で緊張状態が生じることもあるでしょう。(8.42)

こういった緊張状態は、対処していくこともできますーこれは、SaaSへの移行に限らず、新しいことが始まるときには起こりうることですしーでも、ISVによっては3番目の選択肢を選ぶでしょう。SaaS専任の新しい事業部をスピンオフさせるのです。(8.57)

この選択肢であれば、SaaSに関わるビジネス全体を丸ごと新しく作ることができます。魅力的な考え方かもしれませんが、一番大きな変化を伴います。

SaaSを提供するだけのためにすべてのビジネスを二重で持つことが本当に必要ですか?もし、提供するSaaS製品が既存のオンプレミス製品の別バージョンであるとしたら、それでもそうしますか?(9.19)

どこにも唯一最善な解はありません。それぞれのISVが、自社の製品ミックス、顧客、競合などに基づいて、それぞれの道を選択するのです。(9.30)

既存のISVにとって、SaaSを採用することは小さなことではありません。信頼性、スケーラビリティを備えたSaaSアプリケーションを構築するための技術課題もかなりのものですが、SaaSがもたらすビジネス課題は、ずっと大変なのです。

人々とプロセスを変化させることは、たいていの場合ソフトウェアを変更するよりも難しいのです。(9.52)

しかし、たとえSaaSがすべての企業、すべてのアプリケーションにとって合うとは限らないとしても、このアプローチは急速に広がっています― 顧客達は、気に入っているのです。

もしあなたの企業が、今のところオンプレミスのソフトウェアだけに注力しているとしたら、あなたには、ある一つの選択肢しかないことを私は確信しています。

SaaSからの挑戦に対峙する準備を整えておいてください。(10.14)

SaaSがISVのビジネスに起こす変化:平均販売価格の影響 (Webinar抄訳)

Windows Azureの製品サイトにpartnersページがあります。

http://www.windowsazure.com/en-us/community/partners/

英語表記/日本語表記の切り替えは左下の言語設定で選択可能です。

このなかの”Learn about it”というセクション(日本語では「詳細情報」セクション)に
“How SaaS Changes an ISV’s Business”というシリーズのWebinarが6本リンクされています。

いずれもビジネス系の方に向けた内容です。今回は5番目の、”The Impact of Average Selling Price”の簡単な訳です。

(日本語訳の各セクション末にある数字は、ビデオの経過時間目安です。赤太字は特に関心を持っていただきたい部分です)

以下抄訳

SaaS(Software as a Service)が生まれたことにより、企業のソフトウェア販売に多くの変化が起きています。しかし、この変化はそれぞれが完全に個別におきるのではありません。SaaSアプリケーションの平均販売価格が、SaaSビジネスに関わる他の様々なことに影響していることがわかっています。(0.20)

このことを簡潔に考えてみるために、SaaSアプリケーションの平均販売価格を高/中/低という3つのカテゴリーに分けてみましょう。あなたのSaaSアプリケーションがどのカテゴリーに入るのかによって、他の色々なことが決まってきます。(0.37)

たとえば、顧客獲得のコストについて考えてみましょう。平均販売価格が高いSaaSアプリケーションでは、顧客獲得コストも高くなるかもしれません。一つ一つの商談が多くの資金流入につながるのなら、新しい顧客を得るために多くの資金を使うこともできるでしょう。

しかし、もしアプリケーションが中程度の価格であるなら、顧客獲得コストも中程度になるはずですし、低価格のSaaSアプリケーションなら新規顧客のそれぞれの獲得のために資金を使うことはほとんどできないでしょう。顧客獲得コストはかなり低く抑える必要があります。(1.15)

このことが営業リソースの持ち方に直接影響します。平均販売価格が高い場合は、顧客を直接訪問する、外訪の営業リソースを抱えることができます。

中程度の価格の場合は、通常このやり方は許されませんー高くつきすぎます。その代り、電話で対応する内勤の営業リソースを持つということがよくあります。

そして低価格のSaaSアプリケーションの場合は、営業リソースを持つことはたぶんないでしょうー他の方法で販売しなければなりません。(1.46)

このことが顧客との関係に影響します。高価格のSaaS製品を外訪営業リソースを使って販売している企業は、顧客と個人的な関係を築くことができます(そのためにこそ営業リソースを抱えているわけです)。

内勤営業を使って中程度の価格で提供している場合は、電話を通じた関係になります。しかし、低コストSaaS製品の場合は、顧客との個人的な関係が全くないのが普通です。

顧客にとっては、企業はWebサイトそのものですーそれしか見えません。(2.14)

平均販売価格は、SaaS提供のためのユーザトレーニングの選択肢にも影響します。高い平均販売価格で提供している場合は、かなりの数のトレーニングを準備し、提供することが可能です。

このことは、その製品がトレーニングを必要とする程度に複雑でありうる、ということになります。顧客もこの製品の購入には相当額を支払うので、おそらく利用方法を習得するために喜んでさらに投資することでしょう。

中程度の価格で提供する場合は、いくらかのトレーニングを提供することもできますが、低価格SaaS製品はシンプルで、トレーニングも最低限しか必要としないようにあるべきです。それ以上サポートするだけの資金はないからです。(2.54)

こういった違いが、それぞれの価格レベルにおける典型的な顧客層の違いにつながります。

高価格製品は通常、大企業向けに販売されます。製品がもたらす影響力を必要とし、担当する営業リソースがいることを望む組織です。

中程度の価格の製品は通常中小企業(SMB)や大企業の部門が対象となります。

低価格SaaSの場合はSMBや個人が対象となるでしょう。(3.23)

この表をよく見てみると、SaaSの提供が一般的に横の行において一貫性を持つということに気付きます。

たとえば、もしあなたがSaaSアプリケーションを低価格で売ろうと考えていてーつまりあなたは一番下の行に位置するわけですーそれでも外訪営業リソースを持ちたいとか、まとまったユーザトレーニングを必要とする複雑な製品を提供したいと思っているのなら、それはたぶんうまく行かないということです。(3.50)

同様に、もしあなたが高価格製品を提供しようとしていてーあなたは一番上の行にいますーそれをWebサイトを通じてのみ販売しようと考えるのなら、残念な結果を招くことになるでしょう。

大企業は重要で高価格なソフトウェアを人による直接的なコンタクトなしに購入することはまずありません。たとえそのコンタクトが電話越しの会話だけだとしても。(4.12)

ISVがSaaSを最初に考える時には、一番下の行、つまり低価格アプリケーションのみを考えるのが一般的です。

しかしそれは正しくありません。今日ISVは3つのレベルいずれでもアプリケーションを提供して成功しています。

実際のところ、高価格SaaSはISVのビジネスにあまり大きな変化を求めないでしょう。なぜならより大きな資金が入るのであれば、営業のコミッションやパートナーとのビジネス関係への変化がより少なくすむからです。(4.45)

しかし、SaaSプロバイダーがこの表で下に動くのは難しいことに気付くのが重要です。

多くのユーザトレーニングを必要とする複雑なソリューションのような一番上の行に合うように設計された製品の場合、リソースやユーザのコミットメントが比較的小さい下の行のやり方は合わないことになります。

一番上の行のSaaSアプリケーションを作る場合は、製品が営業リソースを通じて販売されることを期待しますが、これは一番下の行に位置するSaaS提供においてはコストが高すぎて実現する余裕がありません。(5.19)

既存のISVにとっては、SaaSの採用は多面的な出来事で、さまざまな種類の変化が求められます。

しかしそれらの変化は個々に独立しているわけではありませんー重要な関連性があります。

その関連性を理解することは、この新しい世界で成功するために欠かせないことなのです。(5.45)

SaaSがISVのビジネスに起こす変化:顧客、課金モデルと収入(Webinar抄訳)

Windows Azureの製品サイトにpartnersページがあります。

http://www.windowsazure.com/en-us/community/partners/

英語表記/日本語表記の切り替えは左下の言語設定で選択可能です。

このなかの”Learn about it”というセクション(日本語では「詳細情報」セクション)に
“How SaaS Changes an ISV’s Business”というシリーズのWebinarが6本リンクされています。

いずれもビジネス系の方に向けた内容です。今回は3番目の、”Customers, Pricing, and Revenue”の簡単な訳です。

(日本語訳の各セクション末にある数字は、ビデオの経過時間目安です。赤太字は特に関心を持っていただきたい部分です)

以下抄訳

SaaSへの移行によって既存のISVのビジネスがどれだけ変化するか、ということはどれだけ強調してもし過ぎることはないぐらいです。最初は、SaaSモデルへの対応はテクノロジーの変化にすぎないように見えます。それぞれの顧客のデータセンターで走らせていたソフトウェアではなく、今度は外部のデータセンターに配置される共有ソフトウェアを開発するだけであると。(0.18)

実は、このテクノロジーの変化はあなたの会社の広範囲にわたって影響を及ぼします。ターゲットとする顧客、製品の価格体系や、収入の把握方法といったことさえも含むあらゆることが変化する可能性があるのです。(0.32)

まず対象顧客の変化から見ていきましょう。SaaSアプリケーションによって、今ターゲットにしている市場の顧客へより効果的にリーチできるかもしれません。(0.40)

たとえば、CRMアプリケーションはクラウドと非常に相性が良いですから、すでに選択肢があります。多くの顧客はSaaSを望みますから、オンプレミスでCRMアプリケーションを販売してきたISVはSaaSバージョンも併せて販売するようになっているかも知れません。

マイクロソフトがその一例です。Dynamics CRM Onlineは、オンプレミスのCRMに加えて提供されています。(1.03)

また、SaaSアプリケーションを開発することで新しいターゲット市場の顧客にリーチしようとしているかもしれません。(1.10)

たとえば、SaaSアプリケーションはオンプレミスのアプリケーションよりも通常初期価格が低く提供されます。ですからISVは、既存アプリケーションのSaaSバージョンを利用して、価格に敏感な顧客層にアプローチすることができます。

このアプローチをとることは簡単ではありませんーSaaSによる低価格オプションは、既存オンプレミス製品市場とカニバリゼーションを起こすかもしれませんーそれでも、やってみる価値はあります。(1.35)

本当のところを言えば、新興のSaaS企業との競争によって、このオプションをとらざるを得ない状況に置かれることになるかもしれません。他の人に自分のランチを食べられる前に自分で食べよう、というのは理に適っていると言えるでしょう。(1.47)

他にも、既存の企業がSaaSを利用して全く新しいビジネスに参入するということもあるかもしれません。この場合は、ターゲットとなる顧客はこれまで通常追っていた市場と全く違うものになります。Google Appsはこの代表的な例です。GoogleはSaaSを使って、マイクロソフトがメールとデスクトップソフトウェアで確立したポジションに攻撃をしかけました。

どのケースの場合でも、SaaSを採用するとターゲットとする顧客層が変わるので、狙いをつけている市場について明確に認識していることが非常に重要になるのです。(2.24)

そして、どんな顧客をターゲットとする場合でも、SaaS提供の価格はオンプレミス製品とは違ったものになることでしょう。(2.32)

パターンは様々ですが、SaaSアプリケーションの価格は通常次にあげる3つのオプションに分類できます。

サブスクリプション:1ユーザあたり、1か月あたりの課金など

特定の単位:トランザクション単位課金やストレージの利用量単位など

無償:無償オプションにはフリーミアムモデルも含みます。これは、基本的な製品は無償で提供され、上位機能だけが課金されたり、広告に支えられたりするモデルです。(3.02)

SaaSアプリケーションのタイプや市場の違いによって、このモデルの選択は異なるでしょう。アプリケーションによっては、複数の価格モデルを組み合わせることもあるかもしれません。

それでも、現在もっとも多くのケースではユーザあたり月額で課金する、サブスクリプションベースの課金体系が採用されています。このアプローチでは、顧客が前払いをする場合には値引きを提供するのが一般的です。つまり、11か月分の料金を前払いすれば、そのSaaSアプリケーションを12か月使えると言った形です。(3.38)

ユーザはこの形式を好みますー誰でも値下げは好ましいわけですがーそして、このオファーに顧客がよりコミットするので、離脱(チャーン)リスクを下げます。前払いによってSaaSプロバイダーのキャッシュフローも改善し、収入の速い成長に貢献します。(3.55)

実際のところ、計上する収入がオンプレミスとSaaSでどれだけ時間の経過に伴って違ってくるのかは、精査する価値があります。(4.04)

従来のオンプレミスアプリケーションでは、収支は最初はマイナスですーアプリケーションの開発のためにお金を使うからです。でも出来上がったら、ライセンスを売ることで新しいアプリケーションはすぐにかなりの金額の収益を生み始めます。

もちろん、この収入は不意に落ちることもありますーたとえば世界的な金融危機があってーそしてすぐに復活したとしましょう。従来型のライセンスモデルでは収入のカーブはかなり凸凹したものになるでしょう。この例が示しているように。(4.39)

SaaSアプリケーションの場合、最初はよりコストがかかるのが普通です。特に初めてのSaaSアプリケーションを開発する際には。新しいモデルをどのように扱うのか、学ぶことになります。

顧客が獲得できるまでの間もアプリケーションを稼働させるためにいくらか支払う必要があります。これも初期投資の増加につながります。(5.00)

サービスが利用可能になると、SaaSアプリケーションの収入は通常ゆっくりですが滑らかにに推移します。

たとえばもし金融危機があったとしても、SaaSアプリケーションから得られるサブスクリプション収入は安定しています。

新しいサブスクリプションの獲得はストップするかもしれませんが、既存のサブスクリプションからの収入は継続して入ってきます。

収入の成長が遅いことにより、SaaSアプリケーションの収支が損益分岐点を迎えるのに時間がかかるのは避けられない事実です。

しかし、長い目で見ればSaaSアプリケーションはオンプレミスアプリケーションよりも長期の収入をもたらす力を持っています。資金の流入がただ遅いというだけなのです。(5.40)

典型的なSaaS価格体系がもたらすもう一つの変化は、収入のトラッキング方法です。従来のパッケージソフトウェアの場合は、どれだけの数のライセンスが売れたのかを追うことで評価するのが一般的です。

SaaSアプリケーションは通常このような価格付けではないので、違う評価指標が必要です。よくある方法の一つとしては、「Monthly Recurring Revenue (MRR=月次更新収入)」です。(6.06)

MRRは、毎月繰返し発生する収入の合計で構成されます。1回限りで発生する費用やサービスは含みません。

たとえば、ユーザ単位月額サブスクリプションモデルで販売されているSaaSアプリケーションの場合は、その月のサブスクリプション収入の合計額がMRRとなります。

カスタマイズ費用のような、繰返し発生するのではない費用は、ここには入りません。(6.29)

SaaSモデルの採用は、テクノロジーの変化にとどまりません。このアプローチで成功を収めるためには、ターゲット顧客が変わり、製品の価格付けが変わることを理解する必要があります。

さらに、企業として収入をどう評価するか、その収入がどのくらいの速さで得られるのか、についても考える必要があります。

SaaSでも多くの収入を得ることは必ず可能です。

そのためには、SaaSのビジネスモデルの実際について慣れなければなりません。

他には選択肢はないのです。(7.06)