モバゲーから提供されているソーシャルゲーム『魔法少女リリカルなのはINNOCENT』は，企画・開発・運用を（⁠株⁠）ユビキタスエンターテインメントが行っています。このサービスを支えるインフラは物理サーバと仮想サーバのハイブリッド構成となっており，（⁠株）IDCフロンティアのクラウドサービスが採用されています。本稿はこの両社から，人気ソーシャルゲームならではのデータを交えながら，DevOps実現に向けての取り組みを披露してもらいます。

前編のおさらい

こんにちは。（⁠株）ユビキタスエンターテインメント（UEI）の水野です。Software Design 2013年11月号に掲載した前編に引き続いて今回は，『⁠魔法少女リリカルなのはINNOCENT』のDevOpsに関して書いていきます。

前編では，ソーシャルゲームに重要な目的と特徴は次のとおりであることと，運営の実際についての事例を書きました。

目的

プレイヤーが常に新鮮だと感じるイベントやシステム，成長素材を提供し，安定してゲームを遊んでもらうこと。

特徴

1. 1ヵ月に数十回の小規模開発＝「カード追加」「⁠UI改善」「⁠小機能追加」のリリースが発生すること
2. 1ヵ月に数回の中規模開発＝「ゲーム内イベント」のリリースが発生すること
3. 数ヵ月に一度の大規模開発＝「新規ゲームイベント」のリリースが発生すること
4. 技術者の調査が必要なユーザサポートへの問い合わせが日に数件～数十件必ず発生すること

今回は弊社で行っているDevOpsへの取り組みを，そして，IDCフロンティアの藤城さんからは，これらを支えているクラウドサービスのインフラについてお話しいただきます。

［Part1：開発サイド］DevOpsを構成する部門要素

本作品でのDevOpsは，「⁠開発（Dev⁠）⁠」⁠「⁠運用（Ops⁠）⁠」⁠「⁠品質保証（QA⁠）⁠」の3部門から成り立っています。前述の目的を達成するには，上記の3部門が互いの立場を理解してコミュニケーションをより多くとることがとても重要です。そのために，どのようなことを行っているかを解説していきたいと思います。

開発するシステムの企画構成をリーンにする

ソーシャルゲームのDevOpsをスムーズに行うためには，まず「企画構成をリーンにする」という意識が重要です。「⁠リーン」とは「引き締まった」という意味で，基本機能をユーザが楽しむために本当に必要な企画のみに絞り，「⁠あるといいんじゃないかな……」や「機能Aと機能Bが連動していると，ちょっと嬉しいよね？」という程度のものは勇気を持って省きます。

たとえば本作では，対CPU戦と対人間戦の機能間は，片方の進行度や勝敗の結果が他方に影響を与えることはありません。報酬も経験値とゲーム内マネー，そしてアイテムに限定されています。しかし企画者としては「対人戦で負けたら，同じようなカード組み合わせが対CPU戦に出現して，勝つまでいろいろと試せる機能があったらおもしろいよね」とか言いたくなります。

が，ここはぐっとガマンです。

もしユーザが本当にそれを求めるのであれば，その内容でイベントを企画・開発すれば良いのです。あまり基本機能を盛りだくさんにしてはいけません。

このことは，ゲーム運営に入ったときに大きなメリットとなって効いてきます。なぜなら，機能的に軽く疎結合であるほど修正や機能追加の範囲を狭くできますから，万が一問題が発生した場合の原因も特定しやすくなるからです。それは目的の1つである「プレイヤーが常に新鮮だと感じるイベントやシステムを安定して提供すること」につながります。

開発チーム構成を考える

企画の次はゲーム運営時のチーム構成を考えます。開発チーム編成が，マイルストーンに対して不足していては新機能を安定して提供していくことはもちろんできません。前述のとおり，本作品では，1ヵ月の間に最低数回のリリースが発生する以上，1チームでマイルストーンをクリアしていくことは難しく，開発チームのマルチライン化が必須です。私たちは開発を3チームに分けて，このスケジュールを次の役割構成で開発を行っています。

• メインイベントの開発
• スキル追加とUI/UX改善
• ユーザサポート

この3つのチームはそれぞれ，

• 企画からの要望による開発
• ゲーム運営からの要望による開発
• ユーザからの要望による開発

に対応しています。これらの開発の中にイベントなどの振り返りで得られた運用（Ops）からの意見も取り込んでいきます。

そして，このチームを数ヵ月ごとにローテーションで役割を変更します。これには次の意味があります。

• 役割が固定されないので飽きにくい
• それぞれの役割の相互理解が深まる

とくに，ユーザサポートを全員が体験することには大きな意味があります。ユーザサポートチームでは，ユーザの問い合わせによって内容を調査し結果を返答しますが，その調査は単純なものでなく，MySQL内のレコードからApacheログまでマッチングした結果でないと返答できないことも少なくありません。ですので，幅広い知識を自然に学習することになります。また，ユーザの生の声やUI要望を聞くことで，それぞれの開発の役割を担うときに，ユーザが理解しやすく質の高いコンテンツや，より調査や追跡がしやすいシステム設計にフィードバックしようという意識を持つことができます。

ファイル構成を分離する

サーバ上に配置するファイル構成は，高頻度でデプロイしてもミスを起こさないように設計しておきます。

全ファイルを1つのディレクトリ以下にまとめる

システム動作に必要なすべてのファイルを1つのディレクトリ以下に集約します。本作品ではPHPを使用していますが，そのライブラリもシステム側にインストールするのではなく，他のコードファイルと並列に格納しておきます（図1⁠）⁠。

これにより，コードと同じようにバージョン管理ができますので，ホスト間でのライブラリバージョン違いなどのわかりにくい問題が少なくなります。

機能別にディレクトリを分ける

本当に基本的なことですが，チームごとに分離して作業しやすくするために機能別にプログラムのディレクトリを分けます（図2⁠）⁠。

プログラムの設定ファイルをサーバに依存しないようにする

プログラムの設定ファイルは各サーバに依存しない記述にしておきます。本案件ではリスト1のように，DBのホスト名などはhostsでの解決にまかせ，設定ファイル上にIPアドレスなどのサーバ固有情報を書かないようにします。

;スレーブDB接続の定義
db_slave_host = "masterdb"
db_slave_user = "dbuser"
db_slave_passwd = "dbpassword"
db_slave_name = "dbname_001"

;マスタDB接続の定義
db_master_host = "slavedb"
db_master_user = "dbuser"
db_master_passwd = "dbpassword"
db_master_name = "dbname_001"

個別の設定ファイルにサーバ固有情報などを書かないでおけば，すべてのサーバで同じ設定ファイルが利用でき，デプロイするすべてのファイルがバージョン管理できることになります。これにより，設定ファイルに記述追加が必要になったときでもデプロイミスを防げます。