はじめに
メリークリスマスイブ！
本日は、QA歴5年ぐらい＆その他CSとかPMOとか5年ぐらいやっているShumaiがお届けします。
そのような経歴ですが、Qiitaの購読者層は圧倒的にエンジニアが多いと思うからエンジニア絡みのことを書きたい、
だから、エンジニアからQAへの要望を聞いてみよう、エンジニアへの要望も書いてみよう、と企画しました。
ちなみに、現在ゲームの事業会社のQA組織にいます。外部のQAベンダーにも委託をしています。
そのあたりを踏まえて読んでいただけますと幸いです。
エンジニアに聞いた、QAに求めること
二人のエンジニア(以下EN)に質問してみました。
####Q：ENがQAに求めることってなに？~1人目～
A：仕様通りの挙動が実現できているか、否かの確認
シンプルでいて奥深い。
ですが、多くのENの方がそう思っているのではないでしょうか。
もうちょっと深堀しました。
『ゲームの仕様を作る段階からチームにQA担当が入っていた場合はテストケースのレビューをする必要もなかったけど、運用フェーズに入り、QAがべた付きではない場合はQA/EN/PLの3者でしっかりレビューしないとつらそう』
素晴らしいですね。。。
良いテスト設計、テストケース作成できるように頑張ります。
#### Q：ENがQAに求めることってなに？~2人目～
A：開発の工数かけないで全部いい感じにやってくれる。
もう少し具体的に言うと、適切な粒度のテスト設計、テストスタジオと内部でのテストの方針説明、各種QAまわりハンドリング。
具体的！
テストの方針説明やQA周りのハンドリングはみんな普通に頑張りましょう、という感じですが、
一番認識差異がありそうなのは、『適切な粒度』のテスト設計、でしょうか。
QAに携わる多くの方が、自分なりに『適切に』テスト設計しているはず。
ただし、この『適切』が難しいと感じます。
ENからすれば
・え？それぐらいQAで見ておいてよね
とか
・え？その機能をQAで見るためにこんなにヒアリングされるならこっちで見るわ
といった感じでしょうか。
QAからすると
・え？そこもQAで見るの？ だったら仕様書もうちょっと詳細に書いてよ！
とか
・え？その機能説明するのにそんなに時間かかるの？（言われないとどこまで複雑かわからんわ)
といったことが考えられます。
この意思疎通、どうするべきでしょうか。
私の中での答えは、『どうしようもない』です！
行き詰まったので、次にいきます。
#QAが思う、エンジニアに求めること
QAも日々、ENに対して色々思っています。
QAの多くの人は、基本的に品質を担保したい、不具合をどうにか防ぎたいと思っている(はず)。
そのため、『適切なやり方で』『適切な時間をかけて』テストをしたくなります。
まだまだ未成熟なゲーム開発において、上記のようなことは当たり前ではありません。
(余談ですが、私は面接を受けてくださる方で「現在はウォーターフォール型ですが、アジャイルのQAに興味があります」なんて方には不安を感じます。しっかりウォーターフォール型でQAをしているゲーム会社をほとんど見たことがないですし、じゃあ現状アジャイルか？と言われると、まぁアジャイルっぽいけど、ちゃんとしたアジャイルでもないよな、と思っている人間です)
リリース前の高負荷状態のときだけでなく、ゲームが運用された後も、一つのゲームにおいて数十個の施策が月間でリリースされる状況のため精一杯の適切なQA、しかできていない状況です。
精一杯の中で、これはお願いしたい、、、ということを列挙します。
####お願いリスト
- お願いだから、QA開始前に、コードFIXを！
- できている箇所からQAするけど、エンバグとか優先順位組み立てとか無駄が多い
- お願いだから、FIX後にいじった場合は一声かけて！
- その箇所もう一回見るから…知らされてないと仕様確認の質問も増えるかもしれないし
- お願いだから、仕様変更があったところの共有を！
- それ教えてくれないとテストの仕方変わっちゃう
- お願いだから、不具合修正で何をしたかもう少し詳しく教えて！
- 直しました、だけだと、どう意図して直したのかがわからない…修正確認大変！
- もしよかったらレビューに協力して！
- レビューによって仕様共有漏れとか観点漏れとか防げます
- もしよかったらデバッグツール拡充して！
- ツールがないとテストってすごい時間かかるのです
上記のことを対応していただかなくとも、すっごい時間をかけて超網羅的なテストをすればなんとかなります。
が、お願いしたことを対応してもらえると、QAの時間(=コスト)はざっくり1/5ぐらいになります。
そして、それに伴い、QAをすることで発生する仕様確認とか開発サイドにも一定かかるであろう負荷がなくなります。
ということで、QAが楽になるためだけでなく、QAもENもWin-Winになれるのでは…と考えています。
ENとQAがお互い幸せになるために
ということで、両者それぞれの想いがあるわけです。
そしてその想いは特段間違っていないと思います。
ですが、みんな忙しい。わかっていてもできないのです。
序盤で『適切な粒度でのテスト設計についての意思疎通の難しさ』に対して
どうしようもない、と書きましたが
改めてこの件はとても奥が深くて難しいと思います。
また、状況・環境・担当者によって条件が違いすぎることもさらに難しくさせています。
ですので、意思疎通すべきことを変えたほうがよいと思っています。
今から当たり前のことを書きます。
ゴール(製品/サービス)に対しての共通認識を持ちませんか？
『これは版元が絡むから絶対不具合を出してはいけないんだ。細かく見てくれ』
『これは世界感が大切なんだ。特にキャラ設定周り。だからそういう品質担保をしてほしい』
『いま運営費用が厳しいんだ。リスクが高いところを重点的に見てほしい』（←これはQAとしては慎重に検討を！)
ゴールの認識があえば、テスト設計もテストケース作成も、またレビューの仕方も認識があいやすくなるはず。
QAとして気を付けなければならないのは
『いつもこういうQAやっているから』と定型業務をしないこと、
『QAとはこうあるべきだ』と意固地にならないこと。
いやいや、そんなこと普通言わないでしょ？と思うかもしれませんが
こういう固定概念を持っている方をそれなりに見てきました。
ので、常に意識をしておきたいものです。
仮にゴールの認識が合ったとします。
ですが、みんな忙しい。わかっていてもできないのです。(再掲)
他にもやることがある中で優先度があがらない。
今からかなり難易度が高いことを書きます。
品質も評価基準にいれてください
最初に質問したエンジニアさんが言いました。
『理想はあれど、人間評価に関わることじゃないとそんな動かないから、開発の評価基準に入れるみたいなことしないと余力ある人しか動けんよね』
そうですよね。そうですよね。
やっぱり見返りも大事ですね。
実は過去、とある開発部門の半期目標の一つに、障害削減・QA費用削減が入ったことがありました。
その時の進み方はすさまじかったです。
そして一度それをやってみると、QA/ENで連携強化するとお互いメリットがあるんだなと体感し、
評価に入っていなくても連携を強めてくれる方がいます。
なので、えらい人、まずは半年でもいいので評価基準に入れることをご検討ください。
でも、これはけっこう難しいことだとは思うので、すぐに叶えられなくてもQAの人は諦めないでください。
ENに依頼するときは、それを実行することで将来的に減るであろう工数を具体的に共有して、優先度を高めてもらいましょう。
（私の感覚だと、ENには、将来的に減るENの工数で、PMには、将来的に減るであろう外注費などのコストが一番効果がありそうだなと)
さいごに
このアドベントカレンダーに参加しているのは、みなQAです。
なのでQAに関することを色々書いています。(当たり前か)
ですが、QAは1セクションにすぎません。
QAができることは所詮限られています。
そして一緒にモノづくりをする各セクションの人々にも事情や思いが色々あるかと思います。
QAがどうだから、ENがどうだから、という言い分は一旦置いといて
一緒にどこに向かっているのかを明確にしたうえで、Win-winになる方法を探していきたいですね！
メリークリスマスイブ！