2011年7月アーカイブ

この記事は「Amazon Web Serviceを活用してきたSaaS事例からの学び」の続きです。（スライド：9〜12にあたります）

youRoomは、SonicGardenとして創業した後に企画・開発したサービスです。かなり実験的な要素の濃い事業として開始したのを憶えています。元々はSonicGardenのプログラマたちとのフリーディスカッションの中で、こういうツールがあると良いよねという話をしていて、その話をしていたのが@mat_akiの夏休み前で、その休み明けには、なんとプロトタイプが出来ていたので、じゃぁそのままローンチしようといって始まったのでした。ただローンチするだけでは自分たちがやる意義がないので、幾つかの仮説をもって事業を始めています。このように事業の内容そのものを実験だと考えて、仮説と検証をやっていたのは、今でいえばリーンスタートアップでした。つまり、どんな新規事業も実験みたいなものなんです。

現在はそこそこ多くのユーザにも使って頂いているyouRoomですが、youRoomをローンチする際に立てたコンセプトは、いかにお金をかけずにマーケティングと運用を行うか、ということでした。お金をかけなくても広めて運用することができるのではないか、という仮説です。実際は、そこまでうまくいってる訳ではないですが、実際の現金という意味ではゼロ円で、口コミとフリーミアムで拡大することが出来ました。多少は広告宣伝費をかけてもよかったかな、とも思いますが、お金をかけずともこの程度までいけるという指標はとれました。

また、SKIPの経験から当初からマルチテナントで動かすことは当然でしたが、それに加え「セルフサービス」というのもポイントにしていました。というのは、アメリカ出張時にクラウドのことを話すと、向こうの人たちは「セルフサービスのことね」と言うんですね。つまり、営業が丁寧に売りに行くのではなくて、ユーザ自身によって選択して購入するのです。確かに、クラウドであれば可能だし、そうしなければクラウドである本当の価値は出せないように思います。youRoomでもフリーミアムなビジネスモデルにして「セルフサービスできる」ことを重視しました。

youRoomは運用のコストも殆どかけないようにするため、当初はHeroku（RubyのPaaS）のフリープランを使って運用を開始しました。そういえばHerokuもフリーミアムでセルフサービスでしたね。Herokuはオープンな技術を採用しており、便利なツールも沢山あり、プログラマが運用まで行うDevOpsスタイルの我々にとっては非常にマッチしていたプラットフォームでした。今でもそう思っています。しかし、youRoomは最初にローンチしてから半年ほどで、AWSへの移行を行うことになりました。

HerokuからAWSへの移行を行った理由は２つ。１つは、Herokuそのものは安価で、かつスケールに柔軟なため、コストパフォーマンスもすごく良いのですが、Railsのアプリを動かしているだけなら、の話で、実際に色々な要望に対応したりしていくと、本体のアプリだけではできないことが増えて関連サービスを使わなければいけなくなるのですが、Herokuの場合、それがオプションになっていて割と割高に感じました。もう１つの理由として、そうした関連サービスや運用の自動化なども含めたAWSの環境を我々が作るだけのAWSに関するノウハウをもっていたということです。自分たちで自分たちに必要なHeroku相当まではいかないまでも、それなりのプラットフォームを作れるようになったので、AWSに移行することにしたのです。

これまでAWSでyouRoomを運用してきて、もっとも大きかった障害が、先日（2011年4月21日）のAWSのus-east-1リージョンにおける障害の影響でした。この障害はニュースにもなり、西海岸に拠点をおくHerokuやFoursquareなどのウェブ企業に影響を与えることになりました。youRoomもその影響で使えないようになってしまったんですが、他社のサービスが復旧までに最大４日ほどもかかっている中、youRoomはなんと１時間程度で復旧まで行いました。その辺りの詳しい経緯と内容は以下のブログに詳しく書かれています。

• youRoomにおいて発生した 2011/4/21 のAWSの障害について技術的な観点から - mat_akiの日記


• AWS障害による影響を小さくするための設計(2011/4/21の障害を踏まえて) - よかろうもん！

SonicGardenでの運用の考え方の根底には、以下の２点があります。

• 障害は必ず発生するので、どれだけ速く復旧するかに注力する


• 運用にかかる人手は、人力を雇わずに自動化でカバーする

一つ目は、AWSを信用しすぎないということです。どんなハードウェアのサーバを買ったとしても必ず物理的に壊れることはあるのと同じで、AWSだからといって壊れることはない、ということはないのです。であれば、それを見越した上でどうやったら速く復旧できるかにポイントを置いたシステム構成にするのです。この辺りは、一般的なシステム構成の設計となんら変わらないと思います。ただ、いかに速く復旧するか、のためにはAMIの仕組みは必須であり、それができるAWSが優位であることは間違いないと思います。

二つ目は、運用のサービスレベルを確保したり、運用作業が発生しそうなときに、人手を用意するというのは最も短絡的で簡単な解決方法ですが、そうして人海戦術にはいってしまうと、大手との価格競争（という名の削り合い）には勝てなくなります。私たちは、足りない労働力は知恵でカバーすることをまず考えて、徹底的に自動化を行います。その際には、APIが充実したAWSに優位性があると言えます。

私たちは、ある意味どっぷりとAWSにすでに漬かっていたので、HerokuからAWSへ移行を行いましたが、これからどちらにしようかというので悩んでいて、かつ、使う言語がRubyであるなら、Herokuから始めた方がきっと学習コストも低く、運用の手間も少なくていいと思います。

あわせて読みたい：Amazon Web Serviceを活用してきたSaaS事例からの学び あわせて読みたい：Ruby版PaaSの"Heroku"で無料Railsホスティング環境を手に入れよう

この記事は「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事例からの学び

SonicGardenでは、Amazon Web Service（AWS）を色々な形で活用してきました。オープンソースソフトウェアをAWSでクラウドのSaaSにしてみたり、HerokuというRubyのPaaSからAWSに移行してみたり。これまでSonicGardenで得てきたAWSのノウハウについて、社団法人コンピュータソフトウェア協会（CSAJ）のAWSセミナーで話してきました。

発表スライドはこちらです。

今回お話ししたのは以下の３つのケースです。次からのエントリーで、内容について補足していきたいと思います。

1. オープンソースをAWSでクラウド化
2. 自社クラウドサービスのAWSへ移行
3. サービス型の受託開発でAWS活用

リーンスタートアップを知ってから出会う人たちに勧められた本の一冊。リーンスタートアップの原点ともいうべき本、ということで読みました。

本書で説明するのは「顧客開発モデル」という名前の事業プロセスです。これからの時代、新規事業を立ち上げたり、スタートアップしたりしようとするアントレプレナーにとって、従来の企業の中でやっているような「製品開発モデル」を参考にした「正しく製品を作る」ことを前提にした事業プロセスに従うことは失敗への道であり、「正しい顧客と市場を見つける」ことを目的とした「顧客開発モデル」である、という考え方です。

どうしても起業や事業創造というと、アイデアとモノ作りに重点を置いて考えてしまいがちです。特に技術者が立ち上げる場合「良いものを作れば売れる」と考えがちです。しかし、本当に重要なのは「誰に」「どうやって」「いくらで」売れるのか、ということです。その顧客と市場の方を中心に据えた「顧客開発モデル」のプロセスであるべきだ、というのが本書の主張です。

本書では、その「顧客開発モデル」がなぜスタートアップにとって大事であるかを述べた後、そのプロセスである「顧客発見」「顧客実証」「顧客開拓」「組織構築」の４段階について、各章に分けて詳しく説明している。筆者の経験談を交えての説明は納得感が高く、リアリティのあるものになっています。

p36より引用

市場と顧客を発見するという作業の性質からして、あなたが何度か失敗することは間違いない。そのため、製品開発モデルと異なり、顧客開発モデルでは４つのステップそれぞれで正しく完了するまでに何度か繰り返しがあることを想定している。この点についてはしばらくの間、その意義をよく考えてみるだけの価値がある。なぜなら、「そのことから学ぼうと考えているなら失敗してもかまわない」というこの哲学が、本書の提示する手法の根幹をなしているからだ。

この引用には100%同意できます。新しい事業をするということは、計画通りにものごとを進めて正解というのではなく、仮説検証を繰り返しながら徐々に正解を探っていくようなものになります。そうであるならば、一発勝負でなく、失敗の許容を前提としたプロセスにすべきです。「顧客開発モデル」では、繰り返しを重視しています。

ここからは私の意見ですが、大企業の決裁文化において新規事業が産まれにくいのは、決裁を通すため計画の時点で叩きまくってリスクをなくそうとする割に、計画が承認されたらその後は計画通りかどうかしかチェックしないからだと思っています。少人数のスタートアップであれば、決裁などチームの合意でしかないので非常にスピーディで、かつ、途中変更などいつでも可能なのです。

エンジニアが陥るのは「良いもの作ったら売れる」幻想だし、大企業が陥るのは「良い計画したらその通りになる」幻想なんですね。

本書の原書は出版されてから相当時間がたっていることもあり、ソーシャルメディア活用に関する言及が薄いのは仕方がないですが残念なところです。おそらく、今執筆するとするならば、ソーシャルメディアによるマーケティングが変わってきていることはふれることになるでしょうし、「顧客開発モデル」とソーシャルメディアの関わりについては考えてみたいところです。

また、この本が執筆された当初に比べて、私が感じるのは、おそらくもっとスタートアップはリーンに（無駄なく）いけるような感覚があります。本書のプロセスが参考になるのは間違いないですが、人も時間もまだかけすぎているのでは、と感じました。

本書の邦題は「アントレプレナーの教科書」ですが、間違いなく言えるのは、教科書通りにやったって、スタートアップがうまくいくわけがないということです。必要なのは、その場その場で自分の頭で考えて進むしかないということです。ただ、もう一つ言えることは、教科書を読んだことがある人かそうでない人がいるとしたら、読んだことがある方が圧倒的に有利だといことには違いありません。もし今「良いものを作ったら売れる」と考えているスタートアップの方がいるならば、読んで損はないと思います。とはいえ、経験してないと納得できないこともあると思うので、実は経験者が読んだ方が納得感は大きいかもしれませんね。

あわせて読みたい：リーンスタートアップで小さく始めよう

この１〜２年、転職であったり起業であったり人の動きが激しいような気がします。私の知人も、大手企業でエリートだったのに起業したり、大手メーカーからソーシャルゲームの会社に転職したり、というケースがあります。そうした人たちを見ていて、人の働く動機には色々ある中で、いくつかパターンがあるのかなと思い、人は何のために働くのかについて考えてみました。

私なりに人が働くモチベーションとして、以下の４つのパターンがあるのではないかと考えてみました。（これは私の知り合いからの類推なので、べつに専門的で正確な話ではないです）

・「アントレプレナー」タイプ
・「クラフトマン」タイプ
・「サラリーマン」タイプ
・「サポーター」タイプ

アントレプレナータイプの方にとっての仕事に対する動機は「夢」が大きく影響しているように思います。何か成し遂げたいビジョンがあり、自分の仕事の結果によってどのような世界にしたいのか、という思いをもっています。この人たちは「どんな仕事をするか」ということについては、拘りをもっておらず、ビジョンを成し遂げられるのであれば、たとえ嫌な仕事であってもやってしまいます。経営者ですね。「どう仕事をするか」よりも「何をするか」に重きをおくので、プロダクトオーナーもこのタイプが向いているかもしれません。

クラフトマンタイプは、職人です。達人プログラマを目指すような「職」に対する動機が強いと思います。自分のスキルアップを何より重視し、業務時間外でも勉強会に参加したり、オープンソースに参加したり。その源泉は、自分のスキルアップです。この人たちにとっては「どんな仕事をするか」ということが重要です。技術者としての誇りを持っており、マネージャをするとなったらモチベーションが萎えてしまいますよね。それは、自分の目指すスキルセットと違うからでしょう。自らの腕を磨いて「俺ってすげー」感を味わうことが幸せです。

アントレプレナーとクラフトマンの共通点は、その「夢」や「職」のためであれば、業務の枠を超えて活動をするという点です。アントレプレナーとクラフトマンの違いは、アントレプレナーの人たちは、世の中にある問題に着目します。もしくは、問題そのものの定義を行うことを大事にします。一方で、クラフトマンの人たちは、用意された問題を解くことを得意とします。難題であればあるほど燃えるのが職人です。だからアントレプレナーとクラフトマンが手を組むことはスタートアップには良いコンビになるのです。アップルの創業者の二人のスティーブは、まさしくこのコンビでした。

サラリーマンタイプは、わかりやすくサラリー「金」のために働く人たちです。そういうとイメージが悪いかもしれませんが、この人たちには、仕事そのものよりも大事な価値のある「家族」や「趣味」をもっており、それを充実させるために、仕事をして糧を得ているのです。なので「どんな仕事をするか」については、多少希望はあったとしても、人事異動など基本的に会社の指示に従います。当然、モチベーションとしては出世をすることで、給与があがることは大きな動機付けになります。良い意味でプロフェッショナルですし、大きな組織で役割を遂行するためには必要な人材になります。真面目な人が向いています。

クラフトマンとサラリーマンが同居するような業種では、時に軋轢が起こります。クラフトマンを目指すエンジニアは、日々自分の時間を使って勉強をしたりするのに対し、サラリーマンはそこまでの気持ちをもっていません。お互いの価値観が違うのに、同じように評価や働き方が決まってしまうと、マイノリティの方が居心地が悪くなるのは当然です。その組織を去る理由としては十分かもしれません。

アントレプレナーとサラリーマンの共通点は、どんな仕事も厭わないという点です。モチベーションは違えど、清濁併せ飲めるのがこの人たちです。ただし、スタートアップのタイミングでは共存しない方が良いでしょう。ミッションに人生の全てをかけるアントレプレナーと、そうではないサラリーマンではうまくいくとは思えません。

最後のサポータータイプは、「誰と（誰に）仕事をするか」を重視する人たちです。ラブではなく、アガペーとしての「愛」をもって仕事にあたります。一緒に働く仲間を助けたい、提供するサービスで喜ぶお客様の笑顔が見たい、困っている誰かの役に立ちたい、といった感情が、最大の働く動機付けに繋がります。重要なのは「誰か」という点で、仕事の内容や仕事の仕方については受け入れていく度量があります。究極的には、ボランティアやNPOにいきつくのかもしれません。しかし、応援したい人がいないと頑張れません。

クラフトマンとサポーターの共通点は、期待に応えることに対するモチベーションが非常に高いことです。難しいことや困っていることがあったら、なんとしても解決したいと頑張ります。この両名はプロジェクトで一緒にいる場合、非常にうまく力をあわせてくれることが多いです。両極端ではあるのですが、だからこそ気が合うのかもしれません。

アントレプレナーとサポーターは、お互いにお互いを必要とする関係であることが多いです。スタートアップのタイミングでは、アントレプレナーだけでは霞を食って生きていかないといけなくなってしまうので、実務を担当しアントレプレナーを支えるサポーターがいることでうまくいくように思います。ソニーやホンダの創業期のそれぞれの２人はこの組み合わせにも思えます。

アントレプレナーとサポーターの行動原理は、右脳的で感情によって奮い立つことが多い一方、クラフトマンとサラリーマンは左脳的で、非常にロジカルに行動します。

「夢」「職」「金」「愛」と、それぞれのタイプのモチベーションの源泉を考えてみましたが、必ずしもどれかということはなくて、自分の中にいくつものタイプが共存しているのが人間だと思います。おそらく、子供の頃に考えていた「夢」というのは「職」であることが多く、「本屋になりたい」「ケーキ屋になりたい」というのが根源的な働くモチベーションだったんではないかと思います。そこから、色々と経験をすることによって「世界を変える」ことが重要になったり「家族との時間」が重要になったりと変わってきたんでしょう。

アントレプレナータイプの人は、それまで属していた企業がもつビジョンや理想に共感していれば、組織の中であっても一生懸命働けるかもしれませんが、その組織と自分の考えている世界観と異なってきたとき、起業という選択肢を選ぶように思います。なぜなら、このタイプはどの組織に属しても違和感を感じながら生きているからです。世界中に自分とまったく同じビジョンをもつ人はいないので、いつかは自分のビジョンのためにスタートアップすることになるのでしょう。

クラフトマンタイプの人にとっては、仕事の内容が自らが極めたいスキルと違ってきた時に、組織を離れることを考えます。マネージャをしたくないから偉くなりたくないと嘯くプログラマもいます。組織を離れるとき「どういう仕事をするか」が重要なので、自らがやりたい仕事がある場所に転職するという選をするでしょう。その方が手っ取り早いからです。クラフトマンにとって、天職と思える職業に出会い、それを一生の仕事にできるとしたら最高でしょう。

会社における評価の仕組みとビジネスモデルは強い関連性があります。もし技術者のままで評価される側に居続けるなら、既存の評価の仕組みを変えることはできないということに気付かないといけません。既存の組織にいながらにして、その組織を変えていきたいと思うならば、まず技術者であることを捨てて何にでもなるという覚悟が必要でしょう。組織を変える一番の難しさは、偉くならないと組織は変えられないけど、偉くなるためには自分自身を変えないといけない、そうするうちに組織に染まって変えられなくなる、ということに尽きるでしょう。もし、クラフトマンタイプで、組織があわずに「職」を極めたいというのであれば、早めに転職を決意した方が良いかもしれません。

転職か起業か踏みとどまるか、自分の中にある働くモチベーションの源泉を、よく見極めてから行動するのが良いと思います。

当たり前のことなんですが、100人月のソフトウェア開発があったとして、100人投入したからといって1ヶ月で出来る訳がないですよね。なのに、そのパラメータは可変だと信じている人がまだまだ多いです。しかも、1人月のバラツキをなくすために生産性の低い方に揃えるなんて馬鹿げています。私はソフトウェア開発で最も重要なパラメータは「期間」だと考えています。かける工数の時間ではなくて、あいた時間も含めての期間です。

SonicGardenでは月額定額のサービス型の受託開発を行っています。その詳しい説明は別の機会にしますが、ポイントは月額定額という点です。月額定額なので、可変できるパラメータは「期間」だけになります。そのポリシーの背景には以下の考え方があります。

・アジャイル開発のボトルネック
・Publickey「納期を半分にしてくれ、金なら出す」

大規模なソフトウェアを作るには、大人数が必要と考えがちですが、これも違うと感じていて、ソフトウェア開発の場合、沢山の人数がいたからといって、価値を産むソフトウェアが作れるとは限らないと考えています。大量に使うかどうかわからないプログラムを作るだけなら、沢山の人がいれば良いかもしれませんが、そこにかけるだけのコストを超える価値を産み出すかどうかを基準においた場合、沢山の人は必要ありません。サッカーや野球をするのに、沢山の素人がいるチームがトップクラスのプロチームに勝てるかというと、決してそんなことはないのと同じで、ソフトウェア開発にも適正な人数があって、それ以上の人が必要なのではなく、高いレベルのソフトウェアを作るには高いレベルのプログラマが必要で、そうでないソフトウェアの場合はそれなりのプログラマで良いのではないでしょうか。

SonicGardenでは、ソフトウェアはお金や人手をかければ速く良いものが出来る訳ではないと考えています。私の考えるメタファとしてのソフトウェアの開発は、植物や野菜を作ることに似ていると感じています（ソフトウエア開発は何に似ているか？）。どれだけ沢山の栄養や人手をかけたからといって、花が咲いたり果実が実るまでの期間を短くすることは出来ません。ソフトウェアも、お金や人手を必要以上にかけるよりも、時間（期間）をかけることの方が良いソフトウェアを作ることができると考えているのです。ちなみに、ここで前提にしているのは、設計者やコーダーといった分業をしない、プログラマがすべての工程を見るようなアジャイル開発です。

例えば５日で出来るとプログラマが見積もったソフトウェアを、本当に５日間で缶詰して作るか、もしくは週に最大１日のペースで５週間かけて良いとしたら、どちらが良いソフトウェアを作ることができるでしょうか？おそらく５週かけた方が良いソフトウェアができあがると思います。ソフトウェア開発という仕事は、対象のドメインを理解したり、プログラミングの技術を磨いたり、本来は「学び」の多い仕事です。設計書通りに作るのであれば、短期間でも良いかもしれませんが、本当に良いソフトウェアを作ろうとするならば、作業時間は短くても制作期間を長くとった方が良いものができます。週１日の残りの４日間を他の仕事や勉強にあてたとしたら、５日後のプログラマのスキルより、５週後のスキルの方が良いものを速く作れるようになっている筈です。

SonicGardenの月額定額のワークスタイルは、プログラマの稼働を100%にしなくても成立するビジネスモデルにしているので、この長期間かけて少しずつ作るということを実現しています。少しずつと言っても、中間に入る無駄を極力なくすことで、高い生産性を実現しているので、出来る量に驚いて頂くお客様が多いです。お客様にとって、本来プログラマを雇って内製するとしたら、この時間はかかるが工数をかけない、ということは実現できません。稼働が空いてしまうからです。かといって、今までの人月の会社に発注しても、空き稼働を嫌がるので結局高くついてしまうことでしょう。私たちのソリューションは、一定以上のお金をもらわない、というものです。

よく聞かれるSonicGardenの名前の由来は、音速のように素早く決断し迅速にプログラミングしていく一方で、出来上がるものは性急に完成させるのではなく期間をかけてじっくりと育てていくというソフトウェア開発のスタイルからきています。私たちが提供するソフトウェアは、スローソフトウェアなんです。スピードを求めるのは、何度も繰り返しながら良いものにしていくためです。また私たちのソフトウェアを作る庭から様々なサービスを育てていきたいという想いも込めた名前が「SonicGarden」なんです。