この記事は「Amazon Web Serviceを活用してきたSaaS事例からの学び」の続きです。（スライド：5〜8にあたります）
SonicGardenの元々のきっかけは、社内向けのSNSをオープンソース化したことから始まっています。2005年に自社用に開発した社内SNSを2008年に”SKIP”という名前でオープンソース化し、オープンソースにしたソフトウェアを使ってビジネスにするために、AWSを活用してSaaS化することにしました。そのSaaS事業をするのがSonicGardenの最初の事業であり、創業のきっかけでした。
SKIPをSaaS化したサービスということで、SKIPaaSと名付けたのですが、その特徴は「シングルテナント」と「月額定額」という点でした。オープンソースにしたSKIPのバージョン1系は、社内向けに作っていたということもあり、複数の会社で同時に使うようなアプリケーションのアーキテクチャーになっていませんでした。なので、必然的に、SKIPを利用する会社ごとにAWSのインスタンスを用意しないといけませんでした。しかし当時の私たちはその点を逆手にとって、メリットであると訴えることにしました。AWSのインスタンスが会社毎に分かれるシングルテナント方式であるため、きちんと他のお客様のデータとは分離して管理しているので安心だという風にマーケティングしました。しかも、会社毎にインスタンスを分けているので、大企業にとっては割高に感じてしまうユーザ課金ではなく、月額定額のビジネスモデルにすることが出来るというのもメリットとして打ち出しました。
そうした発想に行き着いたのは、元々私たちはSonicGardenを立ち上げる前の2004年頃からずっと「仮想化技術」に注目しており、ハードウェア構成を気にしないアーキテクチャを気に入っていて、さらに「ハードウェアそのもの」も自分たちで持たなくて済む方法を模索していた中で、「仮想マシン」のホスティングサービスとしてAWSに出会ったのです。なので、シングルテナントにすることは、アイデアとしては自然な成り行きだったし、当時、その「仮想マシン」のホスティングができるのは、AWSだけだったのが、AWSを選んだ理由です。
オープンソースで公開されているアプリケーションの多くは、自分でインストールすることを想定しているため、シングルテナントで動作することを前提としたものが多いと思います。オープンソースを活用してSaaSにする際の課題は、シングルテナントにせざるを得ない場合が多いということに尽きます。SKIPaaSも、シングルテナントにしたことでセキュリティ上の見かけは良かったのですが、やはり運用していくには、非常に非効率でした。まだAWSを活用していたので、事前にAMIを作っておいて、契約する会社毎にコピーをしていけば良いので、その点は効率的ではあったのですが、バージョンアップをしていく際の手間は相当大変でした。何十社と契約が進めば、それだけのインスタンスに配置されているアプリケーションに順次バージョンアップ作業をしていくというのは、いくらAPIで自動化しているからといって骨のおれる作業だったわけです。
そこで、私たちは大きなPivotの決断をしました。マルチテナントのSaaSにするために、SKIPのソースコードをゼロベースから作り直すというPivotです。SKIP2と名付けて、それにあわせてビジネスモデルもイチから考え直しました。SKIP2での開発上の重要なコンセプトの一つに、バージョンアップなどを含めた「運用のし易さ（Ease Of Operation）」を置きました。そして、それを実現するために、チームの構造も運用担当者とアプリ開発者という垣根をなくし、開発も運用も「プログラマ」が行うというスタイルに変更しました。一般的に言われるDevOpsという形に必然性から辿り着きました。
オープンソースを開発していたときからの大きなパラダイムシフトは、品質管理の考え方です。１度のリリースのタイミングを重視するという考え方（Point of Sales）は、製造業的にはよかったのですが、クラウドのような形で日々提供し続ける、しかも、バージョンアップし続けるという場合には、リリースそのものよりも日々の運用を重視するという考え方（Point of Use）に変えないといけなかったのです。私たちは身をもってその教訓を体験しました。おそらく、パッケージベンダーがクラウドに乗り出して最初にはまる落とし穴かもしれませんので、気をつけると良いと思います。
次のエントリでは、youRoomを題材にしたHerokuからAWSへの移行について書きます。
あわせて読みたい：Amazon Web Serviceを活用してきたSaaS事例からの学び
