こんにちは、転すけ（てんすけ）です。
以前にこちらの記事でスマホゲームQA（デバッグ、テスター）として参画した初期に行う基本業務についてお話しさせていただきました。
今回は、QA（デバッグ、テスター）としての業務を開始して数ヶ月後、
少し慣れたあたりに直面しやすい課題感等についてお話しさせていただきます。
- QAとしてのデバッグ業務への姿勢や懸念
- 慣れによる思考停止と怠慢
- コミュニケーションの課題
QAとしてのデバッグ業務への姿勢や懸念
QAという職種に限らずですが、
初動は何かと色々覚えることが多く、サクサクと仕事が進むことは少ないと思います。
そんな初動を少し乗り切り、
サクサクではないもののある程度業務に慣れつつある頃に生まれる問題があります。
それが「慣れによる思考停止と怠慢」と「コミュニケーションの課題」になります。
基本的な概念ではありつつも、
結局のところここのスタンスで全てが決まると言っても過言ではないと思いますので、
これまでの経験も踏まえ記載させていただきましたので参考にしていただけますと幸いです。
慣れによる思考停止と怠慢
初動段階で行うデバッグ作業というのは、業界未経験でも実行できるレベル感の内容が主であり、
比較的単調で難易度の低いものが多いので、一度やることさえ覚えてしまえば後は反復（つまり思考が停止した状態でなんとなく繰り返している状態）という事も往々にしてあります。
それにより、
「これがデバッグ作業か。余裕でできるな。」
と思ってしまう事もあるかと思いますが、
それは勘違いであり、その勘違いをしたままの姿勢でいると成長にも繋がりません。
当然、チームのリーダーもまだ能力や適正が明らかではないメンバーに対して、
高度な業務を依頼したりはしませんので、
まだ信頼を勝ち得てすらいない=まだスタートラインにいる状況であるということを理解する必要があります。
（新人に仕事を任せるのはリスクが伴うので、当然そこのリスクマネージメントも考えています）
この点、どんな職種であってもよくあることだとは思いますが、
QAについては以下のような傾向にあると思います。
- デバッグの初歩の業務というのは比較的他の職種に比べるとハードルは低い傾向にある
- ゲームデバッグ＝簡単というマインドを持って入社して軽いアルバイト感覚で行なっている人が多い
- 上記のマインドを同調させる人&同調しやすい人がいる風潮がある
- 上記のマインドを持っている（或いはそのような人に影響されて）初動段階で成長が止まる人も多い
こちらの記事を読んでいただいている方は、
ステップアップを目的として、先を見据えている方も多いと思いますので、
上記に当てはまらないようにマインドを強く持つことが重要になります。
ですが、裏を返せば、競合が自ら脱落しているというような見方もできます。
言い方は良くないかもしれませんが「できる人」「できない人」がハッキリと分かれていて、
「できる人（現時点で経験は浅いが将来性を持ったマインドの人も含む）」は圧倒的に少数です。
その点を利用して結果を出せばチャンスを掴むスピードが早いというのもQAの特徴です。
（成長曲線はそのスタンスの2分化で大きく差が出ます）
業務に慣れたのであれば、積極的に新しいチャレンジに取り組むという姿勢を速度感を持って繰り返していけば、自ずと先に進む道もまた速い速度で開けると思います。
（現に私もそういう実体験をしていますし、周りでもそういう方はたくさんいますので、自分次第でチャンスは掴めます）
コミュニケーションの課題
スマホゲームの開発チームにおけるコミュニケーションラインは多岐に渡っています。
大まかには、
「プランナー/デザイナー/ライター/エンジニア/QA」
というようなチームと役割があり、それぞれのチームとコミュニケーションを取っていく必要があります。
（それぞれの職種についてはこちらの記事の “ステップアップ先” の箇所で触れています）
そんな中、QAの初動段階では基本的に自分に与えられた業務を黙々とこなす形となるため、
相談などのコミュニケーション先はQAチーム内の人員のみとなることが主だと思います。
つまり、かなり狭い範囲内のコミュニケーションだったわけですが、
以降は積極的にプランナーなどの他チームとも積極的にコミュニケーションを取っていく必要があります。
一般的な企業など大きな組織の場合、
チーム間のコミュニケーションは各チームのリーダーが定期的に集まってミーティングをするような形式が多く、
何か他チームに相談がある場合もリーダーを通して疎通するというケースがよくあると思います。
一方、スマホゲーム開発等を行う主にベンチャーの企業では、
情報の動きや変化がとても早いという傾向もあり、
都度リーダーを通していては遅延が発生してしまうという事も往々にしてあります。
そのため、各人が主体的かつ積極的に他チームと迅速にコミュニケーションを取っていくことが求められます。
（大企業に比べると比較的人員が少ない傾向にあり、素早い決定をしやすい&小回りが効きやすいという点も理由の一部としてはもあると思います）
QAは基本的に開発の最下流の工程にいるので情報の伝達が遅れることもしばしばあります。
そのため、積極的に情報を取りに行く姿勢や、或いは伝達を促す取り組みが重要となってきます。
この「他チームとのコミュニケーション」の部分がQAにとっての障壁になることが多いので、
デバッグ能力だけに特化せず、コミュニケーション能力の部分も意識することが重要です。
（最終的にはコミュニケーション能力が高い方が有利に働くことも多いと思います）
QAチーム内の誰かを介す形をなるべく早く脱却して、
自分個人で開発チームと良い関係を構築していくことで信頼に加え、働きやすい環境づくりにも繋がると思います。
（逆にこの点ができないと、内弁慶のようにチーム内に留まったような存在になってしまい、他チームとの接点がない状態になってしまうので、将来を見据えると関係性の構築は重要だと思います）
特にエンジニアとのコミュニケーションを円滑にできるようになることは開発事項を正確に理解するために重要な点となります。
（仕様はプランナーが作るものの、結局それを作り上げるのはエンジニアなので、構造を一番理解しているのはエンジニアという事になります）
エンジニアと話をしていると、時に難しい専門用語や馴染みのない言葉が端々に出てくることも多いと思いますが、
初動段階だからこそ「知ったふり / わからないからなんとなく聞き流す」ということはせず、
わからないことは一つ一つ聞きながら話を進めましょう。
（聞くは一時の恥、聞かぬは一生の恥ですね）
エンジニアからの信用を得ることはとても重要です。
話をしていて「あ、理解してないな」というのは確実に相手に伝わるので、
それが起きると信用を損ない「この人に難しいこと言っても理解できないから端的な事だけにしよう」というコミュニケーションの仕方となり、深い話はできなくなってしまうわけです。
そういうコミュニケーションによって仕様の把握力が浅くなり不具合につながってしまうケースもあるので、最も気をつけるべき点として注意が必要です。
今回はQA業務に少し慣れ始めた頃に直面する課題を通して基本概念的な部分のお話をさせていただきましたが、
次の記事ではデバッグに慣れ始めた時期に気にして取り組んでいくべき「QA的な観点」のお話をさせていただいていますので参考にしていただけますと幸いです
