こんにちは、QAチームのakinkです。
今年買ってよかったものは「リファ グレイス ヘッドスパ 」です。
この記事は Gunosy Advent Calendar 2020 15日目の記事です。
昨日はgumigumi4fさんのGoでSIMDを駆使して高速な内積演算を行うでした。
はじめに
入社して約3年、LUCRAやオトクルのQAを経て、今年の2月よりグノシーのQA担当を引き継ぐことになりました。
グノシーはリリースから7年程たっており、弊社の中では一番歴史の長いプロダクトです。そのため、リリース毎に実行している回帰テストもボリュームが多く、担当者として心が折れるところからのスタートでした。
回帰テストで削れそうなところがないかをみていくと、「本当に回帰テストでみる必要があるのか？」「そもそも使われているのだろうか？」と疑問を抱く機能やログが複数見つかりました。
そこで、QA単体でどうこうしようとする前に、グノシーチーム (PO/Dev/QA/BI/Design/マーケ) としてアプリ機能とユーザアクションに紐づくログ（以下アクションログ）*1の棚卸しをすることにしました。
アプリ機能の棚卸し
チームのKPTで前述の課題感を話したところ、「今となっては不要な機能もありそうだし、棚卸ししたい」「今後のメンテを楽にするためにも、消せる機能があれば消したい」という共感が得られたので、TRYとして棚卸しに取り組むことになりました。
1. 機能一覧の作成
まずはじめに行ったのは棚卸し検討用の機能一覧の作成です。
「直近半年以内に新規で開発された機能」、「サービス提供事業者としてはずせない機能」、「収益に直結する機能」以外のアプリ機能をほぼすべて洗い出しました。(87機能)
2. 機能一覧をチームに共有
QAで洗い出した機能一覧に抜け漏れがないか、他に削除候補として議題にあげたいものがないかの意見を募り、加筆してもらいました。
3. 各機能の対応方針を決めMTG
機能一覧をもとにチーム全員で話し合い、対応方針を以下に振り分けました。*2
・「削除候補」：関係者に確認して問題なければ、削除計画をたてる ・「利用率調査」：利用率を調査し、削除時のインパクトが許容範囲であれば削除計画をたてる ・「UI/UX検討」：UI/UX改善PRJで検討してもらうよう、デザインチームにフィードバックする ・「そのまま」：今のまま残す
対応方針を話す過程で、「〇〇機能が××にあるのは、サイドメニューがなくなったときに一時的に退避させたから」、「〇〇機能は、動画フォーマットが主流でなかったときの仮説の名残」など、当時の経緯を確認しつつ削除の影響や機能改善の意見交換を行いました。
4. プロダクトバックログに積み計画に組み込む
MTGで「削除候補」となったものはPOやEMの関係者確認タスク、「利用率調査」となったものはBIチームの調査タスクとしてプロダクトバックログに積み、スプリント計画の中で順次対応していただきました。
このMTGをきっかけに8機能が削除となり、両OSとも対応版がリリース済です。
また、MTGで「UI/UX側検討」となったものはデザインチームとマーケチームに共有し、UI刷新プロジェクトのバックログに積んで検討してもらっています。
アクションログの棚卸し
グノシーでは、施策の効果検証、日々のKPI監視、コンテンツ配信ロジック等幅広い用途でアクションログが活用されており、その数は膨大です。回帰テストもログだけで400ケース程あり、ログ欠損時のリスク度合いに応じたテストの優先度がつけられていない状態だったため棚卸しを行いました。
1. ログの利用目的の整理と棚卸し依頼
まずログを利用するチームに各ログの利用目的の棚卸しを依頼しました。利用目的は大きく以下に分類できました。
A. 事業KPI算出等で継続的に利用しているログ 週次レポートや朝会ダッシュボードのクエリで利用しているログ B. ユーザー問い合わせ等の調査でよく利用するログ 抽選やクイズ賞金等、問い合わせ発生可能性の高い機能のログ C. ロジックで利用しているログ 記事推薦等、ロジックで利用しているログ D. 上記には該当しない、一時利用ログ 深堀り分析用のログ(A/Bテスト100%適用後は使わないログ） E. 監査対象ログ 自社の収益算出、パートナー企業への収益分配計算に利用されるログ
2. ログ欠損時リスクに応じたテスト方針の整理
ログの利用目的別のリスク度合いを確認しつつ、テスト方針を整備しました。*3
- ログ新規追加時、既存ログ改修時
| 対象パターン | 確認レベル | 確認方法 |
|---|---|---|
| 全て(A, B, C, D, E) | 送信条件と送信内容の確認 ・「〇〇な操作をしたタイミングで、××なログが飛ぶこと」を確認 ・パラメータの値が操作時の状態と合致していることを確認 |
mitmproxyを利用し、端末でアプリを動かしながら、送信されたログを確認する |
- 該当ログの改修はないが、他の修正の影響範囲に該当するとき
| 対象パターン | 確認レベル | 確認方法 |
|---|---|---|
| A, B, E | 送信条件のみの確認 ・「〇〇な操作をしたタイミングで、××なログが飛ぶこと」を確認 ・パラメータの値は細かく見ない、飛んでればOK |
mitmproxyを利用し、端末でアプリを動かしながら、送信されたログを確認する |
| C | 回帰テスト期間中、ログが1件以上飛んでいることの確認 ・送信条件、送信内容は確認しない ・1件でも飛んでいればOKとする |
Redashで確認用クエリを作成。 期間/バージョンで絞り込んだときにログカウントが1件以上あるかどうかを確認する |
| D | テスト対象外とする | - |
- 該当ログの改修はない、かつ、他の変更の影響範囲に該当しないとき
| 対象パターン | 確認レベル | 確認方法 |
|---|---|---|
| E | 送信条件のみの確認 ・「〇〇な操作をしたタイミングで、××なログが飛ぶこと」を確認 ・パラメータの値は細かく見ない、飛んでればOK |
mitmproxyを利用し、端末でアプリを動かしながら、送信されたログを確認する |
番外編. 旧基盤ログの棚卸し
グノシーでは数年前にログ基盤を刷新したのですが、一部のログは新・旧両基盤に送られており、完全にテスト対象外にできないという事情がありました。しかし、保証すべきものとそうでないものの切り分けがなされていない状態だったため、回帰テストでは刷新後も多くの旧基盤ログのテストをせざるを得ない状況でした。そこで、BIチームとロジックチームに利用状況を洗い出してもらい、本当にテストが必要なログを特定することでテストケースを大幅に削減できました。(153ケース→25ケース)
棚卸しの気づき・学び
初期に感じた「めんどくさい」という気持ちを忘れない
どんなに面倒な業務でも何回も繰り返すと慣れてしまい、徐々にその目的や意義は忘れられがちです。着任当初の「うわっ」という気持ちの初速を生かし、「重要だけど緊急ではないから誰も手を付けてこなかったところ」の見直しに取り組めたのは良かったなと思います。
相談相手の認知負荷、意思決定負荷を下げる
在宅勤務*4という相手の状況が見えにくい中、複数人の時間をいただきながら緊急度の低い改善業務をすすめるのは大変気が重かったです。
気の重さを解消するためにも、
- カジュアルな相談でも、予め問題点を整理しdocsにまとめておく
- MTG前に事前に資料を共有し、目的と背景を伝えておく
- 大人数で何かを決めるMTGでは、「選択肢の中から何かを選ぶだけ」等、何をどう決めるかの進め方を決めておく
等、相手の認知負荷、意思決定負荷をなるべく下げた状態で相談するよう心掛けました。どれもこれも当然の話ではありますが、そういった準備をする人だと認知してもらうことで、相談に乗ってもらいやすくなるのでやっていて損はないなと思いました。
おわりに
機能自体の見直しやログの棚卸しを事前に進められたおかげで、(今回の記事では詳しく触れませんでしたが)その後のテスト方針の改定、回帰テストのリライト、自動テストスコープの見直し等もスムーズに行うことができました。結果的にリリース前QAのリードタイムを1/2に短縮することができました。グノシーチームのメンバーからも「前より早くリリースできるようになって嬉しい」と言われる機会が増え、やってよかったなと思います。
全体的にテクニカルな話とは程遠い内容になってしまいましたが、現場における泥臭い取り組みの一例としていつか誰かの参考になれば幸いです。
明日はsekiさんの記事になります！お楽しみに！
*1:「記事を開いた」「動画を再生した」等のログ。参考：LUCRAの分析を支えるモバイルアプリのログ設計と実装 - Gunosy Tech Blog
*2:全ての機能について話すには機能数が多かったため、予めQAメンバーで削除候補になりそうな機能をピックアップしたものから優先的に話していきました
*3:QAの独断ではなく、CTOにリスク度合いを確認しながら方針を設定しました
*4:Gunosyでは、今年の2月中旬より在宅メインでの働き方にシフトしつつあります。https://gunosy.co.jp/news/250
