株式会社ナレッジワークのQAエンジニア、コヤマンです。
2024/04/23のEncraft#13へのご参加、誠にありがとうございました！
また当日参加できなかった方も興味を持っていただきありがとうございます。
当日の様子についてのレポートを頼もしい同僚であるiinonが上げてくれたので、ぜひご覧ください。
個人的に社外の方向けにお話しすることが久しぶりだったため緊張していましたが、楽しんでいただけたなら幸いです。また、参加者の皆さまの明日からの仕事について、何らかのヒントになったなら嬉しいです。
さて。当日たくさんの質問をいただいていたので、私が答えられるものについて回答させていただきます。
Q1：開発も含めたバグだし会は何か実施手順やシナリオなどをはじめは用意されているでしょうか？（どのように触るべきか悩む人もいるのかもと思いました）
A1：バグ出し会は事前にシナリオを準備しておりません。「バグ検出能力の高い人が検出したバグを他メンバーが理解することで、機能の概形認識を向上させること(自分たちの開発した機能を触ることで大まかに認識している範囲の精度を向上させること)」を主目的として取り組んでおり、探索的にプロダクトを触る中で見つけたバグを発見するに至るまでの思考過程をリアルタイムで共有したりしています。機能の概要についてはminispecやTestDesignDocなどに記載された仕様をインプットとして利用しております。
Q2：バグまではいかないけど「ちょっと使い勝手悪いな、こうだったらいいな」レベルの要望チケットなどはバグのダッシュボードの中に含んでますか？どう扱われてますか？
A2：QAエンジニアが気づいた場合は起票してseverity=Lowにするのでダッシュボードに含まれています。またドッグフーディングなどで別の方が気づいた場合は、「Good＆Oppotunityシート」というスプレッドシートで、プロダクト領域ごとに管理しています。「Good＆Oppotunityシート」に記入されたOppotunity（要望など）は毎週全社員で1時間集まって行うプロダクトシェアデイで共有され、必要に応じてJIRAにエピックが作られてバックログに積まれます。
Q3：スプリント内で発見したバグは、バグチケットを起票しますか？ それとも、スプリントバックログにフィードバックしますか？
A3：バグチケットを起票し、翌日のデイリースクラムで内容を共有し、Sprint内で扱うか含め優先度の相談をしております。
Q4：湯本さんのお話にもありましたが、バグ分類のタグ付けを浸透させるのが大変だと思いました。どのように浸透させたのか知りたいです。
A4：仕組み化によって運用が回っている印象があります。具体的には、タグ付けをしてからでないと、バグチケットを完了ステータスに変更できないようになっております。一度に多くを求めず1~2clickで済むくらいのコストに抑えているのと、毎朝、その日までに起票したbugをcheckするようにリマインダをセットしていて抜け漏れを防いでいます。(毎日checkすることで自然と件数が少なく保たれます)
Q5：色々な取り組みをされていて、凄いなと思うのですが、何人くらいのQAがいらっしゃるのでしょうか？
A5：ありがとうございます。現在ナレッジワークにはQAエンジニアは6人おります。
Q6:有用さ：伸びしろの理解 に繋がる部分について、もう少し詳細を知りたいです。設計時とバグ傾向から得られる伸びしろは、同じものになりますか？具体的にどういったものかを教えて頂けると嬉しいです。
A6：伸びしろにはいくつか種類があるのと、全体傾向と各チームで着目すべき点を変えています。
- 全体傾向
- 全体件数傾向：件数と安定度合い
急激な変化があった場合に説明がつかない場合は原因を探って解決すると良い - severity=Highの残存傾向：問題解決度合い
残存している場合、その原因を探って解決すると良い。長期的に残存している場合、それをちゃんとCSなども把握しているかも気にした方が良い - Close率傾向：悪化度合い
悪化しているということは処理能力が低下しているかバグ流出量が増加しているので手をうつ必要がある - リードタイム/バグライフタイム：長くなっていないか
長くなっている場合、解決すると良い - 発生要因の偏在傾向：偏在度合い
改善不足。解決すると良い
- 全体件数傾向：件数と安定度合い
- 各チーム
- チームの課題感
着目ポイントはチームで決める。例えば以下など。- 総件数：バグ発生数
- 着手スピード：リードタイム
- エラー低減：発生要因
- 安定化：発生数、Close率
- チームの課題感
Q7:コヤマンさんの発表にあった「チームの伸びしろ」のところって、どんなメトリクスで見られているのか、とても気になります！伸びしろいいですね！
A7：上記(A6)に書きました！
Q8:開発チーム以外への情報提供をしている事例や、今後やりたいことはありますか？
A8：会場でも回答しましたが、現在はSRE/CS/Sales向けにインシデント分析を始めています。
他にもプロダクトシェアデイという取り組みで開発チームの取り組みを全社員向けに話をしたりします。
やりたいこととして現在構想があるのは以下です
- テスト中にわかったニッチなパターンや複雑なパターンの解説資料の全社展開
- 品質とは何かという教材作成
- QAエンジニアが使うツールや技術の解説
- 生産性指標の全社展開
- QA ROIの情報展開
Q9:ラベル付けや分析など、手間やコストが一定かかるなかで、 この活動によってどのくらい品質が上がったのか、 効果やROIなどはどのように評価していますか？ 経営陣がそこまで開発に詳しくない中で、 どれくらいのコストをはるのか、 またその妥当性をどのように説明するのがよいのかの参考にさせていただきたいです。
A9：基本的には現状のルールを守れば取れるようにした（※あんまり複雑なことはしてない）状態で始めています。
Dashboardを作った工数は合計で1人日(8h)未満、バグふりかえり会は30min/Q(今後少し増やすかも)という感じのコスト感です。
また、現状取れているデータがバグの情報なので、バグの件数/Close率などを基準にDREなどを追加整備して計測予定です。
zenn記事で触れている「バグふりかえり会」では、各チームでアクションを決めるようにしているのですが、その中で「改善ターゲット」「施策」「計測するメトリクス」を決めており、効果測定にはそのままそれを使います。
また、QA ROIとしては施策実施前/後で品質コストを計測するのが一般的なのでそうする予定ではいます（上記の効果測定や件数ベースで十分成果が理解できたらやらないかも）
Q10:Jiraでチケット管理をしています。テストはテスト実施記録のドキュメントに記録しています。QAで発見された細々したバグ一つ一つを全てJiraチケットに起こす必要はあると思いますか？手間が気になってしまいます。
A10:チームのリズムによるとは思いますが、例えばページ内の文言ミスの指摘などの「1つのPullRequestで対応できそうなもの」はチケット１つにまとめたりします。（別れてても嬉しくないので）
私の場合、時々slackで「これって起票した方が良い？」と問いかけ、不要であると関係者間で判断できたらしない場合もあります。
起票する手間が気になる場合はテンプレートを使ったり詳細入力を後回しにしたりするのが良いかと思います。（チケットのフィールドに「タイトル」と「問題と感じる内容」と「起票者」と「担当者」があれば何をしているかわかるので）
タイトル書いてslackのリンク貼って終わり、といった形にすることも時々あります。
Q11:QAからサービス利用者（ユーザー）への情報提供って何ができますか？ 以前にダイソンドライヤーからのメールに、XX km分の髪の毛で検証をしましたという内容を見て、とても興味深かったです。あまりwebサービスではそういう情報は見た事ないですが、できることはないかなと日々考えています。
A11:何らかのアピールをしたい場合はブランディングやPRやマーケの方と相談して提供できそうな情報を探るのが良いと思います。
ただ個人的にはアピールよりも情報透明性や可用性向上、障害対応迅速化などといった行動・実績で示すのが良いと考えます。
（毎日〇〇件のテストをパスしています！と言いながら障害で１日落ちてますとなるとあまりアピールになりませんよね。）
Discussion