1. ソシャゲはユーザ層を幅広く意識する必要がある

ソシャゲの大きな特徴のひとつとして、「ユーザが継続的に遊ぶ」という点があります。

ソーシャル性（人との関わり）がある
コンテンツを継続投入する

ことで発生するワケですが、このとき注意しないといけないのがユーザ層についてです。

通常のゲームであれば「ライトなユーザ」か「ヘビー（マニアック）なユーザ」のいずれかターゲットを絞ることも多いかと思います。
ゲームクリアまで遊んでもらうことを目的とするのであればターゲットを絞っちゃった方がコンセプトがハッキリして良いですが、ソシャゲは継続的に遊んでもらいたいがゆえに、「ライトな層を取り込んで育て上げる」のと「ヘビーな層に継続して遊んでもらう」の両方が必要です。

そのためには、クセになる要素、ついついやってしまう要素が必須。
さらに「やらないと損をする」感を出せれば一層効果アップでしょう。
（このあたりがうまく出せていないので苦戦しています。ｗ）

2. ユーザは開発者の想像を容易に超えてくる

ソシャゲに限らずですが、ゲームを気に入ってくれたユーザは開発者の想像を越えてきます。
想像を越えた上手さ、想像を越えたプレイ時間などなど。

で、何が問題かというと、開発者の「ここまでやらないだろう」という甘い予想はアッサリ覆ることです。

自分が一度ヤバイ状況に陥ったのが、int型の上限値問題。
プレイすればするほど数値が蓄積されていく仕組みだったのですが、サービス開始後数ヶ月で数人のユーザさんの値がint型の上限近くまで到達しており、急いでlong型に変更して事なきを得ました。（ヤバかった・・・）

「ここまでやらないだろう」ではなく「どれだけやっても安心」の設計にしましょう。

3. 運用ツールは手抜きしちゃいけない

現ソシャゲの運用ツールは、キャラデータCSVをJSONに直したり、イベントデータを定義したりなど、必要になった処理をPHPでサッと書いたものの集合体です。
必要な機能は揃っているのですが、「Laravel（PHPフレームワークです）にしとけば良かった・・・」と思うことがしばしば。

なぜかと言うと、現ツールは違法建築の集合体みたいで、美しくない＆拡張しづらいためです。。

あと、現ツールは「開発者が扱うためのツール」なのですが、複数人で運用する場合は開発者に負荷が集中してエライことになります。
データが間違ってた、クライアントが文句付けてきたなど、どんな些細な問題でもコッチのタスクになっちゃうわけで。。

ユーザ情報やキャラデータ管理など複数人が頻繁に使う部分に関しては、多少時間がかかってもUIを持たせて誰でも使えるようにしておくのが良いでしょう。
（AssetBundleのビルドも自動化したいなぁ）

4. AssetBundleは細分化すべし

初期のころは、キャラ画像やイベント画像などのデータを1つのAssetBundleにぶち込んでいました。

これは今思うと愚の骨頂でして、何故かと言うと1ファイルの変更があるだけで巨大なAssetBundleの再ダウンロードが必要になります。
これではストレージの通信コストがかさみ、開発者のサイフの中身がどんどん減っていくわけです。

AssetBundleはファイル毎にバラバラに生成するか、それが細かすぎるようであればある程度の粒度（頻繁な更新が起こらない粒度）でまとめるようにしましょう。

頻繁な更新が起こらない粒度とは、具体的には追加キャラ第一弾のキャラ画像をまとめたり、クリスマスイベントの画像データをまとめたりなどです。

5. JSONデータはAssetBundleに含めない方が幸せになれる

これは自身も早く解決したい課題。

現在はキャラデータやイベントデータはPHPでJSONを生成→AssetBundleに固める形で運用しているのですが、各種データはとにかく更新が多い。
JSONは他のリソースと分けてAssetBundle化しているので更新によって大量の通信が発生することはないのですが、とにかく「AssetBundleのビルドが長い」のが痛い。
JSONデータの1文字変えるだけでビルドが発生しますので、ものすごく時間のムダなのです。

ということで、頻繁に更新するデータはAssetBundle管理から外しておきましょう。
暗号化したデータを直DLの方が楽です。

6. チーターは必ず居るものと思え

ゲームをリリースされている方は常々意識されているでしょうけれども、セーブデータの改変などのチートは必ず発生すると思っていた方が良いです。

セーブデータの暗号化
データにチェックサムのようなものを含める
サーバとの通信をセキュアなものにする

などの対策が必要です。

JSONなどでセーブデータをひとまとめにしているのであれば、AESで暗号化して保存し、読み込むときに復号化すればOK。
セーブデータ自体の改変はこれで防げます。

ただ、ちょっと高度なチーターさんはメモリ上の値を直接書き換えやがります。
このあたりも厳密に対応する場合は、チェックサムを使いましょう。
現データのチェックサムを生成しておき、データを書き換える前にチェックサムを使って改変が行われていないかチェックするとかなり安心です。

また、上記はあくまでゲーム内部でのチート対策です。
サーバと通信する場合は通信内容自体を書き換えられてしまう場合がありますので、SSLは必須です。

ちなみに、経験上は数百ユーザに1人くらいはチーターが混ざっています。

※追記: SSLだけではまだ書き換えられてしまうとのご指摘をいただきました。
証明書ピンニング（クライアント側での証明書チェック）を入れるとよりセキュアになるようです！

7. 機能追加よりもクオリティを最優先に

ゲームを運用していると、やりたいことがたくさん溜まりがち。
複数人が絡んでいるのであれば、実装依頼や作業依頼もたくさん来ます。
新キャラを追加したい、こんなモードがあれば面白いんじゃないか、などなど。

開発者はそういったタスクで忙殺されがちですが、本来真っ先に対応すべきはクオリティの向上、つまりは不具合修正です。
不具合はストアのレビューにすぐ書かれちゃいますので、放っておくと新規参入ユーザの人数に大きく影響します。
レビューをいっぺん書かれちゃうと、あとで直してもレビューは消えてくれないんですよね。

ということで、状況に流されずやるべきことを先にやっちゃいましょう。

8. ★5レビューは積極的に求めるべし

不具合や不満などのレビューは放っておいても増えるのですが、面白いというレビューはなかなか増えません。
仮にゲームが面白かったとしてもです。

というのも、普段は楽しく遊んでいるユーザでもゲームの一部に不満を感じると「改善して欲しい」という要望をレビューとして投稿しちゃうワケで。

放っておくとレビューの方向性がマイナス要素に傾きがちなので、ゲーム側で積極的に★5レビューを求めるようにしてバランスをとりましょう。
（何度か遊んでくれたユーザに対し、しつこくない程度にレビューを求めるのが良さげです）

9. Unity Analyticsをフル活用すべし

アップデートやコンテンツ投入の効果を見たり、ユーザの性質を分析して何を求めているかを考えるためにはデータが必要です。

Unityは設定ひとつでUnity Analyticsという強力なサービスが使えますので、ぜひ活用しましょう。
DAUやMAU、リピート率などを分析すれば、自分のゲームの弱点はどこなのかが見えてきます。

ゲームからカスタムイベントを飛ばすこともできるので、どのステージまでクリアしたかなどのログを記録しておけばユーザがどこでゲームを離脱してしまったかもわかるようになります。

10. Unity Performance Reportingも活用しよう

恥ずかしながら筆者は最初このサービスの存在を知らず、わざわざ自分でエラーをサーバに送信する処理を実装していました。

Unity Performance Reportingを見るだけで、いつ・どのエラーが・何件発生したかがひと目でわかります。
どのエラーから潰していくべきかの優先順位もサクっと付けられるので便利。

あとがき

他にもいろいろありますが、今回はこのへんで。

小規模とは言えども、ソシャゲの開発＆運用は大変です。
ゼロから始めると予想もしていなかった問題が次々と発生しますが、反面やりがいもあります。

ただ、やりかた次第では個人での運用も全然できます。
（実際、コンテンツとデザイン以外はソロで回し中ですｗ）

個人や小規模なチームでも大企業と同じ土俵に上がることができる時代。
これからどんな流れになっていくか、その中で自分が何を為せるか、為していくか。
楽しみがいっぱいですね！