2015/12/03

CallConnect の開発秘話selfree, llc CTO 本間 皇成 (@kimihom)

本間 皇成 @kimihom

ボクココ 運営者http://www.bokukoko.info/

CTO at selfree,llc

Ruby on Rails, AWS, Heroku, Android, iOS

TwilioJP-UG メンバー

Table of Contents

✤ Hackathon to Startup

✤ 事業発案

✤ サービス開発

Hackathon to Startup

私のハッカソン歴

2014/10/25 Green Hackathon Tokyo アカツキ賞、リバネス賞

2014/11/01 Rakuten Hackathon 2014 最優秀賞

2014/12/01 Salesforce ハックチャレンジ 2014 Heroku部門 2位

2015/02/16 Docomo Developer Application Contest 3rd 最優秀賞

2015/06/10 RICHO THETA デベロッパーズコンテスト 受賞なし

2015/06/27 Angel Hack Tokyo 2015 ReRaKu 賞

2015/04/12 KDDI Smart Communication Award 　優秀賞、EV賞

私のハッカソン歴

2014/10/25 Green Hackathon Tokyo アカツキ賞、リバネス賞

2014/11/01 Rakuten Hackathon 2014 最優秀賞

2014/12/01 Salesforce ハックチャレンジ 2014 優秀賞

2015/02/16 Docomo Developer Application Contest 3rd 最優秀賞

2015/06/10 RICHO THETA デベロッパーズコンテスト 受賞なし

2015/06/27 Angel Hack Tokyo 2015 ReRaKu 賞

2015/04/12 KDDI Smart Communication Award 　優秀賞、EV賞

こんなにたくさん作って、事業化したのは1つしかない

ハッカソンの動機

賞金や商品をゲットしたい

イベントを楽しみたい

新しい技術に挑戦したい

事業化する前に製品を試したい

98%

2%

ハッカソンをMVPのフィードバックの場にする

MVP = Minimum Viable Product検証に必要な最低限の機能を持った製品

メリット

審査員がベンチャーキャピタルなど、今後につながる相手である

事業化すれば、主催者と協力してプロダクトを広められる

ハッカソンの発表の場がピッチの場に変わる

Hackathon to Startup にするための

ハッカソンの必須条件

✤ 同僚と参加する

✤ マネタイズを本気で考える

✤ 開催目的が事業創出であるハッカソンに参加する

事業発案

事業創出目的のハッカソンで必要な唯一のこと

明確に課題を持っているユーザーがいて、それをお金を払ってでも使いたい場面が想定できるか。

その課題解決部分だけ作る。(MVP)

MVPさえあれば入賞は確実

新しいテクノロジーで既存のソリューションを置き換える=

既存のモノ、サービスの課題解決をする

アイディアの基本となる考え方

新しいソリューションを普及させるのは時間がかかる

CallConnect の場合

既存のコールセンターソリューション

高額 導入コスト高 不便

で解決！

新技術

Twilio で新しくできるようになったことをフル活用して既存のコールセンターより良いものをユーザーに提供する

ハッカソン中に作った機能は1つだけ

UI/UX を徹底的にこだわりました。

ハッカソンの結果

✤ 主催者側のKDDIやVCのEast Venturesなどから評価

✤ KDDI のサポートもあり、事業化を決意

✤ 課金機能だけ付け加えてとりあえずリリース

サービス開発

開発実績2015/08/26 CallConnect のリニューアル

2015/09/08 CSV, Salesforce 連携

2015/09/14 kintone 連携, ガイダンス無し転送機能

2015/09/30 複数電話番号を所持可能に

2015/10/09 Proプランスタート、 通話キューイング

2015/10/30 Slack, Zendesk 連携 通話の保留

2015/11/16 内線、通話の取り次ぎ機能

2015/11/02 分析機能

認知向上

要望実現

開発サイクル

プロトタイプ

実装

テストリリース

振り返り

開発サイクル

プロトタイプ

実装

テストリリース

振り返り

こういうのは作りたくない

新しく機能を開発するより、大きくなったシステムを修正することの方がよっぽど難しい

シンプルであり続ける=

既存サービスの機能を更新・削除を意識する

“シンプルであることは、複雑であることよりもむずかしいときがある。物事をシンプルにするためには、懸命に努力して思考を明瞭にしなければならないからだ。だが、それだけの価値はある。なぜなら、ひとたびそこに到達できれば、山をも動かせるからだ。”

– Steve Jobs

プロトタイプに時間をかける

✤ 隣にデザイナーがいるので、高速フィードバック改善

✤ ユーザー目線: 小俣

✤ UI/UX 目線: 畠

✤ 開発目線: 本間

メンバーは３人がベスト

✤ 1人だと妥協が入る

✤ 2人だと口論になって進まない

✤ 4人以上だと合意を取るのに時間がかかりすぎる

まとめ

✤ Hackathon to Startup の条件は3つ

✤ 既存の課題解決の課題を解決する事業発案

✤ Think Simple.

Thanks.