これはHubble Advent Calendar 2024の8日目1の記事です。
はじめに
HubbleでQAエンジニアをしている @miney です！
記事書いたりするのは初めてなので貴重な機会を頂けたことに感謝！
前提ですが、弊社ではCSがお客様からの報告を受けてから不具合や仕様を確認する必要がある場合に開発へ投げます。また、社内から仕様などの確認もQAが担っているので問い合わせ・不具合対応で工夫した点を紹介します。
（デカイこと言ってますがそのままいきます）
今までの課題
不具合対応がプロジェクトの進捗に影響を与える
エンジニアが不具合対応に時間を取られることで、進行中のプロジェクト作業が停滞する。
Roadmapの兼ね合いもありリリースに間に合わせるべく不完全な状態でリリースされる。
→ 結果、リリースされた機能に対して報告を受けて対応に時間がかかるという悪循環がありました。
担当外の機能への対応に時間がかかる
不具合が自分の担当していない機能に関する場合、仕様の確認後に原因を特定する必要があります。分かる人が対応した方が早いということで属人化と、担当した機能が多い人ほど対応に駆り出される。
QAが一次対応するきっかけ
最初はエンジニアで上記の課題を解決すべく以下の整備を行いました。
- 報告フローを整える
報告を受ける際にslackのフォームを作成しました。これにより優先度や期日、ユーザーのIDなど必要情報を必ず受け取れる様にして調査時間の短縮ができるようになりました。
- 担当者を当番制にする
日次のローテーションで不具合担当者を決めて属人化を防ぐ、担当者が責任持って対応するという習慣が根付きました。
でもやっぱり担当者をメンションして任せてしまったり、仕様や何が問題なのか確認するのは時間がかかる。
（不具合じゃなくて操作ミスの様な場合も体感では半分くらいあるイメージなので）
で、一次対応をQAやってと依頼されたので快諾して運用開始！
QAが一次対応してみて
まず報告のフォームにQAが自動でメンションされる様に修正し準備完了。
こんな感じで依頼が飛んで来ます。
報告受けてからの流れは以下。
（毎回完璧にできてる訳じゃないですが、念頭には置いてます）
1. 確認しますー！とコメント
無視してないアピール大事。
2. 仕様から不具合か判断
仕様通りならここで仕様の背景を説明して終了。
3. 報告者と一次対応のゴールを設定
すぐ修正が必要か、〇〇が原因でしたと説明できることが重要かすり合わせ。
4. 再現確認
エラーが再現すればこっちのもん！再現しなかったら該当のAPIを確認。
5. ログを確認
エラーを基にまた再現させたり、顧客が実際に報告するに至った操作を確認。
6. エンジニアに報告し調査依頼
並行して修正タスク(チケット)を作成
何をして欲しいか明確に依頼するとエンジニアも動きやすいので、依頼の投げ方も大事。
これは依頼したい内容が明確なのでまだいい方ですね！
雑に振ってすいませんでしたw
よかったこと
調査の効率化
QAが広く浅く仕様理解してることを活かし、問題の切り分けや再現性確認を迅速に行えます。エンジニアへのエスカレーション時点で十分な情報が揃えられ、対応がスムーズになりました。
エンジニアの負担軽減
依頼するまで動かないで！とエンジニアに伝えてQAが初期調査を担うことで、エンジニアは本来のプロジェクト作業に集中できるようになりました。（と、願ってる）
顧客対応の迅速化
QAだけで判断できるものもいくつかあります。その場合ソースコードまで調べた結果、不具合じゃなくて仕様だったーより格段に早く回答できます。
ログの可読性向上
これはQAの一次対応とあまり関係ないですが、調査する時にログが見づらいと時間かかります。ログ整備してもらってエンジニアもQAもログから追いやすくなりました。また、新たなプロジェクトでもログ見やすくしてねって言いやすくなりました。
新たに見つかった課題
QAの負担増加
ほぼこれと言ってもいいです。特にQAのメンバーが少ない弊社では露呈しました。
属人化
仕様知ってる人が答えた方が早い。などQA内でも起こり得ることを知りました。私も不得手と思うとお願いしちゃったり。
その場で修正しなきゃいけない雰囲気
調査して原因分かったら修正までしてよ！と思ったり言いたくなる。もちろん緊急度が高ければそれでいいのですが、他に優先度高いタスクない？と冷静になれなくなる。
今後より良くするために
早く改修されるのが正しい訳じゃない
早く調査してくれて、早く改修されたらとってもありがたいです！が、まずは一次対応のゴールに向かってもらうことが大事。
勇気を持って修正は後回しにして、優先度の高いタスクに取り組んでもらう判断するのも今後やらなきゃいけないこと。
エンジニアの方々も優しい言葉づかいで事情説明して修正は後回しにしてください。
情報の共有
ログの見方や、新機能の仕様など情報はできるだけ共有することが大事と感じました。
覚えてなくてもいいので、前にこんなこと言ってたなーきっかけで話し始めてもらえるだけで私も思い出しやすくなります。CSなどが知っててくれると顧客へ返答できたり、情報の精度が上がってくるので大事。
今すぐやらなくていいこと
不具合分析
機能別不具合も分かればいいが今すぐ分かったとこでどうすんの。と思い不要。
今後より良くというフェーズの組織にはいいと思いますが、運用したての組織には不要だと思います。
まとめ
結果的にQAが一次対応をやって良かったと思ってます。
もちろん新たな課題も出てきましたが、エンジニアもこの状態からより不満が溜まってきた時が別の方法で組織品質を上げるチャンスなのかも？
ちょっとでも参考になれば何よりです！
他に上手くいってる、私ならもっとよくできると思ってくださったら気軽にコンタクト取ってください！
明日はフロンドエンドエンジニアの @nishitaku さんです！お楽しみに！！
-
平日のみの投稿なので、投稿日は11日ですが8日目の記事としています。 ↩