LINE Research and LINE Survey QA practice in the upstream process

LINE Developer Meetup #71 - QA
https://line.connpass.com/event/204944/
2021/3/16

LINEリサーチ/LINEアンケートにおける 上流工程でのQA実践とその先にあったもの
後藤 瑞希 (LINE Fukuoka)

Transcript

1. LINEリサーチ/LINEアンケートにおける 上流工程でのQA実践とその先にあったもの LINE Fukuoka QA Engineering室 後藤瑞希 2021.03.16
2. 00.このセッションについて QAチームが上流⼯程で 実践している 品質活動の共有 その活動を通して感じたこと 内容 プロセス品質を 向上させることが QA Engineerの本質 伝えたいこと
3. 00.このセッションについて 私たちのチームではAgile開発の⼿法である「Scrum」に則った開発に取り組んでいます。 チームで⾏っている「Scrum」は教科書通りのかたちに最⼤限近い形でやろうとしていますが 複数のチーム(企画、バックエンド開発、フロントエンド開発、QA)からなるプロジェクトの中で 100%教科書どおりの型を当てはめられない部分があるため 無理なく実践できるよう試⾏錯誤しながら取り組んでいます。
4. はじめに これまでの道のり 上流⼯程での実践内容 その先にあったもの おわりに 01 02 03 04 05 Contents
5. ⾃⼰紹介 後藤 瑞希 LINE Fukuoka/QA Engineer 前職︓ケーキ屋、お⾁屋さん、アパレル、ラーメン屋…など 2019/2︓LINE Fukuokaに⼊社(Test Engineer) ※⼊社時からLINEリサーチ/LINEアンケートを担当 2020/5~︓QA Engineerになる @GTOmizuki
6. LINEリサーチ/LINEアンケートについて 「LINEリサーチ」は、企業における事業開発・マーケティング活動の最⼤化を⽬的にした、 スマートフォン時代のリサーチプラットフォーム。 現在、LINEリサーチのモニターとして約540万⼈※が登録しており、 国内でも最⼤級のアクティブな調査パネルを有するサービス。 福岡ではそのサービスのバックエンドおよびリサーチャー向けCMSツールの開発、QA業務を担当 ※2021年2⽉時点
7. はじめに これまでの道のり 上流⼯程での実践内容 その先にあったもの おわりに 01 02 03 04 05 Contents
8. 以前の開発プロセス 02.これまでの道のり 開発プロセスと役割分担 設計 実装 仕様検討 要件定義 テスト 企画・開発チーム(Scrumを導⼊) QAチーム 1Sprint 1Sprint
9. QAチームが感じていた問題点 ユーザーにより価値があるものを届ける必要があるのでは…︖ 02.これまでの道のり 軽微なバグや UXに対する改善の 優先度が下がり 後回しになる テストフェーズの進捗によって スケジュールを 調節することが多い QAチームが ミーティングに参加しても 効果的に関われない 「チームの⼀体化」が必要
10. 解決策 QAチームが「開発チームの⼀員」としてScrumに参加 開発チームとして⼀緒に動くことで、より価値があるもの素早くリリースする体制を⽬指す 02.これまでの道のり
11. 現在の開発プロセス 02.これまでの道のり 開発プロセスと役割分担 設計 実装 仕様検討 要件定義 テスト 企画・開発・QAチーム 1Sprint
12. 現在の開発プロセス 02.これまでの道のり 開発プロセスと役割分担 設計 実装 仕様検討 要件定義 テスト 企画・開発・QAチーム 1Sprint
13. はじめに これまでの道のり 上流⼯程での実践内容 その先にあったもの おわりに 01 02 03 04 05 Contents
14. 設計 実装 仕様検討 要件定義 テスト 企画レビュー ・企画の狙い、ユーザーに与える価値は︖ ・現⾏仕様との⽭盾点は︖ 実装/テスト⽅法の検討 ・実装箇所の認識は合っているか︖ ・どこに影響がありそうか 仕様書レビュー ・曖昧、誤解を与える表現がないか︖ ・具体化されているか 03.上流⼯程での実践内容 実践例
15. l 実装前にCriticalなIssueの防⽌ l 早期からの指摘で企画チームの⼿戻り軽減 l Incident対応など、不要な⼯数を削減 l テスト設計の品質向上 プロダクト品質以外の部分にも良い影響を与える 03.上流⼯程での実践内容 上流⼯程に関わることによって狙っていること
16. 以前の開発プロセス チームを⼀体化した後 l 軽微なバグや改善が後回しになる l テストフェーズの進捗によって スケジュールを調節することが多い l MTGに参加しても効率的に関われない l 登録したバグや改善はすぐに対応する l 無理なくスムーズなテストフェーズの進⾏が可能 l 開発/QAチームがスムーズに着⼿可能 03.上流⼯程での実践内容 以前との変化
17. QAチームが各プロセスに関わることは⼤きな利点がある 質問「QAチームについて企画・開発チームが思っていること、助かっていることを教えてください」 l 仕様分からない時やなぜ現状の実装になっているのか教えてくれる l 企画のざっくり要件をもとに「どうあるべきなのか」想定して事前レビューをしてくれる l 想定外の使い⽅が運⽤で発⽣した際に問題なく実施できるかを検証してくれる l 全体の良いタイミングでリリース対象・スケジュールなどの調整をしてくれる テスト以外の部分で「助かっている」と感じていることも多い 03.上流⼯程での実践内容 企画・開発チームからの声
18. はじめに これまでの道のり 上流⼯程での実践内容 その先にあったもの おわりに 01 02 03 04 05 Contents
19. 開発チームが感じたこと 04.その先にあったもの 「実装機能に対して、全員が最後まで責任を感じるようになった」 以前の開発チーム l ⾃分たちの実装、ユニットテストを終わらせることに集中 l テストフェーズのスケジュールについて関⼼が低かった 現在の開発チーム l リリースで品質を確保するためにテストスケジュールまで踏まえた 実現可能性を⼀緒に考えるようになった
20. 「問題・課題の捉え⽅が変化した」 以前のQAチーム l 企画/開発チームに相談しても忙しいから対応してもらえないだろう l ⼿が空いたときに出来ることだけQAチーム内でやろう 現在のQAチーム l 各チームの問題は、プロジェクトメンバー全員の問題 l 全員で⽴ち向かった⽅が⾊々な解決策が⾒える QAチームが感じたこと 04.その先にあったもの JaSST Kyushuで和⽥さんの講演を受けた時の話を紹介
21. 「質とスピード」〜ソフトウェア開発の典型的な誤解を解く〜※ l 質を犠牲にするとき犠牲にされがちなのは「内部品質(保守性)である」 →内部品質が下がるとスピードが落ちる l コードの品質を⾼く保つからこそスピードが上がり、リードタイムの短縮につながる l 質とスピードの関係はトレードオフではない ※https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition 講演内容 04.その先にあったもの
22. QAチームの「内部品質」ってなんだろう…︖ テストケースの品質 l 期待結果が古い l 間違った画像が載っている l 他者が⾒た時にテストステップが分かりづらい 作業の品質 l 繰り返し⾏う単純/簡単な作業を⼈⼿で対応 l ⼈⼿の対応が必要な作業でミスや勘違いが発⽣ 受講後に私が思ったこと QAチームの内部品質を上げることでリードタイムの短縮に繋がるのでは…︖ QAチームの内部品質改善を対応 04.その先にあったもの
23. QAチームが別軸で稼働していた時には「プロダクト品質」しか⾒えなかったが チームが⼀体化してからは「チームのために何ができるのか」に意識が向くようになった。 チームが⼀体化したことで ⽇々のコミュニケーションが強くなり、信頼関係が⽣まれ お互いに相談や悩みを共有しやすい 「1つのチーム」となることができた。 「QAチームの課題」＝「チーム全員の課題」 04.その先にあったもの
24. はじめに これまでの道のり 上流⼯程での実践内容 その先にあったもの おわりに 01 02 03 04 05 Contents
25. 05.おわりに プロダクト品質 プロセス品質 開発プロセス全体に関わり、プロセス品質を向上させることで プロダクト品質を⽀える
26. 「QA」=「テスト」というイメージの強さ l プロダクト品質を向上できる最初の⼀歩を邪魔しているかも l チームメンバーの影響＋LINE STYLE＋未経験QA Engineer 「QA Engineer」=「品質を保証する」 l ユーザー⽬線の提案、バグの検出→お仕事の⼀部 l プロダクトを作るチームの品質にも貢献できる 05.おわりに 「QA」という役割について QA Engineerが⼒を注ぐべきターゲットは開発プロセス全体
27. THANK YOU