#このアドベントカレンダーについて
初日から遅刻してしまい本当に申し訳ありません…
このアドベントカレンダーは、ゲーム業界のQA（品質管理）における知見を共有し、業界発展に貢献することを目標としています！
ゲーム業界のQAって具体的に他業界のQAとどう違うの？という点については、↓の記事がわかりやすいので、ぜひご覧になってください！
https://qiita.com/gomez_te/items/40f0d8f898b4f619979c
#再発する障害
##概要
この記事のテーマに移らせていただきます。
運営中のタイトルで障害（本番環境での不具合）やヒヤリハットが起きたとき、QA側に責任がある場合や、開発側起因ではあるものの、QAで防ぐことが出来そうな障害の場合、大多数のQA組織では、再発防止策を設定して、同じ障害が起こらないようにしていると思います。
しかし、しっかり再発防止策を打ったのに、同じような障害がまた発生してしまう…そんな経験はないでしょうか？
この記事では、そんな再発してしまった障害について、見解を書かせていただこうと思います。
今回はよくある2パターンに分けて記載してみます。
##障害の例
以下の障害を例にして、障害が再発してしまったパターンを書いていきます。
▼障害と再発防止策の例
・あるイベント種（イベントA）の登場キャラを更新した際、イベント関連画面（○○画面）を開いた際にクラッシュが発生した。
そこで以下のような障害再発防止策を設定した。
##根本原因の分析不足があったパターン
###概要
障害の根本原因を適切に分析せず、場当たり的な対応で障害が再発してしまうパターンです。
以下に極端な例を記載します
障害再発の例
上記再発防止策の策定後、後日イベントAとは類似しているが別種のイベント（イベントB）の登場キャラを更新した際、○○画面を開いた際にクラッシュが発生した。
調査後の根本原因
この障害の根本原因は、イベントA固有の問題ではなく、○○画面に関連する全イベントの登場キャラが変更されたとき、○○画面から更新後のキャラ画像が呼び出せなくなるとクラッシュが発生することだった。
###この例の場合の問題
この例では、最初にイベントAでクラッシュが発生したときに、原因と影響範囲をイベントAのみに制限して再発防止策を設定したことです。
○○画面を利用する類似イベントがあるなら、開発側と範囲のすり合わせや、QAによる類似イベントの確認をしたうえで、障害再発防止策を策定するべきでした。
これは極端な例ですが、障害の根本原因を分析して、真の影響範囲を探ることは、再発防止においてとても重要な行動です。
##再発防止策が実施されていないパターン
シンプルですが、とてもよくあるパターンです。
障害再発の例
イベントBでの障害を受け、再発防止策を再考したが、再びイベントAの○○画面でクラッシュが発生してしまった。
調査後の根本原因
再発防止策として、○○画面をチェックするルールとしていたが、チームへの周知が口頭のみとなっており、チェックを実施している人としていない人がいた。
###この例の場合の問題
この例は、障害の対応を現場の担当者に任せきりになっている場合や、各関係者が高稼働状況で余裕がない場合に発生しやすい事例です。
再発防止策は策定後、運用されて初めて効果を発揮するので、QAチームの責任者は運用開始まで追跡することが望ましいです。
##では具体的にどんなことをやるといいか
###振り返り会
単純ですが、振り返り会を実施するのはとても効果的です。
振り返り会は次の2形態で開催するのがおすすめです。
握った内容は必ず議事録に残し、チームとして有用な情報なら資料化することも大切です。
開発・QA合同の振り返り会
効果的な再発防止策設定に役立ちます。
基本的には発生した事象をQAでまとめておき、QA側で考えられる再発防止策を開発に共有し、FBを受けるのが良いと思います。
その再発防止策が本当に効果的かの意見が聞けますし、開発側でより良い再発防止策を導き出すことにもつながります。
たとえば、入稿時のバリデーションチェックで拾えるものであれば、QA側の対策よりも、そちらで対策を打つほうがより効果的です。
QA内の振り返り会
再発防止策の実施状況のモニタリングに役立ちます。
FIXした再発防止策をどのように運用しているか、QAメンバーへのヒアリングを行ったり、
開発と話した内容の共有を行うことで、メンバーの意識づけやナレッジの強化につなげることが出来ます。
###BTS等を用いた障害の管理
RedmineやJIRA、もしくはスプレッドシート等でもいいので、リリース後の不具合についても、データ化して一覧で追えるようにしておくと、障害の再発防止において役に立ちます。
まずチームの障害の総数を見える化すると、品質状況についてメンバーに意識づけを行うことに役立ちます。
たとえば、障害数が少ないチームにおいては、現状の運用がうまくいっていることが明確にわかるので、現状のラインに沿ってチームを強化すればよいことがわかります。
逆に障害数が多いチームに対しては、現状の運用がうまくいっていないことが考えられるので、熱量高く改善の取り組みが必要なことがわかります。
これら見える化した障害に対してラベリングを進めていくと、障害の再発率も明らかになってきます。
また、策定した再発防止策の内容も情報として記載していくと、管理者が状況を確認する助けとなるので、効率的なモニタリングに繋がります。
#おわりに
この記事では、障害が再発してしまうよくあるパターンと、それに対する望ましい対応について記載しました。
かなりイージーなミスのようにも見えますが、チームの責任者と実運用の担当者それぞれがしっかりと意識づけしていない場合、起こりうるミスです。
簡単なことほどしっかりとやっていくことが、QAとして大事な心得かなと思います。