「永遠のベータ版」と競争に勝つためのアイデア：自社プロダクト立ち上げ奮闘記（3）

自社プロダクト「Backlog（バックログ）」の作成の過程を、企画段階からご紹介しております当連載も、3回目を迎えます。

　前回は、「ペルソナに機能とユーザービリティを決めてもらおう！」ということで、実際に使用したペルソナ（仮想ユーザー）をご紹介しました。現在に至っては、自社のノウハウとして、新規事業の立ち上げなどの受託開発のヒアリングに「ペルソナ・シナリオ法」を用いることもあります。

　さて、今回は、自社プロダクト「Backlog（バックログ）」の公開です。とうとう、ペルソナ（仮想ユーザー）ではなく、本当のユーザーとのセッションが始まる「リリース」をターゲットにお話しいたします。

Web 2.0からアイデアをいただきました

　すでに言葉だけは「キャズム」*を超えた感のある「Web 2.0」というキーワード、皆さんご存じのことと思います。実のところ、筆者はパネルディスカッションなどで、「Web 2.0ってどうですか？」というような問い掛けをいただいたりするのですが、キーワードだけが先行してはやってしまっている気がするので、キチンと答えることがなかなか難しく、「Web 2.0」という言葉を発音することさえ、少し恥ずかしさを覚えています。

　さて、その「Web 2.0」ですが、単なるバズワードにするには、もったいないくらいのアイデアが詰まっています。ロングテール、永遠のベータ版、オープンソース、集合知、マッシュアップ……。どれも、この業界にいるのであれば、一度は耳にしたことがあるのではないでしょうか？

　「Backlog（バックログ）」では、「永遠のベータ版」のアイデアをいただきました。とはいえ、いま運用している「Backlog（バックログ）」はベータ版ではありませんが。

永遠のベータ版

　「永遠のベータ版」は、すでに説明の必要性がないくらいの言葉になっていますが、いま一度、説明を入れておきます。

　Web 2.0の世界では、未完成のサービスを公開して、「これは未完成ですよ！」と周知徹底し、多くのユーザーに使ってもらって、そのリアクション、フィードバックを取り入れサービスをもっと良くしていくという、「永遠のベータ版」という手法が頻繁に使われています。

　「永遠のベータ版」における大事な部分は「ユーザーの声を聞き、さらに良いサービスに、さらに便利に、いつまでも進化する」というところです。筆者は、「ユーザーの意見をどんどん取り入れるため、完成品にはならない」というのが、「永遠のベータ版」の本質だと思っています。

　ところで、「永遠のベータ版」というと、「未完成なので不具合出ても許してね！」といったニュアンスで誤解を受けがちだと思います。しかし、それは本質ではありません。「未完成なので不具合出ても許してね！」という「永遠のベータ版」の使い方は、逆に「おしゃれな言葉を借りた言い訳」と判断した方がいいでしょう。

　また、「永遠のベータ版」には競争に勝つためのアイデアも隠れています。

　例えば、他社とのスピード競争に勝つためには、「ベータ版」として素早くリリースすることが優位になることがあります。素早くリリースすると、これから出現する競合サービスよりも先行して「熱意のあるユーザー」を多く獲得できます。そして「熱意のあるユーザー」に使ってもらい、ユーザーからアイデアや、競合サービスの動向などをいただけたりするのも、スピード競争で優位に立ったものだけが手に入れることができる「利益」になります。

　「初期ユーザーが味方になってくれて、サービスの完成度を高めるために一役買ってくれる」。それが「Backlog（バックログ）」の初期リリースを、無料で行った理由の1つです（いまでも、実際に触っていただいて、納得したうえで有料プランを使っていただくために、無料プランを公開し続けています）。

ユーザーの声を聞いて育てるソフトウェア

　以上のような理由で、「Backlog（バックログ）」では、Web 2.0の「永遠のベータ版」のような手法を採用しました。

　ユーザーの声を聞くためには、聞くための窓口を用意しておかなければなりません。例えば、ソーシャルネットワーク・システムの「mixi」では、サイドバーに「あなたの機能要望をお待ちしています」と、ユーザーの要求管理への導線を用意してあります。たくさんのサービスを展開している「はてな」も「はてなアイデア」で「要望、 問題の報告」を設け、「ユーザーの声を聞く仕組み」を用意しています。

　「永遠のベータ版」の大事な部分は「ユーザーの声を聞き、さらに良いサービスに、さらに便利に、いつまでも進化する」というところです。ユーザーの声を聞き、ソフトウェアを育てていくことがWeb 2.0時代のサービス公開の醍醐味（だいごみ）なのです。

公開後、最初の壁

　「Backlog（バックログ）」は、リリース当初、いくつかの壁に当たりました。

　Backlogでは、サービス開始に向けて、「熱意のあるユーザー」に使っていただくために、各所でプレスリリースを打ちました。

　ところが、その日のうちに大変なことが起きました。あまりのアクセスの多さに、サーバがダウンしてしまったのです。原因は「スラッシュドット効果（以下、スラド効果）」でした。

　「スラド効果」とは、Webサイトが「スラッシュドット」というWebサイトに取り上げられ、サイトのアクセスが異常に増え、サーバトラフィックが爆発的に増えることをいいます。「Backlog（バックログ）」は、「スラッシュドット」に取り上げられ、スラド効果が起き、見事にサーバ負荷が高まり、動作がとても重くなってしまいました。

　想定外のアクセス数だったのですが、そのような場面に耐えられなかったのも事実です。初期計画ではなかなか分からなかったことだと思いますが、反省点をしっかりと受け止め、いまでは、サーバの増強も行いました。

　さらにビジネスとして展開していくうえでは大きな課題もありました。「Backlog（バックログ）」は「プロジェクトの課題を管理する」という、とてもナイーブなところを扱うAPSサービスですので、社会的な声も初期は厳しいものでした。サービスを公開したとき弊社は会社設立1年目でしたので、「こんなところに預けて大丈夫か？」「実績のない会社が、本当に運用できるのか？」ということは、いろんなところでいわれてきました。

　大まじめにやっていますので、「いつかは認めていただけるに違いない」と続けています。すると、徐々に「初期の熱意のあるユーザー」以外の「実利主義のユーザー」も増えてきました。さらに、最近は、大きな企業さまなどからお声を掛けていただけるようになりました。

　会社の規模など、なかなか超えられない壁も、続けること、継続してみせることによって、超えることができるのかもしれません。

ほかのプロジェクトでも「早期公開」を行っている

　以上のような経験も踏まえ、弊社では他プロジェクトでも、サービスの早期公開を行っています。

　例えば、サービスの裏側にある「業務的なところ」を作り込むようなことを、省いてしまったりします。「業務的なところ」を作り込むよりも、その分、「早期公開」を狙った方が、本当のユーザーとの会話が早目にでき、「勝ち」が見えるわけです。もちろん、プロジェクト属性によるのですが、まだ想定でしかない「業務的なところ」を作り込んでしまうと、逆にサービス運用のボトルネックになることもあります。

　さまざまなドラマを展開してリリースが終わった「Backlog（バックログ）」。次回は、事例や、実際のユーザーの声、裏話などを掲載いたしますので、よろしくお願いいたします。