（第２弾からだいぶ時間が経ってしまった・・・）
サイトの開発に入ってからβ版でのテストまでの、サイト公開直前のお話。
エンジニアがいないチームがいかにココナラを作り上げていったか。
思い返すと、不安と熱気がいりまじった半年だった。
エンジニアがいないチームの悲喜こもごも
今でこそ自社の開発チームが機能しているが、@satoshimmyo は元々業務用のサイトの開発しかやったことないし、やれないこともないだろうけど時間がかかる。
ココナラは、外部の方に開発を委託するか、時間をかけてチームを集めるかしかなかった。
長い目で考えれば自分たちでやるというのが絶対に正しい選択肢なのだが、経験の無いチームに入ってもらえるエンジニアを見つけるのはなかなか大変。。。
このあたりがエンジニアチームでないところの難しさ。
まずはクイックにβ版を作って実験をしたかったし、とは言え有料のサービスだったのであまり変なものを作って失敗するわけにはいかないので、結局外部の方にお願いすることにした。
お願いしたのは、個人間のカーシェアリングサービスのCaFoReや、最近ではたった2分で自分のオンラインストアを作れるStores.jpを展開していることで知られるブラケットさん。
たぶん他の会社だったらお願いしなかったかもしれない。
ブラケットさんにお願いしたのは、自社で個人間（CtoC）のサイトを開発・運営しつつ、デザインから開発まで一気通貫で受託可能だったから。
単に綺麗なサイトを作るということではないので、受託だけではなく自社で運用しているという点が大事だった。
有料サービスとして最低限機能するものをクイックに作るという意味ではブラケットさんしかない、と。
ただ、実際に開発プロセスに入ってみると、当然予想されたことだけど、同じオフィスで開発していないと色々難しい面が多い。
そもそもβ版をクイックに作るために、僕らからはあまり口を挟まずに一気に作るということで低予算で受けていただいたのだが、いざ始まると、僕らから色々と注文してしまった。
色々とテストしたい追加の機能をいれてもらったり、デザインに指示を出したり。。。
誰が何を主導しているか中途半端な状況に陥り、かなり混乱させてしまった。
色々と反省材料が多かった開発期間。
β版なんだから細かいところに目をつぶるのは当たり前なのかもしれないが、いいものを作りたいと思う気持ちは抑え切れない。
ただ、そのせいで、経験のあるブラケットさんからの意見を無視して、結局後から失敗だとわかることを僕らからプッシュしてしまったり。
時間はかかってしまったし、ブラケットさんにはわがままばかり言ってご迷惑をお掛けしたけど、ここで作ってもらったβ版でいろんな事がわかった。
改めて自分たちでチームを作ってサイトを作りなおしてみると、ブラケットさんには短期間でほんとよく作って頂いたと感謝するところばかり。
最後の方はずっと徹夜続きで。。。
 |
| 懐かしのβ版のデザイン |
たくさんの失敗をしたβ版
β版、特に4月頃の初期バージョンから登録していただいた方々に一番迷惑をかけたのは、「音声で回答する」機能だった。
そもそも音声で回答する機能、狙いとしては文字だけでは伝わらないヒューマンタッチな感じや微妙なニュアンスを伝えたいという意図だった。
よくある、「メールだと喧嘩になるけれど話せばそんな意図はなかったのね」、みたいなニュアンスを再現するために。
ちょうど、どうやったら人間らしさを再現できるかという点と、類似サイトにない僕等ならではの体験をどうデザインするかという点で悩んでいた際に、思いついたアイデアだった。
もちろん、その日のうちにテストをした。
「就活のエントリーシートにアドバイスします」という架空のサービスを再現し、学生から本物のエントリーシートを4人分集め、人事部の友人に回答を吹き込んでもらった。
結果はとても評判がよいものだった。
文字と音声ではここまで感じ方が違うのか、というくらいの感想を得た。
出品者側は、文字で書くと15分かかる文量も話せば3分ということで手間が減るし、購入者側も、読めば20秒の内容も聞けば3分ということで「長さに価値を感じる」という仮説だった。
しかしながら、ごく一部の人には好評だったのだが、それ以外にはまったくもって大失敗だった。
ブラウザ上で録音できるようにするのに時間がかかったし、いざテストしてみたらブラウザやPCの設定ごとに「録音できない」トラブルが大量に発生する。
なんとかこれを治したけれど、結局まわりに人がいるから話しにくいとか、話すのに緊張してかえって文字で書くより時間がかかったりと、ほとんど使われなかった。
今思えば、テストをもっと広範にやっておくべきだったのだが、少し見切り発車をしてしまった。
もうひとつの失敗は、購入者と出品者の間でのやり取り回数を２往復と限定したこと。
そもそも、どのタイミングでやり取りを終えていいかわからないこともあるだろうし、延々と終わらなければ出品者の負担になるだろうと思い、２往復限定にした。
一回に書ける字数も限定して。
ただ、ファイルの添付をミスったらリカバリーが効かないとか、一回で回答しきらないといけないという緊張を過度に生んで返信が遅くなったりとか、２往復しか無いから簡単な挨拶やら質問やらもできないとか、まあ、色々と問題が噴出した。
出品者を楽にしようと思って作った機能だったが、これも結局出品者からのクレームとなった。
リーンスタットアップの原点に！
結局のところ、「音声での回答」も「やり取りは二往復」も、頭で考えたことだった。もちろん、過去の経験や感覚から、仮説は持っていい。でもテストをもっとちゃんとやらなくてはいけなかった。
もちろん、β版そのものがテストではあるのだが、３ヶ月もかけてβ版を開発する前にわかる方法はいくらでもあった。
ココナラを検討し始めた頃はもっとリーンにやっていたように思うが、開発が始まってから独自色をもっと出さないとということに意識がいき、ちょっと焦ってしまったのかもしれない。
ココナラのUIというよりフローの整理に関してお褒めの言葉を頂くことがあるが、ひとえにあれは2ヶ月クローズドベータやって、そのあと2ヶ月弱で全て作り直したから。ユーザーに使われなかったりわかりにくかったりした機能やデザインを軒並み切り捨てた。
— satoshi shiiiiimmyo™さん (@satoshimmyo) 9月 12, 2012
もともとクローズドベータやって、全部捨ててもう一回作り直すスケジュールを引いていたが実行するのはなかなかに難しかった。似たようなサービスがローンチされる中、黙々と再度デザインを作り込み、機能をシンプルに、コンセプトを絞り込んでいく作業はすごくストレスの溜まる作業。
— satoshi shiiiiimmyo™さん (@satoshimmyo) 9月 12, 2012
そう、全部作りなおすのも予定通りではあったのだけど、やっぱりスピードと精度はあげていかなくちゃいけない。
仮説検証のプロセスを、もっと早く、もっと速く。
β版を運用し始めた頃から、エンジニアやデザイナーがチームに加わり、自分たちでほとんど作りなおした。
モノがあればリクルーティングルーティンもしやすいもの。
見た目はそれほど変わらなかったかもしれないが、裏側はほとんど作りなおした。
そして、公式版の作成に入って以降、「とりあえず試す」というスタンスを手に入れた。
実装する前にデザインレベルでユーザーに意見をもらう。
いや、デザインに落とす前に、文章だけのレベルでも意見をもらう。
基本姿勢は、「自分たちでは決めない」こと。
チーム内で「こうしたらいいかも」という意見が出たら、それについては必要以上に議論しない。
時間がもったいない。
答えは僕らではなくユーザーが持っているから。
毎日ひとつ仮説を作り、それを試すもっとも簡単な方法を考え、その日のうちに試す。
そんな毎日を繰り返して、公式版にたどりついた。
β版の途中、尊敬する起業家の一人、Cyta.jpを運営する有安さんに会いに行った。思えば、このミーティングが僕らが変わるおおきなきっかけとなった。
４時間は話し込んだのだが、一言で言えば「リーン・スタートアップを読め」なミーティングだった（笑）
この本、読んでなかったわけではないのだが、実践し切るのが難しい。
覚悟の問題というか。
起業をしているわけでもない人がこの本を読んでも、「ふーん、トヨタのカンバン方式の焼き直しじゃない？」みたいな印象しか持たないかもしれない。
でも、起業した人は、「おお、これは確かにそうかも、やるぞやるぞ」となる。
それでも実際はやりきれず、失敗した後に読み返して、「ああ、ここに書いてあるとおりだった・・・」となる。。。
そんな本な気がする、リーン・スタートアップは。
起業をする人は、読みたいところだけを読んで理解したつもりになるのではなく、自分たちは実践できているのだろうか？と何度も読み返すのがいいのではないかと思う、良本。
（シリーズ第４弾は公式オープン前後の話になると思うけど、振り返るのはもう少し先になってからかな・・・しばらくお待ちを！）
