こんにちは、転すけ（てんすけ）です。
本日はIT業界でのステップアップにあたり、QA業務からスタートした場合の初動編というテーマでお話させていただきます。
以前にこちらの記事でQAからスタートした場合のキャリアアップのフローをご紹介させていただきました。
今回はスタートラインに立った直後の初動段階で行う業務やマインド周りについて具体的にお話させていただきます。
・QAで必要なマインド＝ステップアップ先で必要なマインド
・QAの初動段階で必要になる業務
- テスト項目に沿ったテスト
- 不具合レポートの作成
- その他（コミュニケーションツール）
QAで必要なマインド＝ステップアップ先で必要なマインド
まず最初にお話させていただきたい内容としては、
QAをスタートラインとして、1-2年後を目処にステップアップしていくということを推奨させていただいていましたが、
だからと言って「QAの業務自体はそこそこにやれば良い」という訳ではありません。
この役割でまずしっかり実績を出してアピールしていく必要がありますし、
後々のステップアップ先の選択肢を広げる為にも全力投球である必要があります。
また、注意点としては、QAは品質を保証するための役割ですが、
単純な「テスター（デバッガー）」にならないように注意が必要です。
QAは「Quality Assurance（品質保証）」の略であり、
役割の本質はその名の通りで「品質を保証すること」になります。
機能に不具合がないか否かのテストももちろん行いますが、
・そもそもその仕様自体に問題点はないのか（改善点やそもそもアウトな内容は含まれていないか）
・サービスの質としてどうなのか
・エンドユーザーに与える価値とこちら側の意図が合致するのか
・googleやappleのレギュレーションに抵触するリスクはないか
などのようにサービスの「質」の部分を常に考えている必要があるということになります。
上記が根底にありつつ、
・テスト要件を策定する
・テスト要件をテスト項目化する
・テスト項目に沿ってテストを行う
というようなテストを進めるイメージとなります。
・機能などが仕様通りに動作しているか否かをテストするための項目作成やテスト実施を行う
つまり ”プランナー等が策定した仕様＝正である” という考え方が念頭にあるので、
自分の中に ”こうあるべき” というものがない状態でただ単純作業を行なっていることが多いです。
また、この考え方から作られたテスト項目は、
「仕様通りかどうか」のテストはできても、
「品質に問題がないか」という観点は担保できないものとなるため、
テストの質としても低いものとなってしまうことが問題です。
上記のため、
質を上げるための「プラスアルファの気付き」を得る可能性が低いマインドと言えます。
端的に言うと、「QA＝考える業務」で「テスター＝単純作業」ということになります。
以前こちらの記事でも記載した通り、後者（テスター）は市場価値としては低いものになりやすいのでそういうマインドで業務を行わないように注意が必要です。
両者とも「テストを行う役割」という部分は同じであっても、
その考え方により全く成果の質が違うものになるので、当然評価や将来性の部分にも差が出ます。
とはいえ、
「機能の仕様やサービスの在り方をしっかり策定するのがプランナーの仕事じゃないの？」
「そこがしっかりできていればQA側でそんなこと考えなくてもいいのでは？」
という疑問もあるかとは思います。
スマホゲームアプリ関連はベンチャー系の企業で扱っていることが多いですが、
企業の急速な成長に人員側の成長が追いついていない状況も往々にしてあり、
策定するプランナーが全知全能の神のような方ならともかく、
そんな方はなかなかいらっしゃらない状況でもあります。
なのでプランナーと共に質を築きあげていくようなマインドを持っていることが大事です。
その点がむしろ自分にとってのアピールのチャンスになるという狙いもあります。
（その過程で、品質保証としての考え方や根拠を示して周りとコミュニケーションをすることで、信頼やアピールに繋がりますし、将来的に自分がプランナーのようなポジションに就いた際にもそのまま役立つ知識になるので、財産として大きいものになります）
QA業務で得るマインドは、
プランナー/エンジニア/デザイナーなど、どのステップアップ先であっても通用する考え方なので、
そういったマインドを磨く期間という風に捉えても良いと思います。
QAの初動段階で必要になる業務
単純なテスターにならずに品質を保証するという考え方を大事にするということはお伝えしましたが、
とはいえ完全未経験でのスタートの場合、初歩は必ずテスター業務ということになります。
つまりどれだけ早くテスター業務をものにして、品質保証の観点に目を向けられるかという点が重要になります。
まず「単純なテスト業務を行うテスター」から「QA」になる為の期間としては3ヶ月程度という目処を立てて業務に取り組むことをおすすめします。
（その為にどうすべきかということを逆算していくイメージですね）
とはいえ急いでは事を仕損じるということもありますので、
最初は兎にも角にも「丁寧に」という事を心がけてください。
テスト中に検知する不具合は、
ものすごく分かりやすいものもあれば、とても分かりにくいものも多く、
テスト業務速度を上げすぎると見落としが発生しがちです。
最初は寧ろ慎重すぎるくらいの速度感で行なって、
慣れてきたら徐々にペースを上げるようにした方が良いと思います。
（見落としで責められることはなくとも、信用や印象には関わるのでこの点は大事です。※質の伴わない速度は無意味）
また、もう一つ大事な事としては、
「同じことは繰り返さない」という点です。
「同じミスを繰り返さない」という意味合いもありますが、
本件はどちらかというと、
「すでにおおよそ理解している部分を同じように何度も反復するのではなく、なるべく新しい経験が積めるように広く色々実施する」
ということです。
（ここはチームリーダーとの交渉にはなりますが、チャレンジを悪く思うチームはベンチャーでは比較的少ないと思いますし、QAは比較的裁量を与えやすいので交渉はしやすいと思います ※そもそもチャレンジを許さない会社は成長しないですよね）
テスト項目に沿ったテスト
まず一番の基本はテスト項目に沿ったテストになります。
項目に書かれる内容は大枠で以下のようになります
- 実機で確認する表面的なテスト
- アルゴリズム（内部処理されている部分）のテスト
- イレギュラー操作に対するテスト
①は一番基本となる部分です。
実際に実機（スマホなど）で視認しながら確認していくものなので、
比較的未経験でも行いやすいテストとなります。
（例：〇〇というボタンが表示されているか / ボタンをタップして△△という画面にリンクするか・・・等）
②は少し難易度が上がります。
実機上では視認ができないようなアルゴリズム（内部的に行われている処理）についてのテストになります。
例えば最近のスマホゲームだとログインボーナスのようなログイン日数に応じて何か貰えるというようなものを良く見ますが、
・ログインしてからどのタイミングでログイン日数を加算するのか
・ログイン日数を加算した後、どのタイミングで報酬獲得の処理が走るのか
・ログイン日数に対して、ログインボーナスの報酬内容をどう判断するのか
・1日飛ばしてログインした場合にどういう処理を走らせるのか
などなど、
実機上では判断できないような部分で、内部的に一瞬で色々な処理が行われているものがあります。
これらはデータベースという「そのゲームのデータ全てが管理されているシステム」を用いて、
実機では視認できない部分を可視化してテストをします。
③は主に①や②の延長線上ですが、
スマートフォンを普段使っていると、電波が悪くなる、容量がいっぱいになるなど色々な影響を受けることがありますが、
そういった「色々な影響を受けた時にアプリの動作がどうなるのか」という観点であったり、
連打などの「ユーザーがふと行いそうな操作に対してアプリの動作がどうなるのか」というテストになります。
基本的な動作は①②で担保されるものの、
イレギュラーな要素が加わった状態でその動作が担保されなくなることも往々にしてあるため、その点に対してのテストとなります。
このあたりのテストを2-3機能ほど経験することで、
おおよそのテストの感覚というのは養われると思います。
（先にもお伝えしましたが、同じような機能のテストを反復しても経験が積めませんので、色々な事をやるように心がける必要があります ※大きい機能ほど大きな経験を確実に積めます）
不具合レポートの作成
テストを通して不具合を見つけた場合、レポートに纏めて報告する必要があります。
不具合は「原因があって発生しているもの」なので、その原因を明らかにした上で正確且つ漏れ無く不具合発生の起因を記載することが重要です。
基本的な体裁は特別なことはなく、5W1Hの情報が必要に応じて含まれていれば問題ないと思います。
※Who（だれが）When（いつ）、Where（どこで）、What（なにを）、Why（なぜ）、How（どのように）
よくある不具合のレポート例
（ボタンを連打したらエラーが起きたというケースの場合）
〇〇画面にて、
△△ボタンを連打した際にエラーとなった。
エラーコードの内容：××××××
※連打せずに通常に1タップした場合はエラーとはならない
※エラー発生後アプリを再起動したら進行可能だった
※昨日まではエラーにならなかったが、今日から発生した
△△ボタンをタップした際にエラーとなった。
↓
情報がこれだけの場合、
・まずどこの画面で起きたのかがわからない
・「タップ」としか書いていないので連打でなくても起きるニュアンスになっている
・エラーがどういう内容なのかわからない
・エラーの後どうなったのかがわからない
・いつから起きていたのかがわからない
読み手の事を考えて、漏れ無く且つ、なるべくわかりやすく簡潔にします。
それにより報告を受けた側が理解しやすくなるので、
余計な確認コストを減らすことが期待できます。
その他（コミュニケーションツール）
スマホゲームアプリ開発のような開発現場の場合、
ほぼ間違いなくチャットツールが連絡手段として使われています。
（主なツール：Slack / Chatwork など）
これらのツールの使い方に慣れると共に、
ツール内の各種チャンネルの使用用途を覚える必要があります。
（アプリ開発のようなプロジェクトの場合、チャットのチャンネルが膨大にあることがよくありますので、ざっと把握しつつ、まずは自分と関係性が特に強いチャンネルから覚えていくのが良いと思います）
また、
こちらの記事にも記載した通り、
チャットは特に即時性が重要になりますので、即確認即返信を心がける必要があります。
（反応速度も信頼値につながるので、早いに越したことはないと思います）
記載する内容については不具合レポート同様ではありますが、
読み手を考えて確認コストがかからないような内容や言い回し等に注意が必要です。
文章の場合、同じ文言でも複数の意味に取れてしまうようなものもあるので、意図がしっかり伝わる文章を心がけると良いと思います。
よくあるすれ違いの例
（○○という仕事をやる必要があるかどうかを聞かれて返答するケースの場合）
はい、やる必要がありますのでよろしくお願いします。
理由としては△△という理由があるためです。
ただし、そんなに時間をかける必要はないので最低限□□ができていれば問題ありません。
大丈夫です
↓
情報がこれだけの場合、
・”大丈夫” という表現は「必要」「不要」どちらとも受け取れるのでもう一度確認が必要
・必要だとしてもどの程度の成果物があればいいのかの擦り合わせもいる
コミュニケーションが取れないことが一番業務に支障が出るというのもありますし、
リモートを推奨している企業も多いので、
チャットツールでのコミュニケーションを迅速且つ正確にできるようになることはまず何よりも重要だと思います。
いかがでしたでしょうか。
今回はQAとしてキャリアをスタートさせた際の初動部分の業務やマインドについてお話しさせていただきました。
QA業務で培う「品質保証」の概念は、先々への財産になります。
プランナーであればそれを踏まえたサービス作りが必要になるのでQAのそのまま延長線上というイメージですし、
エンジニアにしてもその点は同じであると共に、自分でテストコードを書く必要もあるので、品質やテストの観点は重要になります。
尚、こちらの記事では、QAの業務を始めて数ヶ月後、少し慣れ始めた段階で直面する課題感について記載していますので、参考にしていただけますと幸いです。
また、QA（デバッグ）を仕事にするにあたり、
デバッグ自体を突き詰めていくというキャリアプランもあります。
デバッグで年収400-500万を稼ぐことも十分に可能なので、
筆者の実体験を元にしたこちらの記事についても参考にしていただけますと幸いです。
