広義のQuality向上のためにQAメンバーが大事にしていること

こんにちは、QAエンジニアのakinkです。こちらは Gunosy Advent Calendar 2019、9日目の記事です。昨日の記事は azihsoynさんのAppSync + Nuxt.js(SSR)によるリアルタイム野球詳細ページについてでした。 qiita.com

はじめに

GunosyのQA組織は部長以下5名のメンバーで構成されており、1プロダクトにつき1~2名が専任で担当する体制となっています。
QA組織としては独立していますが、実態はプロダクトチームの一員として企画段階からリリース後の分析MTGまでプロダクトライフサイクルのほぼ全てに関わっています。
そんなチームで働いて思うGunosyの特徴は、
「リリースによって獲得する価値の追求・ユーザー体験の変革・ビジネスの拡大」といった広い意味でのQualityを突き詰める姿勢が全員に求められている点です。
この記事では、チームメンバーから学んだ「広義のQuality向上のためにQAメンバーが（も）大事にしていること」をまとめてみます。

はじめに
1. プロダクトフェーズによってフォーカスするポイントを変える
2. フィードバック精度を高めるための情報を取りに行く
3. すんなりうまくいく確率をあげる
おわりに

1. プロダクトフェーズによってフォーカスするポイントを変える

Gunosyといえば「グノシー」を代表とするニュースキュレーションアプリが有名ですが、「LUCRA」や「オトクル」といったここ1~3年以内にリリースされ急成長しているアプリもあります。
後者の新興アプリのQAでは特に、「リリーススピードとリリース時品質リスクのバランス*1」をとることが重要になってきます。
プロダクトリリースの目的は「施策の仮説が市場に受け入れられるかを検証すること」に主眼が置かれるため、QAの活動目的も「施策の検証を妨げるリスクを許容範囲まで減らすこと」になります。
そのため、機能・要件充足だけに目を向けるのではなく、施策の背景を理解した上で主要価値を妨げるリスクを特定することを心掛けています。

2. フィードバック精度を高めるための情報を取りに行く

QAは「フィードバック」という行為を通して主な価値を発揮すると考えています。特にスピードが重視される状況で、「しょうもないバグを直してくれ！」といってエンジニアの士気を下げ、POの意思決定を阻害することは避けねばなりません。
そのため、フィードバックの内容とタイミングの適切性を高めるために以下のINPUTを意識的に行うようにしています。

事業動向とその影響要因を把握する

Gunosyではどのプロダクトチームも朝会で主要な事業KPI(獲得数,継続率,DAU,Sales/DAU,etc.)、ユーザーのアクティビティ(imp,click,起動間隔,プッシュ開封率etc.), クラッシュ率などを確認しています。
また、毎週「数値分析会」というA／Bテストの結果を議論し、次の打ち手を検討する会も行っています。
QAとしては、こういった機会を通して「仮にプッシュを送信できない障害が起きると、これだけDAUに影響がある」等、何がどうビジネス上の実害を引き起こし得るかという知見を得るようにしています。

事業課題と施策の関係性を理解する

どのチームも短期・中長期の事業課題をオープンな場でディスカッションする機会が設けられており、「何故いまこの施策を優先して行うのか？」をメンバー全員が理解した上で取り組むことを大切にする文化があります。
QAとしては個々の施策意図の理解に加え、施策の前後関係や既に走っている施策（A/Bテスト中の機能や、各種キャンペーン等）との組み合わせの影響にも着目するようにしています。
組み合わせの結果起こるリスクの洗い出しはもちろん、組み合わせ方によってユーザー体験が向上しそうなところはないか？も考えるようにしています。

ステークホルダーの動きをキャッチする

slackチャンネルは全社的に基本パブリックチャンネルのため、別部署のチャンネルにも自由に出入りできるようになっています。
QAもマーケ、営業、コンテンツ運用チーム等のチャンネルに参加し、プロダクトバックログアイテムとしてfixする前の企画の背景、クライアントへの提案状況（クライアントが気にしてそうなポイント）などをウォッチし、テスト要求分析の参考にしています。
また、事業部全体の振り返り会も毎週行っており、気になった点があればその場で気軽に質問できるので非常に助かっています。

ユーザーの反応を観測する

BtoCアプリを扱う性質上、ユーザーの反応を観測できる環境が整っています。（ストアレビュー、ユーザー問い合わせ、プロダクトに関するTweet通知BOTetc）
Gunosyでは役割に関係なくメンバー全員が上記に目を通し、異変があればすぐ調査を開始する文化が根付いています。
QAとしては、ユーザーのネガティブ系コメントをもとに「今後似た性質の施策が走るときに、事前に取れる策はないか」を考えます。
例えば、問い合わせリスクの高いリワード施策（〇〇するとプレゼント等）を行う時は、過去の問い合わせ内容をもとに仕様へのフィードバックを行ったり、PO/CSメンバーに対してFAQ拡充やお知らせバナー掲載等のアクションが有効かどうか相談するようにしています。

3. すんなりうまくいく確率をあげる

狙い通りの品質で狙い通りのリリースをできない原因の一つに手戻りがあります。QAとしても、手戻ってわちゃわちゃするリスクを早めに潰し、「すんなりうまくいったね」となる確率を上げるためのアクションが求められます。
とはいえ人数も少ないため、低コストで効果が大きそうなポイントに絞って、以下のようなアクションを取るよう心掛けています。

価値の明確化・シンプル化を促す

施策のキックオフMTGやバックログの棚卸しのタイミング等、施策の内容を詰める段階では、「どういう属性のユーザーに対する施策か、検証したい仮説はなにか、検証時の判断指標は何か」をチームで議論します。
tech.gunosy.io

QAとしては「検証したいことが明確であるか」「検証を妨げるリスクには何があるか」に着目し質問を投げかけるようにしています。
また、「検証単位がMVP (Minimum Viable Product)であるか」にも注目しています。
夢が膨らむ話に花が咲く時、エンジニア心理としては「技術的には可能だし、できるだけ要望を叶えてあげたい」といった優しい気持ちが芽生えがちです。
ただ、必要以上にプロダクトの複雑度が上がることでうまくいく確率が下がってしまわぬよう、「それってMVPに含まれる？」と強い気持ちで問うようにしています。

テストの議論を通してチームの納得感をつくる

施策のキックオフ後、テスト要求分析の成果物としてテスト観点マップ（テストの意図を図にしたもの）を作成し、ステークホルダーとあーでもないこーでもないといった話をする場を設けています。
主に、テスト内容の合意形成、要求やリスクの抜け漏れ検知、設計の見直し、ステークホルダー間の認識齟齬の解消などが目的です。（施策によってはデザイナーや営業・マーケ担当の人にも参加してもらい多方面からの意見をもらうようにしています。）
QAにとっては、テストをしなくても品質リスクを潰せてラッキーですし、
チームとしても「これから作ろうとしているもの」への解像度があがり納得感も生まれます。この納得感を持った状態で物事を推し進めることができるとすんなりうまくいく確率が上がる気がしています。

POの意思決定ポリシーをみんなで理解する

スプリント途中での急な差し込み等、想定外の意思決定がなされることがまれにあります。
そういった事案が起きた時こそ、「なぜその意思決定に至ったのか」を皆がいる場で根掘り葉掘り聞くようにしています。（※優しく聞いてます）
チームメンバー全員が「どんな制約の下、どのような考えでその判断に至ったか」を理解することで、次回以降POと同じ目線でアクションできる可能性がアップするためです。
POにとっては心が削られる場面の一つだと思いますが、こういった会話を積み重ねることでPOへの意思決定依存が減り、チームの機動力が高まりつつあります。
また、説明コストの低いハイコンテクストな会話でチームが回るようになるため、情報伝達効率もアップします。

「これは罠」を蓄積し、みんなで振り返る

今期より一部のチームで不具合分析活動をはじめました。
「これは罠」というトラップの知見をためてチームで振り返ることで、同じ過ちの繰り返しでビジネス上の実害を生むリスクを減らすためです。
先日LUCRAチームでは第一回の四半期振り返り会を行い、本番障害原因の掘り下げ・リリース前不具合の傾向、どういったトラップで不具合が生み出されがちか？などを振り返りました。
また、「早期に見つける不具合のほうが修正コストが安いよね」という前提や品質コストの考え方などの話も踏まえた上で、今後の改善アクションアイデアを話し合いました。