QA engineer at a Startup イベント登壇レポート

こんにちは、QAチームの関井(@ysekii_)です。

かなり時間が経ってしまい今更ではありますが、1月20日(月) に開催された QA engineer at a Startup vol.4 ysekii編 に登壇したので、準備から当日までの様子をレポートしたいと思います。

ちなみに、イベントの様子は以下の動画でご覧いただけます。

www.youtube.com

QA engineer at a Startup って何?

「QA engineer at a Startup」(QaaS)は、スタートアップの現場で働くQAエンジニアが同じ目線で話し、共に成長できるコミュニティです。大企業とは異なる、スタートアップならではの意思決定のスピードやリソースの制限、日々直面する課題や悩みを相談し励まし合える場を目指して立ち上げられました。

このコミュニティイベントでは「〇〇さんの日常」というシリーズを通じて、スタートアップで働くQAエンジニア一人ひとりにスポットライトを当て、多重露光的にQaaSとしての像を浮かび上がらせることを目指しています。今回のvol.4は私がフォーカスされ、「テストをしないQAエンジニアは何をしているか?」というテーマでお話しました。

準備段階

登壇が決まったのは2024年11月末くらいだったと思いますが、そこからどのような内容を話そうか考えました。

これまでの自分の業務を振り返ってみると、問い合わせ対応とか、ドキュメンテーションのルール策定とか、王道のQA*1からは少し外れたことをしているなという気づきがありました。 また、vol.3までは「テスト」をテーマとした話をされていたので、今回はこれまでとは少し違ったテーマで話したかったこともあり、「テストをしないQAエンジニアは何をしているか?」というテーマにしてみました。

「〇〇さんの日常」というのが大テーマでもあるので、1つの取組みを深く発表するというよりは、あえて広めに自分がやってきたことをまとめる形で資料を作成しました。

当日の様子

イベントは2025年1月20日19:30〜20:30でZoomで開催されました。(その後Discordでアフタートーク)

私が思っていた以上に多くの方に参加登録していただき、結果的には60名以上の方に参加登録いただけたようです。

発表パートでは、QAチームが具体的に取り組んでいる「テスト以外」の活動について詳しく紹介しました:

  1. バグレベル定義
    • 課題:バグの重大度に対する認識がバラバラだった
    • アプローチ:バグレベルの決め方と基準を定義し、変更障害率を計測
    • 結果:品質の目線合わせができ、変更障害率は品質の指標として活用できるようになった
  2. ドキュメンテーションルール策定
    • 課題:ドキュメントのメンテナンス不足による開発生産性低下
    • アプローチ:メンテすべきドキュメントの分類と更新タイミングの明確化
    • 結果:メンテナンス状態の改善
  3. Jiraのチケットワークフロー整備
    • 課題:チーム間でチケットワークフローがバラバラ
    • アプローチ:ワークフローとカスタムフィールドを統一
    • 効果:横断テストチームの立ち上がったとき、すぐにワークフローに適応できた
  4. 開発チームへの問い合わせ対応
    • 課題:開発への問い合わせで開発者が開発に避ける時間が圧迫されていた
    • アプローチ:QAチームが窓口となる取り組み
    • 効果:月平均80件の問い合わせにQAで対応し、開発者の時間を確保

当日の資料はこちらになります。

speakerdeck.com

パネルディスカッションでは、おおひらさん、machoさん、mugaさんからの質問はじめ、Discordでも多くの質問をいただき、回答させていただきました。 下記に当日のQ&Aを掲載したいと思います。

QAチームについて

  • ミッションをどう決めたの?
    • 開発組織のミッションをベースにチーム内でディスカッションして考えました。
  • QAメンバーの規模感はどのぐらいですか?
    • QA8名、SET1名です。
  • ysekiiさんのポジションとしては、全体を見る感じですか??
    • はい、横断的に見ています。

バグレベルと変更障害率について

  • チームごとのバグレベルの解釈に揺れある?
    • 解釈の揺れはあります。開発側でレベルを仮置きしてQAに確認するケースもあります。
  • バグレベル定義 どんな改善余地あるのか気になる
    • 当初は回避方法があるかどうかを含めて定義していましたが、ユーザーが増えてバグレベルと対応の優先度に乖離が出てきているので、改善が必要だと感じています。
  • どのくらい急ぎで修正するかは、最短だとどのくらい?
    • 最速は今すぐ!ということもあります。
  • 変更障害率の計測方法が気になる。自動計測?手動計測?
    • 今は手動で計測しています。

開発への問い合わせ対応について

  • 問合せ対応はQAチーム何人で対応されたのでしょうか?
    • 4人からスタートして今は8人で対応しています。
  • 問い合わせ情報はどう管理してる?
    • JIRAで専用プロジェクトを作って管理しています。
  • Jiraの使い方はPBIでしょうか?BTSでしょうか? 両方?
    • 色々使っています。PBIとしてもBTSとしても使っていますし、問い合わせ管理でも使っています。
  • どんな顧客からの問い合わせが多い?
    • CS*2に来る問い合わせのうち、開発にまで回ってくるのは不動産会社からの問い合わせに関する質問が多いです。
  • 社内問い合わせ件数を減らしたい?
    • 発端となる顧客問い合わせを減らしていきたいです。
  • 開発チームへの問い合わせの回答を肩代わりしちゃうと、開発側でどういうこと聞かれるかの感度が下がったりとかはないですか?
    • 問い合わせには操作ログの確認や仕様確認など、種類が複数あります。QAでサマリーして共有して、開発側の感度が下がることはないように気をつけています。

おわりに

QA engineer at a Startup vol.0 ではパネルディスカッションメインで登壇させていただきましたが、オンラインの発表ありでの登壇は今回が初めてでした。 オフラインイベントは前職含め何度か登壇経験があったのですが、オンラインの登壇はオフラインほど比較的緊張せずにできたのではないかと思います。 登壇に興味があるけど、やったことないしな〜という方はオンラインイベントの登壇から始めてみるといいかもしれません!

そんなこんなで最後に宣伝となりますが、QaaSでは、スタートアップQAの日常について語ってくれる方を募集しています。少しでも興味がある方は下記フォームから応募いただけると幸いです! ぜひ、一緒にスタートアップQAを盛り上げていきましょう!

forms.gle

*1:王道のQAって何だよって話ですが、個人的にはテストや不具合分析とかのイメージです

*2:ニーリーではクライアントサクセス(不動産会社からの問い合わせを受けるチーム)とカスタマーサクセス(駐車場ユーザーからの問い合わせを受けるチーム)に分かれています