はじめに
こんにちは、Kyashの品質管理を担当している Tokki です。
Kyash QAチームの歩みについてお話できたらと思います。
Kyashの品質管理（Quality Assurance）ってどんなチーム
Kyashでは、品質管理チームを英語表記で QA（Quality Assurance）チームと呼んでいます。
会社のバリューの一つに、『One Team』があります。プロダクトリリースに関する一連の活動（企画、開発、テスト、運用）において、チームメンバーが一つになって運用する中で、品質活動についてもチームメンバーが一つになって取り組んでいくことを目指しています。
その中でQAは、プロダクトの品質を最大限保証するために必要な品質活動を行う、クリエイティブな専門家でありたいと考えています。
1人目の社内QAとしての入社
私は2020年10月に社内で1人目のQA専門職として入社しました。
当時すでにテストは外部ベンダーに依頼していて、現状の運用はできている状態でしたが、リリースまでのQAの運用状況において大きく次の2つの課題を感じました。
- 一貫した開発（品質）プロセスがないことで生じる課題
- テスト実施状況や結果が可視化されておらず、外部から分かりづらいことによる課題
開発（品質）プロセスがないことで生じていた課題
たとえば次のような課題がありました。
- リリースタスクの締切ラインがぼんやりしていることで、都度追加QAタスクが生じてしまう
- テスト計画フェーズがなく、テストがプロダクト側の要求内容に流されがちだった
- プロダクト開発工程の下流（後半）からQAが関わり始めることで、仕様に関する指摘事項が見つかった場合に手戻りによる開発工数がかさむ
当初のテストプロセス工程はこんな感じでした。
開発規模の拡大に対応しつつリリーススピードを維持するためにも、開発プロセスを整理して上記の課題を改善・解決していく必要性を強く感じました。
プロセス構築に取り組もうとして失敗したこと
当時の運用では将来的にQAがボトルネックになる可能性も高く、そうならないよう予め回避したいと考えました。
それは開発とQAの人数比率の問題だけではなく、品質を一定に保つためのプロセスが整備されていないことが大きな要因であると感じていました。 ここを整備することで、開発とテストのスケジュール調整への課題、テスト開始時のプロダクト品質への課題が改善でき、バグの作り込みの予防にもつながると考えました。
開発プロセス導入の必要性を伝えきれなかった
プロセスの導入を提案していた時点で、テスト実行の運用はそれなりにうまく回っている状態でした。
結果として、将来的なリスクへの改善をダイレクトに伝えきれず、全体のプロセス導入については保留となりました。説得できる内容が十分に準備できていない、力不足を痛感しました。
その時に感じたKyashのQAの現状（姿）
テストが実際にどのように行われていて、プロダクトの品質が現状どんな状態で、リリース後の運用がどうなっているのかを把握できておらず、QAチーム以外のチームから見た時に『いい感じにやっている』という漠然とした印象しか与えられていない、ということがわかってきました。
そこで、まず行っている業務の結果を見える化していくことにしました。 自称QA丸裸（見える化）計画です。
テスト実行時の状態を見える化する
そこから取り組んだのは、『テスト実施中の状況を、テスト実施者以外の人から見たときにも分かる状態にすること』でした。
そのために、基本的なテスト活動の一つ一つを見直すことにしました。
[見える化1] テスト管理ツールを活用する
テスト管理のJIRAにある「ダッシュボード」機能を活用しました。登録されているTicketの情報を利用してグラフ化しました。
- 登録されているTicketのリスト
- Ticketの修正状況
- 優先度別の登録状況
- プラットフォーム毎のTicket登録状況 等
Next Action
この情報をベースに、次はテスト期間中のテストレポートを改善・整理しました。
[見える化2] テストレポートの充実
テストレポートを、プロジェクト関係者が現状を正確かつ容易に把握できる内容に改善しました。
改善前
改善後
とても基本的なことですが、以下を意識しました。
- 報告時間を18時と定め、定時でテスト報告をする
- 報告内容を記録として、後からまとめて見ることができるようにKibela*1を使用
- Slackでの日々の進捗報告は、Kibelaの内容をテキストとして貼り付け報告
- その他レポート項目内容の改善、グラフによる可視化
改善後に変わったこと
- いろんな人がレポートを見てくれるようになった
- テストに関する情報がより円滑に伝わりやすくなった
[見える化3] JIRA Ticketへ分析項目を追加し、不具合分析をしよう
テスト期間中に登録されたTicketが、どのフェーズのどんな原因で混入したのか振り返ることができたら、プロダクト品質の改善に役立つデータになると考えました。
そこで、Ticket修正完了のタイミングで担当者に以下のJIRA項目の該当内容を選択することを必須としました。
- 障害混入フェーズ
- 要検定義
- 設計
- 実装
- テスト（検証)
- オフショア
- 障害混入区分
- デグレード
- 端末依存
- 実装不備
- 作業ミス
- 仕様考慮漏れ・矛盾
- 仕様把握不足・認識誤り
- テスト考慮漏れ
- テスト実施者認識誤り
- 環境不備
- UIミス、齟齬
- その他
Next Action
このデータを使って、テスト期間中の欠陥分析のデータを加えた週ごとのレポートを配信することにしました。
[見える化4] Ticketの分析、テスト状況の詳細を加えたテスト週報の発信
日々のテスト進捗は、テストレポートで知ることができます。
それ以外で、Ticketの分析結果やテスト状況の詳細、プロダクト改善提案など、振り返りのデータとなるレポートを「週報」として発信しています。
リリース完了後のプロダクトの振り返りでも、改善提案の裏付けや想起原点になっています。今後、より具体的な改善活動に役立てることがNext Actionです。
~休憩タイム〜 ちょっと違うお話
QAチームで改善点を見つける一つの要素に、定期的に行っている振り返りがあります。
QAメンバーでやる振り返りには、KPTを活用しています。オンラインMTGで行っているので、スプレッドシートに記入する方式です。
KPTをちょっと楽しく盛り上げたい！と思い、GASを活用しました。誰かが書いた内容に「共感」したら、シート上の『いいね！』ボタンを押すと、押した人のアイコンがコメントの右に並びます。
いつものKPTが、いい意味で刺激的になり、盛り上がりましたよ！
QA開始前の受け入れ品質を一定にする
開発プロセスの後半にあたるテストプロセスにおいて、テスト開始時の状況がきちんと準備されていることはとても重要です。
テスト対象のバイナリー配布やテスト環境の準備ができていないと、テスト開始時間が後ろ倒しになります。また、デザインや仕様書などがアップデートされていないと、テスト実施中に担当者への確認の手間が増えたり無駄なTicketが起票されたりと、さまざまな課題が起きることもあります。
一つ一つは些細ですが、テスト開始前準備が整っていれば結果としてテストへの負荷も軽減します。
『予め計画されていたテストスケジュールを守ること』、『テスト開始時のプロダクト品質を一定に保つこと』、この2つを目的として、テスト開始前に確認してもらいたい項目をリスト化して運用することにしました。
プロダクトリリースチェックリストの運用
テスト開始前の準備事項や、テスト期間中の運用ポイントで、つい後手に回りがちな項目を整理しました。
各担当者毎に「テスト開始前」「リグレッションテスト開始前」のタイミングで該当事項を確認し、完了していればリストにチェックを入れる、という運用です。
導入後どう変わったか
テスト開始に必要な準備の認識が関係者同士でそろい、お互いにテスト開始前に確認しあう動きが定着してきました。
時として確認漏れが発生することもありましたが、その時はQAから都度Feedbackを行ったり、プロダクトの振り返りのタイミングで原因を確認したりして、よい方向への習慣化を目指しています。
テストでプロダクトの品質はどの程度担保されているのか？
ここまで見える化をしてきて、テスト実施の状況やリリースに向けたプロダクト品質の改善状況は社内でも認識されてきました。
さらに、該当のテスト期間で適正な不具合検出数を目標に設定し、ある程度プロダクト品質の担保ができているかの目安とすることにしました。
実際QAが関わっている工程でどのくらいの欠陥を除去していて、それがプロダクトの品質担保にどれほど貢献しているのか、きちんと把握しておくことで今後のプロセス改善に役立てたいと考えました。
欠陥除去率を出してみた
- QAが関わっている工程と、抽出した欠陥数をリリース毎に集計
- 目安となる除去率の目標目安は、初回だったので参考値（75%~85%）の範囲内で定め、75%としました
- グラフ化するタイミングでは、リリース前に抽出した『リリース前修正必須としているTicket数』もあわせて表示してみました
やってみたことでの意外な効果
日々テスト活動をしているQAメンバーのモチベーションが上がった、ということでしょうか。
日々実施していることが「プロダクト品質の向上に結びついている」ということが、『感覚的』ではなく『数字（データ）』で示されたことで実感できたようです。
欠陥除去率はあくまでも一つの指標
プロダクト品質やテスト品質を考える上で、データを集めて数値化していくことはとても大切です。
一方で、データの分析の観点が偏ってしまうと、全体を正しく見ることができなくなってしまうこともあります。 また、短期的な測定だけだとわかりづらいこともあります。 データは、局所的に考えるのではなく、全体を見ながら視点を変えたりフォーカスしたりする時のひとつのツールだと思っています。
そして、データはとても正直で、はっきり状態を映してくれる鏡でもあります。
QAが開発工程の後半からの参加で、要件定義の初期段階から加われていなかったこと、この事実と結果は欠陥除去率を出すときにまとめたデータにもきちんと表れていました。
仕様段階での指摘数が少なく、開発に入った段階での指摘になっていることで、より多くの手戻りが発生してしまいます。
欠陥の作り込み予防の観点から、開発の上流から参加することの重要さを改めて認識しました。
Next Action
開発プロセスの導入とテスト自動化
これからのKyash QAの取り組み
ここまで、実務レベルの細かな改善の取り組みを書いてきました。
そして2021年8月現在、KyashのQAチームは社員2名となりました！
開発規模も大きく、仕様はより複雑になっていく中、より求められるのが、テストの効率化です。 手動テストをメインで行ってきていましたが、テストの度にその負荷が増しているのが現状です。 現在、テスト自動化にも取り組み始め、将来的なテストの効率化も見据えています。
そしてもう一つは、開発プロセスの導入を進めています。
QAが開発の上流工程から参加することを基本とし、欠陥の作り込み予防や、品質に対してチームメンバー全体で取り組む意識づけ、Kyashで大切にしている『One Team』を、プロダクト品質にも反映させたいと考えています。
このあたりの話も、また機会がありましたらお話ししたいと思います。
おわりに
Kyashではエンジニアの皆様を募集しております。
カジュアル面談も随時募集中です。
もしご興味ありましたら、以下のリンクをご覧ください！
