【文系ど素人シリーズ】開発したmixiアプリの敗因分析まとめ あるいはソーシャル・アプリ戦略論

就職活動の現状

昨日の記事ですが、素晴らしい反響を頂いてびっくりしています。実を申しますと、複数の企業の方から既にアプローチを頂けました。近日中にお会いできるところもあると思います。最終的な結果に関しても、企業の了承が取れればこのブログで報告したいと思います。もちろん、全滅だった場合もここで報告します。その時は【文系ど素人シリーズ】は、【ニートのソーシャル・アプリ開発ブログ】に変更する予定です。乞うご期待、じゃない、がんばって仕事を探したいと思います。

さて、本題に入りましょう。昨日は技術的な面からmixiアプリについて書きました。今日は、企画戦略的な面からソーシャル・アプリを見てみましょう。昨日を記事を読んで今、どんなアプリを作ろうかと試行錯誤している人もいることかと思います。そこで、今回僕が作ったアプリの反省を踏まえながらソーシャル・アプリの戦略論について考察を述べます。僕も今回失敗したのですが、webに興味があって勉強している人ほど陥りやすい「罠」がソーシャル・アプリの開発には潜んでいます。企業でそういう戦略を分析してくれる人がいる場合はいいですが、個人で開発する場合はなかなか事前に調べることは難しいし、そもそもmixiアプリの戦略論とか書いてるブログもほとんど見当たらなかったので今日記事にしてみようと思った次第です。なお、モバイル版の開発は行っていませんのでそのままは当てはまらないかもしれません。mixiアプリPC版を企画するときの戦略論としてお読み頂ければ、と思います。では、行きましょう。

今回のアプリは失敗だった

褒めてくださって、本当に嬉しいし、ブログを読んで頂いた方全てに感謝しています。それでも、敢えて言いましょう。今回のアプリは、ソーシャル・アプリの開発という面においては内容・結果、共に失敗だったと。正直な話、企業が作ったものと競合できるくらいものを本気で作りたいと思って開発してたし、生活費くらいは稼げるかもしれないと踏んでいました。発表しましょう。

「一行リレー小説」のmixiアドプログラムからの現在の総収入は462円です。

駅前でダンボールハウスを作り、うまい棒だけを食べて生きれば生活は可能かもしれませんが、その場合ネット環境を用意するのが難しいという問題点があります。いや、そもそも無理があります。というわけで、以下に失敗の原因とその対策をまとめたいと思います。

失敗要因その1　リレー小説は、CGMを目指していた

これが、原因の根本だと考えています。後述する他の要因も、結局はこれを言い換えただけです。


ソーシャル・アプリで取るべき戦略は、みなさんがアツい！！！！とか思ってるweb2.0的なものとは頭を切り替える必要があります。


正直、僕自身もはっきりと切り替えられなかったというのが、最大の敗因です。例を使いながら、説明していきましょう。みなさんご存知、サンシャイン牧場。これに対抗するには、どのような戦略を取るべきでしょうか。通常のweb的な発想から優等生的に答えると、５００万弱というユーザー数を抱えたこのアプリに真っ向から対抗しても勝ち目はまず、ありません。ニッチな分野に絞って戦う、差別化戦略を取る、というのが最適に思えます。しかし、果たして本当にそうでしょうか？まず、ユーザー数に関して。例えば、「食べログ」などのＣＧＭサイトを考えると莫大な数の投稿数が既にあるので、僕が今から全く同じ戦略を取ったレビューサイトをオープンしたとしてもヒットの目は全くありません。一部の新しいもの好きのユーザー以外は、食べログを使い続けるでしょう。しかし、サンシャイン牧場が数百万のユーザーを抱えていたとしてもその数が直接強みになるという点はありません。直接的な強みは、「マイミクがたくさんプレイしてる」ということなのです。ユーザーは１００万人遊んでるけどマイミクは誰もやってないアプリよりも、１０００人のユーザーしかいないけれどマイミクが５人いるアプリの方を遊びます。


つまり、ユーザー数やコンテンツの蓄積それ自体が強みになるというＣＧＭ的な発想は通用しないのです。

その上、徐々にユーザー数を増やして行っていつかはキャズムを・・・などといった戦略を取っているとmixiアプリでは失敗要因2に後述する理由によりあっという間に導線が断ち切え、誰も訪れなくなります。ソーシャル・アプリがニッチな分野に絞って差別化して戦う理由は、合理的な観点からはないのです。むしろ、ニッチ戦略は有害である場合の方が多いと僕は考えています。これについては失敗要因3でさらに詳しく解説します。海外で凌ぎを削って来たアプリに似たようなものが多いのは、このあたりの戦略が関係しているのではないか、と思います。


まとめ
・ＣＧＭ的な発想を捨てよう！
・キャズムを超える前に導線自体立ち消える！（理由は後述）
・ニッチ戦略は合理的ではない。むしろ有害かも！（理由は後述）

失敗要因その２　バーチャル・グラフを利用していた

mixiアプリの新着アプリをチェックし続けてる方ならお気づきかと思いますが３月下旬、今回のアプリをリリースした直後にmixiアプリのトップ画面から、新着アプリへのリンクが消えました。現在、新着アプリへのリンクはカテゴリ欄の隅っこよほど注意深く見ないとわからない場所にあります。また現状では、カテゴリーもほとんどすべてが「その他」に分類されるようになっています。そして、「その他」はカテゴリ一覧ページに、掲載すらされません。

これは、mixiが勧めるアプリ以外の導線を意図的に細くするためであると考えるのが適切でしょう。あるいは、新着の極めて細い導線からバイラルに広がるものならば、ヒットしても良しとしようということでしょう。とすれば、mixiアプリを開発するに当たって僕たちはある程度mixiの意図に沿ったものを作り、オススメ欄に掲載される、あるいはカテゴリに分類されることを目指す必要があります。では、mixi側の意図とはどういったことなのでしょうか？

分析する必要はありません。笠原さん自ら、発表しています。

mixiアプリをこれから開発されるという方は、以下の記事を必ず読むべきです。

「ソーシャルグラフとバーチャルグラフのどちらが優れているかと比較する意図はなく、それぞれのビジョンが異なるというだけ。ただ（コストをかけて）アプリを作る以上、この違いを理解していただいたほうが、よりポテンシャルの高いサービスを作れるはずだ」

http://internet.watch.impress.co.jp/docs/event/ogc2010/20100217_349493.html

笠原さん自ら、バーチャル・グラフではなくソーシャル・グラフを利用したアプリを推進することを明言しています。よって僕は、バーチャル・グラフを使用したものは、オススメ欄・カテゴリ欄の掲載は絶望的だと考えています。もう一つ、説得力のある例を言うと「記憶スケッチ」がオススメ欄に掲載されていないことです。サンシャイン牧場やハッピーアクアリウムなどが並ぶ中、大ヒットアプリの一つである記憶スケッチがオススメ欄に掲載されてないのは、大きな違和感を感じます。リレー小説は、この記事にあるとおり「過疎化」を恐れ、結果として失敗しました。またここまでmixiが方向性を明言してる以上、もしも現状と違っていてカテゴリ、あるいはオススメに掲載されてれば・・・というのは言い訳でしょう。開発段階で気付くべきだったのです。その上、一行リレー小説には必然的にバーチャル・グラフを利用せざる得ない理由がありました。それは、次項にて説明します。

・まとめ
mixiの意図するアプリ以外は導線が極めて細くなる！
バーチャル・グラフは使わないほうがいい！
mixi関連の記事をチェックしよう！

失敗要因その３　リレー小説は、特定の層をターゲットとしたアプリだった

通常のwebサービスなら、100人に1人が利用してくれるというサービスは大ヒットするでしょう。ただ、あなたが今から作るのはmixiアプリです。前項までに書いた通り、ソーシャル・グラフを利用したものを作る必要があるし、さもなければ導線は限りなく細くバイラルに爆発的に広がるものを作る必要があります。例えば、100人に１人には確実にウケるであろうニッチなサービスをmixiアプリで提供したとします。これは、通常にCGMサイト製作では悪くない、というかセオリー通りの戦略です。しかしソーシャル・グラフの利用を前提としたmixiアプリであった場合、あるユーザーが想定したターゲットにぴったしハマっていたとしても、彼のマイミク達も同時に想定したターゲット層である必要があります。でなければ、彼は友達と一緒に遊ぶことを前提に作られたアプリを一人でプレイすることになるでしょう。


つまり、ニッチなアプリを作って差別化を図るという戦略をとっても、誰とも遊べないソーシャル・アプリが出来上がるだけなのです。


例えば、有名ギークを育成戦わせるゲームとかリリースすればもちろん、みなさんは泣いて喜ぶかと思いますが、一般の人は冷たい目で見るし、喜んでくれるどころか友達を招待してもキモイ目で見られるだです。むしろあなたはそれを恐れて招待すらせにずレベル99まで育てたダンコーガイとかで一人で遊ぶかもしれません。これでは、バイラルに広がる可能性はまず、ありません。この場合、バーチャル・グラフを利用して他のユーザーとも遊べるようにする、という選択肢以外ないでしょう。一行リレー小説はまさにこれでした。β版をリリースしてマイミクだけで遊んでもらったところ、腹がよじれるくらい面白いアプリなのに、なんと腹がよじれるくらい笑ってるのは僕とオタク気質のある知人１人だけで、あとは投稿すらほとんどしてくれなかったのです。最初はソーシャル・グラフメインで考えていたのですが、１人で執筆する小説が散在的に出来るだけという最悪な自体を避けるべくバーチャル・グラフをメインとしたものに変更しました。（ちなみにこのリレー小説は、リリース後の体感で言うとニコニコ動画のヘビーユーザーやネットゲームのユーザー層と親和性が高いように思います）。そして、失敗要因2で説明した通り、バーチャル・グラフを利用した場合ヒットの可能性は極めて低くなります。つまり、最初からニッチな企画ではなく、万人受けする企画で勝負すべきなのです。万人受けする企画、というのはソーシャル・グラフのレイヤーを選ばない、という意味です。みなさんのマイミクも大学時代の友人、地元の友人、会社関係、など様々なレイヤーから成っているはずです。そうしたソーシャル・グラフのレイヤーを超えて遊べる＝万人受けする王道企画を選ぶのがmixiアプリでは重要です。さらに言うと、ソーシャル・グラフ失敗要因1で書いた通り、ソーシャル・アプリは後追いでもCGM的なコンテンツの様に極度に不利になるということはないはずです。


※バーチャルグラフを利用しているが、万人受けするものであるためにヒットするというのは可能性があります。記憶スケッチがその例です。但しそうした企画で勝負する場合は、恐らくオススメカテゴリには掲載されない＆カテゴリ「その他」になり導線は細くなるという覚悟をしましょう。


まとめ
・特定の層を狙ったニッチなアプリはmixiではヒットしづらい！
・ソーシャル・グラフのレイヤーを超えたアプリを企画しよう！
・差別化戦略ではなく万人受けするアプリを企画すべき！

以上、失敗の要因をまとめて来ました。では、それを踏まえてどういうものをつくればいいのか。対策をまとめたいと思います。

対策その１　コンテンツでは無く、コミュニケーションの場を作れ

これまで散々述べたとおり、バーチャル・グラフを使うのはあまりにリスクが大きすぎます。結局、開発者側はソーシャル・グラフをメインにしたアプリを製作することになるわけですが、そこで最も重要なのはコミュニケーションです。当然、ユーザーにコンテンツを作らせて集積するというCGM的な戦略は取りようがありません。そして一人でのめり込めるアプリを作っても、バイラルに広がることは望めません。サンシャイン牧場があんなに単純なシステムなのに面白いのは、友達と遊べるから、に他なりません。もちろん遊んでる人が自分はゲームを遊んでるんだと思っていますが、実際にやってるのはコミュニケーションです。友達のレベルを追い抜く、邪魔する、手伝う。ゲームを遊ぶ中でやってることだけど、これ、コミュニケーションですよね。面白いゲームとかコンテンツの中身より、こういうコミュニケーションをいかにデザインできるかというのが鍵になるのではないか、と個人的に考えています。

対策その２　一部のガチオタ向けではなく、万人受けするものを

これまで述べたとおり、100人に1人の層にターゲットを絞ったニッチな戦略はソーシャル・アプリでは恐らく機能しないでしょう。つまり、ある程度万人受けするアプリを開発する必要があります。その代わりに、超人気アプリと同じコンセプトで真正面からぶつかったとしてもソーシャル・アプリでは勝ち目があります。追い抜けないにしても、数十万ユーザーなら囲い込める可能性があるのです。それは、牧場系とか水槽系のアプリが乱立してる状況を見れば一目瞭然です。

対策その３　感情を、刺激できるものを

コンテンツよりもコミュニケーションが重要だと書きましたが本気でコミュニケーションをデザインしようとすれば、コミュニケーションの起点となる感情をコントロールする必要があるはずです。マイミクに負けたくない！あいつがあそこまで進んでるから・・・・。あの人はあのアイテムを手にいれてるから・・・。みたいに、感情を刺激して持続的に遊ばせる、企業なら課金させるアプリを設計しなければならないということです。

以下の記事に、まさにドンピシャだと思う表現があったので引用します。

例えば、米国のあるソーシャルゲームメーカーは、ゲーム内のアイテム課金は「7つの大罪」（傲慢、嫉妬、憤怒、怠惰、強欲、暴食、色欲）を刺激することでうまく回ると話していたという。

http://www.itmedia.co.jp/news/articles/1002/17/news087.html

この7要素を如何に刺激できるか。ソーシャル・アプリ業界がある程度成熟してくると、そこで凌ぎを削ることになるのではないでしょうか。

非同期性

あ、それから最後にもう一つ。これは今回のアプリの場合満たしていたと思ってたので本文中には記述していないのですが、非同期性というのもとても重要な要素だと考えています。通信技術の話ではなく、時間軸の共有のお話です。例えばチャットは遊んでるユーザー同士が同じ時間軸を共有しているので「同期的」なアプリと言えます。対して掲示板は、ユーザーが書き込む時間はバラバラです。これは「非同期的」な時間軸と言えるでしょう。ソーシャル・アプリでは非同期的な時間軸を共有できる設計が必須だと思います。なぜなら、マイミクと同時にログインしてる時間なんて本当に限られたものだからです。特に、個人が開発することになるパソコンのアプリでは同期的にしか遊べないソーシャル・アプリでヒットするのは極めて難しいでしょう。

以上、今回のアプリの敗因分析と、ソーシャル・アプリの戦略に関する考察でした。今のところ、社会的な立場というものが無いに等しいので思い切って断言した部分もかなりたくさんあります。ニートという身分をいいことに好き勝手書かせて頂いたので、言葉の誤用や的外れなことも書いているかとは思います。ですが実際にアプリをリリースした中で思ったことのエッセンスをまとめたので、アプリを開発する際の参考にして頂ければ幸いです。

というわけで

もしも面接して頂ける、という会社があれば

kazu620@gmail.com　

まで連絡を頂ければ幸いです。

文系ド素人がmixiアプリを開発〜リリースするまでのまとめ

というわけで

プログラミング未経験の状態から、mixiアプリのリリースまでなんとか漕ぎ着けることができました！最近、OpenSocial界隈は盛り上がってるみたいだし、プログラミング経験はないけれど、興味ある！って人も多いと思います。そこで、所謂「ド素人」の状態からプログラミングを勉強してmixiアプリをリリースするに至るまでの僕の軌跡と、何をどう勉強すればいいのか？ってのをまとめてみました。webで調べたり、プログラマの知人に相談したりしてこれは良かった！って部分を抜き出してまとめたので、これから勉強するぞって方は参考にして頂ければ幸いです。これであなたもＳＡＰ（ソーシャル・アプリ・プロバイダー）に！

完成したアプリ

「一行リレー小説」

http://mixi.jp/view_appli.pl?id=15525
開発期間：実質3ヶ月程度
リリース日：3月24日
現在の投稿総数:7622行
現時点でのユーザー数：1112人
一日のPV数：3000超程度
サーバー運営にかかるコスト：月7000円ほど（amazonEC2/S3を利用）

という感じです。大赤字で涙目ですが、正直これくらいのユーザー数なら別にさくらの月1500円のレンタルサーバーでも捌けるはずなので、ちょこっとアプリ作りたい！って人はわざわざクラウドとか利用したりしなくても大丈夫そうな感じです！

スタート地点

・htmlとかcssはなんとなく書ける。
・レンタルサーバーを借りて、簡単なホームページは作ったことある
・でも、プログラミングは全く未経験。配列？ループ文？なにそれ、こわい。
という状態からガチでソーシャルアプリを作ることを決意。

1.サーバーサイドのお勉強をする

とにかく、素人でもPHP使えばいろいろできるんだぜ！みたいな記事をよくはてブで見ていたので、何はともあれまずPHPを勉強してみることに。（というか、この時点ではPHPとMysqlだけでmixiアプリも作れると思ってた）amazonとかブログの書評とかを見てPHPの勉強のために読んだ本が下の2冊。両方読めばとりあえず、データベース使って簡単なwebアプリなら作れるようになります！多分。

改訂新版 基礎PHP

最初に手をつけたのがこの本です。最初はすごく優しく教えてくれるんだけど、なんか途中から急にスパルタになったイメージ。でも、？？？って思ったところもgoogle先生に聞けば大抵教えてくれるんで、何とか読み進めてきました。

プログラミングPHP 第2版

プログラミングの教科書は、動物の絵の本がおすすめという噂を聞いて購入。こちらは、開発と同時並行で読んで行きました。文法構造の細かいところやセキュリティ関係の部分が上述した一冊だけではカバーしきれて無かったので役立ちました。というわけで、まぁPHPのコード書けるようになったしアプリ作るか！と、なるのですが・・・。

2.クライアントサイドのお勉強をする

勢いに乗って、実際にmixiアプリの開発についてググって調べたりコードを見たりしてみると・・・。あれ・・・？あれ・・・？プログラミング勉強したハズなのに、なんだか見慣れない文法や記法ばかり・・・。なんと！mixiアプリ、というかOpenSocialはPHPではなくjavascriptで動いたいたのです！いや、サーバーサイド（PHPなど）の知識も必要なのですが、メインの部分はjavascriptで書かれているのです！というわけで再びamazonのレビューやブログの書評を見たりして勉強の仕方を調べる。結論として、javascriptは以下の二冊だけやっとけばＯＫだという結論に至りました。javascriptの場合、下手な入門書だと本当に上っ面のことしか書いてなかったりするんで、以下の2冊を気合で勉強するのがいいと思います。

JavaScript 第5版

一見、とてもブ厚く見えるし実際こんなの読み進めれるのか？と不安になると思います。だけど、実際開いて読んでみると、やっぱ想像の通りで、わからない部分が何度もあってああ自分はアホだなーとか思って泣きそうになると思いますが、まぁとにかく読み進めてみましょう。

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

これも、開発と同時並行で読み進めて行きました。薄っぺらい本ですが、初心者が実際コーディングしてくと絶対ハマってしまうだろうなーってところの原因と対処方を書いてくれてるので、とても役に立ちました。わいはいも虫から蝶になれるのや！と妄想しながら気合で読み進めてください。

この2冊を読み終えたあと、PHPの知識と合わせてajaxで簡単なアプリを何か作ってみるといい感じです！mixiアプリは、基本全てajax（非同期処理）で書くことになるからです。あと、フレームワークの使い方も抑えておくとさらにグッドです。ちなみに、今回のアプリでは「prototype.js」というフレームワークを使用しました。

3.やっと・・・mixiアプリの開発へ！

というわけで、ようやく開発へ。で、mixiアプリについてはどうやって勉強するんだ？と思ってるかもしれませんが、mixiアプリの中身自体はjavascriptで通信部分に関してはajax的なものとPHPで書くことになるので、新しいことを学ぶ、というより今まで学んだことを生かして実際にコーディングして行くという側面が強い感じです。では、実際にmixiアプリを開発するにあたって、大枠の手順を箇条書きにしてとめてみます。

○下記アドレスの手順に従い、ディベロッパー登録をする

http://developer.mixi.co.jp/appli/pc/pc_prepare/developer_account_regist_pc

○xmlファイルを用意する

このxmlファイルがmixiアプリの本体となります。XML！？と聞いてもビビるかもしれませんが、安心して下さい。以下のアドレスにあるxmlの中身をコピーして、以下の部分にjavascriptやhtmlを記述すればいいだけです。
http://developer.mixi.co.jp/appli/pc/lets_enjoy_making_mixiapp/helloword_of_mixi_app
拡張子にビビらなくてもＯＫ！コピペしたものの中身だけちょっと変えればほら！これでもう、あなたのアプリです！

 <?xml version="1.0" encoding="UTF-8"?>
<Module>

　〜省略〜

  <Content type="html"><![CDATA[
 <!--- 以下の部分にhtmlとjavascriptでコードを記述します。 -->
<h1>Hello mixi App World!</h1>
<p>これはわいのアプリや！</p>
<script type="text/javascript">
alert("わいのアプリなんや!");
</script>
 <!--- コード、ここまで -->
  ]]></Content>
</Module>

○xmlファイルをサーバーにアップロードする

サーバーの準備に関しては次項で詳しく説明しています。サーバーのレンタル方法やFTPの使用法なんかに関しては、事細かに説明してるサイトがたくさんあるので検索すればすぐに親切な解説サイトが見つかるはずです。サーバーを確保できたらば、xmlファイルをweb上にアップしましょう。

○mixiアプリを登録する

以下のアドレスで、必要項目を入力すればとうとうあなたのアプリがmixi上で動作するようになります！ガジェットURLという項目には、先程web上にアップしたxmlファイルのアドレスを入力すればＯＫです！
http://mixi.jp/add_appli.pl

○さぁ、アプリ作成開始！

いよいよ、実際のコーディングです。マイミク情報を取得したり、idからニックネームを取得する、などのmixiアプリやOpenSocial固有の機能の使い方に関しては、以下のサイトを見ると参考になります。大体の疑問はmixi Developer Centerで解決するかと思います。最低限の機能はソースコードも掲載してくれているので、最悪コピペでも動作可能です。それでも分かりづらい部分や疑問があったときは、下の２サイトを見てみると同じことをより詳しくor分り易く書いてたりするので、オススメです。

・mixi Developer Center
http://developer.mixi.co.jp/appli
・goo Developer's Kitchen
http://developer.home.goo.ne.jp/
・OpenSocial API デベロッパー ガイド
http://code.google.com/intl/ja/apis/opensocial/docs/0.8/devguide.html

○補足

アプリの開発を実際に始めると、コードを変更したのになぜか反映されない！ってここが起こります。これは、mixiアプリが強力なキャッシュ機能を備えているためです。詳細と対策は、以下のサイトなんかを参考にしてみるといいでしょう。

・mixiアプリ開発日誌−mixiアプリ キャッシュを無効にする方法
http://blog.soratobu.jp/2009/04/465/

また、実際のコーディングを行う時にはFirebugなどのデバッグツールを使用すると飛躍的に効率がアップするのでオススメ（というか必須）です！それに加えて、プログラミング用のエディタを仕様するとさらに開発効率は上がると思います。僕は、次項で説明するlinux環境を用意できてからは、vimというエディタを使用して開発していました。

4.サーバー環境を整える

大体の個人アプリはサクラのレンタルサーバーで全然大丈夫だとは思うのですが、万が一大ヒット・・・なんてことがあるとmixiアプリの場合ケタ違いのアクセスが生まれるので、並のサーバーではとても持ちません。もちろん、ここまで読んでくれた方は、すでに頭の中で万が一の大ヒットのことを想像してヨダレをたらしていることかと思います。僕も、万が一のことを考え今回のアプリはamazonEC2でサーバーを構成していました。所謂、流行りのクラウドというやつです。実際の運用方法や概念については、下記の書籍が参考になりました。

下の入門書を読みながらVMwareを使って、仮想環境でroot権限の勉強をしました。まぁ、なんだかんだ言って普通にプログラミングしててもどっかでサーバー周りの話は絡んでくるので、linuxのお勉強をしておいて損することはないと思います。なお、VMwareのインストールに関しては下記のサイトを参考にしまいた。
http://bach.istc.kobe-u.ac.jp/lect/tamlab/ubuntu.html

Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)

とっても丁寧に書いてくれてるのですが、いかんせん「cd」と「ls」だけ覚えた状態から読み始めたのでなかなかハードでした。また涙目に。でも、セキュリティからバックアップまで詳しく解説してくれてて、とても良書でした。rootって何？ってのから、実際の運用してみるところまでこの一冊で行けちゃうのでは、と思います。

クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)

amazonEC2の実際の運用の実例と共に説明してくれます・・・が、具体的な内容に関してはこの本よりも著者のブログの方がはるかに充実しています。実際、運用を初めてからググって、この著者のブログを読んで解決ってパターンが多かったです。ちなみに実際に運用するまでには、詰まってgoogleで検索して・・・っていうのをかなり繰り返しました。クラウドの概念的なものをこの本でつかんで、運用に関しては下記のブログを熟読すると良いのでは、と思います。
・RX-7乗りの適当な日々　
Amazon EC2/S3を使ってみた - まとめ (Amazon Web Services関連エントリ目次)
http://d.hatena.ne.jp/rx7/20080528/p1

5.そして、公開へ！

mixiアプリの公式カテゴリ掲載の申請をすると、mixi側の審査を受けた後それが通ってれば正式公開となります。注意点としては、
・推奨環境を書いておかないと審査に落ちる
・バーチャルグラフを使ったアプリは審査は通るが18歳未満の利用が制限される
・バーチャルグラフを用いたアプリは、オススメ欄掲載は絶望的
などでしょうか。審査には大体１〜2週間くらいかかるとmixiのディベロッパーセンターには書いてあったのですが今回開発したアプリの場合、申請から3営業日での公開となりました。実際には大体２〜３日で公開されるアプリが多いみたいです。また、確信はないのですがバーチャルグラフを利用したアプリはmixiアプリのオススメの項目には掲載されないようです。さらに、どんなジャンルのアプリであろうがまず間違いなくカテゴリ「その他」に分類され導線は限りなく細くなるので、ヒットを狙うならソーシャル・グラフに絞って利用できるものを開発するのが良さそうですね。あ、それからアプリをインストールしていなくて、かつマイミクではないユーザーの個人データは取得できない仕様となっています。ここまでは良いのですが、アプリを一度入れたけれど削除してしまった人のデータも当然取得出来なくなるというのが意外と盲点なので気をつけて下さい。バーチャルグラフを利用したアプリだと、下手するとコレで致命的なバグを引き起こす可能性もありそうなので。

6.まとめ

・開発にはサーバーサイドとクライアントサイド、両方のプログラミング知識が必要
・ヒットする可能性があると思うなら、サーバー環境を大規模アクセスに耐えれるよう整えてから公開しよう
・ヒットを狙うならバーチャル・グラフは極力利用しないようにしよう

以下、技術的なお話に関するまとめでした。戦略的なお話のまとめも用意しましたので、これを読んでアプリを開発するぞ！と思った方はぜひこちらもお読み頂ければ、と思います。

http://d.hatena.ne.jp/kazu0620/20100413/1271181653

余談
というわけで、文系でプログラミングは未経験だと言う人でも数カ月かければmixiアプリは作れます。ちなみにこれは完璧余談なのですが、このアプリの公開は大学の卒業式の前夜に始まりました。おかげで、思いも知らなかったバグの修正やまだ時間的余裕があると思ってたために追加してなかった必須機能の追加などのため式の直前まで徹夜でプログラミングをするハメに・・・。とはいえ、なんとか無事式には出席できて僕も晴れてニートの仲間入りを果たすことができました。世間の噂を真に受ければ既卒なのですでに人生終了！という噂ですが・・・。これより、就職活動を開始したいと思っております。アルバイトでも構わないので何とか、仕事を見つけられれば・・・と思っています。

というわけで

もしも面接して頂ける、という会社があれば
kazu620@gmail.com　

まで連絡を頂ければ幸いです。

Elastic Load BalancerでMySQLサーバーを冗長化しようとするとエラーが出る

mixiアプリをamazon EC2上の仮想サーバーで公開しようと目論んでいるのですが上記のところでハマりました。日本語で対策法を書いたサイトが見当たらなかったので、原因と対策法をまとめておきました！

DBサーバーの構成

・マスターサーバー１台
・スレーブサーバー２台
でレプリケーション
OS/ubuntu 9.10
MySQL/5.1.37を使用
という状態で、AWSのElastic Load Balancerにスレーブサーバー２台を紐付けしてみたもののデータベースサーバーに接続出来ず。試しにマスター側サーバーから、スレーブ側に接続しようとすると下記のようなエラーメッセージが表示されました。

エラー内容

Host 'hostname' is blocked because of many connection errors. 
Unblock with 'mysqladmin flush-hosts' 

スレーブのサーバーに接続エラーが大量発生されたためにブロックしてるよー、とのこと。このエラーメッセージにある通りに

Slave# mysqladmin -p flush-hosts" 

を実行してみると、接続できるように！！なりましたが、１０分くらいするとやはり同じエラーがでて接続エラーに。

原因

同じような症状が出ている人がいないか調べたところAWSのフォーラムで全く同じ症状に悩んでいる人が！
http://developer.amazonwebservices.com/connect/thread.jspa?messageID=131707𠉻
さらにリンク先には、amazonスタッフの返信もありました。一部を丸ごと引用させて頂くと

It seems as if the application being load balanced (MySQL, in this case) may have some behavior which is being triggered by the default ELB health check: The CreateLoadBalancer API will set up a default health check of type "TCP", which simply attempts to open a TCP connection to the registered instance at regular intervals.

If that is the case, you would seem to have two options:
1) Reconfigure the health check (using ConfigureHealthCheck) to something that is not interpreted as an error by your application.
2) Reconfigure your application not to interpret the ELB health check probes as errors.
You can read more about the types of ELB health checks, and the default settings, here:

どうやら、ELB側で行っているHealthCheck（インスタンスが正常に動作してるかどうかのチェック）がMySQLサーバーに接続しようとしてエラーが生じている模様。解決するためには、HealthCheck側の設定を見直すか、サーバー側の設定をいじってHealthCheckをエラーと認識させないように変更するかどっちかだよー！とのことです。

対策

HealthCheckの設定（コンソールから確認可能）をチェックしてみたところ、確かに
Ping Target:TCP:3306
となっている。これがエラーの原因だったみたいです。今回は、HealthCheckの設定の方をいじってエラーを修正することにします。そもそも、HealthCheckがMySQLに接続しない限りエラーは生じないんだからポート80経由でHealthCheckすればいいのでは！？ということで、MySQLのポートではなく80番ポートのhtmlファイルにping打つように変更してみます。CUIで設定を行う場合は以下をコピペ、コンソールで変更する場合は、HealthCheck欄の一番下に表示されているEdit Health Checkをクリックして同様の設定を行えばＯＫです。

elb-configure-healthcheck  ロードバランサーの名前  --headers --target "HTTP:80/index.html" --interval 30 --timeout 3 --unhealthy-threshold 5 --healthy-threshold 3

ただし、そもそも80番ポートを通すよう様にロードバランサーを作っていない場合はエラーになるので注意です。コンソールでロードバランサーのDescription→Port Configurationに80番ポートが表示されていない場合は、以下の様にロードバランサー自体作り直す必要があります。コンソールから作る場合はロードバランサー作成時の一番最初の画面に表示されるListener Configurationの項目に80番ポートと3306番ポートの両方を追加すればＯＫです。（作成後にコレを修正する方法、探したけど見つかりませんでした＞＜）

elb-create-lb ロードバランサーの名前 --availability-zones us-east-1a --listener "protocol=TCP, lb-port=3306, instance-port=3306" --listener "protocol=http,lb-port=80,instance-port=80"

設定が終わったら、サーバー側でapacheを起動しておくのとpingの対象となるhtmlを設置しておくのをお忘れ無く。上記の通り設定変更した後に動作確認したところ、エラーなく無事動作していました！

mixiアプリのスクロールバーを消す

mixiアプリでは、記述する情報が増えて高さが一定以上になると、iフレームの右側にスクロールバーが表示される仕様がデフォルトとなっています。これ、意外とウザいんですよね。調べてみた所、openSocialが提供してくれているgadgets.window.adjustHeightというメソッドを使えば、簡単にウィンドウの高さを指定することができるようです。

1.xml内でadjustHeightの利用を宣言する

ここでちょっとハマったんですが、adjustHeightメソッドを使う場合は、xmlで利用宣言を行わなければいけません。メインとなるxmlファイルのModulePrefs部分にという記述を追加します。

     
           ...
        
           ...
    

上記の様になるとＯＫだと思います。opensocialでは、xml部分で宣言しておかないと利用できないメソッドがいくつかあるようで、ビュー画面を移動させるメソッドだとを追加する場合もここで宣言しておく必要がある様です。

2.adjustHeightメソッドを呼び出す

後は、javascript記述部分にてadjustHeightを呼び出してやれば、高さを固定することができます。

gadgets.window.adjustHeight(ここに高さを指定);

これでもう、クソ邪魔なスクロールバーは消えて、安心ですね！なお、高さの単位はピクセルで指定してＯＫです。adjustHeight(1000)とすると、iフレーム内の高さは1000pxになり、1000px以内ならばスクロールバーは表示されなくなります！！adjustHeight()とした場合は自動的に現在のiフレームのサイズに合わせたウィンドウサイズに調整してくれます。データの読み込み処理などを行ってる場合は、処理終了時にadjustHeight()を行うと良いでしょう。