freeeの開発情報ポータルサイト

新卒QAとして1年間やってみたことと見えてきた目標

こんにちは、BaaS(freee振込)でQAエンジニアをしているG2です。freee QA Advent Calendar2025 6日目です。 この1年間で新卒QAとして取り組んできた具体的な業務内容や、今後の目標として定まりつつある「なりたいQAエンジニア像」についてお話しします。

新卒QAのあるある

freeeに限らず、新卒でQAエンジニアというのは珍しいようで、社外のワークショップなどに参加すると、よく「なぜ新卒でQAに?」と聞かれます。社外の新卒QAの方にも共感してもらえたので「あるある」と言ってもいいはず...

私は大学在学中に会計アプリ開発のアルバイトをしており、エンジニアとして就職する道もありました。しかし、アプリ開発の経験を通し、お客様(バイト先の方)から「実際にアプリを使うお客様(エンドユーザー)のことを考えているか?」という厳しい評価をいただいたことをきっかけに、言われた仕様を実現し、最低限の機能を満たしているだけでは不十分なのだと考えるようになりました。というのもお客様の要求は変わり続けるものであり、実際に動くものを見て初めて詳細な要求が浮かび上がってくることも珍しくないからです。

この経験から、お客様とのコミュニケーションを密にし、共にプロダクトの価値を作り上げていくことに大きな楽しさを感じ、「お客様の近くで働きたい」と強く思うようになりました。

その後、freeeのQAインターンに参加し、それまで私が行っていた業務が「QA」という一つの職業として成立することを知り、新卒QAエンジニアとしてのキャリアをスタートさせました。

入社後の取り組み

4月からの8ヶ月間で印象的だった内容をいくつかピックアップしてみます。

配属、最初の壁

入社後、新入社員全体向けの研修が終わるとすぐにQAエンジニアとしてBaaSチームに配属になりました。その間わずか1週間。 昨年であればQAもEngに混じって3ヶ月間の開発研修を行っていたのですが、今年からはよりQAとしての専門性を重視し、OJT形式に変更になりました。

開発知識や社内ツールへの理解もそこそこに配属されたことに対して多少の不安はありましたが、それ以上にQA業務に早くから携われることが嬉しかったのを覚えています。

さて、ここで少しBaaSチームについてご紹介させてください。

BaaSチームが提供するfreee振込は、GMOあおぞらネット銀行と連携してインターネットバンキングを介さずに、請求書の振り込みや給与振込などを一括・効率的に行うためのサービスです。 corp.freee.co.jp

配属時点ではまだプレスリリースもしておらず、機能開発もそれほど進んでいないという状況でした。そしてこれが私にとって最初の難関となったのです...

開発初期段階だったので、まだ機能の仕様が完全には固まっていない状況でした。そのため当時のBaaS QAが行うテストはフロントエンド操作からの機能テストではなく、(基本的に)仕様が変わることのないAPIをテストすることがほとんどでした。*1 後から変更される可能性のあるものをこの段階でテストしても二度手間になってしまう恐れがあるからです。そのような背景もあり、私がQAとして初めて実施したテストもAPIテストでした。しかし、私はそれまでAPIに関して大した知識もなく、テスト以前に大きな問題を抱えている状況でした。

そんな中、私のメンターをしてくださっていた24新卒QAのtonchanがかなり丁寧に(環境構築の時なんかは1日中隣で作業を見ていただいたりもしました)作業手順を教えてくださいました。そのおかげもあり、なんとか最初の難関を乗り切ることができたのでした。

初めてのプロジェクトアサイン

5月になって新しい機能開発が始まったのでその機能のQAを一通り私が担当することになりました。一通りというのは、BaaSチームで取られているQAプロセスの全体を指します。*2

当然と言えば当然なのですが、これがまたかなり難しかった...

まずテスト分析を行う過程で開発仕様のキャッチアップを行うのですが、これがわからない。具体的には会計用語について知らないものが多くそもそも仕様に記述されている内容の意味がわからない、という内容です。さらに私が初めて担当したプロダクトはBaaSサービスだけでは完結せずに、freee会計とかなり強い結びつきを持っている機能でした。そのため、テスト分析を行うためにはBaaSのサービスだけを理解するのでは不十分だったのです。

自分のプロダクトの仕様を把握するだけでも難しいのに、他のサービスのことまで追いきれない...とその頃は思っていました。

そんな中途半端な仕様理解のまま、テスト分析を行ったのですが、当然のように考慮漏れがボロボロ出てきます。そして、その負債は主にテスト設計の段階で明らかになります...

さて、ここでBaaSチームのテストプロセスについて少し補足させてください。BaaSチームでは、テスト分析・テスト設計の成果物をGitHub上で管理しており、PRを通してレビューを受けるという開発チームと同様のフローを採用しています。そのため、自分の成果物に対するフィードバックがすべてコメントとして残り、振り返りや学習に活用できるというメリットがあります。

初めてのテスト設計PR。コメント欄には75件の会話(conversation)があり、レビューでの指摘が多いことが示されている画面キャプチャ。
初めてのテスト設計 あまりにも抜け漏れが多く、conversationが脅威の75に...

こちらは初めて作成したテスト設計のPRなのですが、あまりにも指摘箇所が多すぎる。

さらにはいただいたコメントに対して即時での回答ができないことも多々ありました...

"GitHubのプルリクエストのコメント欄の画面キャプチャ。レビュアーからの質問に対して、筆者が即時での回答ができていない状況を示している。
PRレビューの様子 質問いただいてから答えを出すのに時間がかかってしまった...

このようなこともあり、PR作成からマージまで3週間以上かかってしまっていました。今振り返ってみると、かなりチームのレビュー負荷を高めてしまっていたな、と思います。 ただ、このようなレビューのプロセスを繰り返すうちに自分に不足していた視点が何であるのかが段々見えるようになってきます。自分の場合は主に以下でした。

  1. 外部サービスの実装に関する内容

  2. 詳細な実装に関する内容
    ・どのタイミングでDBにレコードが作成されるのか など

  3. 単体テストの実装を確認できているか

特に印象的だったのは3つ目の単体テストの実装を確認できているか、ということです。単体テストで確認されている内容を再確認するのは二度手間になってしまうため、基本的には確認する必要はない*3ということをレビューを通して教えていただきました。

当時の私はQAがEngの実装を見ることは基本的にないものと思い込んでいたのでこれにはとても驚きました。 ただ、チームのQAの方はそれが当たり前かのようにEngの実装の確認をした上で、テストケースを考慮することで、フィードバックにかかる時間の短縮を実現されていました。その姿が私の目にはとてもかっこよく映り、自分も実装を理解できるようになりたい、ひいては自分でも実装をできるようになりたいと考えるきっかけになりました。

このようにレビューコメントを通して自分に不足している観点を補いながら、テスト分析、テスト設計、テスト実装・実行という一連の流れを5ヶ月ほど(10月頃)繰り返しました。今ではPRなどでコメントをいただきながら標準プロセスの自走がある程度できるようになれたかな、と思います。(そう思いたい...)

現在の取り組み

リグレッションテストの自動化という文脈で単体テストやapi test、E2Eテストの拡充に取り組んでいます。 主な作業内容は以下の通りです。

  1. QAで作成したテストチャーターをもとに自動テストで担保すべきCUJに該当するものをピックアップ
  2. ピックアップしたものに対して、テストしたい内容を細かく切り分け、テストサイズを策定する
  3. 2で抽出したものがすでに実装されているのかを確認
    ・実装がない場合は追加する

この作業がすごく楽しいんです...!
先ほども少し触れましたが、私は実装のできるQAになりたいと考えています。実際にコードを書きながらテストを拡充していく作業は、まさに私がやりたかったことそのものであり、日々やりがいを感じながら取り組んでいます。

このタスクに私がアサインされた経緯についても少し触れさせてください。
私は普段から自身の希望を周りの先輩やJM / AJM*4に伝えるようにしています。「実装のできるQAになりたい」というのもその一つです。そんな中でリグレッションテスト自動化のタスクが出てきた際に、メンターのtonchanが真っ先に私に勧めてくださいました。日頃から私のことをよく見てくださっていて、成長したい方向性を理解した上で背中を押してくださったtonchanには本当に感謝しています。

freeeには、メンバーの「やりたい」という気持ちを大切にし、たとえ経験が浅くてもチャレンジの機会を与えてくれる文化があるように感じます。それは、困ったときにはすぐにサポートしてもらえる環境があってこそ成り立つものです。このような環境で働けていることは、新卒として本当に恵まれていると感じています。

見えてきた目標

この8ヶ月間を通して、自分がなりたいQAエンジニア像が少しずつ明確になってきました。 それは実装もできるQAエンジニアになり、品質に関わる全開発工程にQAとして早期から関わることで確実な品質の作り込みを行うことです。

BaaSチームで働く中で、実装を理解した上でテストケースを設計する先輩方の姿を見て、その重要性を強く感じました。実装を理解できれば、より効率的で精度の高いテスト設計ができる。さらに自分でテストコードを書けるようになれば、チームへの貢献の幅も大きく広がります。

もちろん、QAとしての基本的なスキル(テスト分析・設計・実行)をさらに磨いていくことも欠かせません。ただ、それに加えて実装力を身につけることで、より価値のあるQAエンジニアになれると信じています。

来年は現在取り組んでいるリグレッションテスト自動化の経験を活かしつつ、さらに実装スキルを伸ばしていきたいと考えています。具体的には、単体テストやAPIテストを自分で書ける範囲を広げ、ゆくゆくはプロダクトコードのレビューなどでも貢献できるようになることが目標です。

まとめ

新卒1年目は、右も左もわからない状態からのスタートでした。APIって何?会計用語って何?という状態から始まり、チームの皆さんに支えられながら、なんとかここまで来ることができました。

まだまだ未熟な部分も多いですが、実装もできるQAエンジニアという目標に向かって、一つずつできることを増やしていきたいと考えています!

最後まで読んでいただき、ありがとうございました!

明日は、freee販売とfreee工数管理のQAエンジニアの tomi-san が「『もし、あの時知っていたら…』を無くしたい。Gemと勉強会で築く、チームの「確かな知識」について記事を書いてくれます。お楽しみに〜!

よい品質を〜

*1:これはfreee社内でもかなり珍しく、バックエンドに強いQAが集まっているBaaSチームの特徴の一つかと思います。

*2:QAプロセス:[新卒QA奮闘記:ひとりでQAプロセスを完走して見えたもの] 新卒QA奮闘記:ひとりでQAプロセスを完走して見えたもの - freee Developers Hub

*3:重要な機能の場合、単体テストで確認した内容でもQAとして再度確認することはあります

*4:自身の上司に当たる方をJMと呼んでいます