Webプログラミング素人が利用者9万人のmixiアプリを作るまで

はじめに

最近、

文系ド素人がmixiアプリを開発〜リリースするまでのまとめ
http://d.hatena.ne.jp/kazu0620/20100412/1271071223

というエントリーが話題になりましたね。自分もwebプログラミング素人でmixiアプリを作ってみたので、ちょっと便乗して、自分がmixiアプリを作るまでのプロセスをまとめてみました。
これからアプリを作る人の参考になれば幸いです。

kazu0620さんは、個人で作っていたみたいですが、自分は会社で作りました。会社といっても、自分含め従業員数3人の超零細企業でフリーランスの延長線上みたいなかたちでやっている会社ですが。
ちなみに会社のサイトはこちら。

作ったアプリ

「ふしぎな生き物　ふにゃもらけ」

http://mixi.jp/run_appli.pl?id=9443
リリース日：3/23
実質開発期間：8ヶ月
週間利用者ランキング：13位（4/19現在)
ユーザ数：約94000人（4/19現在)
PC専用にしては、まずまずの数字だと思います。
オススメとして大きく紹介されていたので、そのおかげで結構のびました。

ちなみにオススメの部分は広告じゃないですよ。
最近、会った人にあんな目立つところに2週間も広告出してすごいっすねー、と言われたもので(^^;

1日のリクエスト数：約280万（静的ファイルをのぞく）
サーバ：Google App Engine(Java)、Amazon S3+CloudFront
サーバ代：S3+CloudFront が、4/1〜4/17で330$（転送料は1437GB）
　　　　　AppEngineが4/1〜4/13で40$。
圧倒的にCloudFrontに料金がかかってる。
正直、AppEngineは安すぎてGoogleに申し訳ないと思ったりする。

開発スタッフは3人。
自分が、企画・ライティング・サーバサイド、クライアントサイドのプログラミングを担当。
一緒に会社をやっている共同経営者が、グラフィックを担当。
学生バイト、UIを中心にFlashまわりのアシスタント。
といった役割分担。
1人もWebアプリケーションの開発経験者はいませんでした。

mixiアプリを作るのに必要な技術

• XHTML+CSS
• JavaScript
• OpenSocial
• Flash
• サーバサイドプログラミング
• サーバ運用

開発前の状態

• 普段はiアプリやFlashLiteのプログラミングをしている
• サーバーサイドのプログラミングは未経験
• XHTML+CSS、よくわかってない。
• JavaScriptは、Javaに文法が似てるのでなんとなく読める

1.まずはOpenSocial

mixiアプリはOpenSocialという規格に沿っているので、まずは以下の本を読んでみました。

OpenSocial入門 ~ソーシャルアプリケーションの実践開発

mixiアプリ開発を思い立ったのは2009年2月で、当時はまだ日本語のOpenSocialの情報が少なかったので重宝しました。

今だったら、もうすぐ発売する以下の本がとっつきやすそうで良さげです。著者の神部 竜二さんのブログには、OpenSocial関連の情報がまとまっていて、よくお世話になりました。

mixiアプリをつくろう!OpenSocialで学ぶソーシャルアプリ

OpenSocial入門を読んで、OpenSocialの概要はつかめましたが、自分があまりにもXHTML+CSS、JavaScriptなどの知識が曖昧であることを実感できました。

2.XHTML+CSS

HTMLの知識は、7〜8年前ぐらいのTABLEでレイアウトしていた時代で止まっているので、一から勉強することにし、Amazonで評判の良かった以下の本を読んでみました。

現場のプロから学ぶXHTML+CSS

XHTML+CSSの文法を理解することは、大して難しい事ではありませんが、ブラウザ依存などのクセを覚えるには、けっこうコストがかかるなと感じました。なので、デザインは自分でして、コーディング作業のみをやってくれる会社に外注することにしました。何社か検討した結果、コーディングファクトリーという会社にお願いしました。価格的には1ページ5250円とリーズナブルです。こちらが指定ミスしてしまった箇所などにも柔軟に対応して頂き、助かりました。

結果的にコーディングは外注することになりましたが、XHTML+CSSの知識が必要ないという訳ではなく、JavaScriptによる制御をする際に必要になってきますので、勉強して損はなかったと思います。

3.JavaScript

iアプリでJavaを使っていたので、Javaと文法が似ているJavaScriptはなんとなく読めてしまいます。しかし、それゆえに今まで勉強したこともなく、曖昧な部分も多かったと言えます。本格的にアプリを作っていくのには不安を感じ、基礎から勉強することにしました。手始めに読んだのは以下の本で、JavaScriptの本はリファレンスっぽい本やプログラミング初心者向けに書かれた本が多いなかで、JavaScriptという言語ついてしっかり解説されている本だなと感じました。

JavaScriptマスターブック

これで基礎を固めたうえで、以下の本を読みJavaScriptらしいコードの書き方を学びました。

JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス

あとはjQueryの勉強をしました。jQueryについても色々と本は出ていますが、リファレンスの域を出ていないものが多いのでwebで十分です。わざわざ買う必要はないかなと思います。

ここまで勉強した段階で、OpenSocialの仕様についてもようやく理解を深めることができたので簡単なOpenSocialアプリを作ってみました。
ちなみに開発環境はOSDE(OpenSocial Development Environment)。
OSDEはEclipseのプラグラインとして提供されていて、いちいちアプリケーションをサーバにアップロードせずともローカルで動作を確認ができます。

作ってみて、本格的なソーシャルアプリを作るには、サーバ不可欠ということに気がつきました。ユーザデータはmixiのサーバに保存し、永続化させることができますが、JavaScriptで操作を行うので、GreaseMonkeyなどを使えばいくらでも自由に改ざんできてしまいます。詳しくは以下ページが参考になると思います。

グリモンで OpenSocial
http://d.hatena.ne.jp/asannou/20090416

実は当初は、サーバがなくても作れるかもしれないと思っていたのですが、その思惑は見事にはずれてしまいました。

4.Flash (ActionScript3.0)

本当はサーバサイドのプログラミング、そしてサーバ運営の勉強をしなければと思いつつも、どこから手をつけていいのか、なかなか進まずにいました。仕方ないので、半ば現実逃避ぎみにFlashの勉強をはじめました。

Flash自体はかなり昔から使っていたのですが、ActionScript1.0の経験しかありませんでした。ActionScript1.0は簡単で習得しやすいのですが、ある程度の規模のアプリになってくると、非効率的な部分が目立ってきます。より効率的な開発をするために、ActionScript3.0を使うことにしました。

ActionScript3.0は、Javaに近い部分が多かったため、学習にそれほど時間はかかりませんでした。以下の本をさくっと読んで、だいたい概要はおさえることができました。ActionScript 3.0 プログラミング入門はプログラミング初心者でも読める感じの本で、FLASH OOP for ActionScript 3.0はJavaなどの他のプログラミング言語を経験している人向けという印象でした。

ActionScript 3.0 プログラミング入門 - for Adobe Flash CS3

FLASH OOP for ActionScript 3.0~ActionScript 3.0によるオブジェクト指向プログラミングの基礎と活用

開発環境にはFlex Builderを使用。。Flexプロジェクトではなく、ActionScriptプロジェクトで開発しています。Flexコンポーネントは容量が重いので使用せず、Flashコンポーネントをswcで書き出して使用しています。

Flash CS3 のコンポーネントを Flex SDK (Flex Builder) で使う
http://d.hatena.ne.jp/secondlife/20080331/1206934505

5.Google App Engine

そんなこんなで、他の勉強が一通り完了したところでいよいよ真剣にサーバについて考えなければいけない時がやってきました。ソーシャルアプリでは、急激なアクセス増加に耐えうる高いスケーラビリティと可用性が求められます。

ただでさえ、サーバの知識がないのに、そんな高度な事、まるでできる気がしません！

外注することも検討しましたが、サーバーサイドこそソーシャルアプリの肝であり、それを外注するのは危険だと判断しました。それにアプリ公開後も、継続的な改良と追加をする必要があると考えていたため、そのたびに外注に出していては、とてもスピード的に追いつかない。

他人には任せられない、しかし自分では作れない。そんなジレンマに悩んでいる時に、出会ったのが、Google App Engineでした。

Google App Engineは、WebアプリをGoogleのインフラ上で動かすことのできるサービスで、することはアプリを作るだけ、サーバ構築・運用は不要。自動的にスケールする。しかも安い！といった特徴を持っていて、まさに自分たち向きのサービスであると瞬時に確信しました。

ただ、いくつかの不安要素があったのも事実です。

• RDBが使えなく、Google独自のKVS"BigTable"を使う必要がある
  • 元々、RDBを知らないので問題なし
• 障害が発生したときに、何もできる事がない。
  • 少なくとも自分がサーバ運用をするより、障害は少ないと思う。俺よりGoogleを信じる！

ですが、そういった不安も大きな可能性に比べれば、微々たるものであると考えました。

App EngineはJavaとPythonに対応して、自分は慣れ親しんだJavaを使用することにしました。当初はJava版App Engineが始まってから間もなかった事もあり、日本語の情報自体が少なく勉強しにくい状況でした。それから1年ほど経過した今では、日本語の情報もかなり充実し、初心者でも取り組みやすい環境が整って来たと言えます。

本ならば、以下の本がオススメです。単にコードの書き方だけでなく、実際に使う上でどういう制約があるかなどが書かれていて、知識を整理するのに役立ちました。

Google App Engine for Java [実践]クラウドシステム構築 (WEB+DB PRESS plus) (WEB+DB PRESSプラスシリーズ) (WEB+DB PRESS plusシリーズ)

他にもいくつかApp Engineの本は出ていますが、残念なことにどれもJDO(Java Data Objects)メインで書かれていることです。データストアへの保存にJDOを使うことをGoogleが推奨しているので仕方のないことかもしれませんが、JDOのパフォーマンスが悪いことは既に周知され、現在はLow-Level APIの使用が主流になってきています。「ふにゃもらけ」も最初はJDOを使用していましたが、パフォーマンスを向上させるためにLow-Level APIで書き直しました。Low-Level APIについては、以下ページが参考になりました。
https://sites.google.com/a/topgate.co.jp/systemsolution/Home/googleappengine/datastore-lowlevelapi

ただしLow-Level APIは、非常にシンプルな機能しか提供されていないため、実際にアプリを書くには使いづらい点も多いです。例えば、プロパティのやり取りがタイプセーフでなかったりなど。。そういった欠点を解消するためには、Slim3というフレームワークを使うのがオススメです。Slim3はApp Engine専用のフレームワークで、データストアまわりはLow-Level APIで書かれていてパフォーマンスも十分。しかもタイプセーフなので安心して使うことができます。

ちなみにApp EngineはPythonでも使うことができますが、JavaもPythonも未経験ならばPython版を使ってみるほうが良いかもしれません。App Engineでは必要な際にサーバインスタンスが生成され、必要がなくなると、つまりリクエストがしばらくないとインスタンスが削除されます。つまりスケールアウトしていくたびにサーバーインスタンスが生成されるのですが、その際にJavaのほうが時間がかかります。

起動時間はPythonが有利ですが、実行速度でいえばJavaのほうが高速で有利でしょう。ただ大抵のアプリではデータストアへのアクセスが処理時間の多くを占めることになるので、JavaでもPythonでもそのあたりは、あまり変わらないのかなと思います。
http://d.hatena.ne.jp/higayasuo/20100319/1268984735

6.パフォーマンス向上

そんなこんなで、本格的にアプリを作り始めたのは2009年7月下旬。途中で大幅な仕様変更をしたりなど、紆余曲折あり、11月上旬にはアプリが一通り完成しました。

しかし…とにかく重い！
アプリページ開いてから、すべての読み込みが完了するまで30秒ほどの時間がかかります。これでは使い物にならないと思い、パフォーマンス向上に取り組みました。パフォーマンス向上では、以下の本がとても参考になりました。

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール

webでも読めるみたいです。
http://www.inter-office.co.jp/contents/177/

様々なテクニックが書かれていますが、

• CSS Sprites
• js、cssのファイル連結
• キャッシュの有効期限の設定

はそれほど手間がかからないうえに効果は絶大なので、絶対にやった方がいいと思います。

またApp Engineのサーバは海外にあるため、レイテンシ（ネットワーク遅延）を避けることはできません。少しでもレイテンシの影響を軽減するために、画像などの静的ファイルは、Amazon CloudFrontを活用し、国内に置くことにしました。
これも大きな効果があったのですが、App Engineに比べてデータ転送料がかかってしまうことがネックです。AppEngineのデータ転送料が$0.12/GBに対して、CloudFrontは$0.201/GBと1.7倍ほどの料金がかかります。

ちなみにmixiアプリ モバイルなら、mixiが無料で使えるコンテンツ配信サーバーを用意してくれているので、それを活用できそうです。
http://developer.mixi.co.jp/news/2010031003

こうした改良の結果、パフォーマンスは大きく向上で、キャッシュがある場合は最短3秒ほどでアプリが起動できるようになりました。

7.ようやくリリース

パフォーマンスは向上できたものの、ゲーム内容やインターフェースなど改良すべて点が多く、改良を重ねているうちに時は流れていきました。そして3/23ようやくリリースすることができました。

ソーシャルアプリはスタート時の完成度が大事です。競合アプリがひしめく状況では、ユーザは一度つまらないと思ったら、2度とアプリには戻ってきてくれません。早くリリースすることも大事なのですが、多少の時間をかけてでも内容的に
満足をしてもらえるものを作ることも大事だと思います。おかげでオススメにも取り上げてもらうことができ、利用者を増やすことができました。

しかし、ソーシャルアプリはリリースすれば終わりという訳ではなく、むしろまだ始まったばかりです。ユーザさんに継続的に楽しんで頂くために、もっとたくさんの人に利用して頂くためには、さらなる改良や機能追加が必要になってきます。そしてモバイル対応もいまや欠かすことはできません。いかにマネタイズしていくかという問題も残っています。

そんなこんなで、むしろリリースしてからの方からの方が忙しくなっています。てんやわんやの状態で、とても3人では人手が足りません！

というわけで

エンジニア、大募集です！App Engineに興味がある方、大歓迎です。社員に限らず、アルバイトとか業務委託とか、いろいろな関わり方できると思いますので、まずはご連絡を。

biz@funyamora.com

それ以外にも、弊社のmixiアプリに興味をお持ちの方がいましたら、お気軽にご連絡ください。