こんにちは、QAエンジニアの山本です。先日、machoさんとmurashiさんとともにJaSST Tokyo 2025に参加してきました。
今回の記事はPart3（ラスト）になります。murashiさんの記事、machoさんの記事をまだ見ていない方は、ぜひそちらも読んでいただけると嬉しいです！
初めに
私はestieに2025/02/01に入社をして、2か月になります。
今回JaSST Tokyo 2025に参加して、改めて自分の行っていることを客観視することで、estieでQAを行う上で必要なマインドセットが抽象化できたので、参加レポートとしてその話を書きたいと思います。
murashiさんとmachoさんがセッションの話をしっかりブログにまとめてくれたので、セッションの内容には軽く触れるに留め、estieのQAエンジニアって実際どんなことやっているの？という内容をメインに、学びを発信したいと思います。
QAエンジニアの実施する仕事の話
JaSST Tokyo 2025の話に入る前に、QAエンジニアの実施する仕事って何なんだろう、という話をしようと思います。
QAの仕事というのは、大きく分けると以下の4つに分類されると考えています。
- シフトレフト: 仕様策定や設計段階から品質を考慮し、バグを未然に防ぐ。
- シフトライト: 本番環境でのモニタリングやユーザー行動分析を活用した継続的な品質改善。
- テスト支援、実施: テストの計画、設計、実行やCI/CDパイプラインにテストを組み込み、開発と品質保証の一体化を行う。
- 不具合のトリアージ、修正、リファクタ: 不具合をトリアージして管理する。
このタスクを必ずしもQAエンジニアだけでやるわけではないので、組織や開発体制によってどのポイントに力を入れて取り組むかはかなり変わってくると思います。
また、プロダクトの品質を向上させるにあたって最もクリティカルな課題は何か、も所属する組織に応じて変わってくるはずです。
QAエンジニアってなんでも屋に近い仕事だよね、という話をよく聞くのですが、これはQAエンジニアとして求められる仕事が幅広く存在し、かつそれがQAエンジニアだけで行うわけではないから、が理由だと思っています。
JaSST Tokyo 2025 テストだけがqaの仕事なの？～名もなきqaの仕事に名前を付けて、未来を作るqaになろう～ で感じたこと
今回JaSST Tokyo 2025で「テストだけがqaの仕事なの？～名もなきqaの仕事に名前を付けて、未来を作るqaになろう～」というワークショップに参加させていただきました。
ワークショップとしては、QAエンジニアとして実施している名前のないタスクを持ち寄って、みんなでナレッジをシェアしよう！という内容だったのですが、非常に学びの大きい機会になりました。
ほかの会社でQAエンジニアをされている方々から生の仕事内容を聞くことはなかなかなかったので、非常に楽しみながらワークショップに参加することができ、この機会を設けて頂いて感謝しています。
そこで様々な話を聞いて、おや？estieで求められているQAエンジニアの仕事って、いわゆる世間で話されているQAエンジニアの仕事とは結構違うんじゃない？と改めて客観視することができました。
ワークショップの参加特典として、ワークでみんなで持ち寄ったQAエンジニアの仕事内容（300個弱もあってすごい）をいただいたので、それをベースに、estieのQAエンジニアの仕事って何をしているの？の理解を深めていきたいと思います。
estieのQAエンジニアの仕事って？
estieに入社してから一番感じているのは、「全然テストやってないな」です。
ワークショップで上がったタスクも、3割（AIを使用しつつ、自分の主観で集計）がテストに関係するタスクで、ワークショップに出なかった名前のあるタスクも含めると、QAエンジニアの業務の中でテストに関する割合はもっと多いのではないかと思っています。
私は前職で第三者検証の会社にいたのですが、もちろんテストに関する業務がメインで（テスト計画から実行）、あっても要件定義を一緒に実施するという程度でした。
逆に今estieでどのような仕事を実施しているかというと
シフトレフト
- 受け入れ基準の作成、要件の整理
シフトライト
- 性能モニタリング基盤の作成、ユーザーのFB整理
テスト支援、実施
- e2e,FE,APIテストの実装、一部手動でのテスト
不具合のトリアージやコードの修正、リファクタ
- 不具合をトリアージとその修正、顧客要望の開発対応
のような仕事をしており、テスト業務よりも、テスト以外の業務が多いくらいです。
これはなぜなのかなと考えてみたのですが、
- エンジニア自身がしっかりテストを実施し、品質の高いものを作ろうとする文化がある
- 細かく、頻繁にリリースを行う
が大きな理由である気がします。
細かく、頻繁にリリースを行うので、一回当たりの新機能に対するテストの対象が少なく、エンジニア自身でもしっかりコードのレビューと手動のテストを実施するので、自ずとQAエンジニアがテストをする機会がなくなるというわけです。
この高速なサイクルの中で「どのように製品の品質を高めていくか」が主題になり、シフトレフトやシフトライト、CI/CDの中での自動テストに仕事の主軸がおかれているのだと思います。
良くも悪くも、今までQAエンジニアがmachoさん一人で、QAエンジニアのいないプロダクトユニットが大半だったこともあり、「テスト＝QAエンジニアがやること」というような前提がないことで、チーム全体でテストに責任をもって取り組んでいく風土ができているんだと思いました。（machoさんの啓蒙のおかげもあり、すごい）
セッションから学んだことに加えて、自分の仕事を客観視することで、estieのQAエンジニアに求められるスタンスを言語化できて、JaSST Tokyo 2025に参加して一石二鳥だなという気持ちです。
estieのQAエンジニアチームの話
タスクの話とは別にQAエンジニアチームの話もできればと思います。
現状estieではQAエンジニアチームで活動するというよりは、一人一人が開発ユニットに所属して、実際に開発サイクルに交じってタスクをこなしています。
そのうえでQAエンジニア同士で定期的に情報共有を行い、現在注力しているトピックなどを持ち寄りナレッジシェアを行っています（全員が1人目QAエンジニアのような動き方するイメージです）。
JaSST Tokyo 2025で話を聞いていると、「開発者に仕様を確認する」であったり「開発者にリリースをせっつく」みたいな話がよくあり（自分も前職でよくありました）、開発ユニットに混ざって活動すると、こういったことが起きづらくなるので、メリットがあるなと再認識することができました。
ただ、QAエンジニアの負荷は高くなりますし（テストという決まった仕事がないため、自分で課題を捉えて自走していく力が必要）、QAエンジニアがチームで動いている感があまりないよね、という話をmachoさんやmurashiさんとするので、より良いチームとしての動き方があるのではないかと模索している最中です。
他社のQAエンジニアのお話を聞くことで、チームとしての在り方も再考するきっかけになり、いい機会でした。
これからの話
JaSST Tokyo 2025の基調講演でもありましたが、現在AIが大きなトピックになっているなと感じました。
開発自体の生産性も上がっており、またestieはコンパウンドスタートアップとして今後もたくさんのプロダクトを提供していく予定なので、QAエンジニアの生産性もAIを活用して爆上げしていく必要性があります。
estieのQAエンジニアチームも、様々な業務にAIを活用できないか検証を重ねています。
- PlaywrightのMCPサーバーを使って、テストそのものをAIに代替できないか
- JiraやConfluenceに接続し、シフトレフトの活動の生産性を向上できないか
- 顧客からのフィードバックや、ログをAIを用いて解析し、シフトライトの活動性を向上できないか
- 不具合のトリアージから、実際の修正まで全部お任せできないか
等々、に取り組んでいます。
まだ決まった方法が確立されていない領域にはなりますが、QAエンジニアの仕事がなにもない、という状態になることを目指して日々の業務に取り込んでいきたいと思っています。
最後に
estieのQAエンジニアチームは「高速な価値提供サイクルの支えになる」をミッションにしています。
これは、高速な価値提供サイクルを妨げるボトルネックを考え、そこに対するうち手を講じて、顧客に素早く高い価値を届けることが、我々に求められている仕事だと思っているからです。
「問題に向き合うこと」と「その解決のために行動すること」が大切という話が最後の基調講演でありましたが、改めて「我々の抱える課題は何なのか」「そのためにすべきことは何なのか」を考えるいい機会になりました。
高速な価値提供サイクルを支える土台を作るとともに、時には自らが手を動かして高速な価値提供サイクルを生む一助になる、これがesiteでQAエンジニアを行う上で必要なマインドセットだなと、改めて気づくきっかけになりました。
JaSST’25 Tokyoの参加レポートとは言いつつも、かなりestieの話に寄ってしまいましたが、3編に続きました参加レポートは以上になります。
このブログで伝えきれていないこともあるので、estieのQAエンジニアの仕事に興味を持っていただけた方がいましたら、カジュアル面談もありますので、気軽にお申し込みください！
