はじめまして！
株式会社HRBrainのQAエンジニア、＠Russianblue-sanです。
今回は、私がQAエンジニアに転職するまでの過程を振り返ってみたいと思います。
QAエンジニアになる前の、私の経歴
まず、私の経歴を振り返ってみましょう。
私はQAエンジニアになる前は、第三者検証の会社でQAテスターを約3年、QAチームのリーダーを半年以上、テストエンジニアを約1年経験して、合計で約150件のプロジェクトに携わってきました。
きっかけ
私がQAの世界に入ったのは偶然でした。
当時ゲームが好きだったので、たまたま見つけたゲームテスターの仕事に応募したのが始まりでした。
私がヘビーゲーマーだった頃、ネット掲示板でゲームテストの仕事がある事を知りました。
そこでは「壁にぶつかり続けるテストはあるのか？」等といった会話がされていて興味を持ったのを覚えています。
前職に入社してから実際に壁抜けテストがあるのを知りました、笑。
話を戻します。
面接で即採用されて、その週末からテスターとして働き始めました。
当時はソーシャルゲームが全盛期だったので、初めのうちはソーシャルゲームを中心にテストしていました。
最初は用意されたチェックシートに沿ってテストして、慣れてきたら早く正確にテストすることに集中しました。
上流工程に興味を持つ
入社して半年後には大きなプロジェクトに携われるようになり、アーケードゲームのテストを1年ほど行いましたが、これは楽しかったです。
ただ、その時に携わったプロジェクトは典型的なウォーターフォール型の開発で、問題が発生した時の軌道修正が困難でした。
詳細は書けませんが、ゲームの遊び方が、ユーザーがすぐに飽きてしまうようなもので、テストチームもそうした修正すべき点を認識していたのですが、開発チームに伝えても修正できませんでした。
結果、そのゲームはヒットせず、数年でサービスが終了してしまいました。
この経験が、開発チームに適切にフィードバックを行いたい思った最初のきっかけだったと思います。
コアテスター時代（エンドクレジットに名前が載る）
その後、あるソーシャルゲームのプロジェクトで暫くコアテスターとして働きました。
この時はゲームのエンドクレジットに自分の名前が載るという貴重な体験ができ、いい思い出になりました。
また、このプロジェクトでは、初めて自分でテストケースを作成しました。
この頃になると、テストケース以外の不具合の見つけ方（アドホックテスト、フリーテスト）など、自分なりのアイデアを出すことが楽しくなってきました。
また、オープンディフェクト（ユーザーからの問い合わせによる不具合）を再現し、開発チームに報告したときは達成感がありました。
次に配属されたプロジェクトは、開発の初期段階からQAが関与するプロジェクトでした。
このプロジェクトは、私のQAスキルを大きく向上させました。
開発直後で当然大きな問題が山積しているものをテストすることで、多くの問題を解決した後にどのような状態を目指すべきかを想像しながら仕事をするのは楽しく、自分のスキルアップにつながりました。
仕事に対するスタンスの変化
このプロジェクトの終盤、転職を考え始めていたのですが、同時期にCOVID-19が流行りだしたので、それどころではなくなってしまいました。
私が携わっていた案件と次にアサインされる予定だった案件がリスケジューリングされてしまい、主担当の案件がない状態が続いてしまいました。
しかし、これは私にとってよいきっかけになりました。
それまでは受け身で与えられた仕事をこなすという姿勢だったので、まずはそれを改善することにしました。
その成果はすぐに表れて、たまたま空いていたポストへの配置転換が決まりました。
SaaSとの出会い
COVID-19が一段落した頃、初めてSaaSのプロジェクトにアサインされました。
その頃にはゲームに対する情熱が薄れていたので、ゲームのプロジェクトはもう自分には合わないと感じていました。
それに対してSaaSのQAは、それまでのゲームのQAとは違うことを直感的に感じました。
SaaSの多くは明確な目的意識を持って作られており、そこに惹かれたのかもしれません。
そのため、私はすぐにSaaSプロジェクトのQAに夢中になりました。
QAチームのリーダーになる
SaaSのプロジェクトを沢山担当して不具合や要望を量産していたら、QAチームのリーダーを打診されました。
ゲーム以外にもQAの求人があることを知り、その業界への転職を考え始めていたので、良い経験になると思いQAリーダーを引き受けることにしました。
QAリーダーとしての半年間はとても忙しかったのですが、貴重な経験をたくさんさせていただきました。
テストケースの作成、テスト計画の作成と実行、テストメンバーの選定、10～20人のグループ管理、機材の準備、クライアントへの報告など、これまで経験したことのないものばかりでした。
最終的に私が担当していたプロジェクトはQAの外注をやめることになったので、私のQAリーダーの担当はそこで終了しました。
出向と転職
QAリーダーの担当が終わった直後に、ある外資系企業へテストエンジニアとして出向することが決まったので、これまでの経験を総動員した統括の期間にすることにしました。
同時に、私は本格的に転職活動を開始しました。
出向してから半年後、私はHRBrainに転職しました。
転職活動の振り返り
次に、私の転職活動を振り返ってみたいと思います。
転職活動の準備
QAエンジニアになるための転職活動で重視したのは、自分の経験と転職先の要件を一致させることでした。
テスターとしてのキャリアが長かったのですが、幸いにもテスト以外の多くの事を経験していたので、転職先の要求に応えるのはそれほど難しくはありませんでした。
なので、転職が自分にとってステップアップになること、それを受け入れてくれる環境であること、そして自分が経験してきたことを活かせる環境である事を、転職の条件にしました。
whyを明確にする
次に、転職の動機を明確にすることにエネルギーを費やしました。
QAリーダーを引き受けた時は、QAという仕事に真剣に向き合い、最終的にはQAチームが製品の品質を向上させたいと強く考えていました。
実際のところ、第三者検証の環境ではそれを叶えるのは難しかったので、開発側へ転職したいという強い動機になりました。
スカウトサービスの活用（兎にも角にもコミュニケーションが重要）
転職活動の前半は大手転職サイトを利用していたのですが、転職活動の後半から、企業から直接スカウトを受けるサービスを利用しました。
サービスに登録する際に、自分の考えや実現したいことを記載したところ、ありがたいことに多くの企業が私に興味を持ち、スカウトしてくれました。
多くの企業の人事担当者や現場のメンバーと面接をしましたが、彼らが求めているものと私が提供できるものが違うことが多々ありました。
そこで、可能な限り、人事担当者と現場担当者のそれぞれと面談を行いました。
人事の方は必ずしも仕事内容を熟知しているわけではないので、現場の担当者に実際の仕事内容を聞いてみるのが一番の方法でした。
HRBrainの選考は少し長かったのですが、カジュアル面談と現場担当者との一次面接、現場責任者との二次面接、技術責任者と代表取締役との最終面接という構成だったので、それぞれの面接官の考えを知ることができたのがよかったです。(今は少し簡略化されています）
QAエンジニアになって変わった事
さて、QAエンジニアになって変わったことを振り返ってみたいと思います。
開発サイドのQA
一番大きな変化は、開発サイドで直接、品質に対してアプローチできるようになった事です。
これを叶える為に転職したようなものですが、実際にエンジニアやPdMと直接コミュニケーションを取りながら仕事を進められるのは素晴らしい事です。
アジャイル開発
開発側でアジャイル開発に携わっているのも大きな変化です。
想像以上に意思決定のスピードが非常に速く、問題解決も早いです。
最初の頃は、チケットを作っている間に問題が解決していたこともありました。エンジニアと直接コミュニケーションをとりながら問題を解決していけるので、とても良いことです。
不具合検出時の対応
不具合を検出したときの対応にも変化がありました。
前職では、バグや要望を開発者に報告して終わりでしたが、今はエンジニアやPdMとコミュニケーションをとりながら、最終的にどうすべきかを考えます。
より良い製品にするために、どのように修正・改善するかというロードマップを作成するようなイメージでしょうか。
テスト自動化
また、テストを自動化するようになったことも大きな変化です。
転職してから初めて自動テストに触れましたが、回帰テストの大半を自動テストに任せていることに驚きました。前職でリグレッションテストを行う場合、数人で1～2日かけて行っていましたから。
なので、自動テストが失敗したときの調査やメンテナンスがとても重要です。
上流工程に参加
それと、開発の上流工程に携わることも変わった部分です。
現在進行形で私が取り組んでいることになりますが、ソフトウェアエンジニアが開発に着手する前に、QAエンジニアが問題点や対処すべき観点を洗い出すことが目標です。
現状では、QA確認が始まる前にエンジニアとテストポイントを共有することしかできませんが、上流工程から参加できるのはやりがいがありますね。
My Values
最後に、私がQAの仕事をする上で大切にしていることを書きます。
私はQAエンジニアは発想力、想像力が必要な仕事であり、自分の感性を信じることが大切だと考えています。
もちろん、テスト技術は必要だと思いますが、それに頼ってしまうとテスト技術や網羅性がテストの視点になってしまうので、私はそういった考え方は採りません。
むしろ、実際のユーザーが何を求めているのか、何をするのかを考えてテストを行うべきでしょう。
ほとんどの場合、QAエンジニアは完成品に最初に触れるユーザーですから、そのことを忘れてはいけません。
製品が完成するまでに様々なことが検討されますが、完成した製品に初めて触れたときの第一印象は非常に重要です。
つまり、ユーザー目線です。
この印象は、何度か触って慣れてくると薄れてきますので、臆することなく第一印象を正確にアウトプットし、開発メンバーに伝えることが重要です。
どんなに些細なことや違和感を、そこで感じたことの本質を見極めるために、開発メンバーに伝えることが大切です。
少し勇気がいるかもしれませんが、ここに問題があれば見逃されてしまいますし、そうなると実際のユーザーも同じことを感じる可能性があるので、結果的に開発チームに不利益を与えてしまうかもしれません。
テストによる品質管理だけでなく、プロダクトに適切なフィードバックを行い、より良い製品に改善していくことが、私がQAエンジニアとして仕事をする上で大切にしている価値観です。
おわりに
テスターやテストエンジニアをされていてQAエンジニアを目指している方や、QAエンジニアという職業に興味がある方の参考になれば幸いです。
最後までお読みいただきありがとうございました。