スピーカーは株式会社ソニックガーデン代表取締役社の倉貫義人（くらぬきよしと） 様。同社は「納品のない受託開発」という月額定額＆成果契約で顧問プログラマを提供するビジネスモデルで注目を集めています。 本講演では、倉貫様が多くのスタートアップや大企業の新規事業を顧問CTOという立場からサポートしてきた経験から見えてきた、成功と失敗を分けるポイントをご紹介いただきます。本レポートでは講演内容を再構成してお伝えします。 
倉貫 義人様
倉貫：私が創業し、代表を務めているソニック・ガーデンという会社は、創業から7年で300件以上のスタートアップや大企業の新規事業立ち上げの相談を受けてきました。その中で、いくつか「このケースは失敗やすい」という知見が溜まってきましたので、本日はそのお話をさせていただきます。 最初に、自己紹介と、起業までの経緯をお話します。私は1974年に京都で生まれ、10歳のころにプログラミングを始めて、そこからずっとプログラミング一筋のキャリアを歩んできました。大学では学生ベンチャーを立ち上げてプログラミングの仕事を受けており、大好きなプログラミングでお金をもらえるなんて楽しくて仕方がありませんでした。 
とはいえ、一度くらいは大企業にも入ってみようと、新卒では大手のシステム開発会社に入社しました。しかし、これが楽しくありませんでした。典型的なウォーターフォール型の開発スタイルで、要件定義、実装、テスト、納品と進むわけですが、私が参加する実装のタイミングでは多くのプロジェクトが炎上していることが多かった。上流では顧客との関係性は良かったので、下流に進むほど顧客とのギャップが開いてしまうウォーターフォール型の負の側面が原因でした。
倉貫：そこで私は2000年頃からアジャイル開発の導入に取り組みます。いきなり社内を変えることは難しいですから、最初は社外でアジャイルを普及させる活動に参加して、徐々に社内に輸入していくスタイルです。 アジャイルはスピード感のある繰り返しですから、例えば最初の要件定義で100個機能があったら、10個、20個どんどん作っていって、3ヶ月ほど経つと50個くらい優先度の高い機能が完成しているのです。すると、お客様との間で必ず出てくるのが「残りの50個の機能は要らないんじゃないか？」「他にこんな機能を足すべきじゃないか？」といった議論です。 でもお客様は「要件定義にあった機能はすべてつくってもらわないと検収できない」「新しい機能はぜひほしいけど費用は追加できない」と答えるわけです。これはお客様が悪いのではなく、「一括請負の受注開発」というビジネスモデル自体がアジャイル開発とものすごく相性が悪いことが原因です。 
そこで私は社内異動をして社内向けツール開発をする部門に入りました。目論見通りここはアジャイルと相性がよかった。発注者が同じ会社の同僚ですからダイレクトに反応も見られますし、アジャイル開発を回すことで部内のメンバーのスキルもどんどん上がっていきます。 ところが、社内の別プロジェクトが炎上して人手不足になると、どんどん私のチームから人が引き抜かれて行ってしまうのです。これには参りました。チームを守るには、自分たちで独立して稼ぐようにならなければならないと覚悟を決めました。
倉貫：ちょうどそのタイミングで会社が合併し、社長が交代し、偶然にも新社長に直談判するチャンスが訪れました。新社長は「すぐにでも子会社をつくってやってみろ」と言ってくれたのですが、現実問題としては合併直後に新子会社設立は難しく、ひとまずは新しくつくる社内ベンチャー制度の１期生というスタイルで起業にこぎ着けました。条件は3年間以内の黒字化です。 ようやく、社内ベンチャーとして起業するわけですが、自分も、自分のチームメンバーも全員プログラミングしかやったことがなかったので、ビジネスのことが何もわからないことに気付かされました。 そもそもプログラマーは、仕様に基づいてバグがでないシステムを開発するのが仕事ですが、「システムを開発」そのものは1円も売上も利益も生んでいないわけです。そのシステムが納品後にお客様の手元で稼働することでモノやサービスが売れて、初めてビジネスとしての売上や利益が上がる。 
そうなると、「仕様どおりに正しくつくる」よりも「その仕様が正しいのか？」「その仕様の根拠となっているビジネスは正しいのか？」の方が重要であることこに気づくわけです。 例を挙げれば、自動車のような製造業であれば「お客様が車を買う瞬間」が最高の価値のある状態であり、そこからは価値が償却されているだけの状態になります。一方で、ITサービスのようなビジネスモデルはまさにサービス業、例えばタクシーのようなもので「お客様が使いたいと思った瞬間」に最高の価値がないと意味がないのです。 この気付きによって、私の中でソフトウェア開発に対するパラダイムシフトが起こりました。「絶対バグを出さない」から「出してもすぐ直す」へ。「絶対サーバーを落とさない」から「落ちてもすぐ復旧」へ。「予見的なデータ設計」から「データは変わる前提」へ。といった具合です。
倉貫：社内ベンチャーは外注費をすべてカットして内製化することで、2年目の終わりには単月黒字を達成していました。そろそろ社長との約束どおり子会社化して独立へ、と話が進むタイミングでまた親会社が合併し、社長が変わりました。 上部からは「体制が変わったので子会社化はあと2〜3年待ってほしい」と言われましたが、そのときの私たちのチームは、既に大企業とのスピード感が開きすぎていていたし、何よりチームの仲間と一緒に続けて行きたかった。そこで私がソニックガーデンを創立し、元の会社から事業を買い取るMBOという形で2011年、5人のメンバーで創業しました。 
バーチャルオフィスのデモ ソニックガーデンは「納品のない受託開発」という新しいビジネスモデルが特徴です。これまで大企業でウォーターフォール型の一括受託開発をやってきたメンバーだからこそ、その欠点をすべて裏返すように考えたらここにたどり着くことができました。 まず、ベースになるのが「定額制の顧問CTO」というサービスです。顧問弁護士や顧問税理士が居るように、テクノロジーを専門に扱う顧問CTOが居てもいいんじゃないかという発想です。定額制ですから、いわゆる「人月」換算はされません。お客様からの依頼に対して、毎週、何らかのアウトプットは出しますが、それがソースコードや動く成果物である必要はないのです。 そうなると客先に行く必要もないですし、コミュニケーションもビデオ会議でいい。ソニックガーデンの社員数は39人に増えましたが、17都道府県に点在していて、本社オフィスはありません。ウェブ上のバーチャルオフィスで事足りています。勤怠管理も進捗管理も評価もノルマもありません。それでどうやってみんな働いているかは、1月に出た書籍「管理ゼロで成果はあがる」に詳しく書いているのでぜひお読みください。 
倉貫：ここでようやく、「新規事業を失敗させてしまう7つの罠」に入ります。ここでお話するのは、あくまで「原理」です。原理とは辞書の定義によると「必ず成功するわけではないが、外れたら必ず失敗するもの」です。また、起業家の視点と経営者（大企業の出資者）の視点の2種類に分かれますので、まずは起業家編からご紹介します。 1. プロダクトオーナーが不在がち せっかく熱意と能力のあるリーダーが居ても、とにかく忙しくて新規事業のために時間を割けない、という状態をよく見ます。リーダーの時間が確保されていることは成功のための必須条件です。 2. 事業のコアをアウトソースしようとする よくある依頼に「Twitter的なものをつくって」というのがあります。もちろん予算をいただければつくれますが、それは単なる投資家であって起業家ではありません。良い例としては「アズママ」というベビーシッターのマッチングサービスがあるのですが、これは人脈やノウハウはあるのだけれど、開発能力がないのでソニックガーデンにサポートして欲しいという案件で成功しました。 3. 一度やれば成功するという謎の自信 とにかくつくって世に出せれば売れる、という思い込みも危険です。売れるかどうかは顧客や市場が決めるものです。特にCGMを使った「クックパッドの○○版をつくってほしい」という依頼が多くありますが、ユーザーに支持されるのは簡単なことではありません。 4. 現場や顧客にヒヤリングに行かない インプットと経験がないと事業は進みません。机上でアイデアの話を何度しても堂々巡りになりますので、とにかくユーザーのところに出向いて観察やインタビューをしないと解像度が上がりません。 5. うまくいかない理由を開発のせいにする 開発会社の立場からこれを言うのは勇気が要るのですが、サービスがよければシステム開発は後回しでよいのです。弊社の顧客でも、最初は知人のフリーランスのエンジニアに依頼して本当に簡素なシステムで始めたサービスが、どんどんユーザーが増えてきたのでスケールできるシステムに組み直したい、という依頼がありました。システムがビジネスのスケールの足かせになってから依頼にくるのでもいいのです。 6. クックパッドの○○版がほしい 自分がやろうとしている新しいサービスを一言で定義できないのならば、自分でそのサービスの本質が掴めていません。 7. 優先順位を決めない、全部欲しがる やりたいことを全部やるためのチームやリソースを確保できたとしても、そこに達成してしまったらそこがゴールになってしまいます。それより「今のチームでできること」をすぐにでも始めて、積み上げていくべきでしょう。 
DBIC代表 横塚 裕志
倉貫：続いて、経営者（大企業の出資者）の視点から見た「新規事業を失敗させてしまう7つの罠」をご紹介します。 1. たくさんの関係者を入れる 新規事業のチームは兼務前提で足りないくらいがちょうどいいです。経理、総務、営業、開発、マネージャーなど大企業の原理で細分化した人材構成は不要です。 2. 進捗管理をしっかりとする 新規事業は、開発が進んでもいなくても、売上を1円でも上げるまでは進捗はゼロです。0を1にするまでに中間はないので、進捗管理をする意味はありません。 3. 結果よりも制約を重視させる 大企業に居た頃、1ユーザ数百円というビジネスなのに、取引先に対して信用保証の会社を入れて信用保証確認をしろ、という指導を受けました。クラウドサービスなのですから、支払いがなければサービスを止めればいいだけなのに。 4. 既存事業と数字で比較する 0を1にすることを、既存事業と比較することはできません。 5. 新規事業の狙いが他にある 大企業にありがちですが、相談をよくよく聞いてみると「イノベーション部門ができたので」とか「会社の記念事業なので」といった理由で新規事業を始めようとしている場合があります。他の思惑を入れてうまくいくほど、新規事業は甘くありません。 6. ロジカルにリスクを排除する 世の中をロジカルに考えると、たいていのビジネスは「やらなくていい」ことになってしまいます。例えば、「LINE」はSMS全盛期の時代に生まれたわけです。アイデアを否定する方法などいくらでもあります。でも、それを乗り越えてやったからこそ今の「LINE」があるのです。 7. 事業ごとにチームを組み替える 失敗は財産です。失敗しても、同じチームで何度も別のプロジェクトに挑戦する方がよいです。アメリカでは失敗した人のことを「経験者」というらしいです。失敗は立派なキャリアなのです。 
質疑応答の模様
倉貫：ソニックガーデンでは新規事業を「部活」と呼び替えたことで、突然うまくいくようになりました。先程お話したとおり、顧問CTOという稼働時間で評価されないビジネスモデルなので、以前は社員に対して「空いた時間に新規事業を考えて欲しい」と依頼していたのですね。そして新規事業である以上、私も進捗管理したくなってしまう。投資なので予算も気になってしまう。 ところが、これを「部活」と呼んでみたら、「投資」は「部費」に変わり、福利厚生という位置づけになったのです。福利厚生ですから、お金を出しても回収できなくて当然ですし、失敗してもいいし、何より楽しく遊んでもらえたらいい。 そこから生まれてきたサービスのひとつが「イシュラン」です。もともとは社員の知人に乳がんの患者さんが居て、なかなか良い病院が見つからないと困っていたところから始まっています。 同じような悩みを持っている人は他にも要るだろうということで、最初は縁のあった愛媛県の病院データを集めてDB化して、次は静岡県、といった具合に3年ほどかけて日本全土をカバーしました。すると、SEO効果がグンとあがって、医療系のマーケティング会社から声がかかって、広告費用をいただけるようになったのです。もしこれが「新規事業」だったら、私はたぶん1年目くらいで終わらせていたと思います。 
他にも「ラクロー」という勤怠管理システムが部活から生まれています。もともとソニックガーデンは勤怠管理もしないし、オフィスもないので全員パソコンのログを勤怠管理システム代わりにしていました。 社労士や弁護士にも聞いてみたところ、もし労基署が監査に入ったときに勤怠の証拠として最終的にチェックされるのがまさにパソコンのログなんだそうです。だったら最初からログを使った勤怠システムにするというのは合理的で、経産省や厚労省からも適法のお墨付きをいただきました。こうやって、部活の時間に自分たちの勤怠管理システムをつくろうとしたら、結果的に外販できるような商品になったというわけです。
倉貫：ソニックガーデンは、楽しい仲間と好きな仕事を長く続けたい、という思いで始めています。また受託開発や一括請負にありがちな、依頼側と受注側の不幸なすれ違いをなくせるように、月額定額制の顧問CTOというビジネスモデルを確立しました。 ですから私たちはお客様に対して「つくらない提案」ができるようになったのです。お客様のビジネスの目的を叶えるのに最適なものが、既存のウェブサービスの組み合わせできるならば、わざわざお金をいただいて開発する必要はないのです。
他のDBIC活動
他のDBICコラム
他のDBICケーススタディ
一覧へ戻る
一覧へ戻る
一覧へ戻る
このお知らせをシェアする
