『呪術廻戦 ファントムパレード』新機能 「クリア編成」を新卒サーバーサイドエンジニアが制作するまで

はじめに

サイバーエージェントに2024年新卒入社した島田です。サムザップに配属してから2024年10月末時点でおよそ半年が経ちました。
現在は『呪術廻戦ファントムパレード(以下、ファンパレ)』でサーバーサイドエンジニアをしております。

本記事では、私がサーバーサイドの開発を担当した新機能「クリア編成」を実装するにあたり、工夫した点、学びになった点などを紹介します。
新卒が半年間で培った経験をお伝えし、ゲームのサーバーサイドに少しでも興味を持っていただければ嬉しいです。

新機能「クリア編成」とは

まず簡単に、今回私が担当した「クリア編成」についてご紹介します。

「夢幻廻楼 クリア編成」の実際の画面1
「クリア編成」とはユーザーのクリアした編成が見える機能になります。「夢幻廻楼」と呼ばれる高難易度コンテンツの中で、ユーザーの参考情報として、他ユーザーのクリアした編成を階層別で見ることができます。この一覧は定期的に内容が更新され、いつでも新鮮な編成をお届けしています。
また、クリア編成の一機能として特定のクリア編成のお気に入りも可能になります。

開発当初の状況

サムザップのファンパレに配属されてから、開発用ツールの実装をこなした程度で、メインのアプリケーション部分の開発には携わったことがない状況でした。既存の実装内容などは把握できていない状態からだったため、リリース予定から大分早い段階で本機能の開発をスタートしました。

開発の振り返り

設計時

始めに、私が当初驚いたことでもあるのですが、ソーシャルゲームはとにかくユーザーデータが多く、その更新も多い傾向があります。そのため、基本はユーザーデータの負荷を考慮しながら設計することになります。

例えば「シャーディング」もその考慮の一つかと思います。アクセス負荷対策の方法で、同じ構成のデータベースを複数用意し、アクセスを分散させることで、データベース単体あたりの負荷を下げる方法です。アクセス量の多いユーザーデータを、複数のデータベースで管理することで、一人一人のユーザーのゲームプレイを円滑にすることができます。

シャーディングのイメージ図
ただし複数に分割されているため、扱い方には注意が必要になります。基本的に、ユーザーは自身のユーザーデータを取りにいくため、アクセスするデータベースが限られます。ただし、多くのユーザーが他のユーザーデータにアクセスしようとすると、複数のデータベースにアクセスする必要があり、負荷分散ができずにパフォーマンスに影響します。

そして今回の「クリア編成」は、他ユーザーの記録を見えるようにする必要がありました。
つまりは、上記の面を考慮しつつ、ある程度は既存機能の設計を無視して考えなくてはいけませんでした。

同時にAPIも、各ユーザーが自身のユーザーデータにアクセスする機能を中心に設計されているため、「クリア編成」のAPIを設計するにあたり、既存の設計はあまり参考になりませんでした。

これらの理由から、現状のファンパレの実装から大きく離れないように設計するのにはとても悩みました。

上記のような問題があり、かつここまでの大規模な実装は初めてだったので、かなり念入りに既存実装の把握や設計思想の理解を行いました。 他のチームメンバーにこまめに相談を行い、頻繁にフィードバックをもらうことで日々学びがあり、大変成長することができたと感じています。結果、チームの方々にかなりご協力いただきましたが、このチームで仕事をしていくことの安心感も同時に得られたと思います。

実装時

これは本機能に限った話ではないですが、設計通りに実装しても全てうまくいくわけもなく、機能実装においては総じて、実装時に検討漏れや仕様確認が発生します。本機能も例外ではなく何度か発生しました。
漏れていた分、修正する必要があるので時間もかかります。エンジニアは特にこういった検討要素を事前に発見し、詰められるかが非常に重要だと学びになりました。

万が一考慮が漏れたままリリースした場合、データベースにデータを蓄積している関係で、修正が柔軟にいかないケースが多かったり、通信処理を担っている分、パフォーマンスにも影響を及ぼす可能性があります。場合によっては、臨時メンテナンスを行うケースもあります。なので多くのユーザーに安定して遊んでいただくため、こういった問題が発生しないように、設計時点でいかに様々なことを考慮できるかが非常に重要だと思っています。

「夢幻廻楼 クリア編成」の実際の画面2

同時に、リリースするにあたり発生する技術的な制約や検討要素を、事前にどれだけ他セクションに共有できるかも、エンジニアの重要な仕事だと学びました。特にゲームは機能自体の仕様が複雑な傾向があるため、良い機能を良い状態で具体にするためには、どういった制約があるのかを事前に共有できている必要があるからです。なかなか設計段階で完璧にはいきませんが、それが上手くいくと実装も大変スムーズになります。

実装時の振り返りにもかかわらず設計の話ばかりとなってしまいましたが、大規模なものほど「作業は設計がほとんど」と言っても良いくらい、設計は念入りに行うべきだと感じます。こういった学びや反省は実装時に感じるたため、実装時の振り返りとして書かせていただきました。

まとめ

ここまで書いてきたように、本機能の制作は私にとって非常に活かせる経験や学びになりました。

  • 大規模ゲームの機能設計&実装の把握と経験

  • 設計時でどれだけ詰めれるかで実装がスムーズになること

  • 技術的な制約を共有することの重要さ

大規模ソーシャルゲームのサーバーサイド開発は非常に特徴的ですが、サーバーサイドエンジニアとしてどんなサービスでも活かせる考え方や経験を得られると思っています。今回の話は、アプリケーション開発の一部でしかなく、ゲームの機能や状況に応じて、様々な知識、経験が必要になります。私自身もこれからさらに幅広い経験を身に付けたいです。

ここまで読んでいただきありがとうございました。本記事を読んで少しでもファンパレや、ゲームのサーバーサイド開発に興味を持っていただけたら幸いです。


©芥見下々/集英社・呪術廻戦製作委員会 ©Sumzap, Inc./TOHO CO., LTD.

島田 蒼也

株式会社サムザップ サーバーサイドエンジニア
2024年新卒でサイバーエージェント入社、サムザップ配属
『呪術廻戦 ファントムパレード』にて開発に従事