#ソシャゲの話をしよう 。
どうも、死に急ぐ生命の果実です。

さて、みなさんソシャゲは遊んでおりますでしょうか。
如何な名作・人気作とはいえ、ソシャゲは人の作りしもの。
いろいろな不具合や運営ミスなど、いろいろ感じることもあるでしょう。
そんな中で、不具合とはいえないまでも、わかりづらさや誤解をまねく表現・お知らせなどに出会ったことはないでしょうか？

今回はバグの話というか、ゲームでわかりづらくて快適に遊べないってのは、もはやバグだからな……。という話。
そんな結論に行きつくと思って読み進めてください。

題して「わかりづらさはバグなのか」というお話です。

ざっくり以下のような構成でお話をできればと考えております。

そもそもバグとは

今回の話をするにあたって、そもそもバグとはなによ？というところから話しましょう。

要はプログラムの不具合ですね。
プログラムに不具合があれば、途中で処理をミスったり、そもそも処理が走らなかったり、または終わらなかったり、なんらかの意図通りの動作をしなくなります。
基本的にバグは悪しきものです。

発生要因

要因は無数にあります。
わかっていればこの世からバグは無くなるはずなのです。理論的には。

バグの発生の大元を追っていくと、仕様まで遡らねばなりません。

仕様とは

ゲームはもとより、プログラムなどの制作物に必要なのが、完成までの道のりであり、要件や仕様の書かれた「仕様書」というものです。
主にエンジニアさんに「こんな感じのものを作ってください」と渡される設計図が「仕様書」です。
そして、ゲーム制作において仕様書を作るのは、大抵プランナーです。

発生プロセス

強いて定義するならば、「実装時の発生」と「設計時の発生」に分かれます。
それぞれについて具体的に説明していきます。

実装時の発生
エンジニアが仕様通りの組み込みをした時、エンジニア側のミスによってバグが発生することがあります。
そうすると当然のように動かなかったり、想定する動作をしなかったりすることがあります。

基本的に、「仕様書が正しく、それと異なる実装はバグ」なので、これは明確にバグですね。
まぁ、設計と異なる実装はそもそも推奨されないだろうというのは、なんとなくイメージしていただけるでしょう。

設計時の発生
一方で、設計時の発生というのもあります。
詰まるところ、仕様書にミスがある場合ですね。

要件が詰められていなかったり、知識が不足していたり、チーム内でのホウレンソウがうまくいってなかったり、設計者が徹夜だったりするとまれによく発生します。
そう、「よく発生してしまう」のです。

するとどうなるのでしょう。
その仕様書を受け取ったエンジニアは困惑します。

そりゃそうですよね。
仕様書通りに実装すればうまく動作しないのは明白だし、だからといって無断で設計に改変を加えるのもバグの温床となります。
なので、面倒臭えなぁと思いながら、「ここの仕様どうします？」と相談するのです。

完璧な仕様書というものはあまり存在しない。完璧な絶望が存在しないようにね。

大抵の場合、多かれ少なかれゲームの開発にはこういったやり取りが発生します。
その度に詳細を詰めたり仕様を切り直したり、プランナーやエンジニアの心や目がどんどんどんよりと曇っていったりします。

もちろん、エンジニアとプランナーの間だけでなく、デザイナーもこれに巻き込まれることは多々あります。
素材の透過ミスやサイズの調整。
実際組み込んでみたら、追加で「ここにボタンを追加してほしい」などの要望。
挙げ句の果てには「なんか思ってたのと違う」。

ギスギスしはじめるチーム。

キレてはいけません。
これがゲーム制作の日常です。

ここまでがよくあるバグの発生パターンです。

一方、ソシャゲでは

ここから少し広げて、ソシャゲの運用を視野に入れてみてみましょう。
コンソールと違い、ソシャゲには長期間の運用やイベントや多数のユーザーなど、単独のゲーム開発とは違った側面があります。よって、これまでとは違った問題も発生します。

なお、ガチャについて触れると、それだけで記事が数本書けてしまうので、今回はあくまで運用面の話に止めたいと思います。
触れたいところは色々ありますが、ここではざっくりとイベント運用とお知らせの話をしていこうと思います。

ソシャゲの運用では欠かすことのできない「イベント」。
ゼロからの設計でない場合も多いが、それでも仕様書は必要でです。
レベルデザイナー、またはデータ入力のスタッフに対して、「ユーザーがどういう動向をするか」の指標、ないしは数値を書いた資料です。
これも慣例的に仕様書と呼ばれることが多いですね。

イベントには、目的があります。
そしてその目的を達成する手段が必要です。
例えば極端な話「目標は売上アップ、手段はガチャ、ガチャの需要を上げるためクソ難しいクエストを所望」という感じですね。
（まぁ実際はそんなシンプルなものではなく、細々といろんなものを施策として想定しなければならないのですが、今回は省きます）

さて、話を少し遡って、「実装のバグ」と「設計のバグ」を思い出してください。

イベントに関してもこれは当然発生します。
パラメーターや報酬設計をミスればそれは実装時のバグですし、そもそもおかしなパラメーター設定を指示していれば、それは設計のバグです。まぁシンプルな話ですね。

当然、実装者やデバッグによってテストは行いますが、しかしながら、「それによってユーザーがどう動くか」は、リリースしてみないとわかりません。
これがソシャゲの、というか客商売の現実的な難しさですね。

どれだけ期待を込めて渾身のイベントを組もうが、ユーザーが想定通りに動かなければ成功とはいえません。

なので、運営は過去のイベント時のデータや、どの形式のイベントがウケたのか、どのキャラが売れたのかなどなどから、事前にリサーチとシミュレーションを綿密に行います。
一回のイベントの大失敗は大きな損失です。故に、基本的に失敗は許されません。

が、もちろん失敗するときは失敗します。
そのときは何がダメだったのかを徹底的に検証する必要があります。
この時に原因が「実は実装時の入力ミスでした」とかだったら目も当てられませんね。
実装者やテスターは何してたんだ、という話です。が、なぜかこういうことは稀によく発生してしまいます。

少し話が逸れましたが、これまでの内容をまとめましょう。

• 成果物が正常に動作しないことをバグという

• バグが発生する原因は実装時のとか設計時のとか色々ある

• ソシャゲのイベントは、出してみるまで想定通りにいくかは判断できない

• なので、安易な理由での失敗は許されず、事前の検証をしっかり行う必要がある

• それでもイベントが失敗することはある

• その原因が安直なヒューマンエラーとかだと目も当てられない

わかりづらさはヒューマンエラー

うすぼんやりと一般的な感じに薄めて話しますが。
「報酬設計やタスクのクリア条件などの見せ方がわかりづらく、実装のミスではないがユーザーから問い合わせが殺到した」という事例があったとします。
こればどう考えるべきでしょうか。

あくまで個人的な意見なので一般化はできませんが、「ユーザーに意図が伝わってない・誤解させる時点で、設計がうまくいってないのではないか。そして本来、開発チームなり運営チームなりテスターが、『これってわかりづらくないか？』とアラートを上げるべきではないのか」と考えます。

運営の最初にして最終、そして基本的な目標として、「ユーザーに快適に遊んでもらう」というのは絶対であると考えています。
なので、意図していない限り、分かりづらさや誤解の発生の原因は排除しなければならない。
見ればわかる、指摘されれば納得するレベルなら尚更です。

お知らせなどのテキストで補足しておけば大丈夫、という意見があるのもわかります。が、「無料のゲームをキャラが好みだからちょっとやってみよう」くらいのテンションの新規ユーザーに、お知らせをしっかり読むことを前提にする設計はいかがなものか。
「書いておけば大丈夫」はもはや免罪符ではありません。

お知らせなどのテキスト情報を読ませることが前提の設計というのは、新規ユーザー獲得や離脱の面では悪手です。
ならば、要点などを押さえて、簡潔にわかりやすく、適切に情報を伝える設計が必要であり。これをやるのがプランナーやデザイナーなのです。

文字をガッツリ読まなければいけないほど説明がいるシステムや施策であれば、それを提案したり承認したりする人は遊ぶ人のことを考えなかったのだろうか、とも思います。
もしかしたら、「チームの他の人がなんとかしてくれるだろう」と思っていたのかもしれないですが。

主張についてまとめましょう。

• ゲームにおいて「そもそもユーザーが快適に遊べない」というのは設計上のミスであるといえる

• 上記を前提とすると、快適感の粒度は諸説あるが、誤解をまねくような設計や見せ方、大量のテキストでの補足などは「ユーザーが想定通りに遊べない≒バグ」といえるのでは？

• 上記の視点で、運営チームやデバッグチームは設計やテストをしているのか？

よく「わかりづらいけど書いてあるからオッケー」のように、「書いてあるかどうか」でよい悪いを判断する向きもあるが、個人的には『伝わればOK。書いてあったとしても伝わらなければNG』だと思っています。

ユーザーに意図が伝わらないのは、運営上、設計上のバグなのです……。

本日僕から言いたいことは以上です。