ユーザー・スタッフ一体の“お祭り”として盛り上げていった「ゲームの終わらせ方」や不測の事態に備えるログイン制限・タスクマネジメントを解説

8月21日から23日まで開催されたゲーム開発者向けカンファレンス「CEDEC2024」の3日目にて、株式会社ポケラボは2024年1月にサービスを終了したRPG『シノアリス』に関する講演「ユーザーの記憶に深く残るソーシャルゲームの終わらせ方　～ユーザー自身がお墓に入る？！唯一無二のゲーム体験とそれを支える技術のはなし～」を実施した。 【この記事に関連するほかの画像を見る】 本記事では、ポケラボ 結プロダクションのエンジニアである高田美里氏と悦田潤哉氏によって語られた「メインストーリー完結と同時でのサービス終了を発表し、終了までの期間を“お祭り”として盛り上げる」異例の取り組みや、ユーザーたちの足跡を“お墓”として記録するアーカイブアプリ『シノアリスだったナニカ』の運営・管理にまつわる知識をレポートとしてまとめていく。 文／ヨシムネ ■「シノアリスの死に様」をお祭りに昇華していく“フィナーレ計画” 本講義で取り上げられている『シノアリス』は、2017年6月からスクウェア・エニックスと共同で開発・運営されたiOS、AndroidおよびPC（DMM GAMES）向けRPGだ。 本作では『ドラッグオンドラグーン』シリーズや『NieR』シリーズで知られるヨコオタロウ氏が原作とクリエイティブディレクターを手がけており、童話の登場人物たちが「作者を復活させる」ために殺し合うダークな物語や破天荒な運営施策、最大15対15で戦うリアルタイム形式のギルドバトル要素をもってファンに愛された。 『シノアリス』のサービス終了については2023年10月に発表されており、メインストーリーの完結にともなうサービス終了と『シノアリスだったナニカ』への移行を含めた「エンディングの施策」として展開されてきた。 高田氏によると、エンディングの施策についてはサービス立ち上げの時点からすでに「ちゃんとしたエンディングを作る」構想があがっており、新規ユーザーや引退済みのユーザーをも巻き込んでお祭りのようにエンディングを楽しませる“フィナーレ計画”として練り上げられていたという。 フィナーレ計画のはじまりを飾ったのは公式Xアカウント（@sinoalice_jp）からの告知であった。 “シノアリスの死に様”を拡散することでリポスト数×1個のゲーム内通貨「魔晶石」をプレゼントするものをはじめとした各種キャンペーンや、「サービス終了座談会」の実施、ファンムービーとして制作された映像化作品『シノアリス 一番最後のモノガタリ』の上映など、ゲーム内外を問わない展開によって異様な盛り上がりをみせた。 加えて、ゲーム内では2023年12月に、全7章で構成されたメインストーリー「ヨクボウ編」の1章から6章までを配信。ギルドバトルのチャットを含む各種のゲーム内機能やキャラクターがストーリー進行にともなって「消失していく」演出や、厳しい条件を満たしたギルドメンバー全員で挑む最終レイド戦などの要素を通して「ユーザー自身の手でゲームを終わらせ、ギルドメンバーともに共有する」体験が展開された。 最終レイド戦のクリア後に登録したユーザー情報は、サービス終了後に変化した『シノアリスだったナニカ』で自身のデータとして確認できた。また、アプリ内では「シノアリスを戦った人達」としてともにエンディングまで駆け抜けたユーザーたちの情報やエンドロール、サービス中に展開されたすべてのメインストーリーも公開されており、当時エンディングを迎えられなかった人も一部を除くデータを確認可能だ。 一方、新規・復帰のプレイヤーは本キャンペーンの取り組みに関心を持ったとしても全9編からなるメインストーリーの完遂や、メインストーリー後半における難度の高いバトルを乗り越えなければならなかった。 高田氏によると新規プレイヤーが真面目にクリアしていく場合、最低でも16時間以上のプレイを要する想定になっていたという。そこで運営チームは、独自のユーザー救済施策として、“ある裏技”で「ヨクボウ編」に至るまでのストーリーのスキップ機能を用意した。 もともと「ヨクボウ編」のリリースに合わせたバトルサポート機能の実装は決まっていたものの、いくつかあった案のなかから選ばれた“裏技”の手法は「端末シェイク」機能であった。 担当のエンジニアによってアプリの品質・テスト工数に問題がなく短期間で実装できることを確認したため、ゲーム内では端末を一定の回数振ることで「ヨクボウ編1章」の開始地点までスキップできる機能が本実装されていたようだ。 実装に当たってはUnity側で端末シェイクを検知できる設定を実際に振ってみて調整されたほか、シェイク機能を搭載していない端末向けに「特定の画面で100分放置」してもスキップされる要素や、振り続けることでガチャの曲が1曲分流れる要素も用意されたという。 また、あくまで“裏技”として実装されていたため、運営チームはユーザーの気づきと口コミ効果を狙ってしばらく待機し、サービス終了まで2週間となった2024年の元日にあわせて、暗号文を解くことで裏技の存在が判明するSNS投稿も実施した。 高田氏いわく、実際にSNS上ではスキップ機能の存在が認知されてからたくさん活用され、サービス提供中のあいだにエンディングまで到達するユーザー　の増加につながったという。 ■「終わる瞬間」をギルドメンバー全員で共有するための通信技術 続いて、悦田氏からは最大15人で挑む最終レイド戦のデータ同期に関する知見が紹介された。悦田氏によると、実装にあたっては「ギルドメンバー全員が揃った状態で参加できるようになる」要素の追加と、「バトル前後に流れるシナリオの進行も同期させる」との要望が伝えられていた。 実装にあたっての課題は「どのようにして全員を同期させて開始させるか」と、「同時進行中にアプリ落ちしたユーザーが発生した場合にどのように復帰を行うか」であった。 そこで実装時には、最終レイド戦に参加するギルドメンバーの待機所を設置。『シノアリスだったナニカ』に情報を登録するまでの各段階を“フェーズ”として分け、アプリ落ちしたユーザーが発生した場合は進行中であったフェーズからやり直す形にしていたという。 開発時にはリアルタイムでのデータ同期や負荷への対策が容易なモバイルアプリ開発プラットフォーム「Firestore」を活用し、接続ユーザー数の増加への備えを想定していた。 また、データの読み込み時には「ギルド全体での進行フェーズ」と「ユーザー個々の進行フェーズ」を別々に記録し、どの時点から復帰するのかを細かく定義していたようだ。 一方、接続ユーザー数の増加については増加幅を予測できない点や、予算も考慮しながらログイン制限をかけなければならなかった。そこで『シノアリス』の最終レイド戦においては秒間のリクエスト数を参照し、しきい値を超えた際に新たなユーザーのログインのみを一時的にブロックする「リクエストレート制限」がとられた。 制限の対象については進行中のバトルを妨害しないようにログインのリクエストのみを対象としたほか、ギルドメンバーの誰かがプレイ中の場合に同じギルドのユーザーをログインできるようにする例外などの措置もとられているという。 事例の詳細について説明したのち、悦田氏はログイン制限の導入について「実現方法は様々あり、それぞれにできること・できないことがある」として、リアルタイム性や瞬間的なアクセス増加の懸念、条件設定を考慮に入れて選択するよう提案した。 ■「仕様が決まらず工数を出せない」極限状況でのタスクマネジメント そして話題は変わり、タスクマネジメントに関する事例の紹介は再び話者を高田氏に戻して展開された。エンディング施策の開発当時における運営チーム内では、季節・周年等の通常イベントと並行して施策の開発が進んだ結果、人員の異動や新たな人員の状況把握が難しい状況などの要因から、当初の予定よりもエンジニアの人数が足りない状況に陥っていたという。 そこで、大規模開発におけるタスク管理の経験が初めてに近かった高田氏は、ほかの人から教えてもらった「タスクマネジメントの基本」に従いつつ、全体像の把握と工数の算出、対応の優先順、および工数の圧縮の検討を進めていった。 しかし、タスクマネジメントを進めていった結果、実装の総量に対してプランナーやデザイナーなどのスタッフ人数も不足しており、仕様が決まらず工数を出せない状況に突入していたことが判明。高田氏は不測の事態に対応するべく、エンジニアやプランナーとの話し合いを積極的に行い、地道に未確定の仕様を潰していく手段を取った。 仕様の策定においては、リリース日が確定しているものについて「一番のコアを実装チーム単位で明確化する」ことや、発生した追加仕様に対して「それは本当に叶えたいものなのか」とのイメージをすり合わせていったという。 高田氏によると、エンディング施策は結果的にすべて遅延なしで実装された。一番の要因については「2週間単位でのマイルストーン設定」と、チーム全体で実機環境を試す「プレイ会」の存在を挙げている。 実際の過程ではマイルストーン通りにいかなかったものもあったようだが、「プレイ会でチーム全体に見せる」ことが適度なプレッシャーとなったことで、事前の情報共有やフォローアップのコミュニケーションが綿密化。実際に動いている物を確認することで、スタッフそれぞれのモチベーションを高めることにもつながったと分析している。 サービス運営型のゲームではかなり珍しい事例となった『シノアリス』のエンディング施策だが、高田氏は「工数的にも人員的にも厳しかったがやってよかった。スタッフ全員で“サービス終了を全力で楽しむ”ことを全面に押し出していけたこともよかった」とコメントした。 上記のほか、確保できる人員数を超えるタスクが発生した場合はタスクマネジメントの基本にのっとり、マイルストーンの設定やアウトプット、メンバー間での実機プレイを通してスケジュール通りの実装と少ないバグ件数につながったと講演を結んでいる。