ITエンジニアの人材不足を背景にM&Aが増え、エンジニアにとっても「ある日突然、別の会社のメンバーと一緒に働く」経験が珍しくなくなりました。しかし、異なるチーム同士が1つになる時、品質の基準を揃えることは、そう簡単ではありません。既にある仕組みを活かしながら全社の品質標準へ引き上げていく──QAエンジニアがそんな「1→10」を担うシーンも増えつつあります。
今回取材したのは、M&Aでfreeeグループに加わった「freeeサイン」でQAオーナーを務めるまつじゅんさんです。
「テストは好きじゃない」と言い切るまつじゅんさんですが、20年のキャリアの中で初めて働いていて「うれしい」と強く感じた瞬間があったといいます。多彩な経験を積み上げてきたまつじゅんさんがfreeeで出会った新しい景色について聞きました。
freeeサイン QAオーナー/まつじゅんさん
個人事業主としてカスタマーエンジニアからキャリアをスタート。テレビ開発メーカー、Web制作会社、第三者検証会社などを経て、ビズヒント(ビジョナルグループ)でQA組織の立ち上げに従事。2024年12月にfreeeへ転職し、同年M&Aでfreeeグループに加わった「freeeサイン」のQAオーナーとして、品質の仕組みづくりとPdM業務を兼務する。
品質に不安がなければ、究極「テストはいらない」
― まず、freeeに転職された理由を教えてください。
個人事業主として関わった企業も含めてですが、実はfreeeは14社目なんです。最初はカスタマーエンジニアから始まって、テレビ開発メーカー、Web制作会社、第三者検証会社と渡り歩いてきました。直近はビジョナルの子会社のQA組織の立ち上げやPdM兼務を経験したので、次のキャリアでは大規模なQA組織がある事業会社に行きたいと考えていたんです。
その頃、前職でお世話になった方を通じてfreee QAマネージャーのymty(ゆもつよ・湯本 剛)さんを紹介してもらいました。QAエンジニアの人数が100人を超えるほど大きく、加えて、集まっている人たちのキャリアのバックグラウンドが多種多様なところに惹かれました。エンジニアからQAに転向した方、QAからPdMに変わった方など、いろいろな経歴の人が集まっている。自分のスキルをもう1つ、2つ、増やしたいと思った時に、この環境しかないなと。

― キャリアを積み上げる中で、ずっとQAを軸にされてきたのはなぜですか?
主な肩書は「QAエンジニア」ではありますが、本心を言うと、テスト自体は全然好きじゃないんですよ。テストって、不具合がないか、考慮漏れがないかという不安があるからやるものだと思っていて。その不安がすべて解消されていれば、究極テストはなくてもいいはずなんです。だから「テストしたくないから、テスト以外の領域でなんとかしよう」という発想で、どうすれば品質を高められるのか、ずっと試行錯誤してきました。
要件定義の段階から入って仕様の抜け漏れを潰していけば、後工程のテストは減らせる。カスタマーサポートの声をプロダクトに反映させれば、そもそも不具合として上がってくる問題自体が減る。
お客さまに良いものを届けて、使い続けてもらうための活動全てがQAだと捉えると、究極、企業経営すらQAだと思っています。QAの手段のうちテストが占める部分って実はほんの一部で、そのほかのエリアを開拓していく面白さが、続けている理由ですね。
freeeのQA組織には、テストだけに閉じずに、いろいろなことに挑戦できる雰囲気があると実感しています。自分がやりたいと思ったことに対して、「なぜやるの?」とは聞かれることはあっても、止められることはない。その自由度の高さは、大きな魅力だと思います。
freeeに来なければ出会えなかった「喜び」

「freeeサイン」サービス紹介資料より
― freeeサインのQAオーナーとして着任されて、まずどんなことに取り組みましたか。
freeeサインはM&Aで加わったプロダクトなので、もともと独自のやり方がありました。それをfreeeの全社標準に寄せていくのが私の役割ですが、ゼロからQA組織を立ち上げるのとは全然違う難しさがありました。すでにチームが回っている状態に入っていくわけですから、いわば「1→10」のフェーズですよね。
自分が何かを変えたことで「前の方が良かった」と思われるのは絶対にイヤだったので、今ある良いところはしっかり残しながら、少しずつfreeeの標準に近づけていくアプローチを取りました。

まつじゅんさんが実施した標準化と体制づくりの詳細(転職1年目のQA活動記 - 経験を活かし、新たに学んだこと - freee Developers Hubより)
お客さまに届けるまでの時間をQAのせいで遅くしたくないという思いも常に持っていて、小さいプロダクトには小さいプロダクトなりの、カスタムした標準があるべきだと考えています。
標準化は単なる「ルールの統一」ではなく、標準の意図を汲み取ったうえで、プロダクトの特性に合わせて柔軟にカスタマイズする。その判断ができたのは、様々な現場を経験してきたからだと思います。
― いきなり新しいオーナーが来ると、元のメンバーと軋轢が生まれることもありますが、既存メンバーとの関係づくりに不安はありませんでしたか。
外から来た自分がいきなりプロセスを変えていくわけですから、信頼関係を一番大切に考えていました。といっても特別なことをしたわけではなくて、雑談を多くするとか、会議のファシリテーションを買って出るとか、そういう小さな積み重ねです。
今はリモートとオフィス出社のハイブリッド勤務ですが、出社した日は手を動かすより話している時間の方が多いくらいで、隣の席の人の仕事を邪魔しているかもしれないと思いつつ(笑)、できるだけ対話するようにしています。ただ、そうした場から「このバグどう思いますか」「ここの実装ってどうすれば品質上がりますかね」といった自然な相談が生まれるようになりました。プロセスを変える前にまず、「この人の言うことなら聞いてみよう」と思ってもらえる関係が必要ですよね。
分業されたエンジニア組織だと「QAさん」と役割名で呼ばれることがありますが、私はこれがすごくイヤで。1年かけて、同じチームの一員として気軽に声をかけてもらえる関係になれたことは、本当に良かったと思います。
— どんな場面で、やりがいを感じますか?
freeeサインで「AIが契約書からキーワードを抽出する新機能」を開発した際、そのプロンプトチューニングを担当しました。当初はエンジニアが担当する予定でしたが、工数が逼迫していたことと、プロンプト自体は自然言語での記述が大半なので、じゃあ、私がやろうと。
QAが製品開発の一部を担うこと自体がシフトレフトですし、アプリの完成を待たずにLLM上で出力を検証できるので、開発とプロンプトチューニングを並列で進められた。結果的に開発のリードタイムを大幅に短縮できたんです。
契約書特有の文脈を考慮したプロンプト設計を何度も調整して、試行錯誤した分、お客さまから「精度いいですね」とフィードバックをもらえた時は、本当にうれしくて。QAの仕事って、うまくいっても「当たり前でしょ」で終わることがほとんどなんです。バグを防いでも誰にも気づかれないし、達成感はあっても、それが「うれしい」という感情になることはこれまでのキャリアで感じることがなかった。20年やってきて、初めて「あ、うれしいな!」と思えた瞬間でした。freeeに来なければ、この気持ちは知らないままだったと思います。
20年目で感じた「危機感」と「成長実感」
― freeeに入社して、ご自身のキャリア観に変化はありましたか。
実は、大きく変わりました。14社も経験していると、だいたいの現場で「あ、このパターンか」と見当がつくんです。正直に言うと、前職までは自分のやり方で回せてしまう分、周囲に聞くこともあまりなくて、新しいことを吸収しようという意識が薄かったように思います。
でもfreeeに来てからは、「成長しないと周りに置いていかれる」という危機感を強く感じて。
― 何がそう思わせたのでしょうか?
やっぱり、freeeにはいろいろなバックグラウンドの人がいるからですね。コードをガリガリ書けるエンジニア出身の人もいれば、ビジネス視点で品質を語れるPdM出身の人もいる。自分がこれまで「ここは得意だ」と思っていた領域を、当たり前のようにこなす人たちがいて。それが怖さでもあるんですが、同時にものすごく良い刺激でした。
弊社には「あえて共有する」という文化があって、みんながやってみたことをSlackですぐに発信するんです。自分が考えてもいなかった情報が勝手に飛び込んでくる。外部の記事を目的を持って調べに行くのとはまったく違う体験で、「自分もこのままじゃいけない」と自然に思わされる。強制的に成長させてもらっている感覚がありますね。

― そんな危機感も抱く中で、具体的にはどのような挑戦をされたんでしょうか。
E2Eテストの自動化は大きかったです。freeeサインではSeleniumベースのE2Eテストが自発的に導入されていたのですが、統一された実装方針がなかったので、freeeの全社標準であるPlaywrightへの移行を進めました。
過去にもE2Eテスト自動化は経験していたのですが、ノーコードツールを使っていたので、コードベースの実装は初めてでした。ちょうど社内でもE2Eを書けないQAがいるよねという課題意識があり、全体研修が開催されたんです。2時間くらいかけて環境構築から実装まで実践形式でやってもらって、そこに参加できたのは大きかった。やってみたらスキル的にはそこまでハードルは高くなくて、むしろ日常業務の中でE2Eを書く時間をどう捻出するかの方が大変でしたね。
それ以外にも、隣の席の人がまったく違う専門性を持っていて、ふとした会話から「そんなアプローチがあるのか」と気づかされることが何度もありました。この歳になっても、まだまだ知らないことはたくさんあるんだな、と。当たり前のことなんですが、こんなに毎日成長を感じられるとは思ってもなかったです。
― ymty(ゆもつよ・湯本 剛)さんの存在も大きいですか。
そうですね。横断QA部を率いる湯本さんの存在が、優秀なメンバーが集まってくる理由の一つだと思います。私自身はたまたまご縁で入社しましたが、スキル向上を目指している方にとっては、魅力的な上司や仲間と一緒に働けること自体が大きな魅力でしょう。
過去、恩師に「究極、QAっていないのが理想だよ」といわれたことがあるんです。その理想に近づける環境が、freeeにはあると感じています。
QAはただの肩書き。みんな、もっとはみ出していい
― この連載のタイトルは「QAキャリアの歩き方」です。まつじゅんさんの経験からアドバイスをいただけますか。
みんな「QAエンジニア」という肩書きに縛られすぎだと思います。肩書きってただのラベルです。キャリアを積んでいくと、その先には「マネージャー」か「スペシャリスト」の2択しかないように見えるかもしれませんが、そんなことはまったくないです。私のようにPdMを兼務する道もあるし、AIプロンプトの設計をする道もある。殻を破って、いろいろな領域に染み出していけばいいんです。
実際、プロダクトの品質って、テストだけで成り立つものではありません。仕様の上流から関わっていきたいとか、プロダクトそのものをつくっていきたいという目線を持っている方にとって、すごくいい環境になってきたと思います。
10年前なら異端児扱いされたかもしれませんが、今は開発者の方も対等な立場として見てくれるようになってきていますし、ちゃんと意見も言える。QAって「テストだけをやる人じゃないよね」と理解してもらえるようになりました。だからこそ、要件定義の壁打ち相手をしたり、ユーザーインタビューに参加したり、「それは自分の仕事じゃない」と思わずに自ら手を挙げられるかどうかが、キャリアの分かれ道になると思います。
― まつじゅんさん自身は、今後はどのような挑戦を考えていますか。
今はAIでテスト計画や分析、設計といったQAの一般的なプロセスを効率化している段階ですが、正直それだけでは足りないと感じています。私はもともとテスト設計を全部終えてからテストに入る、という従来のプロセスに縛られないタイプで、その感覚とAIの親和性はすごく高い。
だからこそ、既存の工程をAIで置き換えるだけでなく、AIを前提にしたQAの新しいプロセスを自分で生み出していきたいですね。同じように、テストの枠にとどまらず品質の可能性を広げたいという方がいたら、ぜひ一緒にチャレンジしたいです。
求人票
freeeでは現在、QAエンジニアを募集しています。関心のある方は、以下の求人票をチェック「いいかも」を押して、関心を伝えてみましょう。

.png&w=3840&q=75)