ソーシャルアプリ勉強会に参戦してきた

SNSの進化とソーシャルアプリケーション

SNS進化の歴史
  • social graph - つながりの視覚化
  • 目的/地域特化の時代 - CGMとの融合
  • Activity Feedの時代 - 活動を友人とシェアする
  • Social Applicationの時代 - social graphを前提としたアプリケーション
  • Social Graph外部利用の時代 - 特定のSocial Graphのコンテクストを外部サイトで利用する
Activity Feedの時代の変化
オープンプラットフォームとConnect系API
  • 集客とSocial Graphはプラットフォーム任せに
ソーシャルアプリケーションマーケットの現状
  • Facebookの場合
    • 相当なトラフィックが流れている(zynga)
    • ただ、毎月だまってて伸びるものではない(前月比で落ちるゲームが現れている)
  • 過去と比較すると、gameにここまでトラフィックが集まったのは最近(ほんの数カ月)のこと
    • happy birthday cardとかは最初からあって、未だに生き延びている
これから伸びるのは?(私も知りたいです
ソーシャルアプリケーションの必要条件
  • バイラルを促進する
    • 最大のプロモーションは友達招待
      • ソーシャルアプリケーションの強みは既存ソーシャルグラフの大きさ
      • ひとりが数人を招待してくれるように
    • 友達を招待する理由を用意する
      • 招待に対するご褒美
  • activityを活用する
    • ソーシャルアプリケーションの強みはactivity
    • activityを適度に発生させる
      • 気になるactivity
        • なんだろう?
        • みたい・しりたい
      • 参加したくなる
      • アクセスしたくなるactivity
  • アクションと報酬のバランスをよる
    • 一つ一つのアクションに明確な報酬を
      • アクションを行う動機づけ
    • アクションのコストに見合った報酬
    • アクション→報酬の積み重ね
      • 小さな積み重ねの継続が大きな結果になるようなサイクルを作り出す
  • 再訪問の理由を作る
    • 使い続けてもらうことが大切
    • 再訪問する理由
      • 北風方式:訪問しないとペナルティ
      • 太陽方式:みずから進んで訪問したい
      • 理想は太陽、最悪でも北風
    • いつでも→今しか
      • 今しかできないことを考える
      • 場所と時間を活用
        • もったいない気持ちを出す
        • 特定の場所しかできないアクション
        • 一定時間が必要なアクション
  • コミュニケーションの種を落とす
    • コミュニケーション=しがらみ
      • 挨拶されたら挨拶をする
      • 現実のしがらみとお暗示
    • 負担にならない工夫
      • コミュニケーション漬けは疲れる
      • ライトな手段を用意する
    • 自慢させてあげる
      • 自慢 > 自己満足
      • うらやましい→がんばる→自慢
  • ユーザ同士の助け合いを促進する
    • サービスのすべてを伝えるのは難しい
      • ヘルプ・FAQには限界がある
      • 丁寧に作っても全員は読んでくれない
    • 上級ユーザが初級ユーザをサポートする
      • 誘った手前・・・
  • ライトユーザを意識する
    • インターネット上級者ではない
      • 常識はほとんど適用しない
    • 可能な限りシンプルに
      • 骨子の部分はできるだけシンプルに
      • 機能追加よりも削ることを考える
    • ゲームであればライトゲーム
      • ライトゲームのターゲットはゲームユーザではない
      • ゲームすぎない
      • 単純な作業の積み重ねで進む
  • とにかくスピードが重要
    • マーケットは早期にレッドオーシャン化する
      • 携帯の公式サイト
      • 露出の確保=ランキング上位に残ること
      • ひとりのユーザが利用するアプリの数は限られる
    • 検討を続けるよりも、実行すること
      • 検討している間に手遅れになる
      • 投入してからが本当の勝負
      • 投入後の方がやるべき事は見えてくる
    • 闇雲にはやらない
      • よく考えて、速やかに実行
  • サービス運用が大切
    • ユーザの行動は想定通りにはならなお
      • 事前に仮説はもって望む
    • 弱み・強みを早く見つける
      • 分析・検証は必ず行う
    • どんどん改善する
      • ダメな部分は思い切って切り落とす
    • 飽きる前に次の一手をうつ
      • 他のアプリに目移りする前に
      • 更新感は2週間
      • 今熱いジャンルを追うなら開発期間は2ヶ月
  • よく研究する
    • ソーシャルアプリの文法はほぼ決まっている
    • 成功事例を研究し尽くす
      • 半端なオリジナリティはいいことは何もない
      • facebook, mixiアプリのトップアプリは全部やる
      • 成功のエッセンスは見えてくる
    • 移り変わりに適応する
      • 走り続けます、止まったら負けです
「ぼくのレストラン」のこぼれ話
  • 目指している世界:ソーシャルフィルタリング
    • 友達関係による、情報のフィルタリング:多すぎる情報の絞り込み
サービス立ち上げの敬意
  • 2009/07上旬 企画着手
  • 2009/08下旬 開発着手
  • 2009/10/28 mixi版に変更
    • 途中でmixiアプリに変更してリリース、ダウン、工夫などなど
  • 本家版とmixi版の違い
    • どちらかというとユーザ層を想定し、機能を削った
課題 - RDBMS
  • ゲームは更新クエリがかなり多い
    • mastertの負荷が高い
    • slaveの遅延→selectをslaveに逃がせない
    • table分割、memcached化
    • joinしない、一部データをJSON化する
      • 「ほほー」
  • 1時間に1回全ユーザの計算をする
    • 80万ユーザいると1時間に80万レコードを増える
    • 1テーブルで2000万レコードを超えるとまともに動かない
    • パーティションテーブル化、memcached化
課題 - memcached編
  • パフォーマンス
    • 複数問い合わせはパフォーマンス低下
    • 極力multiple-getするようにする
  • set/getエラー
    • 一定確率でエラーする、数回はリトライするようにする
  • 複数サーバでのクラスタ運用
    • phpperlのライブラリの挙動を確認
    • 表はphp、裏はperl
  • サーバ障害時の対応
    • サーバが落ちるとデータがすべて消える
    • 事前にデータ復元スクリプトを作っておく
課題 - Amazon EC2
  • ネットワーク遅延問題
    • 定期・不定期に数秒〜2分くらい遅延する
      • 日曜の18時22分にEC2アクセスできない
    • そのあとまとめてアクセスが来る
    • 遅延の問題と、まとまった時の不可の問題
    • 国内のデータセンターとの併用が望ましい
  • 障害問題
    • Amazon側で障害が起きることがある
    • 一部のサーバに接続できなくなることもある
  • クレジットカード問題
    • 決済額が高額になる
    • カード与信額を超える
課題 - mash up
  • Google Static Map API
    • 1 application ID/1 IP addrs で一日1000回制限
    • 携帯キャリアIP/mixi proxy IPは固定
    • 有料版でも10000回
    • mixi版ではYahoo地図に変更
技術者募集中
  • Webアプリケーションエンジニア
  • 運用エンジニア

LT1: mixiアプリのkayakのひと

  • mixi app用jsの話
    • AutoAjdust
    • サーバサイドとの自動連携
    • ソーシャルグラフの取得
    • 権限の確認
    • 日記に書くリンク機能
    • Activity送信機能
    • クッキーのサポート

LT2: おもしりとり開発事例

LT3: poncan, happy aquarium

  • ドリコムの人
  • リワード広告
    • 広告をクリックして、報酬を返してあげる

LT4: Red5について