見出し画像

【PdM×QA】QAチームがいなくても品質と改善スピードを維持する方法

藤澤桃子

こんにちは、コネヒトでプロダクトマネージャー (PdM) をしている藤澤です。

コネヒトアドベントカレンダー2022の12日目の投稿として初めてnoteの記事を書いてみることにしました。

この記事は

  • 社内にQAチームがいない小規模組織のPdM

  • 今まで主に自社完結サービスを作っていたのに、突然他社（クライアント）が絡むプロダクトを作ることになった開発チーム

に読んでいただけるとうれしいです

私が担当しているサービス

私は　ママリのプレゼントキャンペーンサイト　を担当しています。
このキャンペーンは、申し込むと抽選プレゼントや全員プレゼントがもらえ、申込時のアンケート回答に沿って後日協賛企業からサービスの案内が来るという座組みになっています。
ママリはキャンペーンにより協賛企業（クライアント）とユーザーをつなぐ役割を担ってます。

QAのやり方がわからない…！

数年前、突然PdMに任命され、他社が絡むWebのキャンペーンサイトを担当することになりました。
PdM業務全般に四苦八苦しましたが、特に困ったのがQAでした。

その頃は自社プロダクトがほぼtoC向けだったこともあり、toB向けに近いサービスのQAの知見がない状況でした。

そのため、自作のQAリストをイチから作って新規サービスのリリースをしたのですが、案の定用意したリストに漏れがあり、先輩たちには見えていた「危なそうなポイント」や「網羅すべき観点」が自分には見えていないことを実感しました。

また、その時リリースしたのが利害関係のあるクライアントが存在するサイトだったこともあり、それまで社内でメインだったtoC向けサービスとクライアントのいるサービスとでQAのやり方を変える必要があることにも気づきました。

みんなはどうやってるんだろう？

その後、新サービスリリース時の反省を活かすため、QA方法をネットで探しまくったのですが社内にQAチームがいる前提で書かれている記事が多く、それもQAチームがない自分の組織で取り入れるイメージがつきませんでした。

私達がたどり着いたQA方法

当時は新規事業を進めていたため、自分も開発チームも初めてすることが多く、リリース後も「あわや」な瞬間が何度もありました。

その度に振り返りMTGを開き、再発防止策を講じたり、QA方法をアップデートするということを繰り返し、自分たちなりに「今の段階でもっともよさそうな」QA方法にたどり着きました。

書き出してみると当たり前のことばかりですが、私と同じようにQA迷子になっている新米PdMのみなさんのお役に立てれば幸いです。

① まずQA実施日と参加者を決める

PdMと担当エンジニアはもちろん、大切だと感じたのはクライアントの期待値を最も理解している営業担当を招待することです。
営業↔開発間で認識のズレがあった場合など気づくことができます。

② 1回めのQA：優先度をすり合わせる

こんな感じで優先度をQAリストに明記します

サイトの中でも特に慎重にチェックすべき所をQAの最初にチームで認識合わせをし、そこを特に重点的にチェックするようにしました。
クライアントがいるサイトなら、報酬をいただくカギになる部分やクライアント側のオペレーションに関わるところが「重要なところ」に当たると思います。
また最初に特に慎重にチェックすべき所の認識をあわせておくことで、エンジニアにしつこく確認することが許容されやすくなると感じています。

③ 1回めのQA：シナリオに沿って操作する

ユーザーの行動をシナリオにしてQAをする…までは最初からできていたのですが、見落としがちなのがクライアントの手に成果物がわたるまでをシナリオにするということ。
例えば私達のサイトの場合やキャンペーンに申し込んで終わりではなく、そのユーザーが見えない部分で起きることももれなくQAリストに入れるようにしています。

④ 1回めのQA：最も使われているブラウザで確認

「iOSでもAndroidでも確認してるから安心♪」と思っていたら痛い目に合いました。ブラウザも掛け合わせて見る必要があるんですね…
とはいえ、ネットで推奨されているように全ての組み合わせをテストしていると切りがないので、すでに存在するサイトに対して変更をかける場合は、よく使われているOS×ブラウザの組み合わせ第2位くらいまででQAをするようにしています。

⑤ 1回めのQA：QAでわかった必要な対応を整理

QAを実施して改善が必要な箇所を洗い出したら、対応に必要なおおよその工数（デザイン工数含む）を出して対応の優先度を付けます。
やる / やらない / 余裕あるならやる / リリース後にやる　の4つに分けたら、タスク化して開発へまわします。

⑥ 修正して2回めQAを実施

改善箇所が多い場合は2回めQAを実施します。

⑦ リリースフローを決める

リリースフローはエンジニアや営業チームと一緒に決めます。
・サイト流入を止める必要があるか？
・必要な事前準備
・時間きっかりに切り替わる必要があるか？
などを考慮して
リリース前後に確認することと担当者を実施日時とともにリスト化します。

理想を極めるよりバランスを重視

私の場合、インシデントやインシデント未遂を起こすと気持ちが萎縮してしまい、「万全の対策をして同じインシデントを起こさないようにしよう」と考えがちでした。

が、危ない体験が起きるたびに理想を極めた再発防止策を設定しているとやることがどんどん増えていき、とられる時間が増えていく…そして本質的な改善使える時間が減ってしまうということに気づきました。

その結果、すみずみまでカバーした理想のQAリストを作るより、特に重要な部分をしっかりと抑えたリストを作ることで、品質と改善スピードを両立させる方法にいきつきました。

小さな組織で品質とスピードの問題で困っているPdMの方がいたらぜひ参考にしていただけるとうれしいです！



この記事が気に入ったらサポートをしてみませんか？