大人気パズルゲームのサービスマネジメントを考えてみた【サービスオペレーション編①】
こんにちは。
ユニリタ クラウドサービス事業本部の澤田です。
年初から始まった
「サービスマネジメント記事まとめ」の
マガジンですが、
早いもので、2023年度の上期
（ユニリタは年度が4月はじまり）の
終わりになりました。
▼#サービスマネジメント記事まとめ
少し硬めの内容から始まって、「LMIS」という
クラウドサービスを提供する
メンバーの記事を中心に投稿してきましたが、
ここで久しぶりに「サービスマネジメント」を
より分かりやすく伝える記事を書いてみます！
■巷にあふれるスマートフォンのゲーム
最近（でもないか）はスマートフォンのアプリで
いろんなゲームがありますね。
ただスマートフォンのゲームも
「お客様に有償で提供するもの」という
視点でみれば、当然「サービス」です。
※あまり意識もしていないかもしれませんが、
さらにいえば、クラウドサービスです。
そんなスマートフォンのゲームで
サービスマネジメントの各プロセスを
考えてみたいと思います。
少しでもサービスマネジメントを
身近に感じてもらえると嬉しいですね。
▼サービスマネジメントについて
■ゲームでもサービスマネジメントは必要？
結論、ゲームでも
サービスマネジメントは必要です！
むしろ企業がビジネスとして
提供するゲームには、企業内システムより
厳しいサービスマネジメントが
必要かもしれません。
そこで10年以上愛され続ける
大人気パズルゲームを例に
サービスマネジメントを考えてみましょう。
長くなる予感がするので、
今回はサービスオペレーション編です！
▼サービスオペレーションとは
「ゲームのアプリを立ち上げると固まる！」
「アプリを立ち上げても直ぐ落ちる！」
ゲーム好きなら
一度は経験したことはあるでしょう。
この裏で起きているゲーム提供会社の
「焦り」と「あきらめ」と「活躍」を
想像していきましょう。
■ゲームの障害に一番早く気づくのはだれ？
ゲームをしていて障害が発生すると、
ユーザーは「アプリが直ぐ落ちる」
「画面が進まない」と
ゲームのアプリの再立ち上げをしたり、
ネットワークの状態を確認したり、
場合によっては
スマートフォンの再立ち上げをするでしょう。
でもいっこうに直りません。
ここでユーザーは気づくわけです。
「これはゲームの障害だ！」と。
ゲームが立ち上がらないのですから、
ゲームのアプリから問い合わせもできません。
そうすると、X（旧：Twitter）に
ポスト（ツイート）したりするわけです。
Xをみると、先に障害に気づいた人の投稿が
たくさん発見されます。
そこで障害であることに確信をもつわけです！
また、障害が起きたときに
ゲームをしていなかった人も
「あ、今あのパズルゲームで、
障害が起きているんだな」と気づきます。
場合によってはアプリを立ち上げて
確認する人もいることでしょう。
じゃあ、
だれが一番早く障害に気づいたでしょうか？
一番初めにXにポストした人？
違います。
もちろん、ゲーム提供会社です！
■スマートフォンのゲームのほとんどはAWS上で動いている
先ほど、
「ゲームはほとんどがクラウドサービスです」と
書きましたが、
そのほとんどがAWS（Amazon Web Service）で
動いています。
※調査したわけではないですが、
体感値としては8割くらいです。
このAWS自体の問題、もしくはゲームという名の
アプリケーション・プログラムが引き金となり、
ゲームの障害が発生します。
そうなると
監視ツールとよばれるソフトウェアから
引っ切り無しにアラートが飛び出します。
監視ツールの画面では
赤い文字の羅列が表示され、
メールや電話も引っ切り無し。
場合によってはパトランプ赤く光ります！
（本当です！）
このアラートこそが、
サービスマネジメント・ITILでいう
イベント管理の「イベント」です！
おそらくゲームができなくなるほどの
障害であれば、1分間に数百という
「イベント」という名のアラートが
鳴るでしょう。
この状況でサービス提供者が
障害に気づかないわけがありません。
障害の最初の発見者になります。
そうしてどうすればよいか
焦って、焦って、焦りだします。
※この場で焦らない人は、
相当に障害慣れをしているか、
「緊急時こそ私の出番」と
楽しんでいる人ですね。
■焦りの次にやってくるものは・・・
たくさんのアラートが鳴り始めると
エンジニアの方であれば、気づき始めます。
「この障害は数分では復旧できない」と。
この時点でイベントから
インシデントとして管理されます。
「インシデント
＝サービスを提供できない
＝ゲームを利用できない状況」です。
半ばあきらめムードで、
ゲームのアプリを開いた際に
「現在、このゲームは利用できません」と
表示されるようにし、
自社の公式サイトで
「〇月〇日×時×分より、
△△ゲームで障害が発生しています。
現在、普及の目途は立っておりません。
障害の状況については
本サイトで随時更新をしていきます。
ご迷惑をおかけいたしますが、
よろしくお願いします。」
と掲載します。
※こういった障害の状況を正確に伝えるのも
インシデント管理の対応の一つです。
さて、初動が終わったあとのエンジニアは、
どうすればゲームを復旧することができるのか、
検討を始めます。
AWSを担当するインフラチームは
アマゾンウェブサービスジャパンの
問い合わせをします。
バックアップサイト
（セカンダリサイトともよばれたりします）に
切り替えることで、
できるだけ早くゲームを提供できるように
考えるかもしれません。
障害が起きた時間に
プログラムの変更を実施していたとすれば、
プログラムを元に戻すかもしれません。
また「とりあえずリブート」といわれるように、
復旧する根拠はないのに
サーバーのリブート（再起動）を
するかもしれません。
■何とかしてゲームが復旧
エンジニアと苦労と活躍のおかげで
ゲームが利用できるようになりました。
Xでは
「パズルゲーム、
ログインできるようになったぞ」という
ポストが増え始め、
公式サイトでも
「〇月〇日×時×分より、
△△ゲームで障害が発生しました。
現在は復旧し、ゲームも利用できる状態です。
ご迷惑をお掛けしました」
と掲載します。
ゲームアプリに
ログインできるようになったので、
問い合わせフォームから
「障害の原因は何だったんだ？」
「ゲームで遊べず、無駄に過ごした時間の
補償をしろ」と
半ばクレームに近い問い合わせも
あるかもしれません。
この一つ一つに丁寧に対応します。
※場合によっては、ゲームのユーザー全員に
「魔法の石を配る」という
経営判断に近い対応をするかもしれません。
ただ、イベントのアラートから端を発した
インシデントはここでひとまずクローズです。
と、インシデント管理のプロセスまで
書いたところで、約3,000文字・・・
本シリーズ
「大人気パズルゲームの
サービスマネジメントを考えてみた」は
連載が決定いたしました！（ﾊﾟﾁﾊﾟﾁﾊﾟﾁ）
次回もこうご期待！