本記事はとあるソーシャルゲーム開発会社でQA(品質管理)を務める筆者が、
業務を通して考えたこと・感じたことを書き留めるポエム記事です。
あくまでも一事例として捉えていただければ幸いです。
また、守秘のために一部フェイクも含みます。
「不具合修正のお知らせ」
ソーシャルゲームなどでよく目にしますね。
リリースされた後も定期的に更新が行われるタイトルでは、望まざるともどこかのタイミングで不具合を持ったままゲームが提供されてしまうことが度々あります。
それらの不具合は重要度に応じて「緊急メンテ」「次回以降のメンテ」「次回以降のバージョン更新」等の要所要所で修正対応がなされます。それらの対応が完了した際にユーザーへ向けて説明を行うのが「不具合修正のお知らせ」です。
重大な不具合には経緯を含めた説明や、必要ならば補填などの内容も盛り込みますが、軽微な不具合の場合は箇条書きで現象の内容のみを記載することが一般的でしょう。
言わずもがな、重大な不具合の発生時には運営スタッフ一同、かなり気を遣った文面を用意し、推敲を重ねてから公開に踏み切ります。
対象的に、軽微な不具合の対応完了のお知らせに関しては温度感は低くなりがちです。
しかしながら、この軽微な不具合の修正お知らせにこそ「憂慮」すべき点があることも事実です。
今回は「不具合の修正お知らせ」に潜むインシデントを私なりに考えてみます。
インシデント：重大な事件・事故に発展する可能性を持つ行動や要素
「対応した不具合が多かった」ときに私が考えること
QA・デバッグの業務を管理していると、対応する不具合の量=業務量であることに気づきます。
対応した業務が多ければ多いほどそれらをアピールしたくなるのが人の性ではありますが、ここはグッと堪えたいところです。なぜなら「そもそも対応する不具合が多い」ことはユーザーにとって褒められるものではないからです。
「たくさん対応したからユーザーは喜んでくれるかもしれない！」
と思いたい気持ちもわかります。ですが全てを書き連ねてしまっては書く側も、読む側も負担です。ユーザーに検知されていない不具合をお知らせした場合は心証を損なうだけの結果となり得ます。
ただし削り過ぎるのもよくありません。
軽微な不具合でも社内で検知できているのであればユーザーにも再現していると考えるのが自然です。
「不具合なんて無かった。いいね？」 という姿勢はやはり心証を損ないます。
あったはずの不具合を誤魔化すような行為もQAという立場上推奨したくありません。
ではその取捨選択はどう行えばよいのか。
「対応したことを知らせないとユーザーが困るもの」
を第一の基準にユーザーへ伝える情報を選んでみるのはいかがでしょうか。
ユーザーにとって親身な対応は何か、それを考えるのもQAの仕事かもしれません。
ただし、残念ながらこれらはどうやってもケース・バイ・ケースです。
サービスの運用には必ずそのサービスの「ポリシー」が深く絡みます。
「伝えるべきこと」はそのポリシーによって選ばれ、努力できるのは「伝え方」だけというのも実情です。無論どんな仕事にも制約はつきものですから、それを語ることはあえて控えます。
クリエイティブな現場は業務量とその成果が評価に直結する場面が多く、結果として注力したものの物量をアピールする姿勢が育ちやすい環境です。それが反って「縁の下の力持ち力」を育てられない土壌となる場合もあるため、「成果とは何か」を考えて仕事をしたいものですね。
「対応できなかった不具合がある」ときに私が考えること
例えば、「ユーザーに既知の不具合」 が複数あったとします。
開発側はそれらを一気に修正できるわけではありませんから、重要度や修正にかかる工数から優先順位を設け、各バージョンに修正タスクとして配置して順番に対応を進めます。
そして対応を行えたものを不具合修正のお知らせを使い掲示します。
これによって伝わる情報は実は修正された不具合の内容だけではなく、もう一つあります。
それは 「運営が何を優先したか」 という情報です。
通常、ソーシャルゲーム内におけるお知らせの形式は、新機能や新キャラクター、キャンペーン等の実装内容をユーザーに伝えるものであり、「広告」的な役割を持っています。故に読み取れる情報もその内容以上には深掘りできないものが多いです。（例外もありますが）
しかし、不具合修正のお知らせは違います。
運用期間が長くなるに連れ、そのお知らせはユーザーにとって 「運営の腹の中」 を探る情報源となります。
例えば、高品質な3Dモデリングキャラクターを売りにしたゲームがあったとします。
更新日にそのゲームではガチャから新キャラクターの登場がありました。
登場直後に3つの不具合が発覚したとします。
・そのキャラが特定のポージングを行うとモデリングが崩れる不具合があった。
・そのキャラのセリフのテキストに誤字があった。
・そのキャラを使用して対戦時、スキルの発動でゲームの動作が重くなる不具合があった。
開発的な観点で考えると、
対応し易い順序は「誤字修正→モデル修正→フリーズ系修正」です。
実際にこの通りの順番でこの不具合を修正対応し、誤字とモデルだけはすぐに直せたとします。そして次の更新日には誤字とモデルの問題を修正したとお知らせで掲示します。
これに際しユーザーはどう解釈するか。
「運営はキャラの見せ方にはこだわるけれど、ゲームの動作が不安定な点は無視している」
そんな風に思われてしまい、ご意見をいただく場面が予想されます。
これは、ユーザーにとっての優先度はプレイングに依存し、開発側の優先度はコストに依存しているというすれ違いです。
このすれ違いを解消することは困難です。
なぜならユーザーにとっての優先度を更に突き詰めると、誤字はどうでも良い層と気にする層とで別れたりするからです。
そのため、不具合修正の優先度は優良誤認などの法的な問題や、プレイング事態の継続が危ぶまれない限りは開発上の都合にそった順番で対応するしかありません。
そこで大事になるのがやはり伝え方です。
上記の例で修正された不具合のお知らせが以下のように書いてあればどうでしょう。
・【修正した不具合】セリフの誤字、モデリングの問題を改善いたしました。
・【修正中の不具合】動作が重くなる問題について、現在も調査を行っております。
少なくとも「ゲームの動作が不安定な点は無視している」という意見は出にくくなるのではないでしょうか。
このように、修正のお知らせに修正の完了していない不具合についても言及することで、開発上のコストから優先度が低いとされた問題にも取り組んでいるという姿勢が示せます。
こういった情報の扱い方1つでユーザーの感じる「運営の腹の中」は姿を変えます。
「ユーザーにとって優先度の低い不具合なんて無い」 というのが私の持論です。
1つ前の項で「ユーザーにとって親身な対応は何か、それを考えるのもQAの仕事かもしれません」と私は書きました。ですが、ユーザーに向けた対応の中で運営チームの姿勢を「より良いもの」に見せることも大切と私は感じます。
ユーザーにとって信頼できる運営の提供するゲームは信頼できるものとなるからです。
QAという仕事は自社の 「ブランディング」 にも直結している点を忘れてはなりません。
ユーザーは統合して読み解く
不具合修正のお知らせからユーザーは「運営の腹の中」を探ると先に書きました。
故にブランディングも意識したテキストへの意識が大切になりますが、ユーザー感情は必ずしも制御しきれるものではありません。
ユーザーは情報を統合して判断を下す からです。
特に近年はSNS上で不具合に対する独自の判断がユーザー間で行われる点が目立ちます。
ゲーム内のお知らせに、SNSで見かけた解釈をあわせてしまうのです。
1つ例になるエピソードを創作してみます。
（類似例は無い筈とは言い切れませんが創作として読み取っていただきたくです）
とあるゲームがサービスを開始し、ユーザー登録を開始しました。
昭和マンガを愛するあるユーザーが「コロスケ」とネーム登録を行ったところ、NGワードが含まれるとしてはじかれます。前半の「コロス」という部分がNGワードとして検知されてしまったわけです。ところがユーザーがこの現象をSNSに投稿したところ、後半の「ロスケ」がNGとなったという説が広まりました。これにより、そのサービスは国際情勢に合わせてNGワードを設定しているだと炎上します。
さて、このような例は運営チームで対策できるものでしょうか。
現象そのものを事前に想定することはできるかもしれませんが、実装として対策するのは難しいかもしれません。
こういった制御できない解釈が流布した時、
私は ユーザーの中で「不具合」が「不手際」に変化した と考えるようにしています。
実際に起きている不具合と同様に対応してしまうと不適切に感じられて炎上がさらに大きくなる可能性があるため、事実はどうあれ不手際に対する対応として動かなければ事態が収集しない可能性が高いのです。
無論、嘘をつくことを推奨するものではありません。
大切なのはやはり伝え方であり、姿勢なのだと考えます。
一見して不手際に見える現象がどのような不具合によって発生したのかを丁寧に説明することは、たとえ手間のかかるものであったとしてもブランディングという観点で見れば大事なのだと私は考えています。
また、ユーザーの中には、開発事情にも明るい人もいることから、
こういった事例も自然鎮火する場合ももちろん多いです。
不具合というのは、開発側にいると原因究明に目が行きがちですが、
こと対応となるとその影響や、 もたらされた状況をいかに判断するか が肝要です。
暴走した情報を止めることができるのが情報なのだとしたら、
不具合によって発生する情報の暴走もまた情報で制していくしかありません。
どうやって伝えるか、どうやって寄り添うか、
どうやってチームとそのタイトルのブランドを守るか。
「不具合修正のお知らせ」を単なる掲示物にしてはいけない。
QAのもう一つの戦場だと私は考えています。