株式会社スクウェア・エニックスとアカツキの協業による新作スマホRPG『ロマンシング サガ リ・ユニバース』（以下、『ロマサガRS』）。SaGaシリーズならではの高い戦略性を持った奥深いバトルをスマホで楽しめるところが広いプレイヤーに支持されています。

『ロマサガRS』を長く遊ばれるタイトルにするために、運用を支えるのが2017年にアカツキに新卒入社し、『ロマサガRS』のサーバーサイドエンジニアを務める梶原 星平さん。

今回は、梶原 星平さんのキャリアと『ロマサガRS』の高いクオリティを実現するためのチーム運用や開発言語選びの裏側についてアカツキ応援団の能登 信晴さんがお話を伺いました。

多様なバックグラウンドの現場が「経験にフォーカスした成長」を支える

アカツキ サーバーサイドエンジニア 梶原 星平さん

能登　最初にまず、なぜ新卒でアカツキを選んだかっていうのを聞かせてもらいましょうか。

梶原　就活をするにあたって気を付けていたことなんですが、仕事って1日8時間平日週5日間とか非常に時間を使うので、せっかくならばより成長できる環境が良いなと考えていました。

そのための条件として、いろんな制度や仕組みを提供してくれているというよりは、自分が情熱を持って仕事に取り組めるかどうかっていうところが一番大事だなと思っていました。他の会社の話を聞いてもそこで自分が一生懸命頑張って仕事してるイメージがあんまりできなかったんですけど、アカツキの選考で小倉さん（当時の新卒採用担当）の話を聞いていたら、ここなら本気で頑張れそうだなみたいな気がして。じゃあ、ここにしよう、ぐらいの割と直感のような気持ちで入社を決めました。

能登　アカツキに新卒入社してくれる人って、迷わない人は全然迷わないって聞きますよね。梶原さんも他の会社と比較するとアカツキは全然違う、ここだって決めた感じだったんですか。

梶原　そうですね。もう他は選考を辞退してアカツキだけに絞りました。

「本気で仕事できそう」と思った明確な理由はほぼないんです。小倉さんの人柄や、ビジョン・ミッションから、ただ会社を大きくすることだけに頑張ってるんじゃなくて、その先のこと見据えていて、そのために会社がある、みたいなことを感じ、すごくいいなと思った記憶があります。

能登　入社したあとは技術研修に取り組んでいましたよね。卒業はいつ頃でしたっけ。（※注釈　アカツキの新卒エンジニア職向け技術研修は個人ごとの卒業制になっている。現場で必要となる技術力や学習する力が身についたと判断されると、現場のプロジェクトに配属される仕組み。）

梶原　5月から始めて8月末でしたね。

能登　8月末に研修終わったということは、結構優秀ですよね。

梶原　他の人よりは早かったと思います。

能登　最初の配属ではどんなゲームタイトルでのお仕事をされてたか、軽く紹介してもらえますか。

梶原　あるゲームタイトルで、サーバーサイドをRubyで書いていました。リリース直前のタイトルで、不具合修正をしたり、その後は運用中の機能追加を担当していました。あとは、インターン生の受入等もしていましたね。

能登　アカツキは社員よりも、フリーランスなどの業務委託の人が多いプロジェクトもあると思います。最初に配属されたプロジェクトもそうだったと思うのですが、社員だけで構成されたチームとの違いみたいなものはありますか。

梶原　いろんなバックグラウンドを持っている人がいることによって、いろんな学びができるという点ですね。例えばある方は、誰かがプルリクエストを出したらすぐにレビューしたりとか、僕が今まで全く考えてなかったような観点でのレビューをしてくださったりとか。

他の方の、ささいな行動を見て学べる機会、いっぱいあると思うんですね。体系化された知識とかだけではなく、振る舞い、所作一つを取っても「この人のこういうところいいな」と思ったことを真似しようとか。そういう意味では良い環境だったなって思ってます。

能登　なるほど。自分なりにいろんな観察をして、そこからも学ぶようにしてたってことですね。

梶原　そうですね。1年目は特に「現場で学ぶ」「経験する」にフォーカスをあてていました。

大学でいろいろ勉強はしてきたので知識はなくはないなと思っていたのですが、入社するまでにインターンやアルバイトをしていなかったので、経験が圧倒的に足りないと。なので、現場での経験から学び、成長につなげようという意識は非常に強かったと思います。

能登　会社選びの条件としても、成長できる環境をっていうのがあったけど、入社してからも一貫して、「成長」を意識して取り組んでいた。とにかく経験にフォーカスして成長につなげようと思っていたんですね。

『ロマサガRS』のバトルロジックをサーバーサイドで開発。高い技術と要件抽出を両立できるリーダーに

※ロマンシング サガ リ・ユニバース』は、アカツキとスクウェア・エニックスとの共同開発による、23 年ぶりとなる『ロマンシング サガ』完全新作の新規ゲームアプリです。

能登　その後、スクウェア・エニックスさんとアカツキで共同開発をしている『ロマサガRS』に異動しましたよね。ここでの経験や学びを教えていただけますか。

梶原　実は異動前に、他職種と連携の難しさを経験していました。そこについてはもともと意識をしていたので、機能を追加するときに、プランナーやQA (Qaulity Assuarance = 品質保証チーム) の人と連携を取るために、口頭でしっかり説明して、Slackでも文章書いて送ったんですけど、ふたを開けてみたら全然そのとおりになってなかった、みたいなことがありました。めっちゃ気を付けてコミュニケーション取ろうと思ってやっても、うまくいくわけではないんだなって気付きがありました。

能登　『ロマサガRS』ではどういうふうにしてそこを克服したんですか。

梶原　仕事をお願いするとき、「伝える」のを頑張って終わり、ではなくて、完成まで見届けることを意識しました。そもそもエンジニアと他職種とで持ってる情報の格差が非常に大きいですし、他職種は他職種でめちゃくちゃ忙しいので、お願いして、「はい、ボール渡しました、もう責任ありません」っていうのは、仕事の進め方として良くなかったなって思い、完成物まできっちり見るようにしました。

レビュー会とかを仰々しくやるのではなく、開発中のプロダクトを都度都度見て触りながら、気付いたところや違和感があったら、細かく発信して確認を取るようにするということも気を付けていました。

能登　なるほど。じゃあ、最後に成果物を確認するだけではなく、中間でもサポートしていくようにしていたということなんですね。

梶原　そうですね。

能登　分かりました。じゃあ、『ロマサガRS』に異動して、どういう仕事をするようになったのか聞かせてもらってもいいですか。まず、言語のことから。『ロマサガRS』の使用言語はElixirですよね。前のプロジェクトで扱っていたRubyとどう違うと思いましたか？

梶原　ElixirがRubyに似ているっていうことをよく言われるんですけど、実際、中身はそんなには似てないと思っていて。文法の一番パッと見の見た目の部分は似せて作ってあるんですが、それってただの表層でしかないので、本質では全然違うなと。

一方で、学生時代に勉強していた、Schemeの方が似ているな、と感じました。大学のカリキュラムがC言語を学ぶ前にまずSchemeを学ぶことになっていて。すごく面白かったので、講義が終わってからも個人でも勉強していました。SchemeとElixirは同じ関数型言語なので、関数型言語特有の考え方、データを受け渡し方であったりとか、あと細かいですけど、連結リストがcarとcdrでできていて、consでくっついてるみたいなところとか、頭の要素を取り出して再帰していくところなど、イディオム的なところが、「Schemeで勉強したことそのまんまな部分もあるな」と思いながらElixirを勉強していましたね。

能登　そういう意味では、割とScheme好きだったのもあって、Elixirのプロジェクトに入れてラッキーだった？

梶原　そうですね。『ハッカーと画家』でCommon Lispで仕事をしている人たちの話がありますけど、関数型で仕事するってどんな感じなのか、すごく気になっていたところだったので、ラッキーでした。

能登　なんで『ロマサガRS』はElixirを使ってるんですか？

梶原　今後必要となる可能性のある機能を開発できる技術、という点でElixirは非常にマッチしているだろうと、焦点が当たったのがきっかけですね。今の市場で新作を作る以上、例えばリアルタイム同時接続の遊びを追加したい、などとなっても、エンジニアリング的には対応できるような想定をしておくべきだろうと考えていました。

結果的に、Elixirを選定したおかげで上手くいったことが多いと思っています。比較的新しい言語なのでコードのフォーマッターや静的解析など、いろいろ便利なツールが整っていて、生産性が良いです。あと、ゲームサーバーの目的では十分なぐらいのパフォーマンスが、標準的に特にあんまり頑張らなくても出るっていうところも非常にマッチしています。ETSというオンメモリのデータストレージも便利で、これのおかげでマスタデータを細かく参照できるようになり、バトルロジックでパフォーマンスを気にせずに済みました。

能登　他のエンジニアに聞くと、同じバトルのロジックをRubyで実施してたら、倍の台数は必要だったんじゃないかって言われてるみたいなんで、そういう意味ではサーバー費用のコストも相当圧縮してるんですよね。

梶原　そうですね。処理速度のパフォーマンスも高いので、通常クライアント側で処理するバトルロジックを、サーバサイドで処理することができています。これにより、チート対策もすることができ、真剣にプレイしてくださる方々に安心してプレイしていただくことができることも、Elixirを選んだ理由の一つと聞いてます。

能登　梶原さんは『ロマサガRS』のチームにはどういう状況で入って、どんなところを担当していたのか聞かせてもらってもいいですか。

梶原　機能の量産をしていくβ2のフェーズですね。当時アウトゲームがざっくりしたところしかできていなかった状況で、まず「梶原だから鍛冶屋（の機能）をやれ」っていうすごいしょうもない理由で（笑）

能登　ダジャレかっていう（笑）

梶原　内容的には独立していたので非常にやりやすかったんですけど。その後色々アウトゲームを開発しているときに大問題が発生しました。先程もお話したとおり、『ロマサガRS』のとても大きい特徴として、バトルロジックをサーバーサイドで処理しています。その領域の人手が足りず、このままだとリリースまでこぎ着けるかも分からないという状況になって。そこで僕に白羽の矢が立って「梶原、やれ」と。それで、めちゃくちゃ難しいバトルロジックの開発をいきなりやることになりました。

なんとかキャッチアップするために、頑張って仕様書読んだり、既存のコードを読んで、Slackで「ここはこうなってるのか」みたいなことをひたすらぼやくみたいな専用チャンネルを作って。アウトプットもしながら理解を深めつつ開発を進め、必要に応じて既存のコードを修正して、ファクタリングもしながら、機能開発もして何とかぎりぎりリリースまでこぎ着けました。

それがひと段落してから、サーバーサイドのリーダーの役割を引き受けました。それまでもリーダー見習い、みたいな感じで動いてはいたのですが。

能登　説明ありがとうございます。『ロマサガRS』の場合、クライアントサイドは外部の協力会社の方がメインで開発されてるんで、社内のエンジニアはサーバーサイドのみでしたよね。つまり、実質的には内部開発全体のエンジニアリーダーということですね。リーダー業務っていうのはどういうことをし始めるようになったんですか。

梶原　かなり雑多なことばかりやってたんですが、まずはタスクのアサインやスケジュール管理、セクション間の連携からやり始めました。不具合があれば原因を推測して担当者に割り振ったりとか、そもそもサーバー起因じゃないですねと言って他に回したりとか。見積もりと進行状況を見てこの機能を入れる、入れないみたいな話をしたりとか。

能登　聞いてて面白いなと思ったのは、エンジニアのリーダーをやる場合、ほんとに技術的なレビューや、設計を中心にやる人もいると思うのですが、梶原さんの場合だと、スケジュール管理や、アサインを決めたり、結構プロジェクトマネジメント面もやっていたってことですよね。

梶原　そうですね。最初は慣れなかったのでプロジェクトマネジメントに追われてしまって。その後、数カ月したらメンバーも増えて、自分も慣れてきたので、コードレビューや技術的負債に対する課題と対策と優先順位をリストアップしてタスクを割り振ったりというのにも時間を使えるようになってきました。

能登　『ロマサガRS』で梶原さんとして技術的に一番わくわくしたのはこれだなっていうのがあったら、紹介してほしいなと思ったんですけど。

梶原　やっぱりバトルロジックのところですね。モバイルゲームのサーバーって、そもそもアウトゲームだけでも十分ロジックの量が多いし難しいんです。さらにそこに輪を掛けて難しいのがバトルロジックですね。

『ロマサガRS』は、システムが複雑で奥深いことが魅力なのですが、それゆえに仕様がかなり複雑になっています。運用型のタイトルなので、既存の機能を保ちながら新しいロジックをどんどん実装していかないといけないので、もうめちゃくちゃハードルが高かったなって思っています。

普通、新規仕様を実装するとき、既存実装との依存関係で問題が起きないように、設計をうまくやりましょうっていう話になるんですけど、『ロマサガRS』の場合、そもそも仕様同士のコンフリクトが発生するのが当たり前なぐらい、仕様が複雑なんですね。

なので、機能追加の際に想定される問題は事前に事細かく、全部洗い出していました。新規仕様と既存仕様のコーナーケースが重なったときに、プレイヤー目線で不自然な挙動にならないよう、ケースごとに議論をした上でテストを書いて、今も今後も正しく動作することを保証するということをやりました。

能登　『ロマサガRS』はそもそも相当難しいゲームだし、結構不確定性の高いロジックを組んじゃうんですよって聞いてたんですよ。そんなの大丈夫なのかなって正直思ってたんですけど、それを何とかして実現する役を梶原さんがやってたってことですね。

梶原　そうですね。

通常バトルロジックって、実装としては汎用的な機能を準備して、新しい技などを追加する場合にはそれらを掛け算して運用データを作っていくというフローになっているんです。ただ、無限の組み合わせをサポートする実装は現実的じゃないので、どういう運用データを入れる想定なのかは、開発前にプランナーに細かくヒアリングしていました。QAチームとも連携を取って、検証のポイントや予想される仕様のパターン、それ以外については必ず運用チームと連携を取ってください、という注意点を伝えていました。運用を開始してからも特に気をつけていましたね。

能登　面白いですね。Elixirでテッキーなことやってるんだなという印象でしたけど、要件ヒアリングと抽象化の妙みたいな部分が実は要だったってことですよね。

梶原　そうですね。普通サーバーサイドの開発ってゲーマーが思うようなゲームのロジックっていうよりは結構システマチックなところの実装がメインなんですけど、『ロマサガRS』の場合はバトルロジックという、ゲームそのものを扱うことになるので、ゲーマー目線でも楽しめる仕事だなと思います。

「ロマサガRS」のバトルの様子。多彩なキャラクターや技、アビリティを組み合わせて敵と戦う。

プロジェクト全体の成功のために苦手意識があった人とのコミュニケーションも地道に克服

能登　技術的な領域も、要件ヒアリングや調整も、エンジニアリング面のプロジェクトマネジメントも、チームづくりも関わってきて。それこそエンジニアって自分は技術的な成長だけをしたいから、それ以外はやりたくないですっていうふうになってもおかしくないのに、梶原さんは何でもやってるなっていうのがあって、なぜそんなに広くカバーできるのかとか、なぜそういう技術的な成長以外の領域を担当してもいいなと思ってるのか、Willとか気持ちを聞きたいなと思いました。

梶原　非常に正直なところ言うと、最初はやりたくなかったですね。僕自身、コミュニケーションっていうか、人と関わってっていうところはすごく苦手だと思っているので、あんま人としゃべる仕事したくないっていう気持ちになったりとか。

もちろん技術的なところにフォーカスしたいなという気持ちがあったんですけど、役割として誰かがやらなきゃいけない状況がプロジェクトにあるのに、自分のやりたいことだけやるっていうのも違うし、経験にもなるので、一遍やってみるかっていうような気持ちで始めました。

やっていく中で思ったところとして、今まで一メンバーとして仕事をしていたときは、いろんな決めなきゃいけないことを上の人が決めてくれてたんですよね。なので、すごく楽だったっていうか。こういう大変な仕事を誰かがやってくれてるからプロジェクトって、仕事って回ってるんだなっていうところを気付いて、それで、自分のやりたいことだけやるんじゃなくて、気が進まないところも含め、ちょっとずつ分担してやっていったほうがプロジェクト全体にとって幸せだろうなって思うようになりました。

能登　しゃべる仕事はしたくなかったようだけど、どうやって克服したんですか。

梶原　人と関わる仕事の中にも色々グラデーションがありますよね。もともと細かいところが気になるタイプなので、興味本位で Slack を巡回してトラブルが起きそうなところを事前に検知したり、オフィスでたまたま耳に入って気になった会話に参加して業務改善につなげたりというところは、自発的にうまくできていました。

一方でチーム作りやスケジュール管理はうまくできないところもあり、島崎さん（『ロマサガRS』のクリエイティブ・プロデューサー兼エンジニア）や湯前さん（Chief of Staff, Games）にアドバイスを頂いて視野を広げていき、繰り返していく中で段々できるようになっていきました。そのおかげで、例えば、機能開発の中で各領域に2人以上はその領域をリードできる人がいる状態になるように戦略的にタスクをアサインして、僕がボトルネックにならずに、スケールできるチームをつくることができました。

能登　そこは「意外とこんな秘訣があるんですよ」っていうよりかは、地道に克服してきたんですね。

梶原　そうですね。

アプリケーションからインフラへ。幅広い現場で獲得した知恵で自分らしく問題解決が楽しめる仲間と仕事をしたい

能登　これからエンジニアとして、どういう人になっていきたいかも聞かせてください。

梶原　今までアプリケーションにすごく寄っていて、インフラをあまり触る機会がなかったんで、インフラの仕事をやらなきゃいけないし、していきたいなと思ってます。

いい仕事をするに当たって、全体を広く理解している人間がいるか、いないかっていうところがかなり大きい分岐点になるなと思っています。『ロマサガRS』の場合だと、島崎さんがエンジニアリングも分かっていて、かつプロジェクトマネジメントやプロデュースもやっていて、うまくいってるところもあると思うんですけど、そういうふうに複数の領域またがる人がいっぱいいることで、よりゲームをうまく作れるなと思っています。今は機能開発とツール開発に寄ってるので、（複数の領域をまたぐために）次はインフラをやろうと思っています。

僕は基本的に何か一つを深めていくっていうよりは、いろんなことをちょっとずつ勉強するのがすごく好きなタイプなので、サーバーに限らず、クライアントもできるようになっていきたいなっていうことを思ったりとか。あと、プロジェクト全体の問題をプロジェクトリーダー1人に全部に押し付けるっていうのも、非常に負担が大きくてうまくいかないことが多いし、全体を見渡せる人っていうのはいっぱいいていいと思うので、技術的なところや、企画の仕様、あるいはちょっとだけ組織面のところとかも見つつ、幅広く携わってプロジェクトのクオリティーを1段押し上げるみたいな、そういう役割を担っていけたらなと思っています。

能登　なるほど、ありがとうございます。どういう人にアカツキのエンジニアになってもらいたいかを聞かせてください。

梶原　仕事をしていく中で、知識よりも、むしろ現場での思考力みたいなところが大事だなと思いました。というのも、ソフトウェア開発、特にゲーム開発って分からないこと、誰も答えを知らないこととか、答えがそもそもないことが無限にあるんですね。そういうときに、知識は多少役には立つんですけど、それよりも、むしろそういうカオスな状況を分析して、整理して筋道を立てて解決に導いていくっていうことのほうが圧倒的に多いと思うんです。

もちろん体系だった知識の勉強もするけど、それをそのまま生かせる機会っていうのが多くはないので、自分なりの解決策を見つけていくことを楽しめる人に来てほしいですね。

能登　現状の技術力だけを問うんじゃなくて、自分なりの解決策を見つけるとか、答えのないとこに答えを出すっていうところが多分、一つ鍵のような気がしますね。

梶原　はい。学生のみなさんは、今何かしら研究だったりとか、趣味で開発したりしてると思うんですけど、その中でどういう問題に当たって、それに対してどういう解決策を考えて進めていったか。現状の問題を正しく捉えているか、それに対する対策が合理的なものであるか、筋が良いかどうかっていうところは、非常に気を付けて見ています。

能登　確かに正論だ。面白いですね。

この記事はアカツキ新卒採用サイト2022に掲載されたものです。