最近ほとんど更新しておらず、イベントに行ったときのメモを上げているだけだったので、それならこのブログでやる必要はないし、ソーシャルアプリについて発信する意義もだいぶ薄れてきたので、新しいことを試したいと思いました。

2009年4月末頃に書いたこのサイトについて | ソーシャルアプリ.jpというページで

そこで今後、SNSプラットフォーム＋デベロッパーという組み合わせの流れが一段と加速するだろう中で、何か関わっていきたいなと考えたのがサイトをつくった動機です。

このように書いていたのですが、この目的は十分達成しました。関わりすぎて書きにくいくらいです。SNSプラットフォーム＋デベロッパーという組み合わせの流れは加速しすぎて事件になってるくらいですね。

アクセスの6割は検索エンジン経由ですが、読んで欲しいと思う人に届ける手段はTwitterが中心になりました。受け取ることのできるフィードバックもTwitterが中心であり、適切な検索ワードを選んで発信すればドメインにこだわらなくてもいいのではないかと思います。

mixiの商標申請の問題も、いいきっかけになりました。「ソーシャルアプリ」については申請が通らなかったということですが・・・

そもそも「ソーシャルアプリ」という言葉は日本ではmixiが最初に広めたものであり、mixiが商標にする資格は十分にあるだろうと思います。私がそれに便乗して使っていたわけで。

socialapplication.jpというドメインは2009年4月23日にmixiがソーシャルアプリカンファレンスを最初に開催した直後に取得しました。その頃お金は無いし仕事は無いしで食べるのにあまりに困っていたので、個人事業でもやろうと考えていました。そこにこのカンファレンスを見て、なんか実態があいまいなまま盛り上がっているなと思って、詳しく紹介するブログを作ればお金になりそうだと思ってドメインとってWordPress立ち上げて書き始めました。

お金はともかく、多くの素晴らしい出会いがありました。地道に更新しているうちに私と会いたいという人が次々と現れ、その人たちの多くは後に業界で重要なポジションを占めることになる人たちだったのです。

いま振り返ると1年以上前にしてはなかなか面白いことを書いていたというのがあるので、Google Analyticsのアクセスログを公開しつつ、過去のコンテンツを振り返ってみたいと思います。

■エントリー別アクセス数

やっぱりFarmVilleが一位です。他の埋もれてしまっている記事を掘り起こして紹介します。

有料ゲーム危機の時代　Free to Play（基本プレイ無料）で収益化はできるか | ソーシャルアプリ.jp (2009年7月8日)

「無料です」が問題になってCMを修正したGREEの例を挙げるまでもなく、基本無料というのはiPhoneアプリですら普通になってきました。でもだから儲からないのではなく、それがパッケージ販売より多くの利益をあげるケースが珍しくなくなってきました。先日のセミナーの記事にも関連した話を書きましたが、”無料”が本質なのではなく、”後払い型”、”オンデマンド”、”ユーザー各個人の効用によって払う額が異なる”といったあたりが本質だと思います。

Come2PlayやOpenFeintがめざすソーシャルゲームプラットフォームの新世界 | ソーシャルアプリ.jp (2009年6月30日)

海外だとAuroraFeintやPlus+(DeNA&ngmoco)、国内ならPANKIAとかモバツイランドみたいに、プラットフォームとユーザーの間にもう1レイヤー作ろうとする動きが本格化してきました。特にAndroidはプラットフォーム自体にコミュニティ機能がないので、どこがコミュニティを抑えるかはポイントになると思います。

FacebookやMySpaceで屈指の人気を誇るソーシャルゲーム「Mafia Wars」徹底レビュー | ソーシャルアプリ.jp (2009年5月27日)

ゲームレビューの手法そのままで書いた記事。怪盗ロワイヤル作った人もチラ見くらいはしてくれただろうと思います。いまのソーシャルゲームでいわれているポイントはだいたい抑えている記事です。ここ経由でけっこうFacebookの友だち申請がありました。

たのみこむ＆口コミ方式で成果を挙げる「Living Social Deals」 | ソーシャルアプリ.jp (2009年9月1日)

グルーポンですよね。これはすごいと思って流行るだろうなと思ったのですが記事は全く人気がなく・・・でもやっぱりビジネスは流行りました。

開発中のFacebook専用ブラウザ「RockMelt」 | ソーシャルアプリ.jp (2009年8月15日)

公開当初は全く読まれてなかったですが、2010年の11月にRockmeltがリリースされてアクセスがあった記事です。ただ、Rockmelt自体は使う必然性が薄いのであまり使われなさそうです。予想していたよりも新しくなく、単なる普通のブラウザでした。

友達が食べに来る！友達を店員にもできる！自分のレストランをつくれる「Restaurant City」 | ソーシャルアプリ.jp (2009年5月28日)

「Restaurant City」はソーシャルアプリの中で初めてはまって熱心にプレイしたタイトルです。ゲームとしてのクオリティも高いなと感じました。ある程度長期的にプレイしていたので、サービス運営のフェーズが変わっていくのを観察し、サービスの成功には運営が非常に重要と実感しました。

■検索キーワード

ソーシャルアプリという検索ワード経由のアクセスが全体のアクセスの1/7を占めていた感じですね。現時点でもGoogleでソーシャルアプリで検索すると上位に来るので、このへんは自分なりのSEOを駆使して狙いどおりいきました。

■トラフィック元

Googleなど検索サイト経由のアクセスが6割で、依然としてGoogleの存在感は大きいと思います。個人的には目に見えるフィードバックというところでTwitterとはてなブックマークの存在が大きかったです。その2つは気にしていました。

更新頻度が落ちた後も2万PV／月くらいを推移していました。アクセス数そのものよりも直帰率の低さがひそかに自信でした。

今のところまだ何もありませんが、新しいドメインはこちらです。

Kirishiki Studios

http://www.kirishikistudios.com/

Kirishikiとは霧敷川（高沼排水路）のことで、実家の裏のあたりに流れている汚くも美しいどぶ川です。昔の地名なのでほとんど使われていないですし商標になることもないと思います。

独立準備ではありません（笑　念のため。

「ソーシャルアプリ」という言葉はバズワードっぽく使われてしまっているので、世間的には数年内に使い古された言葉っぽいイメージになると思います。そもそも”ソーシャル”といちいち冠する必要のない時期にもうなりつつあるからです。

このブログの最初の投稿で書いたように、

「ソーシャルアプリ」というのは、これからしばらく一種のバズワードぽくなるだろうけど、遊ぶ側、使う側にとってすればどうでもいいことかもしれないと思っています。

今でもそう思います。ユーザー・お客さんにとっての価値を表している言葉かどうかは微妙です。業界用語としてはいいと思いますが。

ドメインとサイト名・サイトコンセプトだけ捨て、コンテンツは新しいドメインのほうに引き継いでインポートしようと思います。新しいサイトの中でまた自分のやりたい方向性に沿って発信していく予定です。

これからのスマートフォンアプリ事業戦略 〜海外で大ヒットするスマートフォンアプリを作るために大事なこと〜

https://spreadsheets0.google.com/viewform?formkey=dEtlRXJ2cWJxX0hGYlpTSVkwTHBrM3c6MQ

一つ目の新さんの講演は業界の勘所を鋭くついた、大変充実したものでした。

「機会のイノベーション」とは彼自身の言葉なのかどうか分かりませんが非常に的確で、掘り起こしたニーズや市場に対してタイミングよく資源を集中投入するさまをゴールドラッシュにたとえたあたりも納得がゆくものでした。

スピードが重要なのはその通りだと思いますが、ただ早く動けば良いというものではなく、タイミングが大事かつ瞬発力が大事。早期参入しすぎても花開かないし、ここぞというときの（広義の）開発力が大事なのではないかと思いました。

CAアメリカの河野さんは前職からの知り合いなのでこうして活躍しているのはうらやましくもありうれしくもあります。まあ私よりずっと若いのですが・・・

サイバーエージェントはソーシャルアプリ業界の中で最もうまくやっているグループ企業だと思っていて、企画力・開発力・フットワーク良さ・人材の活発さなどで他をかなり引き離しているのではないかと思います。Facebookで成功した日本企業はないといいつつも、CAアメリカはかなり健闘していますよね。ユーザー数で見ると突出してはいなくても、Ameba Picoなどはかなりうまくいっているのではないかという印象を持っています。

パンカクのPANKIAというのはタイミングという点では？？？なのですが、実績ある会社ですし、勝算はあるのでしょう。ただコンテンツで売ってきた（というイメージのある）パンカクでさえプラットフォームになろうとする動きがあるところを見ると、iPhoneアプリ自体でビジネスやることの厳しさを想像してしまいます。

なんとなく危機感がふつふつと沸いたセミナーでしたが内容は非常に濃かったと思います。3人の講師の人選も絶妙でした。

——————————————————————————–
「なぜスマートフォンでイノベーションが起きるのか」
新清士さん

日本国内ではガラパゴスの市場ができている。これはどれくらい続きますか？
いつか終わるのは間違いない

3000万人いるとしても相当な数
日本国内では1億2千万人しかいない
そこで各社がどう動くかが焦点になっている

今日はかなりマクロな話をする・海外（アメリカの市場）

「機会のイノベーション」が重要になっている
iPhone3Gは十年前のゲーム用パソコンよりも性能が上。
それがまだムーアの法則が効いていて、技術がアップデートされるスピードが落ちていない

そのときに市場で回っているハードにマッチしたタイトルがガンと売れるという状況がここ5年起きている

なぜ、家庭用ゲーム機のローンチタイトルはヒットするのか
他に選択肢がないから
ローンチに紛れ込むのがいまは難しい
開発機材を調達することが難しい　技術的なアドバンテージを維持できる

いまのソーシャルゲームのルールは別。誰でも参入ができるハードウェア環境
ブロードバンド回線の5割以上の普及　これが一気にイノベーションを引き起こした

なぜZyngaは成功したのか？　Facebookのオープン化のタイミングに参入した
なぜモバゲーは成功したのか？　パケ放題のタイミングに全力を注いだ
なぜngmocoに四億ドルもの値段がついたのか？　AppStoreオープン化にタイミングを合わせた　Xbox Liveの仕組みをそのままiPhoneで展開しようという目論見が成功した
なぜ、いまAndroidなのか？説明しなくてもいいですよね

市場の変動が早い　3年で巨大Facebookソーシャルゲーム市場が成立
1年で日本でソーシャルゲーム旋風が起きた

ユーザーが「もういいよ」というところまでスペック・技術の革新は進んでいく
最近イノベーションが起きていない分野といえばメールくらいといえるが、メールですらGmailが無料になったりしている

アメリカンドリームそのもの　ゴールドラッシュとパターンが同じ
付加価値性がある間に収益を上げ、資本自身が収益を出せる体制をつくる
プラットフォーマー側（パブリッシャー・ミドルウェア・キャリア）に変わる・移る
ゴールドラッシュにいちはやく駆けつけ　
早くに砂金を集め　金鉱自体を買う、金鉱を掘るためのツールを売る、砂金を現金化する仕組みを販売する

初期の早くに砂金を集める段階は終わりつつある　資本力の勝負

Facebookソーシャルゲーム市場
超がつく超競争市場
フリーミアムモデルの一般化　アイテム課金市場の国際化
これから参入するにはよほど資本力がないと難しい
2010年1月　55万アプリもある

Playfish
ユーザー数は１４％増加したのに　アプリアクティブ率は２０％定価、特定のアプリのユーザー数１３％低下、トップ企業のアクティブユーザー数の増加が止まった

「もはや無料のチョコレートは存在しないのではないか？ピーナッツバターを得るためにはよりプロモーションコストなどのコストが必要になっていないか？」

日本から参入しても成功例はもはやない　DeNAの撤退　ブラウザ三国志の苦戦　インタフェースが難しすぎる

海外：もともとカジュアルゲーム市場が存在した　40代以上の女性が中心
Plants & Zombies
Popcap Games
カジュアルゲームから最も成功した企業の1社
無料ダウンロード1時間分の製品
徹底したQAプロセス　小チーム
少ない予算での口コミのプロモーション　1万ドル

AppStoreの状況　ほんと儲からない
3万タイトル以上　同じように簡単に埋もれる
トップ40タイトル中、0.99ドル以外のタイトルが2タイトルしかない
なんでこうなっているかというと、EAが0.99ドルのセールスをはじめた　まとめたパッケージ販売　タイトル内での広告

デジタルコンテンツ市場は必ず供給過剰に陥る　在庫フリー　再生産コストフリー　ネットディストリビューションはその流れを加速する
可処分所得から、可処分時間へ時間の奪い合い
前払い型から後払い型へ　価格は極限まで下がる

重要なのはセーブデータ
自分自身の積み重ねた経験だから、他のユーザーと交換できないもの
価格設定ができないもの
セーブデータの価値を増すような仕組みが必要　案外とその仕組みが不足している　例えばTowerDefence系の終了後のマップデータは保存できるようにするべき
上手い例：Kinect Adventure
ユーザー自身が作り出したものの価値がいちばん高い　クラウドソーシング　プラットフォーム側の収益が高い

勝ち方
パブリッシャー単位でのボリュームを出す戦略　大量にタイトルをかかえて、それをタイミングよく出す　規模の経済　グリーやDeNAも同じモデル　GameLoftがこの戦略を同様にとっている
ベンチャーはまじめに口コミをやらないと難しい　
例：Geodefence　サイトに定期的な情報アップデート　コミュニティ形成　フォーラムで積極的に要望対応
例：Fieldrunners　2人のパートタイムで開発　多プラットフォーム展開を急いだためにコミュニティ形成ができていない　悪い例
北米ゲームメディアはお金を払わないと載せてくれない
新規のテクノロジーにどうオーバーラップさせていくか
メディア戦略とも言い換えられる　メディア・ユーザーにどう取り上げてもらうか
AppStoreの市場では、ロングテール市場は無いと思った方がいい　ブランドの構築が大変

たとえばのケース
コミPo!
Kinectハック　モーションキャプチャーが簡単にできる
組み合わせると？→これが機会のイノベーション
存在しない市場のほうが意味がある　リスクはあるが、コストが小さいうちに参入するリスクのほうが重要

ソーシャル機能ミドルウェアに求められるもの
スコア機能、ソーシャル機能はあたりまえ　OpenFeintなどとの戦い　GameCenterには勝てない
弾力的なパブリッシングを仕掛ける能力　複数タイトルをまとめて価格戦略　ブランドとして価値を持つ　共同しなければベンチャーには難しい　
複数のプラットフォームへの展開　例えばiPhone, Android両対応

コンピューティングパワーは余っている　これからさらに余る　なのでユーザーに提供可能な隙間のサービスはこれからもいっぱいある　それはここ数年間変わっていない

——————————————————————————–
「北米ソーシャルアプリ・スマートフォン業界事情」
CAアメリカ シニアプロデューサー　河野さん

[Agenda]
自己紹介　CAアメリカの活動に関して
北米コンテンツ展開における教訓
北米スマートフォンアプリ業界事情
質疑応答

2010年3月から渡米　「1億人が遊ぶタイトル」が目標

CAアメリカの紹介
サンフランシスコに移った理由　駐在員が住みやすい　最近のベンチャーが集まっている

NinjaTrick　会員100万人　2010年8月にクローズ（撤退）
Ameba Pico　会員300万人弱
スマートフォン事業は2010/12~
G-CRESTでTinerMe　2009/10〜　会員150万人

北米コンテンツ展開における教訓

（１）企画マーケティングに関して
北米でうけるテーマ世界観が分からない　現地住み込みでとにかくいろいろ観察した
ゲームを遊ぶ層が分からない
有効なプロモーションメディアが分からない　テストマーケティング多用
→とにかく体感、ヒアリング・トライでカバー

（２）キャラクターテイストについて
想定以上の低年齢化　Ameba Picoは子供しか遊ばないとか　→マネタイズに不利
日本でうけたものが北米で受けない
感覚の違いによるトーンのずれ　アメリカでNARUTOが人気だったのでそれっぽいキャラデザにしたが、NinjaTrickのキャラがゲイっぽいといわれる
でも世界共通で受けるものもある　TinerMeなんかは日本とユーザー層共通

（３）慣習・ローカライズに関して
まず祝祭日がよく分からない
アメリカ人にとってどのイベントが重要なのかが分からない
何をやればユーザーが楽しいのかが分からない
→現地人プランナー、長期駐在者の理解が必要。

（４）ローカライズについて
ゲーム名の変更によるブランド機会損失
会員DBの分離と差異の発生により日本のユーザーが怒る。反面機動力は上がった
カニバリによる社内の調整　日本と海外版でユーザーが移動したり
→最初からグローバルを狙うかどうかで変わるポイント。

（５）翻訳に関して
日本人帰国子女が翻訳して、英語をアメリカ人に馬鹿にされる
普通の翻訳会社だとゲーム語に直せない
細かい文化の違い（OKとAPPLYなど、チェックのマークだったり）
→ゲームが分かって英語ネイティブ、の翻訳が◎

（６）多言語展開に関して
安易な多言語展開による開発工数の大幅増　フランス人ユーザーの初動があったのでフランス語対応したらデザイン工数の増加に苦しんだ
ファイルサイズ増加による通信ストレス　AppStoreの10MB制限など
→主要国で試してから考える方がベター。

（７）アバターか実名か
アバターではアメリカ人のマジョリティは取れない・・・という気がする
実名・写真公開でも言いたい放題レビューを書く
アバターは日本、韓国を中心としたアジア文化。
→ただし、人口規模があるのでマーケットは十分ある。

・さまざまな教訓から重視していること
企画・マーケティングに現地社員がいたほうが良い
（当たるテーマ、世界観、イベントの観点）
遠隔開発リリースより、現地に溶け込んだほうがよい
（ユーザー感覚とずれたものを作ってしまうリスク）
文化の違いによる隠された前提を洞察する必要がある
（でも現地に行ってみないとなかなか分からない）
うだうだ議論するよりとりあえずやってみることで事が進む。
（やることで社内が動く。調整より実行。）

■北米スマートフォンアプリ業界事情

[業界レイヤーとメインプレイヤー]
解析　Flurry
アドネットワーク　Admob　inmobi Apple(iad) Tapjoy
マネタイズ（決済・オファー）　TapJoy
メディア FreeAppaDay clickgamer.com　掲載料200万円で30万DLくらいになるとか
パブリッシャー　Chillingo
SAP　TeamLava　RovioMobile Capcom GameviewStudio
プラットフォーム　AuroraFeint　Crystal 　Plus+　Papaya
OS　Apple Android

業界トレンド
今年6月から、PaidAppsからFree2Playにシフト
iTunesStoreのTopGlossランキングに注目
ソーシャルアプリの場合メインプレイヤーはFacebookアプリのプレイヤーとは異なる新規プレイヤー
シリコンバレー周辺はiOSが主流　ウェブアプリよりネイティブアプリという状況
広告でも結構儲かっているアプリあり

[募集]
スマートフォンゲームを受託開発できる企業
ライセンス系コンテンツをお持ちで一緒に展開できる企業
一緒に働く人
ご協業ができましたらお気軽にお声がけしてほしい

—————————————-

パンカク柳澤さん
「これからのスマートフォンアプリ事業戦略」

米AppStore売上 Top25
有料アプリ(14/25)と無料アプリ(11/25)の数が拮抗　（アプリ内課金が盛り上がっているという意味）
DLが無料か有料かによって売上に大きな差は出ていない

有料：爆発的ヒットをしたものかAppStore黎明期に認知されたかすでに知名度があるものが中心
無料　元々の知名度が低い　知らないものがほとんど

ランキング
直近4日間のDL数の移動平均説が有力

無料で出すメリット
とにかくDL数が多い
有料の10倍〜20倍
タイトルを個別に見ると、ヒットタイトルであればあるほど有料の比率が上がる
LightBikeで１：７　Angry Bird１：３

事例：Paper Toss
iPhone 4750万DL以上、Android550万DL　5000万円以上の広告売上

AngryBirds 有料1200万DL　無料3000万DL　12億円程度の売上
Androidは無料版のみだが広告で8000万円以上の広告売上

Rovio（Angry Birdsの会社）
社員40名
フィンランドの会社
日本のデベロッパーでも同じことをできる会社はたくさんあるはず！

DLへの導線
AppStoreのランキングページが最強　これは未だに揺らいでいない
アプリレビューサイトは見てない　見るのは一部のマニア・同業者だけ　Freeappadayなどは例外
よくあるアプリ内広告はベースアップにはつながるが、最大瞬間風速に欠ける

埋もれやすいアプリレビューサイトではなく、大きなトラフィック（アクティブユーザー）のある部録・ウェブサービス、アプリからの導線は強力

これらを踏まえて

・結論その１
無料で集めた大量のユーザーを集約させ、次の収益源となるアプリ（有料無料問わず）のランキング入りを目指す

・結論その２
良い循環を巻き起こす最善の方法は
DL無料かつ収益化できるアプリのみを継続的にリリース
全自社アプリから新規アプリに対し、日付を指定して直接誘導する
「more」をクリックするやれるみたいなのは押しが弱い　特定の日にDLされるような仕掛けが重要→ランキング入りを狙う

これからのマネタイズ
「スマートフォンは儲からない？」
アプリ内課金に応じるユーザーはガラケーなどに比べると少ない印象
DL無料＋アプリ内課金で売上を上げるアプリがもっとたくさんあって良いはず

その分析
ガラケーはリテラシーの高くない層がメインターゲット
機種変更が増えるに従ってスマートフォンアプリにお金を落とすユーザーも増えるはず
そもそもAndroidの課金体制はまだまだ

今後
アプリ内課金による売上がじわじわと増大していき、Glossの売上ランキング上位を無料アプリが占めるようになる
ユーザーからお金を取らないもの（広告）が重要な収益源になる
例：iAd AdMob,リワード広告

Pankiaとは
北米でヒットするタイトルを出すための最善手段を提供するSDKです

北米でヒット・・・？
ゲームとしての普遍的な面白さを追求すれば国境を越える
non-verbalかつ文化に依存しないレベルまでシンプルにする
明確に北米ユーザーの好みに振って、そこからグローバルを狙う

面白さ・・・？
ソーシャルゲーム・・・
対戦・・・
結局のところ、人と協力しあったり、競い合うこと自体が面白い！

例えば
ガラケー向けゲームの傑作「チャリ走」はPANKIAを載せたあと米国AppStoreの全無料ランキング4位を獲得する大ヒット
人間の根源的ニーズを満たすゲームは国境を越える

いままでは
やり方がよくなかっただけ・・・！
”認知”がボトルネック
日本には世界ヒットしうるコンテンツの素がたくさんある！

PANKIAが提供するもの
対戦機能　ソーシャル機能により、友だちと競いあう面白さを創出
アプリ内課金、リワード広告によるマネタイズ
自社タイトル内での強力な誘導
多言語、複数プラットフォーム対応

PANKIAを利用して一緒に全世界で大ヒットするアプリケーションを連発させましょう！！！

前半で5社それぞれのプレゼン、後半でパネルトークという構成で、あっという間の1時間半でした。

リアルで楽しそうな会社ばっかりでしたね。開発力＋技術力がベースになってヒットタイトルが生まれていることを実感し、業界の勢いを感じさせました。

■ケイブ

”PHPエンジニア向け”とかなり限定して、PHPを主体に開発を行う5社合同のソーシャルアプリの勉強会です。

【残席僅か】STR Vo.2 “PHP x Social App”（CyberX,Sumzap,Pokelab,Cave,Klab） – EventForce

Eventforceで募集ってめずらしいですね。最近こういうイベントってATNDが多い気がします。

他SAP（他のソーシャルアプリケーションプロバイダー）勤務の方はご遠慮くださいとあるので注意してください。ガチの採用目的イベントのようです。まあ私も他SAP、しかもエンジニア面談担当なんですが（採用担当ではないです）。ブロガーぽいフリで参加してこようと思います。

PHPは使える人が多いし開発環境作るのも簡単だしと敷居の低さという意味では非常に良いと思います。同じことができるのであれば簡単なほうが、そのぶん企画など他のことに労力を割けます。

私も普段はインフラやりつつアプリも作っていて、PHPを使う機会も多いですが、PHPだからどうというのはソーシャルアプリ開発に限ってはあまり無いと思っています。むしろデータベースの選定とか、広義のフレームワーク・開発方法が大事かなという印象です。

言語にしてもインフラからバッチ処理まで全部PHPでやるとしたらそれはそれですごいと思いますが、全部PHPにこだわってる会社もそうはないと思いますし。

言語はもとより、今後スマートフォン向けに開発する際に、JavaScriptとの連携が重要になってくると思うのですが、そこをうまくカバーしたフレームワークなり手法を採用することが大事なのかなと個人的には思います。そういう意味ではScala＋Liftってすごくやりやすいみたいで気になっています。

それはさておき、イベントの内容はまたこのブログでレポートします。参加される方は現地でお会いしましょう。

PHPはレンタルサーバー借りれば最初から動いていることが多くて、CakePHPとかだとファイルアップロードすれば動く、みたいな状態になっていることが多いですよね。Ruby on Railsは始めてだったので苦労しました・・・。

ほとんどソーシャルアプリ関係ないですが、環境作ったあと、これからアプリ作っていきます。

Amazon Linux AMIをあえて使う必要もないかもしれません。今のところメリットが見えませんが、さくっと環境整えるにはちょうど良いし、CentOSとほとんど変わりなく使えます。

この記事では、sshで入れる状態になったあと、最小構成の状態のLinuxにRuby on Railsバージョン3を入れてチュートリアルが動作する状態まで紹介します。

ほとんど下記リンクとやっている内容は同じです。Amazon EC2でAmazon Linux AMIでやってる、というくらいの違いです。

いやー大変参考になりました。いくつも見比べるとよりトラブルシューティングに役立ちますね。

さくらの VPS に登録してみた(4) checkinstall, vim, zsh – まゆの日記

VMware + CentOS4 + Ruby環境インストール – プログラマー某の外部記憶

blog: CentOSにrailsインストール

CentOS 5.2 で railsをインストールするまで – akimatter

前回はMicro Instanceを使いましたが、今回はRubyのコンパイルとかでCPUリソースを喰うので、Micro Instanceでは時間かかって大変です。セットアップが一通り完了するまではLarge Instanceを使います（Smallは32bitしかないため）EBSで起動すれば、終わったあとスナップショットをとってMicroで起動し直せばLargeを使う時間は30分くらいなので100円くらいしかかかりません。

よく見たら、Launch InstanceでQuick StartのところにAmazon Linux AMIがリストされてるんですね。ここから選べば簡単です。

Largeインスタンスでデフォルト設定で起動します。途中は前回の記事参照。

[plain]
Yamada-Naoyuki-MacBook-Pro:~ yamadanaoyuki$ ssh ec2-user@ec2-xxxxxxxxxxxx.ap-southeast-1.compute.amazonaws.com -i .ssh/asia_satully1.pem
The authenticity of host ‘ec2-xxxxxxxxxxxx.ap-southeast-1.compute.amazonaws.com (xxxxxxxxxx)’ can’t be established.
RSA key fingerprint is xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘ec2-xxxxxxxxxxx.ap-southeast-1.compute.amazonaws.com,xxxxxxxxxxxxxx’ (RSA) to the list of known hosts.
   __| __|_ ) Amazon Linux AMI
   _| ( / Beta
   ___|\___|___|
See /etc/image-release-notes for latest release notes.
[ec2-user@ip-xxxxxxxxxxxx ~]$ sudo su
[/plain]
以降rootで作業してしまいます。必要なものを先にyumでインストール。
[shell]yum install git gettext-devel gcc rpm-build zlib-devel [/shell]
まずcheckinstallを入れます。これは各種アプリケーションをソースからインストールする場合にそれをRPM化してあとからパッケージとして管理することができるというものです。必須ではありませんが、アンインストールしたりする場合などに便利なので入れておきます。
RPM管理するということで、あとでRPMのソースディレクトリが必要になるので作成しておきます。
[shell]
cd ~
mkdir -p rpm/{SPECS,BUILD,SOURCES,SRPMS,RPMS}
vi .rpmmacros
[/shell]
で”.rpmmacros”の中身を下記にして保存します。
[text]
%_topdir /root/rpm
%_specdir %{_topdir}/SPECS
%_builddir %{_topdir}/BUILD
%_sourcedir %{_topdir}/SOURCES
%_srcrpmdir %{_topdir}/SRPMS
%_rpmdir %{_topdir}/RPMS
[/text]

終わったらソースをダウンロードするフォルダに移動。

checkinstallのソースはこちらにありますが、最新のgitレポジトリからクローンしてこれを使います。
[shell]
git clone http://checkinstall.izto.org/checkinstall.git
cd checkinstall
make
make install
[/shell]
ここまでは普通にソースをコンパイル＋インストールします。で、ここでcheckinstall自身もRPMにするために、その場でcheckinstallします。
checkinstallは/usr/local/sbin/に入りますので、下記コマンドでcheckinstallが走ります。
[shell]
/usr/local/sbin/checkinstall
[/shell]
[text]
checkinstall 1.6.3, Copyright 2010 Felipe Eduardo Sanchez Diaz Duran   This software is released under the GNU GPL.
The checkinstallrc file was not found at:/usr/local/sbin/../checkinstallrc
Assuming default values.
The package documentation directory ./doc-pak does not exist. Should I create a default set of package docs? [y]: y
Preparing package documentation…OK
Please choose the packaging method you want to use.Slackware [S], RPM [R] or Debian [D]? r

RPM package creation selected *
This package will be built according to these values:
1 – Summary: [ CheckInstall installations tracker, version 1.6.2 ]2 – Name: [ checkinstall ]3 – Version: [ 20100920 ]4 – Release: [ 1 ]5 – License: [ GPL ]6 – Group: [ Applications/System ]7 – Architecture: [ x8664 ]8 – Source location: [ checkinstall ]9 – Alternate source location: [ ]10 – Requires: [ ]11 – Provides: [ checkinstall ]
Enter a number to change any of them or press ENTER to continue:
Installing with make install…
（以下略）
[/text]
ドキュメントを作るか？という質問のところでは”y”で、パッケージメソッドの選択のところではRPMなので”R”で。
[text]
****************************************** RPM package creation selected *****************************************
This package will be built according to these values:
1 – Summary: [ CheckInstall installations tracker, version 1.6.2 ]2 – Name: [ checkinstall ]3 – Version: [ 20100920 ]4 – Release: [ 1 ]5 – License: [ GPL ]6 – Group: [ Applications/System ]7 – Architecture: [ x86_64 ]8 – Source location: [ checkinstall ]9 – Alternate source location: [ ]10 – Requires: [ ]11 – Provides: [ checkinstall ]
Enter a number to change any of them or press ENTER to continue:
[/text]

こんな感じで出力されると思いますので、問題なければENTERを押します。
[text]
**********************************************************************
Done. The new package has been saved to
/root/rpm/RPMS/x86_64/checkinstall-20100920-1.x86_64.rpm You can install it in your system anytime using:
rpm -i checkinstall-20100920-1.x86_64.rpm
**********************************************************************
[/text]
RPMが作られます。
[shell]
rpm -i /root/rpm/RPMS/x86_64/checkinstall-20100920-1.x86_64.rpm
[/shell]

でパッケージがインストールされます。
では次にrubyの最新版を入れます。ソースはこちらにあります。
[shell]
cd ../
wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p0.tar.gz

tar xzvf ruby-1.9.2-p0.tar.gz
cd ruby-1.9.2-p0
./configure –prefix=/usr
[/shell]

ここでprefixを/usrとするのは、prefixのデフォルトが/usr/localなので、普通PATHの通っている/usr/bin/rubyのほうにインストールするためです。このオプションをなしでconfigureすると/usr/local/bin/rubyにインストールされます。Amazon Linux AMIだとこちらにはパスが通っていないのでこちらにインストールした場合はパスを追加する必要があります。
[shell]
make
[/shell]
コンパイルします。ここはちょっと時間がかかります。これをMicro Instanceでやろうとすると時間がかかって大変です。。。
で、次にmake install とやらずに、checkinstallを実行します。
[shell]
/usr/local/sbin/checkinstall
[/shell]
同じようにすすめていくとRPMファイルが作られますので
[shell]
rpm -i /root/rpm/RPMS/x86_64/ruby-1.9.2-p0-1.x86_64.rpm
[/shell]
これでOKです。
[shell]
[root@ip-10-128-73-22 ruby-1.9.2-p0]# ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-linux]
[/shell]
ちゃんと入りました。rubyのパッケージ管理システムであるgemも一緒にインストールされています。
[shell]
[root@ip-10-128-73-22 ruby-1.9.2-p0]# gem -v
1.3.7
[/shell]

railsを入れます。今日（2010/09/20）時点ではデフォルトで3.0.0バージョンがインストールされます。
[shell]
gem install rails
[/shell]
railsプロジェクトを作ります。とりあえずテストで。
[shell]
cd /var/www/html/
rails new railssetup
[/shell]
作成されました。パーミッションの問題があるのでapacheユーザーにしておきます。
[shell]
chown apache:apache railssetup/ -R
[/shell]

次にpassenger（mod_rails）を入れます。passengerはrailsを動かすapacheのモジュールです。
[shell]
gem install passenger
[/shell]
passengerをセットアップします。
[shell]
passenger-install-apache2-module
[/shell]

対話型の丁寧なインストラクションが始まります。
[shell]
Checking for required software…
* GNU C++ compiler… not found
* Ruby development headers… found
* OpenSSL support for Ruby… not found
* RubyGems… found
* Rake… found at /usr/bin/rake
* rack… found
* Apache 2… not found
* Apache 2 development headers… not found
* Apache Portable Runtime (APR) development headers… not found
* Apache Portable Runtime Utility (APU) development headers… not found
Some required software is not installed.But don’t worry, this installer will tell you how to install them.
[/shell]
こんな感じで入っていないものが表示されますので、それらを入れていきます。
[shell]
yum install gcc-c++ openssl openssl-devel httpd httpd-devel
[/shell]

openssl support for Rubyを先ほど入れ忘れていました。yumでopensslを入れても、rubyのほうに入れないと動作しません。
[shell]
cd ext/openssl
ruby extconf.rb
[/shell]
これでMakefileが作られますので同様にcheckinstallで入れておきます。
[shell]
rpm -i /root/rpm/RPMS/x86_64/ruby-openssl-20100920-1.x86_64.rpm
[/shell]

再びチャレンジ。
[shell]
passenger-install-apache2-module
[/shell]

正常に終わると、この行をapacheの設定ファイルに入れてね、というメッセージが出てきますのでやります。
[shell]
vim /etc/httpd/conf/httpd.conf
[/shell]

[text]
LoadModule passenger_module /usr/lib/ruby/gems/1.9.1/gems/passenger-2.2.15/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.9.1/gems/passenger-2.2.15
PassengerRuby /usr/bin/ruby
[/text]

217行目付近に書いておきました。
DocumentRootも設定しておきます。290行目付近。/publicを付け忘れないようにしてください。
[text]
DocumentRoot “/var/www/html/railssetup/public”
[/text]

デフォルトでは本番環境モード(production)で動作しますので、今回はdevelopmentモードで動作するように環境変数を設定しておきます。下記の一行をDocumentRootの指定のすぐ下に入れておきます。”RailsEnv”で指定すると書いてあるところが多いですが、rails3からRackEnvになったようです・・・
[text]
RackEnv development
[/text]

ウェブサーバーを起動。
[shell]
/etc/init.d/httpd start
[/shell]

これで表示されるはず。

ところがAbout your application’s environmentをクリックすると・・・

sqliteがまだ入っていませんでした。sqlite3もyumにあるものではダメなので、ソースから入れる必要があります。こちらから。sqlite-amalgamationというので良いようです。
[shell]
cd /usr/local/src/wget http://www.sqlite.org/sqlite-amalgamation-3.7.2.tar.gz
tar xzvf sqlite-amalgamation-3.7.2.tar.gz
[/shell]

[shell]
cd sqlite-3.7.2/
./configure –prefix=/usr
make
/usr/local/sbin/checkinstallrpm -i /root/rpm/RPMS/x86_64/sqlite-3.7.2-1.x86_64.rpm
gem install sqlite3-ruby
[/shell]

おつかれさまでした。ここまで来たらEC2のLarge Instanceはストップし、EBSからAMIを作って、そこからMicro Instanceで起動しなおせばOKです。
ここからはチュートリアルなり、なんなりと。素晴らしいことに和訳もあります。
ruby/rails/RailsGuidesをゆっくり和訳してみたよ/Rails Database Migrations – 株式会社ウサギィwiki
次は実際にrailsでソーシャルアプリ作ってみます。

もう少しエンジニアとしての自分を押し出していきたいと思っているのと、最近仕事でやっていることがほぼ100%サーバーエンジニアリングなのでどうしてもそっちのほうに頭が働いているというのもあります。

業界の人とよく話すので、企画ネタだとどうしても、自分が思いつくネタが本当に自分のオリジナルなのか、他の人と話している中で出てきたネタなのか自信がないと感じたときに、けっこう書きにくいなと思います。その点、技術ネタっていうのは仕事でやっていても書きやすいんですね。基本的にオープンソースを使っているので還元したいというのもあります。

前はこういうのは個人ブログのほうに書いたこともありますが、自分のブランディングを兼ねてこっちに統一してみようと思います。

Amazon公式でEC2専用のLinuxが出たというのはけっこう画期的なことなんじゃないかと思います。OSもクラウド向けにカスタマイズされていくようになっていくのでしょうか。普段使っているのはCentOSなのですが、これはコミュニティ運営のOSで、数年前にちょっと運営が危機になったことがあったようですが、基本的にはそうしたコミュニティのOSSは信頼しつつも、将来的にいざというときにどうかな、という不安はあると思います。特に、私のようにOSについてそれほど詳しくなくて、とにかく安定したものを安価に使いたいと思う人は少なくないでしょう。Amazon Linux AMIはAmazon自身がメンテナンスしていくとしています。

また、EC2に最適化されているということで、もしパフォーマンス面で有利なのならばEC2内で広まる可能性もあると思います。カーネルが同じであればそう差が出るとも考えにくいですが、不要なサービスが入って無くて、EC2で使うのにとりあえずこれ使っとけばOK、といえるものがあるのは個人的には助かります。

ちょっと前にMicro Instanceというのも出ました。今回これを使ってみます。これはEC2の仮想サーバーの中で最安値のインスタンスで、これまでは一番小さいものでも1ヶ月フルで起動していれば6000円以上にはなったのが、Micro Instanceでは2000円以下で使えます。サーバーをいっぱい起動して分散処理のようなことをやってみたかったので、より気軽に試せそうです。

Amazon Web Services Blog: Introducing The Amazon Linux AMI

Amazon Linux AMIの提供開始 – Amazon Web Services ブログ

Amazonクラウド、クラウドにチューンされたLinuxとアップデートパッチを提供 － Publickey

とりあえず起動してみます。

Amazon Web Serviceのコントロールパネルから、Instances→Launch Instanceを選択。

Community AMIsからIDで検索します。IDは下記のURLから検索できます。

Amazon Linux AMI (Beta)

ここではAmazon EBS-Backend(64bit)でSingaporeを使うことにします。そうすると、IDは「ami-de26588c」になります（2010/09/18時点）。

「Select」で先に進みます。

EBSから起動する場合にはMicro Instanceが使えます。CPUは1コアのものが1個（最大2個まで増加）、メモリは613MBとスペックは低いですが、何か試してみる用途や、CPUもメモリも要らない用途には十分です。

その他のオプションは全てデフォルトのままにしました。「Launch」で起動します。

起動には20秒程度しかかかりません。

ec2-user@[public DNS]でログインできます。rootではログインできないようになっています。ログイン後、sudoでrootになれます。

最初から入っているサービスはこれだけです。

ディレクトリ構成はCentOS風になっています。yumでパッケージ管理できます。amzn.repoというレポジトリを使う設定になっています。いつも使っているCentOSデフォのものと比べてアプリケーションのバージョンが新しくて、PHPは5.3、MySQLは5.1などとなっているのがちょっと気に入りました。

私自身はAmazon EC2にSmallインスタンスを1つずっと起動しっぱなしで持っています。いまのところ用途はこのブログ（Wordpress PHP+MySQL）と個人用のsubversionです。このブログがあるのでアクセス時間によってはMicro Instanceでは厳しそうなのでこのままSmallで使おうと思いますが、とりあえず何か試してみる、といった用途にはMicro Instanceはかなりよさそうな印象を持ちました。

Amazon Linux AMIについてはEC2にどう最適化されているのか分かりませんが、CentOSとそう変わらない感じで使えそうなので、せっかくなのでEC2上ではこれを使っていってみたいと思います。

さくらインターネットとかニフティクラウドとか、日本のサービスも頑張っていますが、AmazonはS3やEBSやその他もろもろが便利＆魅力的すぎて、用途次第なのでしょうが、全体的なサービスの豊富さでかなり差がある印象を受けます。Amazonが日本にサーバーを置くのも間もなくでしょうし、使う側にとってはますます楽しみになってきました。

私が参加したのは下記の4つです。

【オープニングプレゼンテーション】 「mixiアプリプラットフォームの次の展開」

【B-1】 ソーシャルアプリ構築のベストプラクティス

【B-2】 エンジニアトーク「日本のプラットフォームの現状と今後」

【メインセッション】　mixi新プラットフォームの発表　- 時代は「インターネット」から「ソーシャルネット」へ

各セッションのライブ記録としては下記もよくまとまっていますので同様に参考にしていただきつつ。

【mixi meetup 2010】「Opening Session」のまとめ：プロジェクトマネジメント10.0：ITmedia オルタナティブ・ブログ

内容については各メディアにも掲載されていますが、こういう場所に参加して良かったと思うのは現場にいることでより危機感が煽られるということですね。改めて次のアクションを早く起こしていかないと、という気持ちがわき上がってきました。

この「socialapplication.jp」というドメインを取ったのが去年の2009年の4月のmixiのソーシャルアプリカンファレンスの直後だったと思います。そのときは何か飯の種程度になれば、と思っていましたが、ここまで日本でも業界として確立するとは思っていませんでした。そうした業界の確立をリードしたのがmixiであるならば、今回のカンファレンスも1つのマイルストーンになるでしょう。キーワードは「仕様の統一」です。

今回個人的に一番インパクトがあったのが、スマートフォン対応アプリがリリースされたことです。mixiが先駆けてリリースした（gumiはともかく）OpenSocialのRestful APIにおいてモバゲーもGREEもほぼ同じ仕様を採用したように、スマートフォン向けアプリの仕様も今回mixiがリリースしたものがベースになっていくと考えられます。これがモバイル型のAPIをベースにしつつも特定のJavascriptをインクルードすることでJavascriptによるAPIも使えるという、大変よく考えられたものになっています。エンジニアトークの中ではいまのモバイル向けOpenSocialの仕様を世界標準として提案中であることにも言及がありました。

グローバル展開についても注目かもしれませんが、サービスのやり方やローカライゼーションの問題もあるのでそうすんなりとはいかないと思います。ただ、ここも「仕様の統一」という面でみると画期的なことだと思います。

Techwaveにも書かれていたのでやっぱり同じことを思う人は多いんだなと思ったのですが、これで「mixi & ヤフーモバゲー」 対 「GREE」の構図は鮮明になった感じがします。かといって1対1の勝負になったのかというと、AmebaやFacebookもこれらと同じくらいの一大勢力にはなりえるんじゃないかと思います。

mixiの特徴の1つは、モバゲーやGREEと違って内製でアプリを作っていないことです（一部キャンペーンなどで例外あり）。

PlayfishのGMのKristian Segerstrale氏による興味深い言及があります。

【mixi meetup 2010】②グローバルSAPの参入戦略、議事録：プロジェクトマネジメント10.0：ITmedia オルタナティブ・ブログ

Q.プラットフォームにおけるフランチャイズの成功要因は何か。

A.プラットフォーマーがコンテンツを作ることは、創成期には意味がある。ただいつまでもそれを続けるとサードパーティーの意欲をそぎ、成長を阻害する。

このあたりはこの発言を引用するにとどめておきます。

ところで、どうしても腑に落ちないのはmixiが「ソーシャル」という言葉をマイミク間のコミュニケーションに限定して使っていることです。

mixiの立場としてマイミク間のコミュニケーションのみに限定したところでSNSとしての価値を高めていきたいというポリシーはとても理解できるし、mixiの差別化戦略として良いと思うのですが、そうでないものをソーシャルでないと言い切ってしまうあたりが残念です。まあ分かりやすさのために言い切っているのかもしれませんが。

私は、ソーシャルとは仲間内のものから近所の人、たまたま同じ時間・場所を共有した人まで、あいまいな境界線でできているものだと思っています。

昔、MMORPGをやっていました。たとえば「Dungeons & Dragons Online」などはすごくのめりこんでやっていました。そこではギルドといって決まったメンバーだけでグループを組んでその中でパーティを組んで冒険するのと、野良パーティと言っていましたが、掲示板のようなものがあってそこから募集したりそれに応募したりして、その都度初めての人同士でパーティを組んで冒険するという2つのスタイルがありました。私は途中からギルドに所属しましたが、その後も野良パーティにはよく参加していました。ギルド内での濃く連携したコミュニケーションを望む一方、新しい人と出会ったり、知らない場所に行ったりするのに野良パーティが最適だったからです。また、ギルド内だけでずっとコミュニケーションし続けることに疲れる部分もありました。

また、RTS（Real Time Strategy）もよくやっていましたが（たとえばAge of Empires III）、こちらはギルドではなくクランといっていましたが同様のものがあって、そのグループに所属してクラン同士で対戦する、というスタイルがある一方で、対戦ロビーみたいなものがあってそこで適当にゲームをホストして誰か条件に合った人がルームに入ってきたら対戦する、というのもよくやっていました。ロビーでの対戦なんて、仲間や対戦相手に対して「hi」「gg」(Good Game. ゲーム終わり、のこと）この二言だけしか言わないことも多くて、そういうのはコミュニケーションとは言わない、という意見もあると思います。でも私は立派なソーシャルだと思います。

そうした「全国大会」も「マイミク大会」と同程度には大事で、楽しいことだと思っています。そこはやり方次第であって、ゲームを進めるためにマイミク同士にならないといけないといった条件をつけるとソーシャルグラフが壊れると思いますが、そこをその都度限りのコミュニケーションとするようなかたちであれば良いのだと思います。

また、こうした仲間内だけでない一期一会的なソーシャル関係を「バザール的ソーシャル」と言い表しているブログを読んで、これだ、と膝を打ったことがあります。

位置ゲーからみるもう一つのソーシャル性 :コラム：インターネットビジネスの種：VentureNow（ベンチャーナウ）

さらには「ギルドやコミュニティの寿命」みたいなところも非常に興味ある分野なのですが、また機会をあらためて書きたいと思います。

ちょっと本題でないところに熱くなってしまいましたが以下メモです。会場でメモったものなのであんまりまとまってないです。何が話題になったかとかキーワードとかはつかめると思います。

——————————————————————————–

10:30~11:00

mixiアプリプラットフォームの次の展開

——————————————————————————–

mixiアプリの総括と今後の展開

公開アプリ数・2000突破

MAU 1450万人（2010年8月）

月間アクティブ率70%

登録数　2100万人

ローンチ後6ヶ月時点での継続率

ソーシャル性の高いアプリ55％

ソーシャル性の低いアプリ24%

mixiアプリとは

ソーシャル/ネットワーキングサービスの1つ

友人・知人とのコミュニケーションを媒介するもの

コミュニケーションを支える進化

アプリの成長過程に応じて、アプリ内でコミュニケーションを生み出すAPIを随時開発。

ボイス連携

フォト連携

今準備中のAPI　9月末公開予定

リクエストAPI デジタルギフトなどに最適

よりコミュニケーションを豊かにするために、コミュニケーションをさらに促し、ユーザーさまが快適に楽しめるようにAPIを強化していきます。

アプリへの導線強化

・通知枠からの誘導

・ホーム画面右カラムへのおすすめアプリの表示

・アプリトップページ拡張　「ソーシャル性の低い」アプリに関しても導線を緩和。10月より。

プロモーション強化

10月以降ホーム・アプリ面でのmixiアプリのプロモーションを強化

マネタイズ支援

UU創出型アプリの支援強化

UU単価　0.37円　PV単価 0.004円   

ローンチ時より課金開始が可能に。

インフラ支援

アプリ売上の10％のレベニューシェアでインフラを提供　←安くないか？

プラットフォームの拡張

世界初3デバイスプラットフォーム

スマートフォン版対応アプリ　課金も可能

広告も料率同じ

ブラウザベースのmixiアプリの他、Appsベースのmixiアプリも準備中

No.1ソーシャルプラットフォームへ

そして世界につながるプラットフォームへ

より世界に出て行きやすい仕組み→午後発表

——————————————————————————–

11:30~12:15

ソーシャルアプリ構築のベストプラクティス

——————————————————————————–

インフラ面・サーバー面について

ソーシャルアプリケーション開発・運用に求められる

スケールｘスピード　＆ローコスト

ベストな手法について考えていきます。

ニフティ上野さん

ニフティクラウドの紹介

ライブドア冨成さん

DATAHOTEL レガシーな形のデータセンターサービス　フルマネージド

Google松尾さん

Google Ap Engine

全体で10万アプリ

1日5億ＰＶ

最大QPS1600

ソーシャルアプリのベストソリューションとは？

※モデルケース

HTML+Flash動的生成

DAU10万人

2000万PV/Day

開発言語未定

mixiやモバゲーで10位〜20位くらい

ソーシャルアプリのPV推移例

一気に上がって下がる→安定期　こんな傾向なのか。アプリが1ヶ月後に急激にＰＶが下がるのは違った傾向。

ソーシャルアプリのサーバー増強例

「みんなで検定」の場合

Web x 3

Cache x 2

DB x 2

↓ 3 weeks

Web x 18

Cache x 3

ReverseProxy x 3

DB x 4

ニフティの構成案

ウェブ small2 アクセス量に応じて増減

Flash Large8 CPU能力を多めに　

Cache medium8 メモリ搭載量を多めに

DB Large16 マスター・スレーブ マスターDBの分割を考慮

※コピー機能を実装予定（10月）

※オートスケール機能を実装予定（10月）

ライブドアの構成案

webに標準10台〜20台

メモリはサーバー間でmemcacheをクラスタ化して使うなら4GB、独立して使うなら8GB

db

batchサーバー ここにスレーブを構成する案もあり

admin/staging

どうやったら少人数で運用できる？

ライブドアならフルマネージド

バージョン管理システムを依頼して入れてもらう　←??

Google App Engine

Flashの動的生成は無理

負荷分散についてはほとんど何もする必要がない

気をつけること　

・平均1000ms以下でレスポンスを返す　※そうでないと自動スケールしません

・重い処理はTaskQueueで

・デフォルトで50QPSの制限　それ以上必要なら相談してください

さきほどの規模だとどれくらいのコスト感？　難しければミニマム構成で

ライブドア：月額50万円くらいでスタート　POIケースなら30万円くらい

質問：Amazon EC2との比較

ニフティ・国内のレイテンシ　サーバー落としてもデータが消えない　ディスクがローカルで見える　コピー機能とオートスケール機能も追加予定

ライブドア　特に問題となるのは海外クラウドの場合、携帯端末向けアプリの応答時間。また、性能面では物理サーバーはかなり有利　1/14程度の性能

Google　分類的に違うので直接比較は難しい

——————————————————————————–

12:30~13:15

エンジニアトーク　「日本のプラットフォームの現状と今後」

——————————————————————————–

mixi山下さん　mixi appli for touchなどのリリース

DeNA山口さん　zigorou

ケイブ安生（あんじょう）さん　Google API Expert

グリー山家さん

Google北村さん　ChromeのDeveloper Advocate　

各SNSのAPIの違い

【mixi】

Classmates API

あるユーザーと同級生かどうかを判断できるAPI

同級生へのinvite

mixiアプリからボイス投稿API

アプリ内でつぶやけるAPI

アプリネタでコミュニケーションを！

→アクティビティAPIとの違いは？

mixiアプリからフォトアップロードAPi

アプリ内で作られた画像を登録するAPI

アプリによる面白いフォトをネタに！

【モバゲー】

Textdata API 自由入力文を保存するためのAPI

Ngword API　入力テキストにNGワードが含まれていないかを判定するAPI

Avatar API　ユーザーのアバターを画像またはswf形式で返すURLを取得するAPI　

Avataritem API ユーザーが所持しているアバターアイテムを取得・削除するAPI

Avatarshop API　販売しているアバターアイテムを取得するAPI

Blacklist API　ブラックリストに登録しているユーザー一覧を取得するAPI

【グリー】

Inspection API コンテンツを監視するためのAPI

Ignorelist API　ユーザーの禁止リスト（ブラックリスト）取得用API

Payment API　課金API

mixiにはコンテンツ監視とかブラックリストがないが？

→マイミク大会・全国大会と呼んでいるが、知らない人と交流することをそもそも想定していないから

・モバイルのプラットフォームについて

モバゲーの場合はアクセストークンを発行している

いま、海外のOpensocialの団体に使用標準化を諮っている状態　サンプル実装開発中

・スマートフォン

【mixi】

本日より開始するアプリ

まちつく　キャバウォーズなど

iframeの中はSAPのドメインをそのまま表示するかたちになっている

applicatin/touch.jsを読み込むことでjavascriptのAPIを使える

他のAPIについてはRestful APIで

ネイティブアプリで使える仕組みというのもやっている　午後発表されると思う

【モバゲー】

モバゲーもiPhone版は年内に出る

【グリー】

つい先日有料課金がスマートフォン上で可能に

年内にスマートフォン向けゲームを開発中

3社とも明確にスマートフォンでブラウザ版、ネイティブアプリ版を進めている

Q：デベロッパー向けに支援することはあるか？

mixi→インフラ支援はある

モバゲー→同じ。インフラ支援はあり

グリーも→同じ。コンテンツ内容のコンサルティングはある

Q：エンジニアとしてここが好きだなと思うところ　やりがい

mixi

PC版はshindigがベース

モバイルはスクラッチでPerlで

モバゲー：全部Perlで　ヤフーモバゲーはGadgetのレンダリングはsyndigg

GREE：ほとんどPHP　処理速度が必要なところはエクステンションのPVあたりのエンジニアが一番少ない

Q：NGword APIの統一なんかは？

まだそこまでいっていない

——————————————————————————–

15:00~17:00

mixi新プラットフォームの発表

——————————————————————————–

Next mixi Platform

MAU 1447万人

今回のオープン化の対象領域

mixi.jp外

mixiが目指すもの

ソーシャルグラフプロバイダー

mixi Connect →　バージョンアップして2つの仕組みに

(1)mixi Plugin 外部サイトでタグをいれるだけでmixiの機能を簡単に導入可能

(2)mixi Graph API

何ができるか

１　ウェブのソーシャル化（SGO)

２　サービス・デバイスとの連携　

３　ソーシャル関連ビジネス

１ウェブのソーシャル化

mixi checkボタン

最も簡単にウェブをソーシャル化できるツール　お気に入り機能

本日より一般公開

ボタンを設置したいページに数行のHTMLを追加するだけ

本日から開始するサイト紹介

食べログ

asahi.com

その他のプラグイン

ワンクリックでmixiの投稿ページへ

Simple Postシリーズ

mixi check pluginの発展系（2010年12月公開予定）

友人の写真を表示するプラグイン

ネット上への投稿に抵抗があった一般ユーザーへのPOSTを促進

これにより高い連鎖CTRが得られるバイラル加速ツール

「イイね！」ボタン

mixi Graph API

既存のサービスからmixiのGraphにストリームできるAPI

たとえばECサイトで購入したらそのフィードがmixi内に飛ぶ（ユーザーが設定していれば）

レビューサイトやCGMでも投稿したらmixi graphへfeed

例：楽天

１　導入サービス紹介

ichiba gora books travel デリバリーの5サービスで展開

２　mixi Graph API連携

楽天共通プラットフォームを経由して投稿することになる

将来的にはお気に入り登録した時点でシェアされるようなかたちを考えている

３　サービス別取り組み内容紹介

例：はてな近藤さん

「はてなでゲームは作れません」

3つのサービスでmixiチェックに対応

ブックマーク　はてなココ　Hatena::Diary

T型コミュニケーションを促進する

今週、mixiもロケーションサービスをはじめました

mixチェックイン　mixiのネイティブロケーションサービス

はてなココとmixiチェックインの関係　mixi上でミックスされる

相乗効果で日本のロケーションサービスを盛り上げ

リアルスポットのソーシャル化を促進

mixiが常にソーシャルプラットフォームで世界の先端を走り続けてきた分野＝Mobile

mixiチェックとmixiチェックイン

3キャリアの利用許諾でました　本日より公式サイト、一般サイトとも申請やブリッジページなしで設置可能に。

DeNA　x mixi連携戦略

本日DeNAのさまざまなサービスでmixi連携がスタート

モバゲータウンでも連携

mixiアプリについても10月より導線改善　モバゲータウンとの連携はより強化していきたい

チェック　カレンダー　ストック向き

イイね！　つぶやき機能　フロー向き

最適なツールでSGOを

SEOからSGOへ

Information DesignからEmotion Designへ

ネタになりつつマーケティング効果を失わない設計

２　サービス/デバイスとの連携

mixi Graph API

あるウェブサイトにmixiボイスを丸ごと組み込むことが可能　mixi.jpに飛ぶ必要がない

プロフィール連携

ボイス

フォト

カレンダー

チェックイン

このあたりのAPIを利用したアプリ開発が可能

ヤフー　喜多埜（キタノ）さん

Life Engine

事業戦略4つの柱　ソーシャルメディア化、Everywhere化、地域/生活圏情報の充実、オープン化

サービスと事業領域の拡大

mixiチェックとの連携　順次対応予定

Yahooポッフィ　POST+FEED

Yahoo!Japanの各サービスやmixi twitterなど複数のソーシャルメディアサービスをまとめてチェック

デバイスとの連携

ウェブ以外のサービス・デバイスでの活用

デジカメ・ソーシャル電話帳・テレビ録画サービスとの連携

mixiがサービスやデバイスなどに柔軟に組み込まれていきます

ーーここから田中洋一郎さん

New mixi Platform Overview

これまで：mixiアプリ　mixi Connect mixi OpenID

(1)mixi Plugin

簡単・シンプル

(2)mixi Graph API

技術的には高度になるが、より柔軟なことができる

5つのAPI people groups updates voice people_lookup

いままで紹介してきたものはすでに世の中にある標準指標をもとに作成してきた

ご利用いただける範囲（パートナー・個人）

mixi Pluginご利用までの手順

https://sap.mixi.jp/check_developers.pl

http://developer.mixi.jp/

年内までに個人開発者に開放

３　ビジネス支援プログラム

今回のプラットフォームによる新たなビジネスを支援するビジネスサポートプログラムを導入する予定です

１，課金

２，アドプログラム

３．mixiファンド

４．現在準備中の次のプラットフォーム予告

次のオープン化領域はmixi.jpとの中間くらいにプラットフォームをつくる（コミュニティプラットフォーム（仮称））

プラットフォームに関するもう一つのご報告

2つのSNSとアライアンスとアライアンスを締結しました

renren.comとcyrworld

mixiは2つのSNSとアライアンスを締結しました

プラットフォームの共通化をはかり、国内のパートナーの海外進出を支援

2億人へつながるプラットフォームへ

本日発表したAPI群も共通化していく方針

また、今回はアジア2カ国との関係だったが、今後各国No.1SNSを中心にアライアンスの輪を拡大

海外展開についてはアライアンス展開以外も今後発表

＃ソーシャルグラフがもたらす新しい流れ

ネットのスタートはソーシャルストリームへ

情報経路は検索からソーシャルグラフへ

全てのウェブはソーシャルかで価値が増幅

それは実世界へもつながり波及していく

従来のインターネットとは違う、新たなネットワーク”ソーシャルネット”につながる世界へ

「コミュニケーションのインフラになる」

Social Graph Provider

下記3セッションについて取り上げます。

大規模ソーシャルゲームのつくりかた ～60分でわかるサーバサイド技術～

藤本 真樹 （グリー株式会社）　ほか1名

2000万人を魅了するソーシャルゲームの作り方

吉田 大成 （グリー株式会社）　ほか1名

怪盗ロワイヤルができるまで、できた後

大塚 剛司 （株式会社ディー・エヌ・エー）

まとめページとしては下記がよさげです。

CEDEC　2010 記事&感想まとめ ※追記更新します – 3dnchus jimdo page!

今のところ確認している、他メディアへの掲載。

【CEDEC2010】各社が公開、大規模オンラインゲームのバックエンドの秘密 – GAME Watch

CEDEC 2010：「ソーシャルゲームは生き物」　「怪盗ロワイヤル」大ヒットの裏側 (1/2) – ITmedia Gamez

————————————————————————————————————————
大規模ソーシャルゲームのつくりかた ～60分でわかるサーバサイド技術～
藤本 真樹 （グリー株式会社）　ほか1名
————————————————————————————————————————

GREEの紹介
SNS+ソーシャルゲーム＋プラットフォーム
2059万人
11億デイリーPV
数千台のサーバー
同時接続10000くらい
レスポンス200msくらいを目安

コンシューマ向けオンラインゲームとの違い
コンシューマ：専用クライアント→Proxy→フロントエンド→バックエンド
ソーシャル：ウェブブラウザ→LVS＋Proxy→ウェブ→DB
結論：そんなに変わらない

（コンシューマ）
同期
ステートフル
世界の境界がある
低レイテンシ
アクセスは夜から深夜
コアゲーマー

（ソーシャル）
非同期アクセス
ステートレス
世界の境界がない
朝や昼もユーザーがプレイ
普段ゲームをやらない人もプレイ
アーキテクチャ

（GREEのサービス自体が）メンテナンスをしないというのも特徴

釣りスタの紹介
2007年5月リリース
エンジニア3人
最大同時プレイ人数は25万人←同時の定義は？

【釣りスタをコンシューマで作るなら】
釣り場ごとにFrontend Serverが存在する
ログイン時にバックエンドサーバーからデータをロードし、フロントエンド上のメモリに置く
状態変化したら更新＋その変更を他のクライアントにも速やかに伝える
即時反映の必要がなければ後から更新

こうするとリアルタイムのメリットがあるが、サーバーをまたいだ処理が難しくなるため、スケールに限界がある
バックエンドサーバーもスケールするように作らなければならない

【GREEの構成だと】
すべてのウェブサーバーは等価。Proxyは一番負荷の低いウェブサーバーにリクエストを割り振るだけ。
そうするとデータベースがネックになる
master情報、user、item,図鑑、rankingなどで全て別のデータベースサーバーにしている

かなりシンプルであるが、MySQLをスケーラブルにしておけば全体がスケール可能
情報をとること自体にコストがかかることを意識する必要がある

最近のソーシャルゲームは5キーを押すとゲームが進行します

モンプラでは
冒険に出る
元気が減って
経験値が増える
達成率が増える
他のモンスターエンカウントする

ただ、これをMySQLでやろうとすると更新処理が多すぎて破綻する

・・・ここで藤本さんに交代

RDBMSのボトルネック
ほとんどはdisk/io
write 15krpm RAID10 で2m-3mbytes/secが目安　readはオンメモリが前提
日々ディスクIOを同さばくかとの戦い

ソーシャルゲームはとにかくwrite heavy
リリース直後のダウンはほぼこれが原因
一部機能はSQLが複雑になりがち
ex 最近ここで魚を釣った友達
ex このアイテムを持っているバトル相手一覧

解決策
１ Sharding
２ diskにかかない　オンメモリファイルシステム
３ diskにあまりかかない　キャッシュ(memcached)や中間データ（KVS）の利用

MySQLのレプリケーションの解説　数十台のスレーブの例もあり

垂直に割る方法
水平に割る方法　同一テーブルを範囲ごとに分割する　Range, Hash/Modular, Index
JOINは基本的に全くしていない

データベースを分けるときに心得ていること　次の2点は担保しておく
・ユーザーの不利益にならないような順番でデータを更新する
・ログを必ず出すようにしておく

水平にShardingするとuser_id以外のconditionが制約になる
たとえばageなどで検索したい場合は？→（invert）転置インデックスを用いる　年齢をプライマリーにしたテーブルを別DBに作っておく
　
究極を言ってしまうと、tmpfsに全データを置いてしまうのが楽。 ioがネックになることはほぼなくなる
ただしサーバーダウンでデータロスト
もしやる場合、ラック単位はもちろんデータセンター単位で分散したりしている
適宜スナップショットをとる
トラフィック　12.5k x 1万qps = 1Gbps
Swap領域
データサイズ

GREEでは　I/OはKVSを用いる　Flare
RDBMSよりパフォーマンスがよい
運用コストが低い
Memcachedよりもデータ信頼性が高い
モンプラならレベルアップの段階でデータをFlushする

サーバーサイドのフロントエンドなポイント
構成の標準化が重要　（Real server or VM?）
たとえばJAVAのDAOに注意
GREEのDAO　DAO:table = 1:1
Shardingをサポートしたアプリプログラミング
SQLの実行時にシャードやテーブルを決定するインタフェース
コストの高い処理は非同期で
「〜さんが〜しました」等のお知らせにはQ4Mなどを使用

チート関連：手動ブルートフォース
モバイルユーザーのガッツは侮れない　場合によっては手分けして・・・
サーバー側トークン＋想定の1段〜2段上の厳しさでチェックしたほうがいい

CSRF対策
仲間を全て削除やステータスリセットへのリンク
主要な処理にはサーバートークンが必須
その他リロードや画面メモ対策など

slaveの切り離し・追加
・ウェブサーバー上のＤＢコネクション情報更新
・スタンドバイ機を利用
マスターが落ちたら
適宜自動化全スレーブでbinlogポジションが一致しているサーバーを用いる

無停止のために・・・
マスターの下にマスターを作ってそこでALTER TABLE　←　必要な場合、これは使える。ただ余分なサーバーが必要だが。

【チェック項目】
レプリケーション状態
遅延状態
テーブルデータサイズ
スローログ
スレーブへの直接書き込み
サーバートラフィック
時計がずれていないか？

質疑応答

ドリヅル　MySQLの簡単バージョン
これらしい
Drizzle (database server) – Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Drizzle_(database_server)

KVSの使用機会が増えている
tmpfsだとパフォーマンスは出るがアップデートログの書き込みすら追いつかなくてディスクへのフラッシュができない

————————————————————————————————————————
2000万人を魅了するソーシャルゲームの作り方
吉田 大成 （グリー株式会社）　ほか1名
————————————————————————————————————————

吉田さん
前職Yahoo
釣りスタ・ドリランド・モンプラのプロデュース

富田さん
前職スクエニ
モンプラのディレクター

6つの内製の中には1000万人を超えるサービスもある

１組織
２企画
３未来

### １組織 ###
垂直統合型スキルセットが必要。＋プロフェッショナルスキル
ゲーム業界は水平分業型。
少数精鋭のチーム体制
少人数によるスピード感
現場主義
プロフェッショナルチーム
同じものを再生産しない体制

・モンプラのケース
プロデューサー兼エンジニアｘ１
ウェブエンジニアx２
Flashエンジニアx１
ディレクターx２
インフラエンジニアx２
デザイナーx２

サービスと個人の成長を最大化する組織体制

データ駆動型アプローチ
1個人のセンスより数千万人のデータ
デザイン１つにもロジカルさを　
おもしろいと思うのはあなただけ
ゲーム開発者は自分がマイノリティであることを自覚すべき

PDCAサイクルの徹底
どの指標を改善するための企画なのか？
この企画により何％変化することを示す
実際にリリースしてみて何％変化したのか？
自分の企画精度を修正→それによってマジョリティ意識をもつ

データマイニングツール　GREE Analytics
登録日、登録経路、そのユーザーの利用状況→ＣＭの効果測定に利用
各イベントの参加率　プレイ率　消費率　アイテム別売上　ゲーム進捗状況　継続率などでゲームバランス調整

プロモーション効果を定量分析化

バナーやアイコンを何種類か試して一番よいものを採用

### ２企画 ###
企画三大モデル　集客・活性化・収益化　この3つが1つのサービスの中でしっかりカバーできているか
集客　ユーザーが集まり続ける仕組み
活性化　ユーザーが使い続ける仕組み
収益化　利益が上がり続ける仕組み
スーパーなどのビジネスのやり方とそう違わない

流入率ｘログイン率ｘ課金率ｘARPU

環境管理型アーキテクチャ＆ユーザーインタフェース
ルールや規制倫理ではなく、環境によって人間をコントロールされていると感じさせずにコントロールするシステム

ユーザーの迷いをなくし、選択と決断を連続的に行わせられるか

【集客モデル】
プロモーション（ゲームデザイン）ｘバイラル（ソーシャルデザイン）
誰もが知っているモチーフ＆誰もが理解できるゲームルール
釣り人口やペット人口や園芸人口などもリサーチしている

バイラルサイクル2種類
ゲームで遊ぶ→コインアイテムがほしくなる→友達を招待する
ゲームで遊ぶ→友達を一緒にあそびたい→友達を招待する

（参考）バイラル効果を可視化する
DAUx 招待率
招待送信UU x 一人あたり招待数
招待数 x 拡散率
招待受信UU x 承諾率
登録UU

【活性化モデル】
さまざまなゲームモデル
ユーザー間コミュニケーション
小さな達成感→→→大きな達成感というステップアップ
短期・中期・長期のゲームサイクルに欲求・達成感を配置

経験値ＵＰ　プレイ対価　レベルアップ　成長感　ロック解除　世界の拡大　コレクション欲求　コンプリート欲求

テキストより画像で履歴を表現　感情を画像で表現　←重要な気がする
あそばれた履歴を確認→ともだちの牧場を訪問→あそぶ→なつきがアップ→あそび履歴がもどる
運営者からのお知らせ　＜　友達からのお知らせ
コミュニケーション活性化は最大のリテンション効果

（参考）ユーザー間コミュニケーション効果を可視化する
DAU x あそび率
あそびUU x 一人あたりあそび回数
総あそび回数 x 拡散率
あそばれ率 ｘ 再ログイン率
再ログインUU

【収益化モデル】
納得のいく失敗　劇的な変化　ネットワーク効果　自己顕示欲の最大化

失敗→課金→劇的な変化
失敗に意味があること　失敗の画面が何より大事　効果が見た目で分からなければ二度と購入しない
細かいゲームバランスよりも課金機会の演出・効果の演出が重要
画像で表現　行動ポイントが無くなった→「おなかがすいた」→おなかがすいたキャラクターの表現　普通にテキストで出しても、行動ポイントが切れたことにユーザーは納得しない

協力型イベント　演出に凝る
競争型イベント
コミュニケーションを収益化　飴ちゃんetc

ユーザーの熱量を収益につなげる
ユーザーの成果を露出する面を増やす

ユーザー数が増えれば増えるほど収益力が上がる仕組み

### ３ソーシャルゲームの未来 ###
ソーシャルゲーム市場のとっても短い歴史
（１）多様なゲームモデル＆多様な世界観　プラットフォーム開放
（２）マルチデバイス対応　数年先を見据えた事業展開・サービス提供が求められる　2010年8月よりGREEiPhone版をベータリリース
（３）グローバル展開　2011年6月期中にアジアと北米拠点での業務開始予定

「ソーシャル化？」「新たな市場？」　→　ヒントは普段の生活に隠れている

——————————————————————————–
怪盗ロワイヤルができるまで、できた後
大塚 剛司 （株式会社ディー・エヌ・エー）
——————————————————————————–
２００９年６月からプロデューサー兼エンジニア
その他いくつかの内製ソーシャルゲームのマネジメント
今年の４月からはプラットフォーム事業担当

＜怪盗ロワイヤルの歴史＞
5月企画スタート
9/25ベータ
10/7正式リリース
12月mixi版開始
2010年4月チーム戦イベント開始
2010年5月戦国ロワイヤルリリース
2010年ヤフーモバゲーでもリリース予定

ソーシャルゲーム展開前は4半期の売上が90億円くらい

ソーシャルゲームプロジェクトにリソース投入
企画一週間　数多のソーシャルゲームを研究し、面白いと思うポイントを発掘
ラフ案2～30個　筋のよさそうなものを2，3個ピックアップ
設計　２，３週間　ゲーム構造を詰めていく　企画書の作成　パラメータの整理　ユーザービヘイビアの想定　バランスのシミュレーション

企画書段階では社内的に全く受けなかった

・ねらい
2，3時間に1分ぐらいずつやればゲームを継続的に楽しめるもの
盗む　盗まれる感覚のハラハラ・ドキドキ感をゲームとして携帯のゲームに閉じ込めたい
ターゲット　一般向け　やや男性向け

ゲームコンセプトに即した世界観　スタイリッシュ　善良な市民には害なし　殺さないなど　を設定し、デザイナー選定　キャラクター設定　クリエイティブ作成

・設計
構造設計　すべてのアクションに明確な理由を持たせるように各機能の関係性を整理
パラメータ設定　シミュレーションをして問題をみつけ再設計を繰り返す。

初期開発　1ヶ月　企画書で伝わらないからといって企画書をいくらリバイズしても先に進まない。とにかく作ってみせる
作って見せたものの　さっぱり受けがよくない。「つまらない」にいちいちへこまない。
仲間や相手がいないのでソーシャル性が成り立っていないのか。単にパラメータのチューニングがおかしいだけか？　ゲームの根幹要素が崩れているのか？
「トライ＆エラー」ボス戦はミニアクションゲーム型、ＨＴＭＬ型、Flash型と作っては壊し作っては壊し作っては壊し。バトルロジック：各種課題　レベル差バトル　ドキドキ感の演出などを作りながら考える。

ユーザーがどこの何にひっかかっているかを見極める。

ベータリリース～本サービス開始　
チュートリアル作り込み　最初の5分でユーザーに何を伝えたいか
→世界観に入り込ませる？　基本操作を理解させる？　ゲームの本質的な楽しさをどう伝える？

チュートリアル　パラメータ　画面遷移　基本構造を徹底的に見直す。
→詰まるポイントはどこか？　スケラビリティは担保されているか？　インフラ面　ゲーム構造面

大事なのはデータ分析
１，ユーザーとしてプレイしている中で違和感を感じた箇所についてチェックする　ユーザーとしての感覚から出てくる仮説を大切にする
２．データマイニング的に取る数字を決めておいて、おかしくなった数値に対して対処を行う

ここで大事なのはエンジニア。企画専任をいちいち通すよりもエンジニア自身が仮説をもってどんどん進めていくのが理想。

開始後3週間で、各タイトル合計で3億円の売上、45億PV
その後、インフラの試練が始まる。

サービス急成長機
伸び続けるトラフィックへの対応
ＣＭ出稿でさらに加速　モバゲー全体のトラフィック　
9月170億ＰＶ→12月380億ＰＶ→7月740億ＰＶ
機動的なサーバーの増設　アプリサイドの修正

ユーザー対応の工数も等比級数的に増加
初期開発2名→バグ修正・ＣＳ、イベント企画準備、各種チューニング　予期せぬ突発的事象への対応

その後　細かなブラッシュアップ
KPI
100万人登録時に月間コイン売上1億円を売り上げるための目安
継続率　ユーザー登録後　7日後、30％～40％
14日後　25～35％
30日と　20～30％
課金率（MAUに対する有料ユーザー比率）5~10%
課金単価 1500円～3000円

上記はあくまで基本的な指標。もっと細かいチューニングが必要。
「ゲームの盛り上がり」「ユーザーの飽き」をはかる仕様
「課金効率が高い」を確かめる指標は？

ユーザーリテンションを上げるには

画面遷移毎の脱落状況をチェックして修正
ウェブサービスであれば当たり前
これで直らなかったら？
ソーシャル性が効いているか
単にメッセージが送りあえることがユーザーにとって楽しいのか？
繰り返す行為がcomfortableか
ツモ要素、何かが上手くっている感覚、要素

継続率はあくまで結果指標。どういった指標を先行指標として追うかはゲームの特性次第
何でも短いサイクルで追えばよいというものではない

課金効率をあげるには
・ユーザーがシンプルに効果を実感できるか
・失敗例：効果が直接的でなくて分かりにくい
目標感が適切か
あせらし要素があるか　今しかない　届きそうで届かない　そのへんをしっかり煽る
課金率やARPPUはあくまで結果指標。課金の鉄則が守られているかをwatchする
数値ベースでは必ずしもはかれないものも考える
考えて分からなければ、試して結果を見てみる

怪盗の初期企画書
God Hand

企画書にとらわれないものづくり
作りながら考えるのが、ソーシャルゲームづくり

日時　

9月2日（木） 16:30～17:30

形式　

セッション（60分）

ゲーム業界からソーシャルゲーム業界への転身 | CEDEC 2010 | CESA Developers Conference

CEDECはゲーム開発者向けのカンファレンスで、毎年開かれています。今年はパシフィコ横浜で8月31日〜9月2日の3日間、開催されています。

タイトルが「ゲーム業界からソーシャルゲーム業界への転身」とありますが、私自身はゲーム業界からの転身組ではありません。本セッションでは主に司会役と技術面の解説役として登場します。

今日（9月1日）のGREEの吉田さんらの講演と内容がけっこうかぶっていて、さてどうしたものかと頭を抱えている最中ですが、プラットフォームとしての王者の戦略と、私たちのような中小デベロッパーの立場はだいぶ違いますので、そのへんにフォーカスした話になるかもしれません。

多くの人にとってより身近に感じられるであろう１デベロッパーの立場から、何かみなさんの参考になることを話せればと思います。