イベント続きでもミスらないライブサービスゲーム公式サイト運用システム開発

GREE Tech Conference 2026で発表された資料です。
https://techcon.gree.jp/2026/session/TrackB-2

Transcript

1. イベント続きでもミスらない ライブサービスゲーム 公式サイト運用システム開発 株式会社WFS プリンシパルエンジニア 藤田貴大
2. 藤田貴大 株式会社WFS プリンシパルエンジニア 組み込みエンジニアとしてネットワーク機器の開発に 携わったのち、2012年にグリー株式会社（現：グ リーホールディングス株式会社）入社。 インフラ、Webゲーム開発を経て、2016年から Wright Flyer Studios（現：株式会社WFS）にてQA エンジニアとして開発基盤の整備等を担当。 2017年からネイティブゲームのサーバーエンジニア として、ゲーム開発のほか新技術導入などを進めてい る。 2
3. アジェンダ • はじめに • ことのはじまり • 改善に向けた整理 • 新しいツール作成 • 導入後 • まとめ 3
4. はじめに 4
5. 公式サイト更新システムの紹介 弊社で運用しているゲームの公式サイトを更新するシステム SlackによるChatOpsを用いたワークフロー について紹介させていただきます 5
6. ことのはじまり 6
7. 1 7
8. 開発メンバー @everyone 公式サイトに、明日発表予定の 新イベント情報が載ってるんですが 8
9. 開発メンバー @everyone 公式サイトに、明日発表予定の 新イベント情報が載ってるんですが え？ 9
10. 本来、翌日の公式生放送と同時に 公開されるはずの新イベントが 公式サイトに載ってしまっていることが 判明 まだ出してはいけない情報 ライブサービスゲームにおいて 情報公開のタイミングは極めて重要 特に今回は生放送での発表も 控えていたため、大きな問題に 生成AIで作成したイメージ画像です 10
11. 予定されていた公式サイト更新スケジュール 当日、もともとはこのようなスケジュールになっており 公開準備がすすめられていました 10/1 イベント 情報公開1 10/3 10/2 イベント 情報公開2 11
12. 差し込みの修正があった 急な情報公開2の修正依頼があったため、その確認作業などが実施されました 9/30 10/1 イベント 情報公開2 の修正 イベント 情報公開1 10/3 10/2 イベント 情報公開2 12
13. もともとの公式サイトの構成 公式サイト リポジトリ Object Storage (開発サイト用) CDN 開発メンバー Object Storage (本番サイト用) CDN お客様 デプロイ ジョブ 13
14. その時の公式サイト更新の流れ 1 2 3 4 5 6 制作会社から ZIP形式で納品 指定フォルダに 納品物を 上書き保存 手順書に従い データを アップロード Jenkinsで 開発サイトを 更新 開発サイトで 更新部分を チェック Jenkinsで 本番サイトを 更新 gitのclone フォルダ (mainブランチ) PR作成/セルフ マージで mainへ反映 リポジトリの mainブランチ HEADをデプロイ リポジトリの mainブランチ HEADをデプロイ 14
15. その時の公式サイト更新の流れ 1 2 3 4 5 6 制作会社から ZIP形式で納品 指定フォルダに 納品物を 上書き保存 手順書に従い データを アップロード Jenkinsで 開発サイトを 更新 開発サイトで 更新部分を チェック Jenkinsで 本番サイトを 更新 gitのclone フォルダ (mainブランチ) PR作成/セルフ マージで mainへ反映 リポジトリの mainブランチ HEADをデプロイ リポジトリの mainブランチ HEADをデプロイ 15
16. わかりますね？ 16
17. 差し込みの修正があった 急な情報公開2の修正依頼があったため、その確認作業などが実施されました 9/30 10/1 イベント 情報公開2 の修正 イベント 情報公開1 10/3 10/2 イベント 情報公開2 17
18. 差し込みの修正があった 10/3に出るはずの 急な情報公開2の修正依頼があったため、その確認作業などが実施されました 情報が出てしまった 9/30 10/1 イベント 情報公開2 の修正 イベント 情報公開1 10/3 10/2 イベント 情報公開2 18
19. もともと想定されていた更新作業 10/1 10/3 情報公開1 情報公開2 git更新 (情報公開1) git更新 (情報公開2) 開発サイト更新 開発サイト更新 本番サイト更新 本番サイト更新 19
20. 実際の更新作業 9/30 10/1 10/3 情報公開2 差し込み確認 情報公開1 情報公開2 git更新 (情報公開2) git更新 (情報公開1) git更新 (情報公開2) 開発サイト更新 開発サイト更新 開発サイト更新 本番サイト更新 本番サイト更新 mainブランチのHEAD (情報公開2+1)を そのまま本番サイトに公開 20
21. 問題の背景 高頻度の更新 弊社のライブサービスゲームではイベント時に お客様に楽しんでいただくため 情報公開を分割して連続更新することがあります タイトな時間制約 情報公開を公式生放送にあわせるため 夜や休日に更新作業が発生する場合もあります 連続更新が想定されていない更新システム 更新が直列的にしか実施できないため 運用チームが公開直前に更新作業を実施しています 21
22. 技術的な整理 JenkinsがmainブランチのHEADしかデプロイできなかった 公開直前までgitの更新ができない構造的な制約が存在 PullRequestが機能していなかった 更新作業が公開直前にしか実施できないため レビューの余裕がつくれなかった Gitのアップロードツール化 サイト更新システムのアップローダーとして存在していた 22
23. 改善に向けた整理 23
24. 公式サイト運用チームへのヒアリング 担当者について 公式サイトの更新は公式サイト運用チームのメンバーが実施 エンジニア職ではない 更新タイミングについて 短期間に連続で更新作業が発生する 夜や休日のこともある タイミングを生放送終わりに合わせたりしたい 24
25. 目指すべきところはわかっている • QA体制を整える • PullRequestのレビューを機能させる • 上記が、事前に、並行して実施できる 25
26. CMSに移行は難しい 公式サイト運用チームも開発チームも多くのリソースは割けない 特に、運用のために定常的にリソースを確保するのは難しい 現状の Object Storage + CDN での公式サイト運用は 運用リソースという点では望ましい QAやレビューを考えた時、Git/GitHubを使うことは望ましい 26
27. ヘッドレスCMSも今回求めるものは見当たらず Object Storage + CDN の構成は実現できるが QAやレビューを含めたワークフローを実現させるものではない 27
28. 人員の問題がある 公式サイト運営チームはエンジニア職ではない 開発チームからも十分にサポートできない中で 専門外のソフトウェアやサービスの習熟は難しい でも、Gitを使うことは手放したくない 28
29. 新しいツールを作ろう 29
30. 改善の目標 • エンジニア以外のメンバーが • サポートの手薄な夜間・休日でも • 「十分にレビューされたコンテンツ」を • 「複数回連続して」安全にデプロイできる状態を作る 30
31. 改善の目標 • エンジニア以外のメンバーが • サポートの手薄な夜間・休日でも • 「十分にレビューされたコンテンツ」を • 「複数回連続して」安全にデプロイできる状態を作る Githubを中心としたワークフローを構築する エンジニアがずっと慣れ親しんできた 道具を横展開する 31
32. Gitワークフローはシンプルに PullRequest 開発ブランチ メインブランチ 追加・修正 レビュー/QA マージ 32
33. 改善の目標 SlackによるChatOpsでワークフローを進行 • エンジニア以外のメンバーが • サポートの手薄な夜間・休日でも • 「十分にレビューされたコンテンツ」を • 「複数回連続して」安全にデプロイできる状態を作る 33
34. Githubの作業をSlackから実行 運用メンバー 運用メンバー @運用Bot 開発ブランチ作成 イベント第一弾_20260101 @運用Bot QAサイトにデプロイ イベント第一弾_20260101 運用メンバー 運用メンバー @運用Bot PR作成 イベント第一弾_20260101 @運用Bot マージ イベント第一弾_20260101 ブランチ名については 後ほど改めて説明 34
35. Slack上で作業することで • 全員が使い慣れているSlackを使うことができる • 進行状況が自動的に可視化される • サポートが必要なトラブルもSlack上で起こる 35
36. Slackで作業を進められる PR作成 QAサイト更新 コンテンツ更新 開発ブランチ作成 マージ 36
37. Slackで作業を進められる PR作成 QAサイト更新 コンテンツ更新 マージ 開発ブランチ作成 結局難しいのでは？ 37
38. 管理スプレッドシート導入 入力欄 コマンド 施策名1 デプロイ日時 ブランチ作成 コマンド PR作成 コマンド 施策名2 デプロイ日時 ブランチ作成 コマンド PR作成 コマンド デプロイ日時については 後ほど改めて説明 • 手順書にしたがって、すべてのコマンドをコピー＆ペーストで実行できる 38
39. ここまで • GithubのPRレビューのワークフローを SlackのChatOpsで進行できる • コピー＆ペーストで実行できる 39
40. 改善の目標 • エンジニア以外のメンバーが • サポートの手薄な夜間・休日でも • 「十分にレビューされたコンテンツ」を • 「複数回連続して」安全にデプロイできる状態を作る ここまでは作った 40
41. 改善の目標 • エンジニア以外のメンバーが • サポートの手薄な夜間・休日でも • 「十分にレビューされたコンテンツ」を • 「複数回連続して」安全にデプロイできる状態を作る ここに工夫が必要でした 41
42. Githubを使ったワークフローが進められるようになった • 複数のブランチを並行進行もできるようになった 施策3 施策2 施策1 42
43. 今回の事故は防げない • マージ順が保証できない 施策3 施策2 施策1 ここで事故発生 43
44. Githubの作業をSlackから実行（再掲） 運用メンバー 運用メンバー @運用Bot 開発ブランチ作成 イベント第一弾_20260101 @運用Bot QAサイトにデプロイ イベント第一弾_20260101 運用メンバー 運用メンバー @運用Bot PR作成 イベント第一弾_20260101 @運用Bot マージ イベント第一弾_20260101 ブランチ名については 後ほど改めて説明 44
45. 管理スプレッドシート導入（再掲） 入力欄 コマンド 施策名1 デプロイ日時 ブランチ作成 コマンド PR作成 コマンド 施策名2 デプロイ日時 ブランチ作成 コマンド PR作成 コマンド デプロイ日時については 後ほど改めて説明 • 手順書にしたがって、すべてのコマンドをコピー＆ペーストで実行できる 45
46. ブランチ名ルールの導入 ブランチ名をルール化しました イベント第一弾_2026122412 施策名 施策が公開される 年月日時 2026年12月24日12時に公開される施策 46
47. ブランチ名のルールで実現したいこと • マージされる順番を保証 • 自分より日付が前のブランチが未マージだとテストが失敗する 施策3_2026010300 施策2_2026010200 ❌ _02が未マージ ❌ _01が未マージ 施策1_2026010100 ✅ 47
48. 順番にマージできる • マージされる順番を保証 • 自分より日付が前のブランチが未マージだとテストが失敗する 施策3_2026010300 施策2_2026010200 ❌ ✅ _02が未マージ _01がマージ済み 施策1_2026010100 48
49. 順番にマージできる • マージされる順番を保証 • 自分より日付が前のブランチが未マージだとテストが失敗する 施策3_2026010300 ✅ _02がマージ済み 施策2_2026010200 施策1_2026010100 49
50. 順番にマージできる • マージされる順番を保証 • 自分より日付が前のブランチが未マージだとテストが失敗する 施策3_2026010300 施策2_2026010200 施策1_2026010100 50
51. ついでにマージコミットにタグ 施策1_2026010100 施策2_2026010200 施策3_2026010300 51
52. HEADではなく、指定のコミットをデプロイ 運用メンバー 運用メンバー @運用Bot ステージングデプロイ イベント第一弾_20260101 @運用Bot 本番デプロイ イベント第一弾_20260101
53. 改善の目標 • エンジニア以外のメンバーが • サポートの手薄な夜間・休日でも • 「十分にレビューされたコンテンツ」を • 「複数回連続して」安全にデプロイできる状態を作る 53
54. Slackでデプロイが簡単にできるようになったが 運用メンバー @運用Bot 本番デプロイ イベント第一弾_20260101
55. 単独でフライングする可能性が残る 運用メンバー 2025/12/31 @運用Bot 本番デプロイ イベント第一弾_20260101 事前にきちんと準備ができたとして フライングしてしまうのは防げない
56. ReleaseApprovals.txt 公式サイトのリポジトリに置かれている1行のテキストファイル 内容は、日時分 2026010112 このファイルが意味するのは、”このコミットはこの時刻以降いつでもデプロ イしてよい”ということ デプロイシステムは、このファイルの時刻より前にデプロイが実施された場合 エラーになって停止します 56
57. PRのレビューで、デプロイタイミングの合意が取れる PRのレビューで、コンテンツそのものと、コンテンツの情報公開タイミングの 両方を同時にapproveできる 例えば、生放送終了後の公開を意図したコンテンツの場合 生放送開始時刻など これ以降の公開であれば許される時刻 にしておくことで デプロイタイミングの自由度を確保しつつ、事故のリスクを低減できる 57
58. 改善の目標 • エンジニア以外のメンバーが • サポートの手薄な夜間・休日でも • 「十分にレビューされたコンテンツ」を • 「複数回連続して」安全にデプロイできる状態を作る 58
59. 改善の目標 • エンジニア以外のメンバーが • サポートの手薄な夜間・休日でも • 「十分にレビューされたコンテンツ」を • 「複数回連続して」安全にデプロイできる状態を作る イベント続きでもミスらない ライブサービスゲーム 公式サイト運用システムを導入 59
60. 導入後 60
61. 導入後 公開タイミングのミスは発生していません 導入後しばらくは、開発メンバーが本番サイトデプロイに立ち会っていましたが 現在は、運用チームだけで本番デプロイが実施されています 61
62. まとめ 62
63. 公式サイトで公開タイミングの問題が発生 • • • イベントが大切なライブサービスゲームでは 公式サイトが短期間に複数回更新されることがしばしばある ワークフローがそれに対応できていなかった 適切なツールも見つからなかった 公式サイト更新システムを作った • • 公式サイトを短期間に複数回、安全に更新できるようになった 導入後、最初に発生したような問題は発生しなくなった 63
64. ご清聴ありがとうございました 64