【勉強会】CtoCサービスの開発の裏側を公開！ プロダクト責任者、CTOが全て語ります！
勉強会に参加した時のメモです
connpass
セッション1
各社紹介
- メルカリはローンチから1年半くらい
- チケットキャンプの運営会社フンザ
- 従業員は23名。うちエンジニア5名
- チケットは売れないと死活問題->需要あるのでは
- ココナラ
- 20名
- 知識・スキルのマーケットプレイス
- 最近の売り上げは右肩上がりだけど、最初の頃は苦労した
ローンチ時の開発エピソード
メルカリ
- 開発は6ヶ月
- 両OS
- 機能を削りまくった
- 検索ができない
- 1日出品100件くらいを目標にしていた -> 検索いらない
- 出品数が増加してあわてて検索 SQLでLIKE検索を1stリリース
- 1ヶ月かけて検索リリース
- 口座からお金を引き出す機能もアップデートで対応
- タイムラインや商品ページはこだわった
フンザ
- 最初は3人でやっていた
- 何人が気になっているかを可視化
- KPI2倍ルール
- 2倍のびない機能改善はやらないなどのルールを作った
- 退会機能も半年間できなかった
- 優先順位をうまくつけていた
- ローンチ後、しばらくトラフィックが増えなかった
- サマーソニックが転機
- サマソニのチケットが沢山売買された
ココナラ
- 一度クローズドベータでローンチ
- 結果をもとに全部作り直して正式ローンチ
- 失敗機能
- 相談数を制限した -> ユーザーからの反発 -> 作り直した
- 「これは買えるのか？」を意識していた
- mixiのコミュニティ感を意識していた
- ボタンをECっぽくしてみたりした
- 値段設定も検討した -> 迷う必要がない価格 -> 400-1000円 -> ワンコイン -> 500円
これをやったら伸びた、などのブースト経験はあるか？
メルカリ
- 何かがきっかけで変わったかは見えずらい
- 細かい機能改善はやっている
- 最初の半年くらいはとてもきつかった 鶏卵問題
- 何かが良かった、というよりは地道な改善
フンザ
- 特にない
- 地道な改善
ココナラ
- もともとはすべて500円
- 2013年末にそのモデルを変え始めた
- 値段を上げることが可能にすることで、マーケットプレイスが活性化した
今後の展望
メルカリ
- もともとグローバル展開を目指している
- 8,9割くらいはアメリカ対応をメインにやっている
- CtoCは色々な可能性がある
- UberとかAirbnbも
- ソウゾウでも1つアプリを作っている
- メルカリのIDで使える
- メルカリ経済圏
- 新しい体験 BtoC
- いろいろやりたいと思っていて人員不足
フンザ
- itunesのデータとチケキャンのデータを突き合せてレコメンド push
ココナラ
- back to basic
- これからは機能を追加するよりも機能を減らしていく
- ユーザーを特定してフォーカスしていく
- アプリの領域を攻める
会社のカルチャーなど
メルカリ
- ウノウからの人が10人、mixiからも結構
- 自由なカルチャー
- フラット
- 上の人の発言も覆る
- 下からの意見も自由に取り入れられる
- GO BOLD 大胆にやろう
フンザ
- 少数精鋭
- 5人で月間500万人
ココナラ
- 難しいプラットフォーム
- PDCAをゴリゴリ回している
セッション2
- 株式会社メルカリ プリンシパルエンジニア 鶴岡 達也
- 株式会社フンザ 取締役/CTO 酒徳 千尋
- 株式会社ココナラ 取締役/CTO 恵比澤 賢
プロダクト立ち上げ時の体制
メルカリ
- 最初は社長がメンバを集めた
- SNSでエンジニアを集めていった
- 厳選したメンバ
- サーバサイド1人、iOS1人、And1人
- プロヂューサー1人
- 1つのテーブルで集まって全員で開発
- 1stリリース時は20人くらい
- 人づてでの採用がほとんど
フンザ
- もとジンガジャパンの3名で起業
- エンジニアは1人
- 採用は人づて
- 半年でエンジニア1人、1年で1人
- 1年で従業員は10人くらい
- 厳選して採用
- 良い面：1+1=2になるとは限らない
ココナラ
- 3人で創業
- エンジニアは1人
利用している技術の選定基準
フンザ
ココナラ
- 一番最初に担当したエンジニアが自信があった技術
- LAMP環境
- 新しい機能開発の場合
- メイン機能は慎重に選ぶ。サブ機能は比較的チャレンジしやすい。
メルカリ
- 自信が持てる技術
- スケジュールを間に合わせるのが一番大事
- 自分以外の人も入ってきやすい環境であるか
- PHP
- フレームワークは内製
- 学習コストが低い
- 1週間学習が必要なものは採用しない
- ソウゾウは最初PHPを考えてた
- 社長からGoはどう？という連絡が来た
- CTOからもGoはどう？という連絡が来た
- 3年後を見据えたときにGoを選択
- 子会社だから挑戦
- メルカリはPHP
機能追加の判断軸
メルカリ
- ディレクターとエンジニアが近い -> 1つのチーム
- JPとUSで1人責任者がいる
- ディレクターの企画を信用する
- サービスの設計思想
- 使う人の思想
- モバイルの思想
- ディレクターはアプリをめちゃくちゃ使っている
- エンジニアも。話が早い
フンザ
- 技術的負債を残さないようにしたい、と常に思っている
- 納得できないことはとことんプロデューサーを話す。納得感を持って仕事をする
ココナラ
- 大きな目標感は全員で持っている
- 数字をもとに根拠の説明
- リリース後の結果もきちんと確認している
会社や開発チームをまとめるための工夫
メルカリ(ソウゾウ)
- 一人一人と話す時間を増やしている
- 1ヶ月に1度以上は話す機会を作っている
- 人が増えても変えない
フンザ
- チームのモチベーションを下げる要因はリーダーの振舞い
- 朝と夕方で言っていることを変えない
- 価値観や軸をぶらさないようにする
- コミットログはきちんと、ユニットテストは書こう
- 自分もしっかりやる
- サービスが伸びていることは大事
- リファクタリングよりも売り上げを伸ばす
ココナラ
- 目標をしっかりと共有すること
エンジニアのキャリアパス
メルカリ
- 急激に成長する可能性のある会社に身を置くことが大事
フンザ
- 1つの技術を極めることは大事
- 限界をさだめない
- 勉強会。外に出て知見や人脈を広げる
会場からの質問(CtoCサービスの苦労話)
メルカリ
- そんなに苦労したところはない
- ゲームの方が断然難しい
- CtoCは安定稼働がまず第一
- リアルでの配送、決済周りの難しさはある
フンザ
- ユーザーの書き込みをエレガントに監視する仕組みを検討中
- ユーザーの幅が広がることで自分の予想外の問い合わせやドロップポイントがある
システム自動化の判断基準
メルカリ
- まず手動でやることを考えてリリース -> 耐えられなくなったら自動化
- 最初から自動化を目指さない
- 警察からの問い合わせ用の報告ツール
- 最初は月1回程度
- 問い合わせが増えて時間がかかるようになったから自動化
フンザ
- 手動化 -> ツールを改善して手動化を効率化 -> 自動化
- ヒューマンミスを減らしたいものは自動化を検討する
ココナラ
- あえて自動化していないところ
- 人の判断が必要なもの
