愛嬌こそが最強の武器

「障害を減らそう、機嫌よく働こう、自分の市場価値を高めよう」
というのが、僕がマネジメントしているQAチームのビジョンです。
自分で言うのもなんですが、このビジョンを作れたこと、特に「機嫌よく働こう」というフレーズを作れたことが、ここ数年の一番の成果だと思ってます。

QAチームのビジョンというと「品質向上！」みたいなのをよく見かけます。実際、僕も最初のうちは「障害減らそう、市場価値高めよう」というビジョンを掲げてました。

でも、なんかしっくりこなかったんですよね。画竜点睛を欠くというか。僕は、いい仕事をしたいのと同時に、対人関係のストレスを減らしたかった。別の表現すると、嫌な奴と働きたくなかったw

そんなときに、なんかの本で「健康で機嫌が良い、という身近な幸せを、もっと現代人は大事にすべき」的なことが書いてあって、すごく共感したのです。

「機嫌の悪い人」というのは、一つの災害だと思います。周囲の人に多大な負荷がかかる。なんかの研究によると、チームに1人機嫌の悪い人がいると、周囲3人以上のパフォーマンスが下がるとか(逆にチームメンバの機嫌が良いと成果をあげやすい、という研究結果もあった、はず)。
つまり、其の人にどんだけスキルがあっても、機嫌が悪ければ、周囲のメンバをデバフしちゃうわけです。最悪のパッシブスキル。

機嫌のいい人に囲まれたいですよね。そのためには、まず自分が機嫌よくなるために出来ることを考えて、そして、周囲の人の機嫌を損ねないために何が出来るかを考えていくことが大事かと思います。

諸々の鍵になるのは「礼儀正しさ」なんじゃないかな、と思ってるのですが、そのへんの話はまた今度。

ブレーキにもエネルギーは要る

テスト計画というと、いつ何をどれくらいのリソース充ててテストするのか、というところに焦点があたりがちだけど、テストの中止条件もちゃんと定めといたほうがいいんじゃないか。というお話。

「バグが出まくりだし、収束しないし、テストしても意味なくね？」っていう状況は、割とよく見かけます。
そんな状況になったときに、速やかにテストを中止して、開発フェーズを上流に戻せれば健全なのですが、いろんなシガラミで、テストを渋々続けざるを得ないことも、ママあります。

まぁ、そんな状況でテストしてるだけでも、結構しんどいのですが(しょうもないバグのバグ報告に手を取られるので)、場合によっては、「なんでこんなに不具合出てるの？リリース遅れちゃうんだけど。」みたいなことを、テストチームに言ってくる輩も存在し(バグを作ってるのはプログラマなので、クレーム言う先を間違えている)、こうなると、テストチームは、一気に無力感と疲弊感と無常観に襲われ、モチベーションもパフォーマンスも下がっていくわけです。

なので、そうなる前に、テストを中止できたらよかったよね。
と思うことが、長年テストの現場を見てると、ちょくちょくあるので、そのためには、
テスト始める前に、中止条件をきっちり、ステークホルダと握っておきましょう。

中止を伝えるときですが、以前もこのブログ(リンク)で書きましたが、QA側に必要なのはデータと誠実さです。

データは、まぁ、新規オープンしたバグ、未対応のバグ、対応されたバグ、の3つが可視化されてて、未対応のバグが増えていってるのが見えれば良いのではないでしょうか。
誠実さに関しては、過度に煽ったりせず、このままの品質だと市場に出してもユーザは評価してくれないということを、丁寧な言葉で伝えればよいかと思います。このとき、大事なのは、レポートを出すだけではなく、ちゃんと口頭でも説明することです。悪いニュースの書かれたレポートは、読み手が誤解して、変なトラブルになることもあるので(実際に「これ書いたやつ誰だ！」と、プロデューサに逆恨みされそうになった人も居ました)、レポートだけが独り歩きしないように気をつけましょう。

なお、このテのトラブルが発生するプロジェクトの共通点は、以下が挙げられると思います。以下の条件を幾つか満たすプロジェクトのテストをする際は、気をつけましょう。

• 技術力の低い開発会社(チーム)が開発している
• これまで取引実績のない開発会社(チーム)が開発している
• テストチームにバグを洗い出してもらおう、という意識が働いている(QAチーム、テストチームの役割を勘違いしている)
• 新しいテクノロジを採用している
• 開発ボリュームの割にはスパンが短い
• テスト側は、きっちりリソースとスケジュールを組んでしまっている。そのため、走り出してからの融通が効きにくい

人は怒りながらマラカスを振れない

オードリー若林の書いたコラムを読んでます。いい感じに人見知りと被害妄想をこじらせてて、とても親近感がある。

完全版 社会人大学人見知り学部 卒業見込 (角川文庫)

好きな下りがあって、企画会議中に作家だかディレクタだかが発表した企画に対して、若林が「それは面白くないっすね」的な発言したところ、ベテランスタッフに「うん、若林くん、言葉を選ぼっか」とたしなめられたそうな。

「うん、○○くん、言葉選ぼっか」である。

これが嫌味なく言えて、かつ、ちゃんと当事者(と周囲の人)が受け止められる雰囲気って、とても凄いことだと思う。普通なら、険悪になるところだ。相手の致命的なミスをすかさず指摘し、雰囲気も崩さない(そして、そもそも、若林が雰囲気を崩しかけたのをちゃんとリカバリしている)。

テレビ番組制作というクリエイティブな現場だからだろうか、一人ひとりの本気のアイデアがぶつかり、ときにはそれを否定することが必要になるからこそ、否定する相手にに対しての気遣いというものがしっかり守られている印象を持った。この雰囲気、とても羨ましい。

人の意見を否定するときに、とても強い言葉を用いて、相手をやっつけようとする人が居る。そのようなシーンを見ると、とてもイライラするし、家に帰ってもずっと頭からその光景が離れず、寝付きが悪くなったりする。

仮にそのような人に「言葉を選ぼうっか」と言っても、残念ながら、おそらく、火に油を注ぐだけな気がするしなぁ。

どうすれば、このような人を落ち着かせることが出来るのかなと色々と考えてみたところ、罵声を浴びせてるところを動画を撮って共有してあげたら、いくらかマシになるかもしれないなと思った。それか、会議室に鏡を置くとかね。

自分が人に罵声を浴びせてる姿って見たことあります？私は見たことないですが、それはそれはきっと醜い姿だと思うのです。

それか、人に意見を述べるときは、両手にマラカス持つとかね。
冷静かつ和やかに議論が進むと思う。
人間は怒りながらマラカスは振れないようにできてるから。たぶん。

『ゲームテスト＆QA』 その6

ドラクエ11のダウンロード待ち時間の間に、ブログ更新。

近所のツタヤで購入したのですが、ダウンロード版も最後の1個でした。売れてるようですね。僕の周りの従業員も先週末はドラクエ漬けだったみたいです。同世代の評判は良いので、楽しみ。

ゲームテスト&QA

ゴールに向かって ~バグハンティングの上級テクニック~

全面的に同意出来る内容でした。この章に書いて有ることを実践すれば、間違いなく、優れたテスターになれるでしょう。といっても、特別難しいことは何もありませんので、そこの駆け出しゲームテスターのあなたも、ご安心ください。

この章では、優れたテスターとそうでないテスターの差を説明しています。題名は「上級テクニック」となってますが、別に特殊なスキルとかではなくて、文章力とか自己管理能力とか向上心だとかゲーム制作のテクノロジに対する興味だとか、そういう基本的なところで、優れてるかそうでないかが決まる、と。ゲームの上手い下手はあまり関係ありません。

基本的なところで差がつく、ということは、裏を返せば、「ゲームが好きだから」という理由だけで、この業界に入ってくる人が後を絶たないということです。もっと厳しく言うと、ゲーム以外に興味がない、ゲームを消費することしかできない人たちが多いのです。

僕はテスターの採用面接をすることもあるので、色んな人とお会いするのですが、ゲームを消費してるだけの人の多いことが気になってます。
ゲームが好きなのは良いのです。しかし、その好きなゲームについて、自分の言葉で熱く語ることすらできない人が沢山います。「どんなゲームが好きですか？それを私に勧めてみてください」と質問してみても、「好きなゲームはドラクエです。え～と…う～ん…」と、言葉が出てこないことがよくあります(まぁ、緊張してるということもあるでしょうけれども)。こういう人は、雇っても、だいたい勤怠が悪かったり、おしゃべりばっかりしたり、逆に全く報連相ができなかったりと、結果として仕事が長続きしない傾向にあります。

「ゲームが好きだからゲームテスターに応募しました！」という、動機は良いのですが、その後のこと、つまり自分自身のスキルとキャリアパスをちゃんと考えられるかどうかが、ゲームテストで結果を出して次につなげる人と、ずっとテスターでくすぶる人の差なのだと思います。

ここまで書いて思い出したけど、傾向として大卒の人は優れてますね。コミュニケーションや自己管理もちゃんとしてるし、自走してスキルを伸ばしていってくれます。まぁ、あくまで傾向であって、例外に当たる人(大卒じゃなくても優秀な人)はいくらでも思い浮かびますが。

メモ

・ゲームをテストすることは簡単ですが、プロのようにテストすることは難しい

・抜きん出た存在になるためには、強い意志と完璧な労働感を持ち合わせなければいけません

・簡単なバグは、二流のテストチームでも労せずしてみつけることができます。

・ゲーマーとテスターの違いは、素人俳優とジャック・ニコルソンやメリルストリープのような伝説の俳優を比較するようなものです。素人でも演技はできますが、魅力的で魂を揺さぶる事ができるのは伝説の俳優たちだけです。

・オーディオやビジュアルのチェックは、一人のテスターにまとめて割り当てると良い

・ゲームのテストを開始する前に知って置かなければ行けない一番重要なことは、「何が起こるべきなのか(「期待される動作」と呼びます)です

・(テスト対象の)ゲームについて、よく知ることが大事

・テストをするときは、楽しみすぎないように注意が必要です。

・テストをして給料をもらうのであって、遊んだりおしゃべりをして給料をもらうのではない

・優れたテスターになるためには、プログラミングやスクリプティングの基本的な理解、しっかりとした分析的・批判的思考能力、画像やビデオ編集ソフトに関する高度な知識、大学レベルの文章力が必要です

・プログラミングやスクリプティングを学ぶことで、(バグの発見という)結果だけに振り回されるのではなく、その根底にある原因を対象に出来るようになる。

・優れたテスターになるためには、「書く」技術を学ばなくてはいけません。文章力の優劣は、大きな違いをもたらします。

・3時間に1回の割合で、休憩を取りましょう。効率が下がります。

・何もかも詳しくなる必要はなく、何か一つのエキスパートになりましょう。

・アドホックテストは自由形式のテストのことです。アドホックテストでは、他の方法では見つけられなかったバグが見つかることがあります。

・極めてタチの悪いバグは、アドホックテストを通じて見つけやすいようです。

・多くのテスターは、自分自身の評価に対して、「問題なし」(クビにならない程度)のレベルで満足している。

・細部に対する鋭い注意力と優れた文章力は、新人テスターに取って最も重要な能力です。

・ヒューマンスキルの欠如は、本質的に技術重視で2進法のゲーム業界において、もっとも大きな問題の一つです。

・優秀なテスターは、相手に敬意を示しながら自分の意見を主張できる。

結局は人を相手にする仕事

現状、ゲームQAの専門書や記事って非常に数が少ないので、独学するときは他業種に目を向けることが多いです。

最近参考になるなと思ったのは、医療の現場に関するものです。
医療とQAは、仕事の性質や、業務のフローなど、結構似通っている部分が多いと感じています(こんなことを言うと、医療現場の人からは反感買うと思いますが。背負ってる責任が違うから)。

似てると思ってる点を挙げると

• 健康と品質、いずれも目に見えないし、明確な基準も存在してないものを相手にしている。
• 病気もバグも、診断中(テスト中)に見逃すことは許されない。完璧を求められる緊張度の高い仕事である。
• しかし、人の仕事である以上、完璧などないが、顧客はそれを理解しようとしない場合がある。
• 患者は自分の健康状態のことを知ってるようで、実は知らない。開発チームもチーム自体の質を正確には知っていない(興味もない)。そのため、病気もバグも出続ける。
• 治療よりも予防のほうが安いし効果的である。ソフトウェア品質も上流で不具合の作り込みを防ぐ方が、安いし品質も上がる。
• しかし、予防をちゃんと出来る人間(チーム)はごく少数である。
• インシデントが発生した場合、理由は複合的である。
• 其の気になれば幾らでもお金をかけることができるが、だからといって、成功を保証するものではない
• レビューが効果的

とりあず、ざっと思いつく限りだとこんなもんでしょうか。無理矢理感を感じるところもあるかと思いますが…。

どうすればエラーが出ないか？という研究は、医療の現場のほうが、ゲームQAの現場よりも、きっと進んでるはずで、そして、その成果はゲームQAにも活かせるのではないかなと、ちょっと期待してます。これから、折を見て調べてみたいと思っています。

ちなみに、軽くググってみたところ、このようなページがありました。
うん、不謹慎かもしれないけど、とても親近感ある。

チーム医療で防ぐ医療過誤

『ゲームテスト＆QA』 その5

EVO2017の最終日を家で見てました。スト5が劇的やった。

自分が携わったゲームがユーザ参加型のイベントに使われたことがあるのですが、ユーザが夢中で楽しんでる姿を見るのは、やはり良いものでした。一生懸命不具合取り除いて、ユーザがバグに気を取られることなく楽しんでる姿をみると、ゲームQA冥利に尽きます。

ゲームテスト&QA

CHAPTER 5 エンジン始動！バグ探しの要点

この章では、シューティング、2Dアクション、格闘ゲーム、RPG、FPSなどなど、さまざまなジャンルのゲームQAの勘所を、ジャンルごとに説明しています(第二版があるなら、VRゲームも書いてほしいですなぁ)。不具合だけでなく、ユーザエクスペリエンス部分でもどのような指摘をすべきかも説明してあって、ゲームQAのお仕事は単なるバグだしだけじゃないということが伝わってきます。

テスターやテストリーダの立場でも有益だし、それよりも上流で、テスト計画や見積もりの参考にもなりそうな内容でした。

MMORPGのテストが一番難しい、というのは、覚えておきたいところです(僕はMMOもRPGもテストしたこと無いので、いつかしてみたい)。

また、不具合報告書の書き方も記してあって、テスト初心者におすすめしたい内容でした。

以下メモ

・ゲームをテストすることは、プレイすることとは大きく異なります

・2Dゲームをテストする際は、重点をゲームプレイに起きます

・3Dゲームをテストする際は、カメラについてレポートすることは、テスターの使命である

・FPSでは、レベルデザインが理解しにくかったり、迷宮のようになっていてはいけません。プレイヤーを迷子にすることなど、あってはならないのです。

・マルチプレイヤーのFPSをテストするときは、ネットワーク接続に関連するバグに注意しなければなりません

・RPGゲームのテストを始める際には、仕事量が実に多くなることを前提に準備をしてください。テストの難易度は「ハードコア」だと思って良いでしょう。

・ストラテジーゲーム(シヴィライゼーションみたいな)をテストするときは、ゲームバランスに注意すべき

・パズルゲームで注意すべき点は、すべてプログアムに関する部分です。

・MMOはゲームテスト界の頂点です。

・MMOでは、βテストでユーザに不具合を上手く見つけさせる仕組みを用意すると、うまくいく。例えば報酬を上げるとか

・ゲームのテストには大量の書類が伴うということを想像している人はあまり居ませんが、筆記力がなければ優れたゲームテスターになることはできません。

・不具合報告書のタイトルは、ジャーナリズムの基本である５W（誰が、何を、いつ、どこで、なぜ)を抑えればOK

・テスターは会話と筆記の両方で、明確かつ有効なコミュニケーションを取れなければいけません

・バグレポートには、常に正しいバージョンを記入していくことが重要です。

・私が求めるテスターは、プレイ中にバグを発見してレポートを提出したことがあり、「バグレポートの記入時に最も重要な項目は何か？」という質問に答えられるテスターです。この質問に対する答えから、回答者がどのようなテスターになるかわかります(一番の解答は「再現手順」です)

・ゲームをテストしているときは、自分が今何をしているのかを正確に把握していなければならないのです。ただプレイするのではなく、機能していない何かを見つけるのが仕事です。

仕組みでどうこうじゃなくて、マインドの問題かもしれない

実際に目にしたインシデントを振り返ってみるコーナー。

事例：一部のリソースが、実は最新じゃない状態でリリースしてしまった

凡ミスの類。
確かに不具合だけど、大した事ないんじゃない？と思うなかれ、ゲームだとコラボイベントなどで版元が絡んでると、かなり大問題になるのです。

リソースにも色々あります。ゲームだと、画像、音声、データ、ソースコードなど。
最近は、バージョン管理ツールを全ての部署で利用することもあるので、この手の不具合は、起こりにくくなってはいます。特にコードは。

しかし、画像や音声に関しては、外注してたり、こだわり派のデザイナが締め切り過ぎても(こっそり)手を加えたりで、管理が行き届かない現場も、よく見かけます。

スケジュール守りましょうね～、最新のものをこっそりコミットしたりはしないようにしましょうね～、と伝えても、こだわることが正義だと思いこんでたりもするので、あまり響かず同じ失敗を繰り返しがち。

「今、俺が見ているデータは最新なのか？」という保証は、結構難しい。

テストする段階で、諸々の素材はfixしてることが好ましいが、スケジュールがタイトな現場だと、仮素材でとりあえずテストを走らせつつ、fix次第、組み込むということも珍しくない。そして、fix素材アップしました、からの、やっぱ微調整しました、が繰り返されると、プログラマが更新し忘れたり、仕様となるドキュメントを更新し忘れたりで、ミスが入る余地が増えてしまう。

また、デザイナとプログラマは、別の管理方法を取ってる現場もあって、

①デザイナが最新データを共有サーバに上げる
②プログラマそこからデータをとる
③ゲーム内フォーマットに加工して組み込む
④プログラマ用のリポジトリにアップする

みたいな感じだと、最新の生素材から組み込みまでに複数のプロセス(しかも手作業の)が入るので、ここをミス無く運用するのは、難易度が高い。

これを防ぐにはどうしたらいいのか。
まぁ、余裕を持ったスケジュールを引いて、特定の日以降は素材の更新を認めない、というのが正攻法ではある。けど、そうも言ってられない場面もあるわけで、なので、大事なのは、「この画像・音素材が最新です」と記したドキュメントを作成し、それの更新を徹底することかなと思う。そのドキュメントがあれば、最新のビルドと素材の突き合わせを関係者全員が行うことができ、仮に素材の更新漏れがあったとしても、誰かが気づく可能性が高くなる。

しかし、ドキュメントの更新というのは、大抵が手作業で、忘れがちだしミスも起こりがち。つまり、「今、俺が見ているドキュメントは最新なのか？」という保証も難しいわけで、堂々巡りの様相を呈してくる。

解決策としては、ドキュメントの自動化とかかな？
それか、絵や音声に関しては、QA時に制作者に最終チェックしてもらうとか。作った人が、一番、細かいところまで知ってるからね。

ただ、後者の場合は、素材制作者がQAプロセスのボトルネックになりがちなので、そこがデメリット。「最終チェックしてください」と依頼をしても、全然見てくれなかったりね。

そこを解決するには、関係者が定期的に集まる場を強制的に設けて、そこで滞留してるタスクを動かすとかかなぁ。朝会とか夕会とか。この手の、ミーティング嫌う人多いけどね。

素材の更新ミス、みたいな単純な問題でも、それを徹底して防ぐのは難しいのです。