見出し画像

大人気パズルゲームのサービスマネジメントを考えてみた【サービスオペレーション編②】

こんにちは。
ユニリタ クラウドサービス事業本部の澤田です。

前回、
「大人気パズルゲームの
 サービスマネジメントを考えてみた」と
題して、サービスマネジメントを
身近に感じてもらうための投稿をしました。

書き始めてみたら筆が止まらず、
前回はイベント管理・インシデント管理で
3000文字になってしまいました・・・

今回は同じくサービスオペレーションである
問題管理について
「大人気パズルゲーム」を例にして、
ご紹介していきたいと思います!

▼前回の記事はこちら


■インシデントの復旧で終わりじゃない

前回の記事で書いたように、
インシデントの対応中は、誰も障害の
本当の原因(根本原因と言ったりします)は
考えていません。

まずはゲームの復旧に専念します。

今回はゲームの復旧をして、
ユーザが再びゲームで遊べるようになった後、
ゲーム提供会社がどういった対応をするか、
そのプロセスを考えていきたいと思います!

■問題管理のプロセスは必要??

問題管理はもちろんITILプロセスのひとつですが、
実は、企業のIT部門では
インシデント管理との切り分けが
曖昧になっているケースが多くあります。

インシデント管理と問題管理を
まとめて「障害管理」として
管理していることもよくあります。

言葉の定義は、以下のようになっています。

インシデント管理
 -可能な限り早く、
   正常なサービス提供ができるようにすること
問題管理
 -障害の根本原因を解決し、再発を防止すること

このような違いはあれど、
障害を解決するという「目標」の視点で見ると
二つのプロセスは似通っており、
実運用では混同するケースが多いからです。

では、ゲームを提供する視点で見ると
問題管理のプロセスは
どうなるでしょうか・・・?

実は外部にサービスを提供するケースにおいて
問題管理は非常に重要なプロセスです。

何故かというと、それは
「ゲームが利用できない」
=「ビジネス機会の減少」
=「売上げ・利益の減少」となり、
同じ原因でインシデントを発生させることなど
あってはならないからです!

■ゲームの復旧後の問題管理

ここからはゲーム開発のエンジニアも交えながら
「アラートの内容」「出力されていたログ」
「クラウド基盤であるAWSからの情報」をもとに
根本原因を特定していきます。

そう、これがサービスマネジメントでいう
「問題管理」です。

根本原因の特定は容易ではありませんが、
問題管理では何かしらの結論を出します。

中には、
・非常に特殊な要因が複数重なって、
 障害が発生した。
・ゲーム上で、以前に提供していた
 キャンペーンが原因だった。
・原因が特定できないため、
 再発するまで様子見する。

という結論にいたることもあるかもしれません。

ただ、何かしらの結論を導き出し、
再発防止策の実施を検討することが、
今後のインシデントの発生
(=ビジネス機会の損失)の減少に
つながります。

ただし、
問題管理のプロセスで導き出した再発防止策は
必ず実施しなくて良い場合があります。

上記の例でいえば、
ゲームの一時的なキャンペーンが原因で発生し、
そのキャンペーンが終了しているのであれば、
再発防止策は実施しなくてもよいでしょう。

また、非常に確率の低い事象が
偶然に重なって発生したインシデントの場合は、
その解決に掛かるコストと
「ビジネス機会の損失」のトレードオフとなり、
実施しないという判断になり得ます。

ひとつ言えることは、
ゲームというビジネスを提供している以上、
再発防止策の実施には
経営的な判断がいるということです。

この点が企業のIT部門の問題管理とは
大きく違う点、かつ問題管理が
重要であるポイントですね。

※企業のIT部門ではインシデントが再発しても、
 売上げ減少・利益減少に直結するケースは
 稀ですからね・・・

■再発防止策を実施するか否か

問題管理で明確にした
根本原因・再発防止策を実施するかどうかは
「変更管理」のプロセスにバトンタッチします。

理想はすべての問題を解決することです。

ただ前述のように費用対効果や再発のリスクを
変更管理でしっかりと検討した上で、
その根本原因を解決するかを決めるのです。

ゲームの提供という視点で見ると、
変更管理、その後のリリース管理には
ゲームというサービス提供の停止が
(ほぼ)必ず伴います。

※〇月〇日〇時~〇月〇日〇時は
 ゲームの利用を停止し、
 メンテナンスを実施します。

 その時間はゲームを利用できませんが、
 ご容赦ください。

というアレです。

その時間はサービス提供ができず、
ビジネス機会の損失です。

そのため「インシデントが発生したら、
ひとまずサービス止めて調査してみるか」という
安易な対応はできず、
問題管理が重要になるわけです!


■次回予告!サービストランジション編!

企業のIT部門はサービストランジションの
変更管理・リリース管理を一連のプロセスとして
管理しているケースもあり、
リリース管理は「変更管理の一部」として
管理しているケースもあります。

ただゲーム提供会社にとって、
実は重要なのはリリース管理です。

なぜか!?ここまで記事を読まれている方だと
想像がついているかもしれませんね。

リリース作業こそ、ゲームというサービスを
一番長く停止させることであり、
ビジネス機会を損失させる要因になるからです!

次回は、パズルゲームにおける
サービストランジションの重要性の話を
したいと思います!