QAスクラム活動報告(2020年4月〜7月)

こんにちは。
株式会社LibryにてQAエンジニアをしている大村です。

今回は、2020年4月から7月までやってきたQAスクラムの活動についてご紹介しようと思います。
QAスクラムとは、弊社の全サービスのQA業務を効率化および改善などを目的に発足したスクラムチームです。

Why？

なぜQAスクラムをやることになったのかというと、実は2019年までQA業務はPO（プロダクトオーナー）が管理し対応していた経緯がありました。

というのもLibryのサービス状況は、一般的なBtoCサービスのように急激なサービス拡大およびユーザー数増加とは異なり、大きなリリースは約半年に一回とユーザー数も学校の年度始まりである4月頃に増加するので、QAを実施するリソースの準備が難しかった現状がありました。

累計フローダイアグラム

直近の大きなリリースのリスト

そのため、これまでPOがリソース調整し、そのときの状況によってテスト作業者を用意して一緒にテストしてリリース判断を決め、Libry全体の品質状況をPOが一番把握している対応をしていました。

ですが、今後のスケールを考えると流石に限界ということで新たにQAチームを立ち上げ、チームの中でスクラムを実施しながら『急激なサービス拡大およびユーザー数増加、それにより開発メンバーが増えたときにも柔軟にQA業務ができる環境ができる』体制を作ることを目標に4月から活動をはじめました。

目標設定

4月に2021年までの新たなマイルストーンが確定し、8月頃に次の大きなリリースが予定されたため、8月までに一般的なQA業務の環境が最低限できていることを必須とし、さらにMVV（Mission / Vision / Value）をもとに目標設定を行いました。

MVV（Mission / Vision / Value）

引用：https://vision-cash.com/keiei/vision-mission-values/

一般的なQA業務として、「リグレッションテストできるテストケース」「次のテスト計画」「新規機能テストのテストケース作り」「テスト実施とフィードバック対応」などをイメージしていました。
また、ただこれらができるようにするのではなく、ワークフローやマニュアルなどを一緒に作っていくことも必要不可欠だと考えました。

IT業界内の企業で会社の経営理念などに使われているMVVですが、スクラムをやっているプロジェクトやプロダクトでもMVVを活用するとプランニングやレトロスペクティブなどで効果があると思いやってみました。

一部抜粋ですが、以下のようなMVVの達成を目指すことにしました。
ビジョンが先にある理由は、ビジョンがあってミッションができるイメージをしているためです。

V: ビジョン
- Libryアプリが安全にリリースできる。
M: ミッション
- リリース日から5日前で品質チェックが終わりリリースできる品質であることを証明できる。
  LibryアプリがSTG環境でデグレが起きる件数が3件以下に減る。
V: バリュー
- リリース前に実施する品質チェック作業（テスト、フィードバック、再テストなど全て含め）が最短5日で終われてリリースできる品質であることを証明できるようになる。
  前回の品質チェック作業との差分を可視化でき、次のリリース時にQA業務がスムーズに実施できる環境ができるようになる。
  STG環境へデプロイする前にツールなどを駆使して最新の開発ブランチで定期的にテストが行えている。

QAチームのスクラム体制

幸いなことにスクラムで必要なPO・スクラムマスター・開発チーム1名、スクラムの最低人数3名を集めることができたためスクラムチームが作ることができ、私は開発チームのメンバーとして参加しました。
ですが、POは開発スクラムを兼任してQAスクラムを実施する形になったので、各スクラムイベントに対して次のような工夫をし、リソースを最適化することにしました

インセプションデッキやエレベーターピッチの作成代わりにMVVを作成
プロダクトバックログプロダクトバックログとスプリントバッグログを1つにまとめたバックログをスプリントバックログとして活用
スプリントレトロスペクティブ課題などの共有は「デイリースクラム」で行い、改善については「スプリントプランニング」で一緒に実施
インクリメント必要に応じてスプリントプランニングで実施

活用しているツール

スクラムでは、バッグログやスプリント管理、ドキュメント管理など作業しているとツールの活用は必要不可欠です。
現在は、主にJiraでスクラムを実施しており、「ロードマップ」「バックログ」「ボード」「レポート」「ページ」機能を日々活用しています。
この「ページ」機能は、Confluenceに連動しているため正確にはJiraとConfluenceを活用しています。

また、弊社ではConfluenceを活用する以前からドキュメント管理はesaを活用していたため、QAスクラムでは次のルールに基づいてドキュメント管理をesaとConfluenceの両方を活用することにしました。

esa社内展開したい情報
開発チームに共有したい情報
ツールやサービスのマニュアル
Confluence
QAスクラムのみ関連する情報例: MVVやスプリントプランニングなど

ストーリーで発生する情報（※ただしesaにまとめるべきものはesaで管理する）例: テスト計画やMTGの議事録など

ロードマップ

MVVのミッションに関連するやるべきことの大項目を洗い出し、その各項目をエピック化して管理しました。一部ではありますが、次の項目が実際にエピック化したものになります。

QA業務の作業工程
品質OK判断の共有
テスト計画
不具合リスト管理
テスト準備
テスト開始
CI/CD対応
リグレッションテストの自動化
パフォーマンス計測

これらのエピックに関連するストーリーを必ず紐付かせて、エピックに関連しないストーリーがなるべく出ないようにすることで、常にエピックの見直しと無駄なリソースが発生しないように注意していました。

バックログ

ストーリー名には、一目で分かるように「スプリント番号」をタグ付けするようにしました。
例えば、『[S1] QAスクラムのMVVができる』と設定することで1週目のスプリントであることがスプリント名ですぐに把握できます。

※ スプリント番号タグ付例

これは、スプリントプランニングでページ上にストーリーのリンクを貼ったときに、自動的にリンクがストーリー名に表示変換してくれるJiraの機能を最大限に活用できると考えました。
また、ストーリーの詳細に「概要/目的」「Doneの定義」を書き込むようにし、ストーリーの詳細を常にスクラムチーム内で同じ認識を持てるように徹底するようにしました。
もし、ストーリー内で小さい作業が発生し、1ストーリー内で管理することが難しいときのみ、ストーリー上の「子課題を追加」からタスクを発行することにしました。

ページ

スプリントプランニングのページの場合は、ストーリー名同様に何週目のスプリントなのかといつ実施したのか一目で分かるように「次のスプリント番号」「年月日」をタグ付けするようにしました。
例えば、『[S2] 2020-04-07 スプリントプランニング』と設定することで管理するようにしました。
また、ストーリー内で発生した情報をページで管理した際には、これも一目で分かるように「ストーリー番号」「ストーリーID」をタグ付けするようにしました。
例えば、『[S1][QA-1] 2020-04 ~ 2020-08 MVV』と設定することでいつ何のために作ったドキュメントなのかをストーリー名で把握できるようにしました。

QA業務

先ほど「QA業務の作業工程」「品質OK判断の共有」「不具合リスト管理」をエピック化したとご紹介しました。
今回の目的は、『8月までに一般的なQA業務の環境が最低限できていること』なんですが、8月リリース予定前に実施するテストを準備するだけでなく、ほぼPOがワンオペしてきたQA業務を可視化させて、PO以外でもQA業務が担当できるような環境を作る必要がありました。

属人化の脱却

どんな仕事や組織でも属人化は発生してしまい、属人化にも「なるべき属人化」と「危険な属人化」があると思います。
POは属人化しやすい業務が多く発生しがちな役割ですが、QA業務がPOに属人化している状態に関しては「危険な属人化」と言えるので、一刻も早くトラブルなく業務を引き継ぎたい思いがありました。

属人化してしまっている業務というのは、そう簡単に引き継げるものではないため、まずは属人化している人から情報を引き出し、業務の詳細を全て把握する必要があります。
特に今回、POからQA業務に関して引き出すべき情報について「どんな作業をやってきたのか」「不具合以外に気になる箇所を見つけた際にどんな判断をしてきたのか」「現状のサービス品質について」などを聞き出さないとテスト計画を作成することが困難だったため、POから約一月ほどQAに関する情報を聞き出して可視化していきました。

テストの基準をどうするか

これまでPOが担当してドキュメントも履歴も残っていないテストの可視化を進めるにあたり、今後の状況に合わせてどこまで・何をマニュアル化やワークフローの整備を行えば良いのか、各スプリントのプランニングで話し合いながら全メンバーの認識を合わせて進めていきました。

現状の品質を確認するテスト（リグレッションテスト）ケース作り

「どのように作るのか」「どのくらいの粒度で作るのか」「どのように管理するのか」など、色々と話せるネタである『テストケース作り』ですが、これまでPOがやってきたテストを可視化させることが最優先であったため、よく使われるスプレッドシートを用いてテストケースを作ることにしました。

まずは、テストケースの詳細をざっくりと決めて、一部ではありますが今回は次のような項目の列を作ってユーザが操作する機能全てを実際に触りながらテストケースの雛形を作りました。

No, 画面, 確認する機能, 前提条件, テスト操作, 期待値, プラットフォーム, 作業日, コメント

これまでPOがやってきたテスト内容を完成した雛形と照らし合わせて、差分を見つけてマージする作業を実施して完了することでリグレッションテストがいつでもできるテストケースの完成です。

最近だと、脱Excel・スプレッドシートとしてZephyrやTestRailなどのサービスを用いることも考えられますが、テストケースを作りながらサービスの導入・学習・管理をするには各コストがかかってしまう懸念があり、実際に個人アカウントでやってみたところ、やはりその懸念は晴れませんでした。
スプレッドシートでテストケースを作れば後から比較的移行しやすい状況になります。
また、並行して他の優先度の高い作業ができるなどのメリットもあって、このような判断をしました。

おそらく、テストの規模や内容が拡大すると以下の記事のような状況になると思いますが、当面はスプレッドシートとGAS（Google Apps Scripts）の活用で運用できる見込みです。

テストのワークフローとマニュアル化

ただテストケースを作っただけでは、POからQAに関する全ての業務を巻き取ることはできません。

テストする前とテストした後でどんな作業をしていたのか、エンジニアとどのようなコミュニケーションをとってQA業務ができていたのかなど、業務に関する情報をもう少し可視化する必要があると感じ、テストのワークフローおよびテスト作業のマニュアルを作成することにしました。

開発→テスト→リリース→デプロイの各フロー前後でどんな品質管理を実施するのかを考えました。『QAとしてどんな作業工程が生まれるのか』について洗い出した結果がワークフローとなり、テスト作業者のリソースを柔軟に確保できるようにしたかったことからテスト作業者が「どこまで」「何をやったらいいのか」などが分かるマニュアルを用意することで、順調にPOからQA業務を巻き取れるようになりました。

それ以外でやった/やれなかったもの

上記ロードマップでご紹介した他のものについて、「CI/CD対応」は4月以前からMacBookProにJenkins環境を作り、リソース準備→ビルド→UIテスト（Appium）→Firebase App Distributionでデプロイまで一通りCI/CD対応が完了してました。あとは、運用やセキュリティなどを対応して完了予定だったのですが、コロナによりフルリモートワークとなり、社内ネットワークでしか扱えないJenkinsが活用できなくなりました。
ちなみに、Jenkinsを採用したのは一刻も早く自動化を実現したかったためです。

Jenkins環境が動いているPCを会社外からでもアクセスできるようにネットワーク対応も考えましたが、コロナの感染リスクを考えるとやるべきではないと考え、Jenkins/Firebase App DistributionからAzure Pipelines/App Centerに移行することにしました。

「リグレッションテストの自動化」「パフォーマンス計測」については、POからテストに関する業務を巻き取るタスク及びCI/CDに関するタスクを優先したため完了できず、現在も引き続き作業を進めています。

最後に

以上、簡単にですがこれまでのQAスクラム活動を振り返ってみました。スクラム活動する中でわかった事として、次の内容がありました。

フルリモートワークでコミュニケーションが減ったことによって、いつもよりデイリースクラムの精度を上げたり、作業履歴を残すなどしてやったことの見える化をしないとスプリントが上手く回らないことがあった。
限られたリソースでスプリントを回すことによって、余裕が無くなり他メンバーよりも目の前のタスクやストーリーに集中しがちになってしまうため、定期的に他ストーリーの状況を確認して助け合いが必要だった。

また、やってよかったと思った事としては、次の内容がありました。

Jiraで発行したストーリーやタスクに対してコメントを書ける機能を活用し、メンバーのコメントの他に作業履歴やメモなどを徹底的に記入するように運用したことで、レビュー会やプランニング会などで活用できました。
Jiraでスクラムを運用しているとストーリーやタスクの「担当者」を素直に使いすぎてしまい、各メンバーが担当のストーリーやタスクだけを管理して作業しがちになってしまいます。限られたリソースでスクラムをやったということもあり、この点については注意することができました。

最後まで読んでいただいた方にはおわかりかと思いますが、現在のQAスクラムでは通常やるべきスクラムイベントの一部をリソースや兼任などの都合からやっていません。
ですが、大きなトラブルなく目標通りに一般的なQA業務の環境が最低限できている環境は整備できてきたため、やってよかったなと感じています。

まだまだ課題がありますが、これからもQA業務の品質を上げるため、QAスクラムを続けていきます。

株式会社Libry's job postings

QAスクラム活動報告(2020年4月〜7月)