品質を揺らがせないためのデータ活用

こんにちは。スタンバイでQuality Assurance（以下QA）を担当している樽井です。

我々QAグループはプロダクトの品質を守り高める存在として、日々の品質業務を改善するためにデータを活用しています。ここではデータの概要と実際の活用事例をご紹介していきます。

スタンバイのプロダクト開発とQA体制

スタンバイでは、求人検索エンジン「スタンバイ」のWeb・Native Appの求職者向けサービスに加え、求人入稿や広告管理などの企業向けサービスを運営しています。サービスごとに担当開発グループが決まっており、多くのグループは1週間〜2週間単位のアジャイル開発で作業を進めています。

対するQAグループは6名で、複数開発グループからの検証依頼を効率よくこなす必要があります。「特定のメンバーに検証が偏っていないか」「検証の改善ポイントはないか」を中長期的に確認していく上で、データを活用できないかと考えました。

実際にやったこと

検証業務全体のデータを取得

元々は本番障害、検出不具合のみを集計していましたが、検証業務全体を捉えられるようにデータ取得範囲を広げています。

現在取得しているデータ群
　・本番障害
　・検出不具合
　・検証依頼
　・作業工数
　・業務知識

データ元はJira、Zube、Slackなどバラバラです。それらをGoogle スプレッドシートに集約後、データの最終加工をして、Looker Studioへダッシュボードとして出力しています。

図1：Looker Studio仮想データ出力例

月次の数値振り返り会を開催

ダッシュボードは日々、データの急変動がないか、発生した出来事によってどのデータが変わったかを確認しています。

また、毎月頭に先月の数値振り返り会を実施しています。QAメンバー全員が揃い、その月の出来事や忙しさの肌感など定性的な素材と、実際に出た数値の定量的な素材を照らし合わせて、意見交換を行います。

例えば「今月の本番障害が多いのはなぜか」「急に残不具合が増えたのはなぜか」を複数人で話すことにより、「この観点が漏れていた」「この機能の不具合が多く出ていた」「差し込みの案件で優先度が下がった」など、より多くの視点で捉え、実施者が検証中に感じた思いを全員で共有できます。

加えて、過去データを元に「この時期は検証依頼が増えるから細かいものは先に取り掛かっておこう」「この観点で不具合が増えてきているため設計段階でクリアにしておこう」といった直近の作業について話し合いをしたり、データの不明点について議論します。

数値振り返り会内で解決しなかった疑問・調査事項はNext Actionとして担当を決め、不明点が明確になるように努めます。

データ活用事例

事例1：忙しさメーター

QA業務の忙しさは、自分たちの感覚を可視化することから始まりました。案件のボリューム＆難易度は、ストーリーポイントとして数値化しています。現在はテスト設計終了時に設計担当者がポイントをつけ、検証終了後にQAメンバー全員でポイントの見直しをする方法を採用しています。

この忙しさメーターにより、「先月は何だか忙しかった」「来週は忙しくなりそう」を可視化できるようになってきました。自分たちの感覚で捉えていたものを他の人にもわかる形にできたことで、共通認識を持てるようになりました。

図2：忙しさメーターの出力例

事例2：業務知識シート

QAメンバーは担当する開発グループ・システムが固定化される傾向にあり、知見が属人化している状態でした。

各システムに対して検証に利用するスキルを一覧化し、どのスキルを身につけたのかを毎月チェックしています。スキルは「XXログの取得」「XXシステムの○○操作」「XXシステムのテスト項目作成」の様に分かれています。スキル習得の推移を追うことで、自分自身の成長やQAグループ全体の変化を確認しやすくなりました。「この案件はAさんとBさんが良いね」「この知識が属人化しているから勉強会で共有しよう」など、案件割り振りや教育戦略も立てやすくなりました。

図3：業務スキルシートの出力例

例えば、左図のAさん業務知識を見てみると、4月時点で求人作成サービスの知識は０です。

求人作成サービスに関するスキルは、求人管理のシステム操作がメインになります。この時は複数メンバーが同様の状態であり、特定メンバーに知見が偏っていることがわかりました。そこでハンズオンの勉強会を実施し、まずは利用頻度の高い「求人作成」スキルを取得してもらいました。このスキルを起点として「求人編集」「会社作成」と次のスキルを身につけていき、12月には求人作成サービスだけでなく、企業向けサービスのスキルも伸ばすことができました。

また、右図のQAチーム業務知識では、個人の業務知識を総合した値を見ています。4月から右肩上がりとなっていたグラフですが、9月は人員入替によりが下がってしまっています。

このような場合、直近スキルを習得したメンバーが教える側に回ることで、新規メンバーのフォローアップと教える側の知識の定着を図ってきました。結果として、以前は5ヶ月間（4〜8月）かけて達した水準に、4ヶ月間（９〜12月）で近づくことができました。

データ活用による変化

検証工数の拡大と不具合検出の増加

データ活用を始めて3年が経過し、ようやく成果らしきものが見えてきました。

3年前に比べ、QAメンバーの全工数におけるテスト工数割合が上昇傾向にあることがわかってきました。これはQA業務の本質である、検証作業に割ける時間が増加していることを示しています。

これまでは、普段担当しないシステムの検証を実施する際、都度インプットを行ったり、知見のあるメンバーが他業務と並行して全面サポートをしたりしていました。現在は各サービスの知見を事前インプットしているため、忙しいタイミングでの説明工数を短縮でき、各メンバーが割り振られた案件に集中できるようになってきています。工数全体を見ても、一人当たりの稼働時間が増えたわけではないことから、工数を抑えつつ、検証に割く時間を増やせていると言えそうです。

図4：テスト工数割合の出力例