QAエンジニアってどんな働き方をしているの？ estieのQAチームに聞いてみた！

初めに

こんにちは！estieでQAエンジニアとして働いている山本（yamachan）です。

estieのQAエンジニア職に興味を持たれている方に向けて、「estieのQAエンジニアってどんな働き方をしているの？」という疑問に答えるブログをお届けします。

今回はQAチームの3人で、Q&A形式で実際の働き方を紹介していきます。

QAメンバーの紹介

山本龍平（yamachan）

慶應義塾大学を卒業後、2022年に新卒でソフトウェアテストを専門とするメガベンチャーに入社。 QAエンジニア、プロジェクトリーダーを経験したのち、2025年2月よりestieに参画。

村上槙（murashi）

福岡県出身、九州工業大学卒業。大学卒業後、製造業の品質管理、自動車の組込みシステム開発を経験後、QAエンジニアにキャリアチェンジ。SHIFT→Shippioを経て2025年1月にestieに参画。

粕谷恭平（macho）

不動産業界で賃貸仲介・収益不動産売買の営業を経験。趣味ではじめたプログラミングをきっかけにIT業界へのキャリアチェンジを考えたタイミングでestieを知り、2021年に1人目のQAエンジニアとして参画。

Q1. 普段どんな業務をしていますか？

macho：
今は大きく分けて2つのユニットに所属し、アジャイル開発の中でQA業務をしています。日々の開発で発生する品質課題に向き合い、開発やリリースサイクルの改善につながる活動をしています。

1つ目が、社内では賃貸DaaS(Data as a Service)と呼ばれる「estie マーケット調査」・「estie 物流リサーチ」というオフィスと物流アセットのデータを取り扱うデータ分析基盤を開発しているユニットです。このユニットでは、直近はデータ周りの品質で抱える課題を解決するために、プロダクトにとってのデータの重要度の整理や、それら重要なデータへのテスト実装、データエンジニアと連携したインシデント防止の施策などに取り組んでいます。

2つ目は「estie J-REIT」というアセット横断でJ-REIT物件に特化したDaaSの開発をしているユニットです。このチームでは、大きな機能開発時のリリース前QAをチームメンバーと協力して行い、機能追加に伴う自動テストのメンテナンスをしています。

これら2つのユニットに所属しながら、適宜ユニット外のメンバーも巻き込みながら活動しています。

murashi：
私は今やっている業務は大きく2種類あります。1つはmachoさんと同じように開発ユニットに入ってプロダクトと並走しながらやっていく業務で、もう1つは、プロダクト横断的な課題に向き合う業務です。

前者はいわゆるインプロセスQAのような働き方なのですが、チームの中に入って開発と並走しながら、どうやって良いプロダクトをユーザーに届けるかをチームメンバーと一緒に考えながら取り組んでいます。具体的な業務としては、実はテストをする時間は全体の3割程度というのが感覚としてあります。というのも、私が所属しているユニットが毎日リリースするというスピード感なので、普通にテストしているだけでは、とても間に合いません。

その開発スピードを前提とした時、いわゆるテストプロセスを通すということをやると、チームにとって良い方向に働かないので、頭のほとんどは「どうやったら高速なリリースを維持しつつ、品質を保てるのか」ということに使っていることが多いかもしれません。具体的には最近で言うと、フロントエンドテストの方針を立てたり、その実装含め整備を進めたり、あとは地道なところで言うと、Confluenceの整理やJiraの使い方をガイドライン作って整備して、チームの中で良い感じに運用するということをやったりしています。

後者の横断的な業務側は、プラットフォームチームに所属しているエンジニアと事業部のテックリードと一緒に進めています。特に、estieのプロダクトの特徴であるマルチプロダクト展開における品質リスクについて議論しながら、どうやって品質保証するのが良いかを決めたりしています。もう少し具体的に言うと、複数のプロダクトそれぞれが連携するユースケースに対して「いつ・誰が・どうやって品質保証していくか」をテーマとして関係者と話しながら方針を立て、ようやくつい先日実行アクションに起こせるタイミングになったので、これから具体的な実装に入っていこうとしています。担当ユニット外の関係者とコミュニケーションをとりながら課題と向き合うのも私たちの仕事の1つだと思っています。

yamachan：
私は「estie レジリサーチ」というプロダクトの開発ユニットで、インプロセスQAをやっています。

私もmurashiさんと同じく、普段の業務ではテスト以外のことをやっている時間の方が多いです。

開発の優先度が上がりづらいけれど、品質のためには必要だよね、というようなタスクに目を向けて取り組むということをやっています。

具体的な業務としては、テストはもちろんとして「ログに向き合って、プロダクト改善につながることを分析する」、「ログを入れる」、「本番環境で飛んでくるエラーのトリアージ」、「顧客要望の開発対応」などにおいて、幅広に業務を行っています。

日々の働き方としては、所属する開発ユニットが1週間スプリントのスクラム形式で開発を行っているので、リファインメントやプランニングなどのイベントに一緒に参加しつつ、開発者と同じようにチケットを積んで業務を行っていくという形で仕事を進めています。

Q2. estieのQAエンジニアの特徴って？

murashi：
まず開発組織の話をしますと、1人1人のエンジニアがめちゃくちゃ強いなというのは入って感じています。強いというのは色々あると思うのですが、まず技術力が高いというのはもちろんのこと、商談同行も積極的に参加して、顧客の声を直接自分たちで聞きに行くバイタリティや、受け取った声をすぐにプロダクトに取り入れて次のフィードバックを貰いに行くサイクルを自ら起こすというような、プロダクトやユーザーと向き合う強さがあるなというのを感じています。

estieでは各開発ユニットにユニットリーダーと呼ばれるOps側（estieではBiz組織をOpsと呼ぶ）の人が1人所属する体制をとっているのですが、そうすることでOps/Dev関係なく同じ目標を追いかけやすくなり、エンジニアも顧客の声と向き合いやすくなる仕組みが整っているからこその強さかもしれません。

その上で組織の歴史も踏まえると、早い段階からmachoさんが1人目のQAエンジニアとして参加していたものの、1人だと、どうしてもカバーできる範囲は限られるので、各開発エンジニア自身が自律して回すような形に自然となったのかなと想像しています。

ただ、そんな背景もあって、かなり自律した開発組織がすでにある状態だったので、私が入った時に思ったのは率直に「あれ？僕なんかやることあるっけ？」でした。（笑）私が所属したチームも自律していたので、基本的には大きな品質課題もなくゴリゴリ開発やリリースをしていたということもあって、何をやるかについて考えるところで正直困ったというのがまずありましたね。

ここからQAエンジニアの特徴の話なのですが、私自身のQAエンジニアキャリアが6年目に入ったのですが、その上で感じるのは、これまでと全然違う頭の使い方をしているということです。具体的には、これまではプロダクト開発の中でどうテストすると良いかとか、テストレビュー含めてどのようにQAエンジニアとして関わってプロダクトの価値を最大限にするかということに頭を使っていたのですが、estieではプロダクトというよりは開発チームやプロセスと向き合うことが多いなという感覚があります。

その中でチームにとってどういう状態が良いのか、高速な開発を維持した状態でどうやってチームで品質を守るか、ということに頭を使っているなと思っていて、自分だけでは完結しない課題や技術的に深い課題に対しての問いを解くことにより時間を使っているなぁと思います。かつ、プロセスやチームに向き合うとなると、自分のエンジニアリング力も高めないと、技術的なトピックに対してエンジニアと良い議論ができないので、その辺はAIに助けられながらも日々自己研鑽に励んでいます。課題との向き合い方やそのために技術的なトピックも深掘りしていくスタイルはestie QAエンジニアの特徴かもしれません。

yamachan：
QAエンジニアという職域に求められる仕事（具体的にはテスト設計やテスト計画のような）に囚われずに、仕事をすることが多いなと思っています。

先ほどmurashiさんが言っていた話にも通じるのですが、割と私が入ってきた段階で開発組織が自立していて、そこまで大きい品質課題もないという状況だったので、頭の使い方としては「今あるバグをどれだけなくすか」とか「どれだけ不具合は少なくするか」というところよりも、「良いプロダクトを作っていくために必要なことは何か」というところに目を向ける機会が増えた気がしています。

また組織的なところで言うと、開発がDevOpsを実現しているな、と思っています。

それこそ毎日リリースするくらいの開発速度で今進めている環境での活動となると、今まで自分が培ってきた常識とは違い、別のスキルが必要になってくるので、そこはestieのQAエンジニアの特徴になる気がしています。

また、評価の方法としても特徴があって、murashiさんが話している通りOps/Dev関係なく同じ目標を追いかけて、その達成度合いが自身の評価につながるような仕組みがあります。

そういった面も含めて、QAエンジニアという職種職域にこだわらずに、自分で課題を見つけて解決していく力が求められているなというのはすごく感じています。

macho：
私自身estieがQAエンジニアキャリア1社目なので、他社との比較が適切にできるのかという話はありつつ、メンバー個々の自律性が高いところが特徴かなと思っています。

タスクを与えられるというよりは、所属するユニットの中で主体的に動いて課題特定し、解決のアプローチを取るということをそれぞれがやっています。

実際に2025年頭にmurashiさん、yamachanが入社した際も所属ユニットしか決めていなくて、雑に言うと「xxユニット所属なのであとはよろしく！」みたいな感じでしたよね。(苦笑)

murashiさんはさっき「やることはあるっけ？」ということを言っていましたが、実際はmurashiさんもyamachanも入社直後から自身で情報取りに行ってタスクを見つけて爆速でユニット内でバリューを発揮していて、めちゃめちゃすごいなって思っていました。

また、品質とスピードのトレードオフ的な話で言うと、両立を目指すことは多いと思いますが、estieはどちらかというとスピードが正義というところが現状は強いかなと思っていて、それにQAエンジニアも同意して活動できているのはQAチームとして珍しいんじゃないかなとも思います。

あとは、テストという手法にこだわらないところも特徴の1つかなと。もちろんテストをするのは大事ですが、実際estieのQAエンジニアはテスト以外のアプローチに使っている時間の方が比率として圧倒的に多いですよね。

Q3. やりがいを感じる瞬間は？

yamachan：
定性的なところで嬉しいなと思うのは、顧客から製品に対する良い声を聞いた時です。

estieの特徴だと思うのですが、顧客商談の議事録が開発の目に入るところにポンポン飛んでくるんですよね。

そこから結構顧客要望を拾って開発に活かしたり、改善の種がないかを見たりしているのですが、その中でプロダクトに対して顧客が良い反応を示してくださっている時というのは、やりがいを感じます。

要望に応えて開発を行った時に「もう対応してくれたんですね！」というような声があるとやってよかったなと思います。

特にBiz側も積極的に顧客の声をDev側に届けてくれるので、実際の顧客の声を聴きながら開発ができているというのは、やりがいにつながっています。

また、定量的な面で言うと、エラーや利用ユーザー数、処理時間などが数字として見える部分が改善されていると、チームとして良い状況で、自分がやっていることの結果が見えて嬉しいですね。

macho：
私がやりがいを感じるのは、開発しているプロダクトの新規受注や契約継続が決まった時です。

yamachanがさっき言っていたとおり、estieでは商談の進捗がかなり詳細にかつタイムリーに共有されています。新規受注や契約継続に向けての開発にも日々取り組んでいて「あの機能開発・改善のおかげで新規受注いただきました！」というコミュニケーションが発生した時は嬉しくてテンションが上がりますね！

所属ユニットの開発や品質まわりの課題に貢献できた時もやりがいを感じます。

あとは新しい知識や技術を経験し、それが身についた時もやりがいを感じますね。

Q2でも触れましたが、手段にこだわらないスタンスを心がけているので、おのずと今まで取ったことないアプローチを試す機会も多くなり、その度に新しい手法や技術に触れることで自己の成長を感じます。

murashi：
私は個人の仕事面で話すと、QAエンジニアは結構地道にコツコツやって改善の種を仕込むということが多いなという印象がある中で、それがうまく機能した時はやってよかったなと思います。

例えば、さっき触れたフロントエンドテストの話で言うと、フロントエンドの結合テストの実装を自分で進めていたのですが、そこがなかなかうまくいかなくて、テストが動くようになるまでに結構苦戦していました。

結果それは色んな要因があったのですが、例えばUIコンポーネントのライブラリとテスト環境の相性が悪いとか、DOM表示待ちが実は思ったより必要だったとか。まあ、この辺は自分の技術力の足りなさというところが相まって苦労したという点もあったんですが、その苦労が実となった時はやりがいを感じました。例えば、パッケージアップデートや大規模なリファクタリングをする必要があった時に、デグレをCIの中でキャッチできて「良かった！助かった！」という声を聞くと、やはり嬉しくなりますね。

細かいところでも、これもさっき話したJiraやConfluenceの整備の話なのですが、実際整理整頓ってやらなくても業務は止まらないですし、何だかんだ毎日の業務は進むのであまり人がやりたがらないものですが、やるとちょっとだけ毎日の仕事が気持ち良くなったりすると思っています。そういう土壌を作ってチームの運営が前よりも少しでも良くなると、小さな喜びを感じますね。

Q4. QAエンジニアとしてどんな成長ができますか？

murashi：
前の話でもあったように、estieではこれと決まった仕事がなく、自立した開発組織があるという前提がある中で、開発課題の発見力やその課題に向き合い続ける胆力は強くなるかなと思っています。併せて、コードを読むとか、システムの仕組みを理解するという技術的なところも得られるのかなと思っています。

というのも、良くも悪くも誰かがご丁寧に課題を分解してタスク化してくれるということは本当にない、本当にない！（強調）ので、自分で発見した課題をどうやって解決するかや、実行まで完遂するかは自分の裁量が大きいです。そうなると、プロダクトの内部を深く理解するためにはやはりコード理解や、システムの裏側を理解する力が必要になってくると思っています。その辺は課題発見する上での前提となるスキルにはなるので、スキルを身につける力も大事だなとestieに入ってかなり思いました。

最近はAIが素晴らしすぎるので、私はChatGPTを先生として自分の理解を深めつつ実装タスク周りにはCursorを使っているのですが、便利すぎてもう離れられません（笑）。自分の土壌を作りつつ、課題を発見して解決するサイクルを作ることは大事ですし、そこがQAエンジニアとしての力に結果としてなるのかなとは思っています。

macho：
QAエンジニアとしてできることの幅が広がりやすいと思います。

現状のestieのQAは狭く深くよりかはどちらかというと良くも悪くも広く浅く寄りの業務が多いかなと思います。その分様々なアプローチを取る機会が多いため、業務の幅も広がっていく実感がありますね。と言いつつ必要なタイミングでは積極的に深さも出していきたいと考えています。

他のメンバーも触れていますが、ベースとしてestieには優秀なメンバーがたくさんいるんです。

そんなメンバーに囲まれて働けるという前提があるからかもしれないですが、現時点で自分に足りていない知識や能力があったとしてもコラボレーション的にメンバーを巻き込むことで業務を進めることができます。コラボレーションと言えど結果的にその業務を通して自分も経験値を得られるのでそれが成長につながっていると感じます。

あと、estieでは全体的にアジャイルQA寄りの立ち回りが多いのですが、一方ではプロジェクト型の規模の大きな開発も行われていて、こちらではウォーターフォール寄りの開発の中で必要なQAスキルも求められてきます。そのため幅広い業務に携わる機会があり、それだけ成長のチャンスがたくさんあります。

yamachan：
QAエンジニアという文脈で成長しているかと言われると謎なのですが、コードを書く力やデータ分析する力、顧客要望を整理する力とか、そういう包括的な能力がとてもついてきているなと感じています。

QAエンジニアとしての能力というと、テスト分析をするとか不具合分析をするとか、そういう能力が思い浮かびがちな気がするのですが、どちらかというと包括的なエンジニアの能力がもりもりつく環境があるなというのは思っています。

murashiさんの話やmachoさんの話にかぶるのですが、やはり今の動き方は、全員が1人目QAエンジニアとして働いているのに近いんじゃないかなと思っています。

そうなると前提として決められたタスクというものがなく、誰かが自分にタスクを振ってくれるわけでもないので、自分でやるべきことを決める力というのを身につけないと、しんどいところがあるだろうなと思っています。

また、フェーズとしてやはりAIというのがホットで、会社としても「AIをどんどん活用していこう！」というところに注力しているので、AIを活用する力というのは、現在進行形で付いている気がしています。

会社として今ChatGPTやDevinなど、色々なツールを試してみている状況なのですが、QAエンジニアとしてもその辺のツールをバリバリ活用して業務を行っています。

AIが優秀になるにつれて、自分の仕事がなくなっちゃうんじゃないかという不安感というのもあったりはしますね。（笑）

ただ、時代の流れとしてAIは避けては通れないところなので、最前線でAI活用できているのは良い環境だなと思っています。

Q5. これからどのような仕事をしてきたい？

macho：
ちょっと抽象度が高い話になってしまうのですが、estieという会社の今後の中長期的な進み方を考慮した上で、QAエンジニアのあり方をチームで考え少しずつでも具体の行動に落とし込んでいきたいなと改めて考えています。

2024年末までの1人QA時代に比べると、3名体制になりチーム立ち上がったことで現状を最適化することは出来はじめていると思います。しかしestieはスタートアップ企業で、意思決定・実行・成長どれもスピードがかなり早いです。

今後もプロダクトやプロジェクトの増加も見えてきている中で、求められる品質やできるアプローチも更に変わってくると思います。

少数精鋭のQAチームでestieの品質に向き合い、中長期的な行動を逆算していきたいです。

yamachan：
QAエンジニアに限らず、AIがガッツリ入ってきて、エンジニア1人1人に求められる職の幅がどんどん広がってきているように感じています。

QAエンジニアもその例外ではなくて、開発サイドにコミットしたり、PDMの業務を一部担ったりと、少人数で高い生産性を上げるために、できることの幅をどんどん広げていく必要があると思っています。

幅だけではなくて、品質ということに対して、深い知識も身に着けていないといけないので、日々勉強の毎日です。

また、今のQAチームの働き方には、あまりチーム感というものがないなと思っておりまして…

個々の能力ではなく、チームとしての相乗効果で会社やプロダクトに価値貢献できるようになると、もっとできることの幅が広がって仕事が面白くなるだろうなって思っています。

murashi：
私もyamachanと似てるのですが、QAチームとして全社的に価値が認知され、頼られる存在になるための活動をやっていきたいです。

今のestie QAチームには3人いるものの正直個人個人で動いている状況です。まだチームとして動き出して間もない今のチームフェーズでは、チームとしての強さより各々好きに動いて価値を出すことが大事だと思っていますし、それができる仲間がいることにとても頼もしさを感じますが、仕事をしているとやはり私もチーム感は欲しくなってきますね。今すでに一人一人が価値を出せている状態でチームとして一丸となった時にどれぐらいのパワーになるのかある意味楽しみです。