ツイート8Aimingは、この夏、スマホ向け新作タイトルを一気に5本リリースした。怒濤のリリースの裏側には開発者の人知れぬ苦悩もあった。「トライリンク」というゲームを例に、開発チームが何に苦悩し、それをどう乗り越えたのかを赤裸々に語ってもらった。光の女神と七魔獣」(以下、トライリンク)は、社内では「お正月プロジェクト」と呼ばれていたそうですが、なぜですか?保泉:長い話になりますよ(笑)。そもそもは2014年の正月明けに椎葉(忠志)社長から「スマートフォン向けのMMORPGゲームを作りたい。“レイドバトル”ができるものにせよ」というお題を言い渡されたのがきっかけです。レイドバトルというのは、レイド専用のクエストを複数のプレイヤーで同時にプレイするモードのこと。マップのどこかにいるボスを追い詰め、協力して倒すのが目的となります。その頃、エンジニアは僕一人。プランナーとデザイナーと僕の3人で、まずはゲームの方向性を考え始めました。光の女神と七魔獣」Aimingが自社製作タイトルとして2016年7月6日にリリースしたスマホ向けMMORPGゲーム。500年前に繰り広げられた神々の戦いを元にしたストーリーを軸に、9人のプレイヤーが力を合わせて巨大なボスと戦う“ボスバトルRPG“に特徴がある。3対3のリアルタイム対人戦ではユーザー同士ならではの深い心理戦が楽しめるほか、チャットやギルドなどのコミュニティ機能も充実。リリース1週間で30万ダウンロードを突破。その後も、頻繁なアップデートやイベント開催を実施。9月にはUIを大幅にリニューアルした。──最初はどんなイメージだったんですか。保泉:スマホ向けということで、最初にイメージしたのは、ターン制ストラテジー。敵と自分に分かれて、お互いコマンドを決めて、規定のターン(手番)数までに大きなボスを倒す。リアルタイム性はさほどなくて、1ターンごとにプレイヤーは考える時間があります。その頃は、まだスマホの通信環境もよくなかったので、サーバに常時接続のバトルゲームを作る気はなかった。WebAPIだけで面白いバトルRPGを実現しようとしていたんです。最初の3カ月はモックも目まぐるしく見た目が変わりました。動かすうちに、ああしたい、こうしたいと、プランナーやデザイナーからもいろんな要望が出てきます。それぞれ別のことを言う(笑)。それを僕一人で実装するわけですから、それは大変でした。高広氏エンジニア側のリーダーとしてディレクションを行う。当初は1人でクライアントのプロトタイプを開発。その後、バトル系のサーバーとのつなぎこみなどを担当。前職は、Aiming大阪スタジオの前身会社でソーシャルゲームやMMORPGの開発に従事。オンラインゲームを開発して13年のベテラン。3人が共通して感じるようになったのは、同じターン制でもやはりもっとリアルタイム性が必要だよね、ということ。たしかにスマホの通信環境というネックはあるけれども、僕ら自身が遊びたいゲームを作りたいじゃないですか。僕もPCのMMORPGの開発経験はそれなりにあって、やはりMMORPGで最も大切なのは、リアルタイムにそこに人がいる感じ、リアルタイムにその人とコミュニケーションが取れていることが大事なんだと思っていましたから。スマホだからと妥協せず、本来のMMORPGらしい技術実装を考えるようになりました。いえ、リアルタイム性が求められるのは、レイドバトルのところ。それ以外の、アイテムを強化する、ステイタスを見るというところはそこまで同期性を必要としない。非同期でもいいところはWebAPIを利用する。ゲームサーバーとのリアルタイム通信とWebAPIの両方の技術を盛り込もうとしたんです。簡単には納得しない「最も面倒なユーザー」が社内にいた──そのあたりに時間がかかりましたか?保泉:最初のプロトは1カ月でできたんですが、遊ばせ方のイメージを固めるのが難しかった。最初のプロトの段階では、ユーザーさんが遊んでいるイメージがまだ見えなかったんです。うちの社長はどんなゲームをするにも徹底したユーザー目線で指摘します。「分かりづらい」と何度言われたことか。うちの社長こそが“最も面倒なユーザー”です。社長を納得させるのは大変ですが、その指摘のおかげでブラッシュアップできたと思っています。──増田さんと市東さんは後からチームに合流したんですよね。増田:クライアントのモックがだんだん形になる頃でした。ボス戦を3人のユーザーがマッチングして戦うというモードがあるんですが、それをどういう方法で実装するか。最初は全部の戦闘部分をWebAPIで実装する仕様でした。ところが、社内レビューで「プレイ中に他のユーザーがやっていることがわからない。ゲーム中にもチャットしたい」という意見が出ました。これを実現するためには、WebAPIのみの実装をやめて、ゲームサーバーとリアルタイム通信でやる必要がある。僕はその部分を全部C++で作り直しました。そのほうがリアルタイム性を出せるし、パケット量も少なくてすむし、通信も安定する。最初からC++で実装しろって話ですけど、当時は社内にC++を書けるエンジニアが少なかった。一方で、Railsを書けるエンジニアは豊富にいる。僕としては、後々のメンテナンスを考え、自分一人でカバー仕切れなくなったとき、安心して人に任せられるようにRailsでWebAPIを書いていた方がいいと思ったんです。ゲームとしての醍醐味を出すためには、やはりレイドバトルの実装にはリアルタイム通信が必要だなと、仕様を転換したわけです。一浩氏クライアント側のプロトタイプができて、これからサーバーとつなぎ込む段階という2014年4月ごろ、チームに参画。サーバー技術全般を得意とする。前職では「メビウスオンライン」のサーバー側を開発していたこともある。──技術仕様を変更するのは、社内的に簡単にできるんですか?増田:社長はユーザーとして要望は出すけれど、技術選択については信頼して任せてもらっていますから。保泉:僕も以前C++でサーバーを書いていたので、大きな抵抗はなかったですね。それに「お正月プロジェクト」の方針で若い人がやりたいことは拒まない。他のセクションに大きな影響が出ない限りは、前向きに話をする。頭から否定しない、というのがありましたし。市東:若い人って(笑)、そんなに年違わないけど。準氏2015年5月から「お正月プロジェクト」チームに参入。ゲームサーバー側のWebAPI担当。管理ツールなどのバックエンド開発にも従事。前職は、印刷会社のSE。ビジネス帳票の案件を仕様書にまとめてエンジニアに流すというポジション。開発をしたくてAimingに転職した。保泉:あ、後からチームに合流する人っていう意味ね(笑)。市東さんが、コードレビューにGitHubを使いたいと提案したときも、僕、反対しなかったじゃないですか。それまではGerritを使ってコードレビューをしていたんですが、GitHubに移行しようと提案したのは僕です。それぞれいいところがあるけれど、リクエスト機能が優れていて、レビューのしやすさはやはりGitHubですから。保泉:社内の基盤開発チームや大阪スタジオは以前からGitHubを使っていました。そのチームにレビューしてもらえるということも、GitHub採用の大きな理由ですね。今は僕らのチームは、プランナーもデザイナーもGitHubを使っています。Trackerでチケット管理しています。これは業務委託のエンジニアたちと共同作業を進めるのに、とても役立っています。市東:こうしたツールの選択は、所詮クールかどうかが重要。クールじゃないツールは使う方のモチベーションにも影響すると思います。エンジニアはやりたくない理由を論理的に説明できなければならない──開発組織では、技術者が使いやすいものを、非技術者も使えるようにするというのは、大切なポイントですよね。ところで、2014年の正月に始まってからリリースまで長かったですね。保泉:中心機能のバトル部分はできたものの、周辺機能の実装で手間取りました。最近のゲームを参考にいろいろな機能を入れていきたいという意見がありました。コミュニティ、フレンド、ミッション、装備品の強化など育成の部分ですね。このあたりは市東さんに担当してもらったのですが、それでも手が足りなくて、エンジニアを他に2名、さらに業務委託の人にも加勢してもらって機能を充実させていきました。市東:経営や企画サイドから上がってくる要望を、エンジニアはどう受け止めるか。それには二択あると思うんです。一つはハイハイといって何でも作っちゃう方法。一つはとりあえず、そんなのできないよと否定から入る方法。従うか、抗うかのいずれか。前職では、会社の風土なのか、とりあえず抗うのがエンジニアの流儀とされていました。最初は決してイエスと言わない。イエスと言うとどんどん無理難題なタスクを振られるからです。それって社内政治の論理ですよね。エンジニアだからできないものはないんです。要望を実装するのがエンジニアの仕事。「オレ、やらないよ」というのなら、その理由を論理的に説明できないといけないんです。この会社では許されていることだけど、「この仕様はクソだから作りたくない」ということが言える。私が面白くないといっても世間の人は面白いと思うかも。そこで、自分がクソだと思う理由をちゃんと説明できないといけない。それを企画サイドに伝えないといけない。いう前職とは違うエンジニアの仕事のスタイルを、このプロジェクトで体得していきました。保泉:それって会社のスタイルというよりは、うちのチームの特色かも。プランナーに意見を言うエンジニアが多いのはこのチームの特色(笑)。リリース後、いきなりメンテが必要に──2016年正月のころは、開発はどんな感じだったんですか。保泉:椎葉社長からは対人戦(PvP)の要素が足りない、と言われていました。そこでさらに1カ月かけて、対人戦のところを作り込み、ほぼ機能が揃った状態になったので、リリーススケジュールを組むことになりました。外部のデバッカーさんにも入ってもらって、ずっとデバッグ、バグ修正の繰り返し。その間にもプロモーションをしていくので、外部に見せられるものを作りつつ、本番のバージョンを用意するというわけです。サーバーのほうは僕らが全部メンテナンスをする時間がないので、サーバー更新はプランナーや運営担当者もできるように、Jenkinsを使ってメンテンナンスの自動化を試みました。増田:その担当は僕ですね。最近のJenkinsは進化していて、例えば本番環境の実行もボタンを押せば誰でもできて、実行状況がグラフでわかり、成功・失敗の結果も色ですぐわかる、そんなGUI的なUIで使えるようになっています。デバッカーさんもこれを使ってデバッグする。いうのを用意したことで、プランナーも自分でテストするようになりました。保泉:僕らは基本、面倒くさがりなので。自動化できるところは自動化したい。MMORPG開発経験で、メンテナンスの大変さをよく知っていましたから。デプロイまで自動化するのはうちの会社でも珍しいかも。ターミナルでコマンドを打ってというのはあるけれど、GUIでやれるようにしたのはうちのチームぐらい。「トライリンク」の運用が落ち着いてきたタイミングで、その知見は他のチームにも伝えていきたいと思っています。──7月6日のリリース直後はどうでしたか。保泉:僕よりもこの二人が大変でした。市東:リリース直後に瞬間的な負荷がかかって、それは想定通りだったんですが、エラーが飛び交ってログインできないという状態が発生しました。リリース1時間以内で、最初のメンテナンスに入るというのは、Aiming始まって以来の不名誉な快挙です。なんとか3時間で修正して、改めてリリースしましたけれど。他にも、対人戦でマッチングするユーザーが多くて、マッチングできないという問題も発生しました。そこは自分が実装したところなので、一瞬、青ざめましたね。いえ、誰が実装していてもそのコードはチームのモノなので、誰かを糾弾するという文化はうちにはないですね。謎の実装の背景にはなぞの仕様があったりしますから(笑)。増田:僕はそんなにあわてることはなかったです。負荷が増えれば、サーバーリソースを増やすことで対応できるような仕様にしていましたから。心配はしていなかった。保泉:最初のメンテナンスはともかく、「トライリンク」は臨時メンテが実はそんなに多くないんです。WebAPI側のメンテナンスはゲームを止めずにオンラインでできる。C++でリアルタイム機能を実装したゲームサーバー側も、もともと振り分けを管理しているので、振り分けから外せばオンラインでメンテできる。クライアント以外は止めなくても修正できるように設計されていますから。ユーザーの継続率を高めるために、まだまだできることはある──さて、「トライリンク」の評判はいかがでしょうか。保泉:古くからのMMORPGユーザーからは、古き良き時代のゲームの雰囲気だねとよく言われます。作っている人間が古いのかもしれないけれど(笑)。スマホから入っている若い人たちも、ぜひ一度トライしてみてほしい。前にも言ったように、MMORPGって僕が思うには、ユーザー同士のコミュニケーションが一番の醍醐味。若い子もSNSでコミュニケーションをとっていると思うけれど、単方向が多いと思う。双方向でダイナミックに遊べるゲームがこれからどんどん出てくる。その面白さをぜひ味わってほしいなと。増田:社長が言い出していまや会社の社訓みたいになっている、「ゲームは飽きるが友達には飽きない」という言葉。それが実感できるゲームだと思うんですよね。──アップデートも盛んに行っているようですが、これからはどんなところを強化していきたいですか。保泉:ゲームを純粋に継続してもらうための仕掛け。分かりにくさも残っているので、それを改善したいですね。エンジニアもプランナーもユーザーとして意見を言い合う文化が当社にはあります。中にはネガティブなコメントもあるけれど、それを真正面から受け止めて、改善につなげていきます。その上で、プロモーションも積極的に仕掛けていきたい。うちの会社のゲーム全体の特徴としてよく言われるのは、スロースターターということ。リリース後に改善に改善を重ねることで、高い収益に達したタイトルがたくさんあります。「出足はそんなでもなかったけれど、今は稼ぎ頭だよね」というように、そうですね、プロジェクトが4回目の正月を迎える頃には言われたいですね。2まつもとゆきひろ氏がSpeeeで語った、勉強会・英語・プログラミングの話3永江一石さんが語った、WebメディアにおけるSEOと著作権、その利活用例とは?4GMOペパボの新技術「Haconiwa」、新アーキテクチャ「FastContainerアーキテクチャ」とは?5綺麗なコードと汚いコード。#Elixir6本日の調理実習は「スパゲッティコード」です。RSSCodeIQとはCodeIQ(コードアイキュー)とは、自分の実力を知りたいITエンジニア向けの、実務スキル評価サービスです。Tech総研ページ上部へリクルートグループサイトへCodeIQとはCodeIQ(コードアイキュー)とは、自分の実力を知りたいITエンジニア向けの、実務スキル評価サービスです。Co.,Ltd.リクルートグループサイトへ。