Movatterモバイル変換


[0]ホーム

URL:


freee Developers Hub

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

トップ>Advent Calendar 2025>転職1年目のQA活動記 - 経験を活かし、新たに学んだこと

転職1年目のQA活動記 - 経験を活かし、新たに学んだこと

こんにちは。freeeサインでQAエンジニアをしているmatsujunです。

freee QA Advent Calendar2025 16日目です。

転職してから、ちょうど1年が経ちました。

この1年を振り返ると、「前にも経験したな」と思う場面と、「これは初めてだな...どうしよう」と戸惑う場面が交互にやってきて、毎日が今までにない刺激を多く受けた1年でした。長年、QAエンジニアとしてキャリアを積んできましたが、まだまだ学ぶことは多いなと感じています。

この記事では、転職1年目にやったことと、過去の経験がどう役立ったか、そして何を新しく学んだかを書いていきます。

これまでの経歴

これまでの経歴の一部を紹介します。

第三者検証会社(2017-2021年)

案件相談窓口として顧客折衝を行いながら、テスト領域の提案や見積作成、テスターへの指示や進捗管理など、いわゆるテストマネジメントを経験しました。また、インプロセスQAの導入やQA組織の立ち上げも経験し、テスト体制を作るところから、オフショアチームとの連携まで、ゼロイチで体制を作る難しさと面白さを味わいました。

この時に身につけた「何もないところから体制を作る力」と「複数のステークホルダーを調整する力」は、今でも役立っています。

QA責任者・PdM(2021-2023年)

次はビジネスメディアの会社に転職しました。QA責任者としてQA組織立ち上げを行いました。

プロダクトの成功に直接関われる立場でのQA活動は、品質に対する責任の重さも、やりがいも大きく異なりました。カスタマーサポートもQA組織が中心となり対応し、ユーザーの声を元にプロダクトを改善し体験向上に寄与できたのは、良い体験でした。

また、BtoBプロダクトのPdMとしても活動する機会を得ました。要求・要件の整理、開発リソースと優先度の調整、潜在要求の具現化など、ビジネス視点でのプロダクト開発を経験したことは、QAエンジニアとしての視野を大きく広げてくれました。

転職サイト運営企業のインプロセスQA(2023-2024年)

転職直前の1年は、転職サイト運営企業でインプロセスQAをやっていました。プロセスの異なる2チームを担当し、リリース前テストの整理、開発とQAの品質責任範囲の定義、リリース判断基準の策定などを行いました。

スクラム開発におけるセレモニーの役割見直しや、PdM・デザイナーとの分業体制の再設計など、プロセス改善に注力した1年でした。

転職1年目でやったこと

現職には「freeeサインのQAオーナー」として入りました。freeeサインはM&Aでfreeeにジョインしたプロダクトで、全社標準のプロセスに完全には沿っていないという独特の状況がありました。そんな中で、1年間でやったことを書いていきます。

テストプロセスの標準化と体制作り

まず取り組んだのがテストプロセスの整備です。長年協力いただいている業務委託のQAエンジニアの方もいましたが、テストを依頼するためのルールが曖昧で、品質のばらつきにつながっていました。

そこで、以下のように標準プロセスとの差分を洗い出して、少しずつ修正していきました。

タスク 標準プロセス freeeサインプロセス
開発情報キャッチ チーム内でQA実施判断 依頼型でテスト実施
→標準プロセスに準拠
開発内容理解/仕様把握 要求・要件定義書・開発設計書を元に仕様把握 チームの活動を通じて把握
→要求・要件定義から参加
テスト計画書の発行・作成 標準フォーマットで作成 独自フォーマットで自由に作成
→ 標準プロセスに準拠
リスク洗い出し ステークホルダー全員でリスク洗い出し会を実施 決められた形式はなくQA担当もしくはチームで任意に実施
→標準プロセスに準拠
テスト設計・実装 テスト管理ツールを利用し、テストチャーター単位で実装 スプレッドシートを利用し、テストケース単位で実装
→標準プロセスに準拠
テスト実行 テスト管理ツールを利用し、実行スプレッドシートを利用し、実行
→標準プロセスに準拠
テスト完了 プロジェクトの振り返りを実施完了報告のみで終了
→状況に応じて振り返りを実施

標準プロセスと異なる点はありますが、個人的な方針として、後工程でのコストを減らすために上流への関与をより強くしており、要求・要件定義から参加し、場合によっては要件定義書をQAエンジニアが書く場合もあります。

同時に、業務委託QAのリソース調整や作業依頼の体制も整えました。テスト内容を明確に整理して、適切なタイミングで適切なリソースを使えるようにしました。

全社標準化は単なる「ルールの統一」ではないということを念頭に、プロダクトの特性を理解した上で、標準の意図を汲み取って、うまくカスタマイズする柔軟性が必要でした。

E2Eテスト自動化

freeeサインにはSeleniumベースのE2Eテストが自発的に導入されていましたが、統一された実装方針がなかったため、全社標準であるPlaywrightへの移行を進めました。

過去にE2Eテスト自動化は経験していましたが、ノーコードツールを使っていたため、コードベースのE2E実装は初めての挑戦でした。

環境構築から実装まで未経験の領域でしたが、すでに導入が進んでいる他プロダクトのサポートを受けながら、プロジェクトとして立ち上げることができました。

まだE2Eに頼れるレベルには達していませんが、実装すべきシナリオを洗い出し、目標を立てて推進しています。

AIとの格闘

一番チャレンジングだったのがAI関連です。プロセス改善での活用を研究したり、プロダクトに組み込まれるAI機能のプロンプトチューニングをやりました。

プロンプトチューニングからAI機能のテストまで一貫して担当しましたが、思うような出力にならないことや、あるべき期待値をどう定めるかなど、苦労することも多かったです。

例えば、AIによる契約書からのキーワード抽出機能では、日付を推測する部分の調整が難しく、何度もプロンプトの調整を繰り返しました。「2024年4月1日」のような明示的な日付は正確に抽出できるのですが、「n日前」のような相対的な表現の解釈が不安定で、契約書の文脈を考慮したプロンプト設計が必要でした。

モデルごとの出力の傾向を調査して、選んだモデルがどういう学習状況なのかを対話しながら探るなど、非常に面白みのある取り組みでした。

過去の経験が活きた場面

もちろん、過去の経験が活きる場面もありました。

PdM経験

PdMをやった経験は、新しいプロダクトでも活きています。ソフトウェア品質だけでなく、プロダクト品質に目を向けて提案をするという機会は多く、ユーザーインタビューへの参加や要件定義の壁打ち相手など、他のプロダクトのQAエンジニアとは少し違う活動ができています。

プロセス改善経験

過去の経験パターンを元に、今のチームにはどのプロセスが適切であるか、全社標準に合わせるために、どこからやっていくべきか・何をやらずに柔軟性を持たすかなどは過去の経験を元に判断しました。そのおかげか、大きな混乱もなく少しずつ全社標準に近づけることができ、品質も安定してきたように思えます。

経験がうまく活きなかった場面

過去の経験が必ずしも役立つわけではないことも学びました。

QA組織の立ち上げ経験

QA組織の立ち上げは何度か経験していましたが、今回はすでにQAエンジニアが活躍している環境への参画でした。「ゼロから作る」経験は豊富でしたが、「既にあるものを活かしながら改善する」というのは別のスキルが必要でした。

過去の成功パターンをそのまま適用しようとすると、既存のやり方を否定することになり、一時的な品質低下や生産性低下のリスクがあります。

結局、「立ち上げてから改善」ではなく、「今の良さを活かしながら少しずつ全社標準に寄せていく」というアプローチが必要でした。

この経験から、「同じQA組織作り」でも、ゼロイチとイチから10では求められるスキルが全く違うことを学びました。

これからやりたいこと

1年の経験を経て、次の1年でやりたいことが見えてきました。

品質ビジョンとロードマップの策定

それなりに安定した品質を保てる体制にはなったので、次は「目指すべき品質の姿」を明確にしたいと思っています。品質と効率を両立するビジョンを策定し、それを実現するためのロードマップを描く予定です。

AI×QAの深掘り

既存プロセスをAIで効率化するだけでなく、AIだからこそできる新しい品質保証プロセスを構築できないか検証したいです。

品質文化の醸成

最終的には、「QAチームが品質を担保する」のではなく、「チーム全員が品質を意識する」組織にしていきたいです。

おわりに

転職1年目を振り返って思うのは、「経験を活かす」と「新しく学ぶ」の両立によって成長を実感できた1年でした。

特に印象的だったのは、同じ「QA組織作り」でも、ゼロイチとイチから10では全く違うスキルが求められるということ。過去の成功体験に固執せず、今の環境に合わせて柔軟にアプローチを変える重要性を実感しました。

QAエンジニアは、テスト技術だけじゃなくてコミュニケーションもプロジェクトマネジメントもビジネス理解も必要です。だからこそ、さまざまな経験が活きます。

freeeでは過去の経験を活かし、業務に活用する機会が多くあります。この先も、QAエンジニアとしてさまざまな領域に挑戦していき、キャリアの幅を広げていければと思います。

明日は、freee人事労務のQAエンジニアのalex-san が「Cypress vs Playwright」について記事を書いてくれます。お楽しみに〜!

よい品質を〜

検索
このメディアについて

freeeの開発組織を紹介するメディアです。freee Developers Blog、技術情報、イベント情報、エンジニア採用情報などを公開しています。

フォローして更新通知を受け取ろう

Follow @freeeDevelopers

引用をストックしました

引用するにはまずログインしてください

引用をストックできませんでした。再度お試しください

限定公開記事のため引用できません。

読者です読者をやめる読者になる読者になる

[8]ページ先頭

©2009-2025 Movatter.jp