CtoCサービスの開発の裏側を公開！ プロダクト責任者、CTOが全て語ります！ に参加してきました

こちらのイベントに参加してきました。
CtoCサービスの開発の裏側を公開！ プロダクト責任者、CTOが全て語ります！
http://connpass.com/event/22515/

メルカリ、フンザ、ココナラのCOO、CTOの方々の話を聞いたり、
実際にCtoCのサービスをやってる方々と話す機会を設けていただき、
自分もCtoCのサービスをやってる身としては、有意義な時間を過ごすことができました。

つらつらとメモったことについて、載せていきます。

◯Founderが語る、プロダクトへの想い
・メルカリ
　従業員200名(日米合計)
　半数以上がカスタマーサポート
　エンジニア、デザイナー40名（9割はアメリカ）

ローンチのときのエピソード
　開発6ヶ月
　ios/android両方
　クオリティを下げないように機能を削った
　　検索ができない→想定以上に出品→　SQLのlikeでとりあえず→ちゃんと検索作る
　　振り込み申請できない→　アプリのアップデートでできればよいよね

　CtoCこのモデルは最初きつい、地道にチューニングしていく。一点越えるとわーっと増えていく。

中長期の話、チャレンジしたい話
　アメリカの改修が日本に反映されたり
　メルカリのID使って、メルカリの経済圏でまわしていきたい
　BtoCでもモバイルで新しい体験を作っていきたい

会社のカルチャー
　ウノウ、mixiからの人多め
　go bold

・フンザ
　従業員23名（エンジニア5名）
　mixi子会社
　2015年9月 流通26.5億円

ローンチのときのエピソード
　チケットなので、写真がないので、人気（ひとけ）がない
　KPI2倍ルール→2倍にならないものはやらない
　退会半年間できない

　 　５ヶ月くらいトラフィックの波が来なかった
　　転機　サマーソニックのチケットだけがやたら売買されている　→恩としてサマソニに協賛（1億円）

　CtoCの機能でブーストかかるようなものはない

中長期の話、チャレンジしたい話
　スマホの中には音楽の情報がつまっている
　　itunesとチケットキャンプの情報をマッチングして、プッシュしたりとか。
　　位置情報とマッチングしてプッシュしたりとか。

会社のカルチャー
　少数精鋭、一人当たりの生産性、責任

・ココナラ
　従業員20名
　ユーザー数20万人、取引件数 26000/月

ローンチのときのエピソード
　クローズドベータでローンチ
　　→一回作り直している wantedlyモデルw
　　長い相談してると時給がさがる
　　　文字を制限したら非難轟々
　　　→作り直す
　買い気
　　コミュニテイっぽい雰囲気→買える感なくなる（商品に見えない）→ボタンとかECっぽくしてみる
　プライシング
　　同じ内容でも価格が違うときに適正がわからない
　　わかりやすいようにワンコインで

　　出品者が増えて慣れてきて窮屈になってきた→価格をあげていった

中長期の話、チャレンジしたい話
　プロダクトを作ったときのモデルを見直した。
　モデルに即した形に機能を減らしたり、fine tuningしたりしてる。
　アプリに。

会社のカルチャー
　サービスに共感してるメンバー
　難しいところが好きみたいなメンバー
　サービスを伸ばすんだという気概があるメンバー
　言いたいことを言って、それがすべてサービスのためになる会社


◯CtoCサービスの裏側
・メルカリ
プロダクト立ち上げ時のチーム体制や採用について
　最初は知り合いに声をかけてウノウのつながりやjingaのつながり
　最初のリリース時も20人いないくらい
　知り合いが知り合いを呼んで
　スキルがあるだけではだめで、文化がマッチするかどうかも含めて

利用している技術の選定
　一番自信のあるものにする
　一人で作っていくものではないので、同じレベルで開発できる人が集められる技術を使う
　PHP
　学習コストが低いもの

機能追加や機能改善の判断軸はどこに置いているか？サービス設計の思想などあれば。
　ディレクターとエンジニアが近いところにいる

会社や開発チームをまとめるためにやっていること
　全体に対して何かをやるのではなく、一人一人に対して話すことを増やしている
　10人以下なら意思疎通は簡単だが、どんどん増えてくとこうやったほうがいい

エンジニアのキャリアパスについて
　急激に成長している会社に身を置くのが大事

　どういうエンジニアがいるか
　　平均年齢が高い
　　10年前とかにばりばりネット企業で活躍していた

技術的に苦労した点
　そんなにない
　ゲームの方が書き込みとか多くて難しい
　CtoCは安定的に動かす、そんなに難しくない

どこまでオペレーションで済ませ、どこから自動化するかの判断のポイント
　まず手動でやることを考え、耐えられなくなったら自動化
　最初にめっちゃがんばって自動化作っても、手でやった方が早いってなるともったいない
　デフォルトは人間にがんばってもらう

・フンザ
プロダクト立ち上げ時のチーム体制や採用について
　元同僚とか紹介などつながりで。
　初めて半年で1人、1年で1人増えた
　カルチャーにマッチするかを重視

利用している技術の選定
　python django
　AWS
　MySQL
自信を持って使える技術

機能追加や機能改善の判断軸はどこに置いているか？サービス設計の思想などあれば。
　技術的負債を残さないようにしたい
　　新しく入った人にがっかりさせたくない
　できませんを絶対に言わない

　納得できないことがあったら、とことん話あって、納得して仕事する

会社や開発チームをまとめるためにやっていること
　チームのモチベーションを下げることは、リーダー的な人のダブルスタンダードな振る舞い

エンジニアのキャリアパスについて
　１つの技術を極めるのが大事。自分の拠り所になる技術があるからサービスが作れたと思う
　限界を定めないことが大事。
　webからアプリにの流れは続く
　データ解析とかやれる人とかいい。

技術的に苦労した点
　どうやってユーザーの書き込みなどをエレガントに監視していくか
　　禁止ワードみたいな
　普通の人がどう使っているかみたいなところが難しい

どこまでオペレーションで済ませ、どこから自動化するかの判断のポイント
　手動か自動かだけでなく、手動でやっていることをいかに短くやれるかも考慮
　手動でのエラーレートが高いものは自動化を考える

・ココナラ
プロダクト立ち上げ時のチーム体制や採用について
　基本１人でシステム作ってる
　内製にこだわる
　一部外注したり、知り合いのフリーランスにお願いしたりとか
　ないところから作っていくのを楽しめるメンバーかが重症

利用している技術の選定
PHP CakePHP
MySQL
最初に担当してたエンジニアが一番得意な言語

機能追加や機能改善の判断軸はどこに置いているか？サービス設計の思想などあれば。
　数字を見て根拠を出してやるかを検討する
　やった後にちゃんと数値を見て反省を行う

会社や開発チームをまとめるためにやっていること
　みんなが目指すべき目標を共有していく
　みんなで一緒にランチを食べるとかも意外と重要

エンジニアのキャリアパスについて
　単に人並みにできるってことがいくらあっても市場的にはつらいかな
　長い時間を培った技術などをつけて差別化していかないとつらい
　10年たっても変わらない技術などを身につけていく

技術的に苦労した点
　いかに運用コストをかけないようにまわしていくかとか。
　決済手段を幅広く用意しているが、各社思想が違うのでどうモデルに組み込んでいくかとか。

どこまでオペレーションで済ませ、どこから自動化するかの判断のポイント
　あえて管理ツールでできないようにしてるフローも残してたりする