放置系スマホRPG「偽りのアリス」、ユーザー最重視の障害対応 [事故対応アワード受賞レポート]

[2020/03/10 20:20]周藤瞳美 ブックマーク ブックマーク

「放置系」と呼ばれるジャンルのスマートフォンゲームとして人気を博している「偽りのアリス」に障害が発生したのは、年の瀬も押し迫った2019年12月18日。ゲーム画面へのログインが不可能になり、公式Webサイトもダウンしてしまった。

ユーザーから見て障害発生時に詳細が不明なケースはよくあるが、同ゲームの運営チームは、障害発生直後からTwitter公式アカウントで状況を随時報告。復旧後の続報では図版を使ってわかりやすく障害箇所・復旧状況を説明したことで、「ここまで詳しい障害説明は初めて」「素人でもわかった気になれる」などとユーザーから大きな反響を呼んだ。そして今回、障害情報公開の新たなお手本となったとして「第5回 情報セキュリティ事故対応アワード」を受賞した。

なぜ、ここまで迅速かつ丁寧な対応が実現できたのか。同作品を手掛けるビジュアルアーツ teamAeca 武内郡氏と山田耕輝氏、そして同アワードの審査員であるpiyokango氏と辻伸弘氏による座談会から紐解いていきたい。

DAU3万人、運営チームは超少人数

辻:まずは「偽りのアリス」の概要について教えていただけますか。

辻伸弘氏

武内:ゲームを起動していないときもキャラクターたちのレベルが自動で上がっていく、いわゆる「放置系」と呼ばれるジャンルのソーシャルゲームアプリです。2019年10月にリリースしました。タイトルのとおり、童話をベースとした世界観のもと、おとぎ話の「失敗作」であるキャラクターたちが「本物」になるために戦い、物語が展開していきます。

山田:合計ダウンロード数は30万程度、DAUは約3万人です。ユーザーは1日に2-3回程度起動し、5-10分程度プレイをするようなプレイスタイルを想定しています。

武内:役割分担としては、僕がプロデュースとディレクションを担当しています。その他にも広告運用から発注業務、Twitter更新、伝票処理、テキスト作成など、何でもやっているという感じです。

山田耕輝氏

山田:私はバックエンドエンジニアとしてteamAecaに参加しています。偽りのアリスは、チームに5人しかいない状態でリリースし、10月に私がチームに入り、12月の障害が起きたときには6-7人という少人数のチームでした。現在はデバッガーが増えて9名体制で運営しています。

piyokango:アプリの規模感からすると、メンバーの数は少ないですか?

山田:他の会社では、そもそもゲーム全体のチームとイベントのチームに分かれていて、イベントごとに10人くらいのチームを構成して回しているという話を聞きます。それを考えると、私たちは全体の運営もイベントもすべて同じチームで行っていますので、人数はかなり少ないといえると思います。

武内郡氏は大阪オフィスに在勤中のため、インタビューはWeb会議での参加となった

検知後5分で第1報、メンテナンスモードへの以降……障害対応の裏側

武内:障害が発生したのは2019年12月18日16時44分でした。その約10分後に、今まで見たことのない画面のスクリーンショットとともに「つながらない」と投稿するユーザーのTweetを発見したことで、障害発生を検知しました。16時59分には第1報として障害が発生していることと原因究明中である旨をTwitterに投稿しました。

運営側も「見たことがない」と口を揃える表示がされ、社内は騒然とした

山田:公式Webサイトを確認したところそちらも落ちていましたね。障害発生から15分後にはクラウドベンダーの営業の方経由で、クラウドベンダー内部のネットワークに障害が発生したという連絡を受けました。営業の方曰く「ネットワークのスイッチが再起動したかもしれない。マウントされているハードディスクがRead Onlyになっている可能性があるので、すべてのマシンを再起動してほしい」ということだったので、これはもしかするとタイミングによっては全サーバのデータベースが壊れている可能性があるぞ、と思い、すぐさまメンテナンスモードに切り替えました。

17時11分には第2報として緊急メンテナンスの実施を行う旨を報告しました。ベンダー側のネットワークが復旧すればこちらも自動的に復旧するようになっているのですが、データが壊れている可能性もあるなかですぐに復旧してしまうのは問題ですよね。そこからマスターデータの確認と、レプリケーションの再構築を開始し、20時に完了しました。

武内:その後、社内のチームメンバー全員で1時間半ほど不具合がないかどうか確認作業を行い、21時40分に復旧しました。自分たちで実際に課金してみるというチェックなども行いましたね。

障害をプラスに変えようと、非エンジニアでもわかるような図版を作成

辻:障害について解説した図版がわかりやすいと評価されていますが、どういう経緯で作成することになったんですか。

武内:僕はエンジニアではないので、何が起きているのか山田をはじめ社内のエンジニアから説明を受けましたが、さっぱりわかりませんでした。話を聞いていると、これをユーザーにテキストだけで説明するには限界があると感じ、ユーザーにも理解できるような図版を作成しようと考えました。

図:武内氏が作成しようと試みるも、挫折した図版

山田:ユーザー向けの図版は当初武内が作成していたのですが、あまりにもわかりづらい図が出来上がりそうだったので(笑)、私のほうで書き直しました。当時は年末ということでイベントなどもあり、多くのユーザーの方々にご利用いただいているタイミングでしたので、障害は不信感を与えてしまったり、アプリから離脱されてしまったりすることに繋がりかねません。なんとかこの状況をプラスに変える方法はないか考え、せっかくならバズらせようということでサーバ構成図の公開に至りました。Twitterを意識してかなり抽象化し、1ツイートで完結できるよう4枚にまとめています。

piyokango:大変わかりやすくまとめられていますよね。

山田:上層部への説明用の資料を流用しているのではないかという指摘もTwitter上でありましたがそうではなく、ユーザーの方々を念頭においてPhotoshopで作成しました。ある程度知識のある人たちにもわかるし、知識のない人でも理解した気になれるというレベル感を目指していたので、「わからんけどわかった」といったユーザーからのコメントを見たときは嬉しかったですね。「レプリケーション」という言葉は入れていませんが、見る人が見たら、レプリケーションが切断されて、スレーブの再構築をしたんだなとわかるようになっていると思います。

代打・山田氏による、ユーザー目線を意識した力作がこちらの4枚

piyokango:図を使った説明は多くの組織で参考にしてほしい事例です。私もセキュリティインシデントが起きたとき図に整理することがありますが、イチから作成する作業は難しいと感じています。それを障害対応の最中に行い、迅速に公開する対応力は、本当に素晴らしいと思います。

超少人数チームであることのメリットを最大限に生かした対応

辻:障害発生時の体制やマニュアルづくりは普段から行っていたんですか?

山田:マニュアルは用意していません。かなりの少人数で回しているので、マニュアルを作るメリットがあまりないためです。

武内:何かしらの障害が発生したら、僕の判断で指示を出し、メンテナンスモードへ移行するという体制は徹底しています。それと並行して必ずTwitterでユーザーに案内を出すようにもしています。

辻:人数が少ないからこそ、素早い意思決定ができるということなのかもしれないですね。

山田:偽りのアリスチームは、社内では割と独立して動いていて、チーム内でコンセンサスが取れれば、すぐに動けます。基本的にお金関係のこと以外は上層部にお伺いを立てなくても良い風土があるんですよね。

piyokango:少人数ゆえのメリット・特徴が十分に生きたケースなのではないでしょうか。ビジュアルアーツさんと同じスピード感で対応できますか? と聞かれて、手を挙げられる組織は多くはないのではないでしょうか。

辻:今回はTwitterで障害報告をされましたが、ユーザー全員がTwitterのアカウントを持っているわけではないですよね。障害の告知やイベントの告知はTwitter以外ではどのように行っているんですか?

山田:アプリの起動時に出てくるお知らせ画面で通知しています。Twitterで簡易的な告知文を出して、ゲーム内で詳しく報告するという感じですね。ただ今回は、ログイン画面も公式Webサイトも落ちていたので、Twitterでの告知という形になりました。

武内:ユーザーサポート用のメールアドレスも用意していますので、そこに問い合わせていただくという方法もあります。12月の障害発生時にも外注先のサポート会社に連絡を入れて、対応方針を伝えていました。

作り手であるからこそ、ユーザーであれ

piyokango:説明責任を十分に果たされずに、一応の報告をしてクローズ、と見えてしまう組織が少なからずある中、ユーザー本位で非の打ちどころがない、教科書のような対応という印象を受けました。

辻:ゲームアプリの場合は、人によって違う対応をされてしまうという話もありますよね。

piyokango:窓口がワンボイスになっていないといわれる例ですが、これは大きな組織でも見かけることがあります。今回の場合は、何かあればTwitterで告知される流れがユーザーとサービス提供者双方で意識されており、コミュニケーションの取りやすい状態が醸成されていたことが良かったのだと思います。

辻:大きな組織では、「今何が起きています」という情報すら出てこない場合もありますしね。

武内:作り手であるからこそ、ユーザーであれという意識を持っているのも大きいと思います。自分がユーザーとして楽しんでいるゲームの障害発生時には、やはり原因や現状が気になります。長期間停止しているゲームには、まず今どうなっているかだけでも知りたいという気持ちを抱きますしね。

山田:ユーザーとしては、何の情報も出てこないのがいちばん心配です。なので今回も 、「わかっていないことをわかっています」という情報だけでも早く出そうと考えていました。ユーザーによっては、わかっていないことに対して怒りを感じてしまう方もいるかもしれませんが、それでも「わかっていないです」と報告することのメリットのほうが大きいと思っています。何も報告がないと、対応してるのかどうかわからず不安になってしまうと思いますので。

武内:障害対応の進捗が見えると、ユーザーもどれくらい待てばよいか推測できるようになります。そうすると、不満や不安の解消にも繋がります。

piyokango:報告はタイミングも大事ですよね。障害発生直後、迅速に広報機能が動けるかは、ユーザーを意識していなければできないことだと思います。

武内:普段から、バグの検知時には10分以内にTwitterで報告するよう心がけています。Twitterでバクを報告してくれたユーザーにはいいねを押して、運営側から「ちゃんと気づいているよ」というアピールもしています。

piyokango:ユーザーの方にも聞いていただきたい良い話です。

辻:ゲームは放置しても、ユーザーは放置しない、ということですね(笑)。

piyokango:それ私もずっと言おうと思っていました(笑)。

※ 本記事は掲載時点の情報であり、最新のものとは異なる場合がございます。予めご了承ください。

もっと知りたい!こちらもオススメ

DeNA、楽天、LINEに学ぶ! セキュリティ規定&プライバシー保護規則への対応

DeNA、楽天、LINEに学ぶ! セキュリティ規定&プライバシー保護規則への対応

ディー・エヌ・エー(DeNA)は10月16日、セキュリティ担当者に向けたイベント「Security×Discussion」を開催した。第1回目となる今回は、DeNA、楽天、LINEの3社がセキュリティに関する取り組みについて紹介した。本稿では、DeNA 茂岩祐樹氏、楽天 福本佳成氏、LINE 新美融氏によるパネルディスカッションの様子をお届けしたい。

関連リンク

この記事に興味を持ったら"いいね!"を Click
Facebook で IT Search+ の人気記事をお届けします
注目の特集/連載
[解説動画] Googleアナリティクス分析&活用講座 - Webサイト改善の正しい考え方
[解説動画] 個人の業務効率化術 - 短時間集中はこうして作る
ミッションステートメント
教えてカナコさん! これならわかるAI入門
知りたい! カナコさん 皆で話そうAIのコト
対話システムをつくろう! Python超入門
Kubernetes入門
AWSで作るクラウドネイティブアプリケーションの基本
PowerShell Core入門
徹底研究! ハイブリッドクラウド
マイナビニュース スペシャルセミナー 講演レポート/当日講演資料 まとめ
セキュリティアワード特設ページ

一覧はこちら

今注目のIT用語の意味を事典でチェック!

一覧はこちら

会員登録(無料)

ページの先頭に戻る