こんにちは、転すけ（てんすけ）です。
以前にこちらの記事で、
スマホゲームのQA（デバッグ、テスター）としての業務を開始して数ヶ月後、そのあたりで直面しがちな課題感についてお話しさせていただきました。
今回は、QA（デバッグ、テスター）で少し慣れてきた頃、
単調なデバッグ業務からの脱却を図るために重要な観点や取り組みについてお話しをさせていただきます。
・QAとしての仕様把握への取り組み
- 開発の流れ
- QAとして必要な取り組み
- 他チーム（プランナー/デザイナー/ライター/エンジニア）との連携
・QAとしての不具合への取り組み
- QAとして必要な取り組み
QAとしての仕様把握への取り組み
まず単調なデバッグ作業から抜け出すためにすべきことですが、
・「単純にテスト項目に沿ってチェックをする」というスタンスから離れる必要がある
・「この機能はどういった仕組みや仕様なのか」というのを理解する
・「その仕様になるに至った経緯は何なのか」についても理解する
という観点を加味した上で業務を進められるようになる必要があります。
初動段階では右も左もわからない状態なので、
テスト項目に書かれていることをベース（絶対の正）としてチェックを進めていたと思います。
ではこのベースとしていたテスト項目はどのように作られたのかについてですが、
プランナーが作った仕様書を元に上記観点を理解した上でQAチームが作っているものとなります。
そのあたりについて、
どうやってテスト項目が作られるまでに至っているのかという点を、
上記観点が必要となる理由を交えつつ、以降の記述で順を追って説明していきます。
開発の流れ
ここで、テストに入るまでの流れをわかりやすくするために、
おおよその開発チームの過程を以下に記載します。
①プランナーが新しい開発要件を決める
↓
②プランナーがエンジニアやデザイナーなどと実現性の可否などを話し合う
↓
③プランナーが上記までを加味して開発要件を仕様書としてまとめる
↓
④エンジニアやデザイナーなどが仕様に問題がないか仕様書をチェックする
↓
⑤問題がないことを確認したらQA側でも品質的な観点で仕様書をチェックする
↓
⑥問題なければ仕様書がfix
↓
⑦仕様書をもとにエンジニア/デザイナーが開発に入る
と同時に、
QA側でも仕様書をもとにテスト項目の作成に入る
↓
⑧エンジニアなどが開発中に何らかの不都合が出た場合、プランナーの判断で仕様を変更する
（変更は比較的頻繁に起きる）
↓
⑨QA側で仕様の変更に合わせてテスト項目を修正する
↓
⑩エンジニア/デザイナーの開発が完了
↓
⑪QA側でテストを開始
QAとして必要な取り組み
上記がおおよそのテスト開始までの流れとなりますが、
QAチームとしては仕様書の作成段階でQA的な目線でチェックを入れ、
「起き得る不具合」「ユーザビリティ」などへの懸念をプランナーへ伝えます。
・ここにボタンAを追加することで、元々あったボタンBが押しづらくなるように思う
・1つの画面にボタンなどのUI要素が多く、雑多でわかりづらいと思う
・ボタンAの遷移先を変えると他の画面でも使っているボタンに影響があって危険だから止めた方がいいと思う
などといったようなフィードバックを行い、
事前に不具合発生の可能性やユーザービリティ欠如の可能性などを下げておくことが目的です。
こういったフィードバックを行うためには、
「こうあるべき」というQAとしての意見、個人的な考え方、ユーザー目線、一般論など、
そういったことを加味して考えをアウトプットできるようになる必要があります。
つまり「テスト項目に書いてあることを単純にやる」というスタンスでは「こうあるべき」という考えがないので、
フィードバックを求められても期待に沿うことは難しい＝単純作業からの脱却は難しいということになってしまいます。
常に「なぜ」や「こうあるべき」というように思考停止とならない進め方が重要になります。
この段階ではまだテストの実施がメインで、テスト項目の作成は任されていないかもしれませんが、
同じテスト実施者でもこの考え方を持ってテスト項目をやっているのか、
何も考えずにテスト項目をやっているのかでは意味が大きく違います。
その後にテスト項目の作成を担う事になった場合でも役に立つ考え方なので、
成長の伸び方が変わってくると思います。
テスト項目は仕様書をベースにしつつも、
項目作成者の「なぜ」や「こうあるべき」が形になったものなので、
繰り返しとなりますがQAは「なぜ」や「こうあるべき」を突き詰めていくことが重要です。
（仕様書に書いてあることや或いは他の人が作ったテスト項目に対しても同じことは言えて、基本的にはそれを正とはせず、個人的におかしいと思ったらフィードバックする姿勢が大事です）
これを踏まえつつ、
テスト項目書のベースである仕様書を見て、
構造や思想を理解しながら本質的に仕様を把握しながら進められることができれば、
視野がだいぶ広がると思いますので、
そうなった際には次のステップは近いと思います。
他チーム（プランナー/デザイナー/ライター/エンジニア）との連携
テストについて、
仕様書をベースに作成されたテスト項目で行なっていることは分かったと思いますが、
⑧⑨のような仕様の変更に合わせた修正事項というのも頻繁に発生するので、
プランナーやエンジニアなどと常に連携して情報共有ができている状態を作る必要があります。
この点、プランナー→エンジニアへの共有は早くてスムーズだが、
下流工程のQAチームへはしっかり共有できていなかったと言うようなケースも少なくはないです。
「共有を漏らした人が悪い」のような他責にするスタンスではなく、
「情報をキャッチアップしていなかった側も悪い」と言う考え方があることも事実なので、
自チームのみならず、他チームの情報も常にキャッチアップして積極的に介入していく姿勢が重要です。
（前提、共有漏れは基本的にアウトです。ですが、他責にするスタンスでは物事は解決せず、お互いの心象も悪くなるだけなのでメリットがないと言う意味ですね）
QAとしての不具合への取り組み
QAの目的ですが、
まず最低限のラインとしては不具合が限りなく少ない状態でリリースさせることです。
言い方を変えるとユーザーが何の支障もなくプレイできる状態でリリースするという事になります。
（もっと高いラインで言うと、不具合はゼロで且つ、品質全てに対する保証がクリアされている状態であるべきですが、今回は最低限のラインということでお話します）
その不具合を限りなく少なくするという事を念頭に業務を行えているかはとても重要なポイントになります。
QAとして必要な取り組み
QAチームによるテスト項目を使った検証は「不具合がないかどうか」を検知するためのものですが、
そもそも検知自体はテストが始まってから検知し始めるものではなく、
テスト前から検知して未然に防ぐこともでき、またその点が最重要であったりします。
先ほど開発の流れを説明させていただきましたが、
プランナーが仕様書を作成する段階や或いは修正する段階で、
QA側からの指摘により、その時点で考えうる不具合の発生可能性を下げることが可能というお話をさせていただきました。
PDCAサイクルで言うところのPの部分の介入するようなイメージで、
上流工程に早い段階で介入することが不具合抑止に最も効果的となります。
役割上、「不具合はQAチームで検知するものである」というイメージがあると思いますが、
それは組織として悪い考え方で、
上流工程に一切介入せずに下流で待ち構えて、来た球を打ち返すようなスタンスのQAチームの場合、
確実に不具合は撲滅できないと言えます。
エンジニアの意見：開発はしっかりやった。不具合については見つけられなかったQAのせい（他責）
プランナーの意見：QAが不具合を検知できなかったのが悪い。QAで何か対策を立てるべき（他責）
QAの意見：やれることはやった。QAチーム単体で立てられる対策はない。（対策がないので、次は気をつけますという曖昧な状態）
のような構図になりがちです。
つまり、次回も恐らく同じような事になるというのが目に見えますね。
これでは不具合はいつになっても無くなりません。
表面的な不具合は検知できても、
プログラムの深い部分にある不具合や、特定条件で稀に起こるようなレアケースの不具合は検知が難しいためです。
例えば発生率が1%の重篤な不具合（100回試して1回でるかどうかの不具合）があったとして、
テスト中にQAチームの数人で検知しようとしたところでマンパワー的に検知は非常に難しいわけですが、
リリース後に10000人のユーザーが一斉にプレイした場合100人程のユーザーで起きる事になるので、
かなりクリティカルな問題であると言えます。
クリティカルながらテスト中に検知は難しいとなると、QAチームだけでは対策は立てられないという話になります。
そこで、開発の段階でエンジニアリングで懸念点をカバーしておくということが重要になります。
仮に事前にQA⇔エンジニアでコミュニケーションを取っていたり、上流工程に介入できていれば、
「今の実装状況では、発生率はとても低いが重篤な事象が発生する可能性がある」と判明していた可能性もあり、
そこに対して不完全であっても何かしらの対策をエンジニアが打っておくことができる可能性もあります。
不具合について、
テスト項目を網羅することが不具合を検知→撲滅させる唯一の方法ではなく、
もっと早い段階で不具合をそもそも発生させない方法を取る事が一番効果的であり、
QA側からエンジニアを積極的に巻き込むアクションを取って不具合対策をすることが重要ということを念頭にしていただければと思います。
いかがでしたでしょうか。
今回は単調なデバッグ業務からのステップアップという内容でお話をさせていただきました。
この「ほぼ新人だが少し慣れたような段階」になると、
ただ検証項目をこなすことだけが目的になっていて、
仕様を深く理解することができていないまま進んでしまっていたり、
本来のQAの目的である不具合を撲滅するという事に対しての意識ができていなかったりします。
自分の意識一つでそこからの伸びやキャリアアップの可能性というのは大きく変わってくるので、
意識的に取り組んでいきたいですね。
尚、QA（デバッグ）を仕事にするにあたり、
デバッグ自体を突き詰めていくというキャリアプランもあります。
デバッグで年収400-500万を稼ぐことも十分に可能なので、
筆者の実体験を元にしたこちらの記事についても参考にしていただけますと幸いです。
