2011年6月アーカイブ

ソフトウェアを開発していくにあたり、ユーザからのフィードバックは非常に重要です。自分たちの作っているものをより良く修正していくための重要なインプットになります。ユーザからのフィードバックを想定しないで、最初に計画した通りのものを作ったところで、独りよがりになってうまくいく訳がありません。リーンスタートアップでは、早い段階で市場に出して、ユーザからのフィードバックを受けつつ改修していくスタイルを薦めています。うまくフィードバックをもらいつつユーザを増やしていくことができれば、市場と提供者で良い関係を構築していくことが出来ます。

では、フィードバックをもらえるようになったとして、ユーザに対して、どのように応えていくのが良いのでしょうか。

私たちがソフトウェアを世に出して、ユーザからフィードバックをもらってきた経験から、ユーザからのフィードバックには２種類あると感じています。ひとつは、バグの報告やインタフェースの改良などといったフィードバック、もうひとつは、ソフトウェアの機能そのものについての要望です。

バグの報告やインタフェースの改良についてのフィードバックに対しては、出来るだけ速いスピードで対応し、そのフィードバックに対して返事をしてあげることが重要だと考えています。バグの報告をしてくれるようなユーザは熱心なユーザであり、そのようなユーザからのフィードバックに対して素早く対応することで、いちユーザから「ファン」になってくれる可能性があるからです。このときに重要なのはスピードです。

SonicGardenでは、DevOpsということで、開発と運用を一つのチームでやっていますが、ユーザサポートについてもプログラマがするようにしています。ただリーンスタートアップで人手を少なくしているからという理由で、そうなっているに過ぎないのですが、実際のところは非常にうまくいったと感じています。ユーザからのフィードバックを直接プログラマが受け取ることで、時には厳しい意見を受け止めなくてはいけない時もありますが、一方でユーザからの喜びの声も直接受け取ることができるということは、モチベーションに強く影響します。自分の作ったものを、使ってくれる人から直接声を聞くことができるというのは、モノ作りが好きな人はわかると思いますが、想像以上に励みになります。そんな訳で、プログラマ自身がユーザサポートをしているので、バグ報告やちょっとした改善のフィードバックに対して、自分たちの判断で対応して、リリースまでしても良いようにしています。結果として、それが一番スピーディな対応に繋がっています。

もう一つのフィードバック、そのソフトウェアの機能そのものについてのフィードバックの扱いは慎重にしなければいけません。ユーザの要望は、自分たちの置かれた背景の中で「あれば良いな」と考えるものをフィードバックしてくれます。そのソフトウェアの上級者になれば、上級者にとっての使いやすい機能を要望してくるかもしれませんが、それは初心者にとっては複雑にしてしまう機能の要望かもしれないのです。機能が増えれば、ユーザにとって複雑になるし、保守性も下がってしまいます。リーンスタートアップの中で、簡単に「機能を増やす」という選択肢をとることは、リーンさを無くしてしまう第１歩です。とはいっても、ユーザからのフィードバックを無視する訳にもいかないですし、要望を取り入れることはしていきたいものです。

SonicGardenでは、そのような場合にどうやって取捨選択の判断をしているのかというと、ソフトウェアのビジョンに沿っているかどうか、で判断することが多いです。ソフトウェアのビジョンとは、そのソフトウェアを使うユーザにどうなって欲しいか、というソフトウェアそのものが提供する価値で起きる未来像のことです。そのフィードバックの要望を取り入れることは、ソフトウェアのビジョンの達成に貢献するのか、という観点で考えます。なので、私たちはフィードバックを頂く際に、「なぜそう思ったか？」ということをよく確認させてもらっています。他のソフトウェアを真似するだけの機能を作っても仕方がないからです。

例えば、youRoomの場合は、以下のようなビジョンをもっています。

新しいコミュニケーションの形を提案するyouRoomでは、グループにおける秘密や階層をなくし、文書よりも対話を重視し、駆け引きよりも協調しあえる、そんなコラボレーションスタイルの変革を目指しています。

グループの情報共有の仕方にメーリングリストを使うと、メールのメタファである手紙のやりとりに近くなってしまい、お互いに連携し合っている感じが無いのが不満でした。その解決をするためのツールとしてyouRoomを開発しました。よって機能を追加するにしても、その先に見えるものが、このビジョンにそったものであるかどうかは、重要になってくると考えています。

フィードバックを受けて次々と沢山の機能を付けていくことも一つの戦略ですが、それだと体力勝負になってしまい、大手企業には勝てなくなってしまいます。リーンスタートアップを目指すのであれば、機能はシンプルなままでも競合優位性を保てるようにアイデアを絞る方が得策だと思います。そのためにも、ソフトウェアにビジョンをもって開発するというのも良いかもしれません。

リーンスタートアップ"Lean Startup"という言葉を最近知りました。SonicGardenでは、アジャイル・Ruby・クラウドを実践してきましたが、開発だけをしている訳ではなくて、スタッフ一丸となってマーケティングも経営もしていたりして、それらを包括した言葉ってないのかな、と思っていたのですが、どうも「リーンスタートアップ」がうまくフィットしていると気付きました。

とはいえ、リーンスタートアップを学んだ上で実践している訳ではなくて、日々の試行錯誤の中で得たスタイルが、たまたまリーンスタートアップになっているということだけなので、正解かどうかはわからないので、自分たちなりのリーンスタートアップを考えてみました。（この正解かどうかわからないけど実践しているという感覚はアジャイルという言葉に対する感覚に似ていますね。）

リーンスタートアップを理解するのにわかりやすいスライドは以下にあります。平鍋さんが翻訳されブログで紹介されていました。

ここからは、私の考えるリーンスタートアップです。リーンスタートアップとは、ウェブサービスの新規事業を立ち上げる際の成功確率を上げるための考え方であり、手法であり、ベストプラクティス集です。新しいビジネスを成功させるということは非常に難しく、様々な知見が必要なはずです。幸運にも成功体験をした人は、次々と事業にとりくみ、その経験を深めていくことができるでしょう。しかし、新しいビジネスが成功する確率は非常に低く、よく「センミツ」つまり千個あれば３つしか当たらないと言われる世界です。

特にウェブサービスの場合、ただ起業をして八百屋を始めるのとは違い、ビジネスとしてスケールできることを目指しており、かつ、ユーザ自身も気付いていないニーズを発見し、新たな価値の提供とそれに伴う取引を産み出すことを目指しています。イノベーションですね。それは、非常に不確実性が高く、タイミングもあり、成功のための方程式など無い世界です。

一度、幸運にも成功した人だけがノウハウを蓄積できるのでしょうか。スタートアップにチャレンジして、運悪く失敗してしまったとして、そこでの経験やノウハウは、価値のないものでしょうか。いいえ、決してそんなことはなく、真剣に考えて行動し、取り組んだ経験をもってすれば、おそらく、もう一度チャレンジをしたならば、一度目のスタートアップよりもきっと上手に進めることができる筈です。それが経験です。

しかし、多くのスタートアップでは、デッドオアアライブ、生きるか死ぬかの世界だと思われています。一度でも失敗したら次のチャレンジが無いと思われています。実際、一昔前に起業すると言えば、そうだったかもしれません。もし実際に失敗した後の再チャレンジの機会がないとすれば、そこで得た経験がどこにも引き継がれないとしたら非常にもったいない話だと思いませんか。

もし、スタートアップをするのに、一度の失敗で人生の全てを失うほどのリスクを負わずに、しかも、一度や二度の失敗の経験を積むことで、成功の確率を高めていき、何度目かのチャレンジの果てに成功まで辿り着けるのだとしたら、スタートアップにもっと科学的に取り組むことができるし、起業リスクをマネジメントできるようになります。そうした考え方がリーンスタートアップです。

今、ウェブサービスを始めるとしたら、どれほどのコストがかかる、つまり、どれだけのリスクを負う必要があるでしょうか。ソフトウェアを構成する基盤のほぼ全てがオープンソースで提供されているので購入費用は必要ないし、実行環境もAmazonなどのクラウドを活用することで最初の段階では非常に低コストで運用が可能です。開発をするためのノートPCさえあれば、オフィスをもたなくてもできるはずです。そう考えると、ほぼ人件費だけで始めることができます。

このように、スタートアップに対するリスクを最小限にすることが出来れば、まず始めることが容易になります。スタートアップに対する投資を下げることができれば、恐れる失敗も小さくて済むことができます。小さく始めて、小さな失敗と小さな成功の中から、事業の経験を積み、学びを得ていくのです。リーンスタートアップでは、事業の見直しをすることを「ピボット」と呼び、継続する事業の繰り返しの中で、方向性を見直し続けて成功まで進めます。

このピボットをするかどうかが非常に重要で、最初に描いた事業がそのままうまくいく訳がないので、次へ次へと切り替えていかないといけません。日本の例で言えば、mixiも最初は求人サービスを展開していましたし、DeNAだって携帯オークションなどを手がけていました。ある時点でピボットした訳ですね。この最初に計画した通りにいかないというのは、ウォーターフォールのダメな点と共通します。受託開発で完成さえすれば良いようなビジネスであればウォーターフォールで良いかもしれませんが、リーンスタートアップではアジャイルであることは必須です。

既にある程度大きくなった組織や企業で新しい事業をするのに難しいのは、この計画に重きを置きすぎるというところがあります。スタートアップは正解がないので、成功するまでピボットを繰り返しながら、次々と内容を変えていかないといけません。しかし、組織をあげて新規事業をしようとすると、まずは計画に対する総意をとらないといけなくなります。その合意をとった関係者が多くなればなるほど、計画の変更が難しくなるのは容易に想像できます。企業の中で新規事業を成功させようとするのであれば、人件費の予算だけを確保して、その内容については口を出さないというのが、おそらく良いでしょう。ただ、そのために計画を通すのが大変、という鶏タマゴの問題があるので、うまくいかないのでしょう。

リーンスタートアップでは、繰り返しの中の学びを重視します。リーンスタートアップは低コストであると誤解されるかもしれませんが、そうではありません。確かに、一度にかける金額は低コストかもしれませんが、何の為に低コストにしているのかといえば、長く続けるためです。繰り返しの中の学びと経験を積んで成功の確率をあげようとするには、それなりの期間が必要になります。チームでスタートアップを長く続けることで、そこから成功を導きだすことができるのです。これは、アジャイルが速く安くのファストフードだと勘違いされているのに似ています。アジャイルも学びを重視し、その繰り返しが重要になるので、長く続けることを前提としています。簡単な例を出すと、１億の資金があったとき、３ヶ月で成功させるか、３年で成功させるか、と言えば、明らかに後者の方が成功の確率が高いと思いませんか。

リーンスタートアップであれば、すぐに始められます。今、サラリーマンや学生であれば、スタートアップする前に、ベンチャーキャピタルからお金を入れると支配されるとか、資金がないとプロモーションできないとか、色々と心配することが沢山あるかもしれません。しかし、まず経験もない人にVCも投資しません。そんな心配は投資が入る位まで注目を集めてからで十分です。最初に必要なのは、スタートアップに関する経験と学びです。それを得る為にも、リーンスタートアップで小さく始めることが大事になります。サラリーマンをあと２年経験してから、と考えるよりも、リーンスタートアップで２年経験した方が、経営者を目指す人にとって価値あるものになるでしょう。

リーンスタートアップであれば人件費くらいで済むとはいえ、その生活費を稼がずに資金がショートするまで続けるのは不安というのは理解できます。SonicGardenでは、日々の仕事しながらも、新しいチャレンジが出来るようなビジネススタイルを構築しました。その一つがサービス型受託開発であるカスタムクラウドという手法です。人月の受託開発をしないので、それぞれの個人の中で投資と受託をバランスもつことが出来るのです。この辺りの詳しい内容については、またの機会に書きましょう。

私たちがSonicGardenで目指しているビジョンは、次々とウェブサービスのスタートアップを立ち上げ経験し、社員が小さく失敗してもそこで人生が終わり、ではなく、そこで得た学びを組織として蓄積していき、何度もチャレンジできるような母体となる企業です。SonicGarden自体は一つのウェブサービスに特化するのではなく、ウェブサービスを産み出すアントレプレナーたちのトライブでありたいと考えています。SonicGardenは、リーンスタートアップを実践するための組織です。SonicGardenでは、私たちの文化と価値観に共感してコラボレーションしてくれるスタートアップや、ジョインしてくれるアントレプレナーを募集しています。まずはソーシャルメディア上で交流しましょう。

ここ数年で、クラウドのプラットフォームが広まることで、従来のSIビジネスの市場が影響を受けるということが起きてます。そこで多くの大手SIerが採った戦略は、自社でIaaSのようなクラウド環境を作るといったものです。自社が持つデータセンターに仮想化のエッセンスを加えて「クラウド」の冠を付けて売るというもので、あまり目新しさはありません。

今、それでは付加価値が薄いということで、PaaSに手を出そうとしているところもあるかと思います。ゼロから作って徐々に上にのせていくという戦略です。こういう戦略は、非常にお金を持った大手企業で、かつエンジニアが採りたい戦略に感じます。

なぜならば、これはGAEやAWSなどのプラットフォームが日本上陸したときに、その中で使われている技術を勉強して、自分たちでゼロから同じレイヤのプラットフォームを作ろうという発想ですよね。おそらく技術的には可能だし、技術者としてのプライドもあるのかもしれませんが、正直、その領域でこれから戦おうとしても追いつきこそすれ、追い抜かすことは難しいのではないでしょうか。WindowsやMacOSXを見たからといって、各社が自社製のOSを作ろうなんて思わないはずです。ここは思い切って、すでにあるプラットフォームの上でどう戦うかを考えた方が良いように思います。黒船を作るのではなく、操船技術をまずは磨くのです。

お金や資産を持たないスタートアップにとっては、そもそも、そんなゼロから作る戦略はとれるはずもなく、すでにあるプラットフォームにうまく乗れるように考えます。そして、その土壌をベースに、さらなるプラットフォームを作ろうとする訳で、そうするからこそベンチャーが大きくなれるチャンスがある訳です。ゼロから作って同じレイヤのものを作ろうとしても、先行者には勝てないですし、品質で戦おうとしてもユーザの多い大手には体力勝負で勝てません。

しかし、既にプラットフォームがあるのであれば、その上にプラットフォームを作ろうと狙えば、勝ち目は産まれます。大手になった企業は「イノベーションのジレンマ」に囚われがちですし、「破壊的イノベーション」というのは最初は品質が低くても市場には受け入れられます。米国で起きてる企業の世代交替はこうして起きているように思いますし、あちらの人たちは乗っかるのが上手な気がします。

まじめで優秀なエンジニアほど勉強家だったりするので、新しい技術などがあれば、自分のものにしようと勉強します。そして、最近の新しい技術はクラウドの企業から産まれていることが多いです。勉強すること、それ自体はとても大事なことなのですが、中の技術を知れば知るほど、自分たちで同じようなものを作ってみたくなってしまう症候群にかかってしまうのかもしれません。私もエンジニアだったので、その気持ちはとてもわかります。

そういえば、Javaでサーバサイドを作り始めた頃に、SIerが各社でオレオレフレームワークを作っていましたよね。デジャブを感じます。

【告知】
弊社SonicGardenでは、AWSと対抗するのではなく、なるべくAWSに乗っかって、その上でのビジネスを考えて実践してきました。その経験をふまえて、ビジネス視点で事例紹介をさせて頂くイベントがあります。よかったらご参加ください。
ソフトベンダのためのクラウド活用ビジネス事例紹介～事例から学ぶクラウド活用事業構築のポイント～

ちかく今のオフィスを出ていく時期がせまっているので、移転先のオフィスを探して契約するか、それとも全員がノマドと在宅にしてしまうか、考えてみました。

「仕事するのにオフィスはいらない (光文社新書)」という本が注目されたように、確かにインターネットやデバイスの進化によって、オフィスを持たなくても仕事をすることが出来るようになってきました。

筆者の会社（SonicGarden）でも、ノマドワークは実践しています。自分たちで使っているツールは、Google AppsやDropbox、youRoomにPivotalTracker、githubなど、すべてクラウドで提供されたものを使っていますので、ノートパソコンさえあれば、どこからでも仕事できるようにしています。

実際に、3.11大震災の直後は、一週間ほどスタッフは出社せずに自宅や実家に戻り、そこから業務をするということをしましたが、まったく問題なく日常の業務は遂行できていました。また、スタッフの一人はバンクーバーで２ヶ月ほど滞在しながら、今の仕事をしてもらうということをやってみましたが、Skypeも駆使しながら、まったく問題なく仕事はできていました。逆に「会社に来なくても良い」としたことで、より一層仕事に励むようになりました。会社に来る、ということが仕事をするという認識でいてしまうと、ともかく会社に来さえすれば給料が出るもんだと勘違いしてしまうのかもしれません。会社に来なくても良い、というのは思った以上に大変です。

そうなると、まさしく「仕事をするのにオフィスはいらない」状態になってしまうんですが、ちょっと違和感がありました。ノマドでは、すでに決まった仕事はできるんですが、新しいアイデアから動くものを産み出すという機会が起きにくいと気付きました。まだきっちり決まった仕事になっていないような、ふわっとしたアイデアの状態から、仕事にしていくようなプロセスの場合に、バラバラにいるのでは難しい。

ライターなどのフリーランスで個人でやっている方にとっては、ノマドなワークスタイルは集中できる時間と場所で仕事ができるので良いと思いますが、私はチームを持っていますし、チームで仕事をしていて面白いのは、仕事の途中の相談をしている中での雑談であったり、一緒に休憩をしている中で閃きがあったりして、そこから新しい事業やサービスの種が産まれることです。

それも、時間を決めてミーティングすれば良いかというと、そうではなくて、アイデアがおりてくる瞬間なんて決まってないので、決められた時間の中でのミーティングでは新しいアイデアは出てこないんですね。だからこそ、一緒の場所で、隣や近くで働いている様子が見えれば、いつでも声をかけれるし、その話の中でアイデアを共有できます。

また、ホワイトボードの存在も大きいですね。いつでもすぐに立ち上がって、近くにある壁に絵を描いて共有しながらディスカッションできる、これも大事なポイントです。ランチの途中に思いついて、ナプキンにメモをする、なんてのと同じことです。物理的にバラバラにいる中で、お絵描きを共有するのに便利なツールは沢山あるのですが、ふわっとした状態で、すぐに手軽に、ということになると、ホワイトボードにはかないません。ただ、それも自分たちのチーム専用で、すぐに使えるようになっていないと意味がないですね。アイデアを思いついてから、ホワイトボードの使える会議室を予約なんてしてたら、もう消えてしまいます。

そういう意味で、当社では「会議室と執務室を分けない」というのも、立ち上げた時からずっとやっています。まぁオフィス自体が小さいので、分ける余裕がないというのが実状ですが、これが以外と良かった。壁際にプログラマ席が用意されていて、そこで普段はプログラマ達は仕事をしているのですが、その部屋でお客様やパートナーを呼んでの打ち合わせをしたり、営業状況の会議をしたりします。プログラマには筒抜けになるのですが、逆にそれがよくて、なんとなく話の内容を聞けたり、興味ある話題だったらすぐに会議に参加できる訳です。（SonicGardenのオフィスの写真）

当社の場合、自社でクラウドのサービスをお客様に提供させてもらっているので、自分たちでも最大限クラウドを活用するようにしています。その結果、社員は誰も会社のオフィスに出社しなくても、仕事ができるような環境をつくることができたんですね。一方で、そこに行き着いたその先が見えてきた訳です。オフィス→ノマド→オフィスとまわって２週目なので、オフィス2.0とでも呼びましょうか。

それぞれが一人だけで、決められた仕事を遂行するということだけであれば、ノマドで集まらない仕事の仕方で十分だけど、一方で、チームでアイデアを出し合ってクリエイティブなものをつくっていこうとした際に、コラボレーションする場が必要だと判断しました。そのコラボレーションのための場としてのオフィスは、事務所や執務室という使い方や感覚ではないし、そのオフィスに来ることで仕事をしている、というような意味ではない。あくまで、チームで新しいものを産み出す為に集まるためのオフィスです。

そういう訳で、SonicGardenは新オフィスを賃貸して移転することにしました。決まったら公開するので、ぜひ遊びにきて下さい。あと、狭いですけどシェアしたいスタートアップかフリーランスがいれば共有しても良いかな、と思っています。

翻訳者の渋川さんから献本頂きました。ありがとうございます。

最近は、FacebookやTwitterのおかげもあって、企業の枠を超えた勉強会やコミュニティが沢山産まれています。コミュニティに参加するには、特に難しいことはありません。一方で、コミュニティを作り出し、運営していくことは、そう簡単ではありません。

私も、アジャイルに関するコミュニティの運営に携わったりしましたが、そこには明文化こそされていませんが、どうすれば良いかノウハウがあったように思います。この本では、そうした暗黙知として伝えられてきたコミュニティの運営に関する知見が書かれています。

この本で書かれているコミュニティ運営の根底に流れる考えに、「信用貯金」（social capital）というものがあり、コミュニティに人を引きつける原動力は一体感であり、その一体感が「信用貯金」によって回る信用経済の物差しになる、というものです。（余談ですが「social capital」を「信用貯金」と訳してくれてるのはアジャイル界隈の人にとっては嬉しいですね）

そこには、貨幣経済とは別のモチベーションで活動する人たちがいて、それこそが人間の本質ではないか、次の社会を形成するものではないか、と感じさせてくれます。ダニエル・ピンクのモチベーション3.0にも通じるし、昨今のソーシャルネットワークが起こしつつある革命にも通じるように思います。次の時代の働き方の息吹を感じることが出来ます。

この本の著者による、コミュニティを運営する「コミュニティマネージャ」の仕事とは、「世の中に変化をもたらそうとする協力しあう世界中のボランティアたちに対して、それを達成することを『可能にする』のが仕事です」ということです。もし、コミュニティマネージャを目指すのであれば、読むと多くの知見を得られるでしょう。

先日、とあるお客様のところで、講演をさせて頂く機会を頂きました。

普段の講演では、アジャイルやRuby、クラウドといった技術についての話のご依頼は多いのですが、今回は、異業種ということで、あまり専門的な話をしないことにしました。

ただ、ふと考えてみると、まだ私にそれほど偉そうに話せる実績はないので、自分が辿ってきたキャリアと、その中で起きた出来事や考えたことなどをお話することにしました。

「技術」について話をするのではなく、「自分」について話すのはとても緊張もしましたし、その資料を作るにあたっても、「人生の振り返り」をしないといけなくて、自分自身にとって貴重な体験になりました。

こうしてふりかえったことで、今の私にとって次に選ぶ道の指針が見えたように思います。