こんにちは、DevBrandingのellyです。6月1日に配信した「品質を追及するfreeeの守護神、QAエンジニアのお仕事」の様子をご紹介します。
今回はfreeeに新卒として入社後、QAエンジニアとして活躍している2人と大ベテランがQAエンジニアの仕事・魅力・やりがいなどについて話してもらいました。
※感染対策をしっかり行った上で配信しました。
berry：写真左から2番目。2021年新卒入社。入社からQAチームに配属されて2年目。
kin-chan：写真右から2番目。2019年新卒入社。入社から2年間iOSエンジニアとして開発に従事し、QAチームに異動して1年目。
ymty：写真右端。2019年freeeに中途入社。業界歴としては30年近くのベテラン。
terara:写真左端。今回の司会。IAM（認証認可）チームエンジニア。好きな映画はSAWシリーズで、好きな食べ物はニンジン。笑いのツボが浅いので「げらら」とも呼ばれている。
QAエンジニアとは
―まずQAエンジニアってどんな仕事なのか簡単に教えてください。
berry:プロダクトを作ってリリースをする際に、安心して世に出せるように確認するのがQAの仕事です。具体的には、出来上がったプロダクトを触って、ちゃんとバグなく動くかどうかをテストするような活動がメインです。
ユーザーさんにももちろんバグがないものを使って欲しいですし、開発チームにもこれを世に出していいんだな、という安心感をもってもらうための最終確認をしています。
ymty:最終確認のためにテストをするんですけど、リリースする直前に最終確認をしてバグがあると困るんですね。直さないといけないし、すぐ直ればいいけどどうやって直せばいいか分からないとなると、リリースするタイミングが遅くなって迷惑がかかります。
最終確認するときにはもう問題なくOKで出したいわけですよ。どうやったらそうなるかというと、もう少し前の段階から確認するとか、何なら仕様書とか間違ってないかを見るとか、そういうところまでどんどん色々入り込んでいくといいQAになっていきます。
―いいQAエンジニアはプロダクトが出来上がる前のプロセスも重要視するんですね。
ymty:そうですね。そういうところから知ってれば、何でこの仕様なのかとか分かるから、テストするときもスムーズに出来る。何も知らないで最後だけ入ると、何でそもそもこうなっているんだろう...と悩みだして時間がかかるので、なるべく早い段階から入ったほうがいいと思いますね。最後はスーッとさせるっていうのが大事。
―QAのプロセスの中でここが一番重要だと思うところってどこでしょうか？
berry:自分が大事だと思っているのは、「リスク洗い出し会」というミーティングなんですが、開発に関わるPM、Webエンジニア、UX、セキュリティエンジニアなどを全員集めて、それぞれの観点から「ここが危ないんじゃないか」「ここを注意して開発したほうがいいんじゃないか」といったところを開発の序盤のタイミングで出し合うことによって、実際に開発を進めるときに注意ができるので、QAの活動にも役立っています。
ymty:リスクをちゃんと洗い出して、リスクを元にどれくらいテストするかを考えるっていうのをリスクベーステストって言うんですけど、特に海外欧米では2000年ぐらいからそういうテストの仕方をやろうって言うのが広がってるんですけど、日本では最近だと思います。freeeは結構先駆者なんじゃないですかね。
―kin-chanは元々モバイルエンジニアだったと思いますが、QAエンジニアとの業務の違いはどういったところですか？
kin-chan:そうですね、モバイルエンジニア時代はずっとコード書いてることが多かったですね。 それに比べて、QAエンジニアの仕事としては先ほどのリスク洗い出し会だったり、エンジニアが書いたコードに対するテストだったり、リリース後のバグが出やすかったところの振り返りだったり、仕様についてずっと考えていることが多いです。
―QAになることによっていろんな仕様、いろんなプロダクトのいろんなフェーズを見る機会があるんですね。どういうきっかけでQAエンジニアになりたいと思ったんですか？
kin-chan:元々プロダクト全体に一貫して関わって、全体をコントロールしていく、影の支配者みたいな感じになりたかったですね。（笑）
ymty:実はこの人がfreeeを支配してます、こう見えるけど（笑）
kin-chan:全体を見るという意味でいえば、PMのような上流の仕事で実際のデータを元にどんな機能を作るか企画するみたいなところも入ってくると思うんですけど、僕はより仕様だとかプロダクトが出来ていく段階に関わりたいと思ってQAを選びました。
―berryさんがQAの仕事をしていて面白みを感じる部分はどこですか？
berry:昔からゲームとかで遊んでるときに、バグ技とかを試してみたり再現したりするのがすごく好きだったんですね。何でバグ起きるのかな？、ここでバグ技出来るんだったら他の場所でもこういうことしたら起きるんじゃないか？みたいなことを考えるのが好きでした。
QAになってから考えてみると、プロダクトでバグが発生したときに、バグの発生原因はやっぱりコードのどこかにあるわけなので、ここにバグが入る要因があるねと話し合いができるのは、自分は一番面白いポイントだなと思ってます。
―ゲームのバグ技はどういうものをやってたんですか？
berry:一番はマリオ64DSという、バグの宝庫のゲームでしたけど、あれが大好物でしたね（笑）
―幼少期の頃からQAしてたんですね（笑）
berry:QA業務の中では、例えばWebページだと、ボタンを連打したり、別々の画面で同時に操作したらどうなるかというのを試したりしますね。
freeeのQAエンジニアの特徴
―freeeのQAエンジニアと一般的なQAエンジニアって何か違いはあるんでしょうか？
ymty:あまり明確には分からないですが、ベンチャー系のQAはfreeeのQAに近いんじゃないかなという気はします。QAっていままで部署がそれ以外の開発の部署と完全に分断されてることが多かったんですね。そうするとここまでやったから、じゃあQAさんここからお願いしますっていう、別の組織に依頼するという形になると思います。
freeeはそういう意味で言うと、かなり一体化してて、それこそエンジニアやUX、プロダクトマネージャーと同じチームの一員みたいな感じで仕事が出来るって言うのが、すごく好きです（笑）
―確かにチームが完全に別々に分かれてしまうと、プロセス的にも無駄が多いし、意思疎通しにくいところもありそうですね。
ymty:そうなんですよ。プロダクトが大体できてきた頃に「QAさんお願いします」となると、そこから「どういうものなんですか？教えてください」みたいな感じで説明に時間もかかるし、コンテキストをキャッチアップするのも大変ですが、最初からどういう仕様にするか検討している段階から一緒に出てると、すごくやりやすいというのがメリットだと思いますね。
ymty:自画自賛で申し訳ないんですけど（笑）freeeはエンジニアもみんなどういうものが作りたいかって思いがちゃんとあって作ってるから、そこに乗ってるとQAもその思いが分かって一緒に考えられるので、やりがい持ってできますよね。
QAエンジニアに求められるスキル
―QAエンジニアのキャリアを考えるうえで、必要な技術はありますか？
ymty:やはりテストのことはちゃんと覚えたほうがいいですね。最終的にQAはテストをするので、テストケースを書くためにどういうパターンを設計すればいいのかという技術であったり、覚えることはいっぱいあります。
あとは、さっき言ったようにどんどん前の工程まで入っていくとなると、どういう仕掛けで動いているのか、認証の仕掛けはどうなってるのか、仕様を決めるときも今どきのアジャイルのやり方だとユーザーストーリーマッピングについても知識があるといいですね。
けど、一番はじめにQAに必要なのは、さっきberryが言ったような、何でバグが出たかを調べていくというようなことなんですよね。そのノウハウがいっぱいあると、ある問題が起きたときにちょっと発想を変えればこういう問題も起きるかもしれないとイメージが出来ます。
それは現場でいろんなバグを調べていくのが一番いいんですけど、ソフトウェアとは関係ないですが、本でいえば失敗学とかを読んでみると単にソフトウェアじゃないけどこうやって人は間違えるんだ、という知識が溜まって、間違える瞬間にも気付くようになりますね。勘が働くようになります。
―まずはしっかりテストを覚えて、そこからソフトウェアエンジニアリングの基本的なところを覚えて、さらに経験していく中で勘を働かせていくということですね。
ymty:その通り！ソフトウェアエンジニアリングはちゃんと覚えた方がいいと思いますね。 エンジニアとチームで話してるときに自分だけ知らなくてエンジニアが知ってるとかだと分かんなくなっちゃうので、普通のエンジニアとQAエンジニアは違いがないって思うくらいちゃんと覚えた方がいいですね。
freeeのQAチーム
―kin-chanのメンターはymtyさんなんですね。普段ymtyさんとどのように関わっているんですか？
kin-chan:そうですね、優しく教えていただいています（笑）こんな感じでフランクに。僕は元々QAのことを何も知らずに異動してきたんですけど、良いQAとは？というところから教えていただいてますね。
―実際QAを長年やっている方から直接指導を受けれるというのは凄くいい機会ですね。berryさんはどうですか？
berry:自分は直接のメンターではないんですけど、社内でもymtyさんの資料を見て学ばせてもらったり、「QAのこの業務なんでだっけな？」と思ってネットで調べるとymtyさんが書いた記事出てきたりして、「これってどういう意味でしたっけ？」って本人に聞けるのがめちゃくちゃレアな体験させてもらってます。
―分かんないなって思ってググったら目の前にいる方の名前が出てくるってスゴイですね（笑）
berry:ymtyさんめちゃくちゃフランクな方で、軽く接してくれるのでそこも助けになってると思います。
―すごい照れてらっしゃいますけど（笑）
ymty:（笑）けどそれってfreee全般に言えると思いますね。freeeのカルチャーがいいと思ってます。
またfreee自慢で何の会なんだ？って感じだけど（笑）、あえ共（「あえて、共有する」というfreeeの行動指針のひとつ）みたいに自分の取り組みとか困っていることを広く発信して役立ててもらったり意見もらったりするところはすごいいいなって思うから、そういう風に自分もやろうと思ってますね。
視聴者からの質問
―いくつか質問をいただいているので読み上げていきます。「リスク洗い出し会ってどういう基準でやるんですか？ある程度の開発規模が出来た段階でやるべきなのでしょうか？」
ymty:基本必ずやっています。リリースする予定の案件があればリスク洗い出し会はやりますね。
ある程度大きなリリースだとしたら、まずは1回やっておいて、実際リリースするときって小出しにリリースしたりするから、小出しのところはリスクの内容次第で必要に応じてミーティングをセットしています。
最初のリスク洗い出し会で洗い出したリスクを追跡してゼロになったら一旦リスク洗い出し会は終わりで、そのあとは実際テストをしていくので、問題が起きたら起票するという感じですね。
あとはあんまり仰々しく構えないで、何かヤバイなって思うことをみんなでちゃんと言い合うって言うのが一番大きいと思いますね。
―「freeeの中で『ゆもつよメソッド』って使われてるんですか？」
ymty:使ってます。コソっと。
kin-chan:僕は知らず知らずのうちに（笑）使ってるって感覚はないのに、自然とって感じですかね。
―これいいプロセスだなって思って調べたら実はymtyさんの本に書いてあるみたいな（笑）いいですね。
freeeが求めるQAエンジニア
―最後に改めてfreeeのQAエンジニアに向いてる人ってどんな人でしょうか？
berry:好奇心を持ってこれやったらどうなるんだろうみたいなお話があったと思うんですけど、いろんな可能性を考えて、プロダクトに対してこういうことしたらどうなるんだろうとか、こんなことが起こったらどうなるんだろうだろうみたいな、ちょっとした悪さをしに行く（笑）というか、好奇心を持って付き合っていくようなスタンスが大事なのかなと思ってますね。
ymty:かっこいい言葉で言うと、好奇心とか想像力みたいなのって、freeeに限らずQAをやるんだったらすごく必要だと思っていて、コーディングする人はロジックを考えるのにすごく集中するタイミングが必要で、そのときにあんまり発想ばっかり広げていくとうまく集約されないことがあると思うんですけど、QAはどちらかというと常に発想を広げて、好奇心を持って物事を見る人がQAにはすごく向いてると思います。
―プロダクトに対する愛を感じますね。
ymty:そうそう、プロダクト好きだとすごくやる気出るからいいと思いますね。kin-chanもバグ見つけるの好きなの？
kin-chan:僕も好きですね（笑）
ymty:向いてる！向いてる！
この後も非常に多くの質問をいただき、とても有意義な時間となりました。
▶freeeではQAエンジニアを募集しています。ご興味のある方はぜひ気軽にご応募ください！
https://freeecommunity.force.com/jobs/s/detail/a4l1000000170iZAAQ
▶今回のイベントのアーカイブ（録画）
