基本的に開発自体は1ヶ月、大きいものは2ヶ月かかる
司会者：次の質問です。「コラボなどで新しいシステムを構築する場合、だいたいどのくらいの期間をかけて制作するのでしょうか？ また、企画段階から開発の方も入っているのでしょうか？」ということですが、こちらはどうですか？
上平竜也氏（以下、上平）：規模によってけっこう期間は変わりますね。例えばレイドイベントだったら、すごく大きな企画だったので開発期間だけで2ヶ月ぐらいあったと思います。そうでなかったら1ヶ月ぐらいが多いイメージがあります。
王奇氏（以下、王）：そんなものだと思います。内容にもよりますが、モンストはみなさんが遊んでいると、バージョンアップメンテが月に1回ぐらいあると思います。コラボの案件だと大抵2回分の期間になりますね。2回前のメンテから開発をしている感じです。
司会者：じゃあだいたい2ヶ月分ぐらいになる。
王：そういう感じになります。もっと大変な案件だと開発期間は延びないかもしれませんが、その場合事前に相談が入ります。
司会者：なるほど。
王：コラボだと「これは作れるんでしたっけ？」みたいな。
（一同笑）
司会者：確かに、そうですよね。
王：世界観があって、「こういう感じの要件を落とし込みたいんですけど、これって作れるんでしたっけ？」という事前相談が入って、作れるもしくは無理という判断があって、また版元と調整するみたいな感じです。
司会者：開発できるかの調査などで実際の開発に入る前の段階で時間が使われる時もあるということですね。
王：全力で提案させていただきますけど。
（一同笑）
司会者：開発できるように（笑）、がんばって調査する感じですね。基本的には開発自体は1ヶ月で、大きいものは2ヶ月くらい。
王：そうですね。
調整やすり合わせの段階で開発が企画に入ることもある
司会者：企画のものによってはその前に調査期間がある感じですね。
王：そうですね。
上平：コメントでいただいた「企画段階から開発の方も入っているのでしょうか？」という話は、今王さんが言ったように調査もありますし、企画の方から「こういう仕様でコンテンツを作ります」とすり合わせがある時に、僕たち開発からも「ここはこういうほうがいいんじゃないか」とか「これはこうすると現実的にちょっと厳しい」とか、みんなで調整やすり合わせをすることもありますね。
王：サーバーで言うと、作れるか作れないかと同時に負荷的に大丈夫かどうかが常にポイントになります。「作れるけどサーバーは落ちますよ」だと作れたとは言えないので（笑）。
司会者：なるほど。確かに、モンストは本当に多くのユーザーに遊んでもらうので一気に稼働するとなるとサーバーがバタッと落ちてしまうことも……。
王：そうですね。キャンペーンをする時にちょくちょく緊急メンテを飛ばしています。ご迷惑をおかけしています。
モンストは良いサーバーを惜しみなく使っている
司会者：多くのユーザーに遊んでいただく上で、クラウドとかオンプレとか、モンストがサーバーをどう持っているのかという紹介もできますか？
王：モンストでは、マルチクラウド＋データセンターというこれ以上ないハイブリッド、何でも使えるスタイルを採用しています。会社名は出しませんが主流のクラウドはひととおり使っていて、プラス自社のデータセンターを構えています。
司会者：もうそれをフルで活かしているんですね。
王：そうですね。各種特徴があるので、急いでサーバーを確保したい場合はやはり自由度が高いクラウドを使います。また、既存のサービスで一部使えるものは使って、重要なものは基本的に自社のデータセンターの中に大事に持っています。あと、単純に自社のサーバーは性能が良いです（笑）。
上平：すごく良いカードが並んでいますよね。
王：そうですね。
司会者：「モンストは良いサーバーを使っている！」と。
王：普通のアプリケーションで使っているサーバーもメモリが200GBとかはザラです。そういうものを3桁台買ったりします（笑）。
上平：普通の感覚だと「え、え？」となる。
（一同笑）
上平：僕は最初に見た時に「え？」となりました。
司会者：それぐらい多くのユーザーに使ってもらっていて、同時接続もけっこうあるんですもんね。
（一同笑）
司会者：ぜひいっぱい遊んでほしいですね。
「フラパ（XFLAG PARK）」には負荷の監視のために参加している
司会者：もう1つ質問を追加でいただいています。「週末にフラパ（XFLAG PARK）が開催されますが、こういうオフイベントに関係する業務はされているのでしょうか」。
王：上平さんは担当していませんが、フラパ用の機能も開発の案件には入ります。これまでもフラパでやっていた「オラフラッグ」のイベントとかも専用に開発したシステムです。
司会者：なるほど。そうなんだ。
王：あとは単純に負荷の監視ですね。フラパには参加しますがやはりサーバーとなると何かあるかもしれないので。
司会者：確かに。みなさんが楽しんでいるところで落ちるわけにはいきませんからね。
王：待機することが多いですね。
司会者：ゲームから派生しているイベントではあるので、そのあたりは一緒に携わっている感じなんですね。
王：フラパが警戒されるのは、過去に1度だけ緊急メンテで落ちたことがあるからです。それはルシファーの獣神化ですね。
司会者：あれは大イベントだったので。
王：そうそう。それからはフラパではルシファーが要注意対象に（笑）。
司会者：なるほど。サーバー的には（笑）。だから、そこらへんの監視には携わっているんですね。
王：はい。フラパの会場でPCを開いている人を見かけたら、サーバーかもしれません。
司会者：サーバーの人かもしれない。
（一同笑）
司会者：（視聴者に）もし行かれる方がいて、会場でパソコンを開いている人がいたら「サーバーですか？」と確認してみてもらって（笑）。確かにそういう負荷監視の業務はあるかもしれないですね。（コメントを見て）「大変だ」とコメントいただいていますが、大変ですね。
（一同笑）
サーバーサイド側にとって想定外の仕様はバグになる
司会者：次の質問です。「これまでに『バグではないが、想定外の仕様になったこと』はありますか？ ステージ仕様と特定のストライクショットの組み合わせで、ボスワンパン（ボスを一撃で仕留める）など」。
上平：サーバーサイド側からの視点で言うと、想定外の仕様になってバグではない扱いになることはほぼないんじゃないかなと思っています。サーバー側は、基本的にユーザーの資産を操作する処理が多いので、そこで想定外の値を出したりしたらもうそれはだいたいバグな気がします。クライアント側だとそれが楽しみにつながることがあるのかもしれませんが。
王：そうですね。やはりサーバーの不具合になるとユーザーの損失につながるので、笑って流すようなバグは出ませんね。大抵はサーバーがバグになると補填になります（笑）。
司会者：そっか。クライアント側との話はまた別の視点という感じがしますね。
上平：そうですね。
和気あいあいとした雰囲気のサーバーチーム
司会者：私から1つ質問してもいいですか？モンストのサーバーグループはどんな雰囲気、どういうグループですか？モンストって和気あいあいとしていて職種関係なく企画を上げたい人が上げたり、本当に分け隔てないイメージがあるんですが、サーバー側はどうですか？
上平：すごくダジャレが多いし和気あいあいとサーバー側は笑っています。
司会者：なるほど。
王：昔面接する時にダジャレを正当化したことがありますね。
司会者：どういうことですか？
王：ある種の頭のトレーニングになるからというもっともな理由を出して、日々ダジャレをやっています（笑）。
司会者：（面接を）受けてくれる方のハードルが上がるかもしれないけれど本当に和気あいあいという感じなんですね。
王：リアルボディではあまり会えないですね。
司会者：けっこうリモートですか。
上平：例えば僕は今は奈良のほうに住んでいてフルでテレワークをしているので実際に出社するのはけっこう稀な感じです。
司会者：今日上平さんを生で見られているみなさんはレア会に参加しているということですね。
上平：こういうタイミングで出社をすると「リアルボディだ」とすごく珍しがられますね。
司会者：（笑）。そうなんですよね。ミクシィでは4月からフルリモートがOKになっていて働き方が変わってきています。その中で上平さんは今日奈良から来てくださっているので。
王：出社をされる方もいて自由にやっていますが、サーバーとなるとやはりどこでも対応ができる状態が求められるので、そういう感じになりやすいですね。
司会者：なるほど。働き方の柔軟度もありつつ、対応する時はしっかり業務としてやっていて、雰囲気としては和気あいあいですね。
サーバー側の視点から企画担当者に提案することもある
司会者：ちょっと質問が来たので紹介します。「サーバーサイド担当者から企画担当者に提案することはあるのでしょうか」。例えば、企画の提案だったり、先ほどお答えした内容にもありますが、調査の時に企画から依頼が上がってきた時に答えるだけではなくて、「こうしたら？」のところとか……。
上平：企画が「こういうコンテンツをやりたい」というのに対してサーバー側から「こういう方向でできないかな」ということはよくあります。サーバー側からキャッチボールを始めるパターンだったら「ここの負荷を軽減したいからこういうことをやっていっていいか？」と聞くことはたまに発生しますが、基本的にはそんなにないイメージですね。
王：サーバー都合の提案ですね。負荷上必要なので「今年もがんばるので合わせてください」みたいな提案のほうが多いですね。
司会者：なるほど。例えばエンジニアさんや企画担当者などの職種は省いてけっこうみんな企画の提案ができる雰囲気だと以前お話をさせてもらったのですが、そういった企画とかもサーバー側からできなくはないという感じなんですか？
王：できなくはないというか、実際にやっている方もいると思います。サーバー側のメンバーが企画を回していることはまだありませんが、「モンストをもっと良くしたい」というスレッドがあって、みんなでそこに書き込みしていますね。
司会者：何かあれば提案できる環境で、適宜企画の担当者にもサーバー側の都合で提案することもあるということですね。ありがとうございます。
アイテム付与、ガチャのロジック、ステージのクリア処理などは年に1度大きく整理をしている
司会者：次の質問です。「ソースコードの中で、昔のコードをきれいにしたいのに……と感じる時はありますか？ その場合は書き直しますか？ それともテストする時間がなくて、諦めていますか？」。
上平：これは歴史的経緯の話なので王さんに……。僕が感じることだけを先にすると、書き直したいコードが出てくることはあります。モンストも歴史が長いので、そういうところも発生しています。そういうまだまだ残っているコードは少しずつ直していく時間を取っていますし、周辺のコードを書き替える時に一緒に対応したりしています。
王：テストする時間がなくて泣く泣く諦める時はなくはないですが、実はそういう感じのことは毎年やっています。諦めずにやってくれる方はきちんと評価していますし（笑）。
ユーザーのみなさんには何が変わったのかがわからないかもしれませんが、直近のケースだとアイテム付与、ガチャのロジック、ステージのクリア処理など、年に1回ぐらいは整理が入っています。もう昔のモンストのコードとはだいぶ違います。
司会者：なるほど。メンテに間に合うか間に合わないかというところで（コードの修正を）諦めることもなくはないけれど、年に1回大きく整理をしている感じですかね。
王：そうですね。そこは担当者に実装できる技量を求めるだけではなくて事を運ぶ。うまくスケジューリングします。
司会者：確かに、それも大事ですね。
王：大きな仕事をサーバーを落とさずにちょっとずつやっていくということも考えなければいけないです。
司会者：モンストは止められないですからね。
（一同笑）
司会者：技術もそうだけど、スケジューリングの中でどうできるかというところはもともとやっているという感じですね。
王：はい。
司会者：分かりました、ありがとうございます。
サーバーが落ちた時はどう復帰するか？
司会者：次の質問です。「サーバーが落ちた際は、復帰のためにどのようなことをされているのですか？ また、サーバーが落ちないようにどのような対策をされていますか？」。
上平：難しい（笑）。落ちる理由によって対策は変わってくるし、落ちないようにというのもハード的な話だったりソフト的な話だったり、それぞれありますもんね。
王：そうですね。雰囲気の話でお答えしますと（笑）、まずは復帰のためにとりあえずメンテを入れます。
（一同笑）
司会者：そうですよね。
王：すべてがそうではないかもしれませんが、これ以上被害が拡大しないように適切にメンテを入れる判断をします。基本的にバックアップのサーバーが大量に用意されているので、復帰する時はそれに差し替えるのが主な対応になります。
司会者：ゲームのサーバーのところだと、一般的にそういう感じになるんですかね。
王：そういう感じになります。操作をしなくても勝手にバックアップのマシンを適当に持ってくるのが仕組み化されているところはクラウドサービスを使っていますが、モンストのデータセンターは今はそういう仕組み化はされていません。ただアプリケーションとかは、ロードバランシングされている部分が数台壊れても問題はないようになっています。
司会者：なるほど。
上平：ソフト的な話で言うと実装まわりの問題でサーバーを壊しちゃった場合だったら、（ハード面と）同じようにメンテを入れるんですが、そこからログを見ていって、何が問題を起こしたかとかを調査する必要があります。例えばデータベースにメチャクチャ処理が走ってしまってサーバーが思うように動かなくなっているところを調査したり対応したりします。
王：復旧のために今までにもっとも大変だった作業は失われたデータの復元かな？ 例えばデータベースは複数のバックアップを持っていますが、仮にマスターが死んだ時はそのバックアップを使って復旧します。普通はそうなんです。ただバックアップといっても常にリアルタイムでマスターと同じデータを確保できているとは限らない。
司会者：時差がある、と。
王：ズレが発生している場合は、マスターのサーバーが残したログから実はこういう更新が発生しましたということを分析して、サルベージして、それを復元します。もしくは変な操作が行われた場合は、その操作がなかったようにロールバックする。こういうことはごく稀に、数年に1回は発生します。
司会者：数年に1回。モンストはもうちょっとで9年なので数年に1回だったら……。
王：僕が知る中でも1回あるかないかくらいで、相当大変なのでみんなあまりやりたくないんですよ。
（一同笑）
上平：僕もやりたくないですね。
司会者：そういう復帰や対策をしている感じですね。ありがとうございます。
登壇者からのメッセージ
司会者：このあたりでQ＆Aは終了とさせていただければと思います。それでは最後にまとめに入っていきたいなと思います。上平さん、王さんから一言ずつ感想をいただければと思います。上平さん、今日のイベントのご感想はどうですか？
上平：そうですね。みなさんからすごく質問が来ていたので、それがうれしかったです。
司会者：オンラインイベントの良いところですね。
上平：モンストのサーバーに興味を持ってもらってうれしいです。
司会者：ありがとうございます。王さんお願いします。
王：そうですね。みなさんの質問がすごく鋭かったです。最初に「覇者の塔はなんで大丈夫だった？」という話が出てきた時もそうだし、「昔のコードをきれいにする」のも重要な課題で、サーバーとして継続的に取り組んで行かなければいけないことなので、まったくもってみなさんがおっしゃるとおりでございます。今後も引き続きサーバーを落とさないように運用していきたいと思います。よろしくお願いします。
司会者：ありがとうございます。本日のThe Methodはこれにて終了としたいと思います。楽しんでもらえたでしょうか？ 次回もみなさんに楽しんでいただけるThe Methodを検討中です。日程やイベントの詳細は、別途イベントページにてご案内いたします。
モンスト事業本部では、The Methodを含むイベントの案内やキャリア情報をTwitterの「モンスト採用アカウント」から発信をしています。ぜひこの機会にフォローしてもらえるとうれしいです。今回の感想も「#モンストのメソッド」を付けてぜひ発信をしてもらえると私たちも見られるので大変うれしく思います。それではお時間になりましたので、こちらで終了といたします。
また会える日を楽しみにしています。本日はありがとうございました。さようなら。
