! This post is also available in the following language. 韓国語

デュアルQAプロセスを紹介します

こんにちは。LINE PlusサービスQAチームのKIM JIN HEEです。同じチームのKim Woo Youngさんと一緒にオープンチャットのQA(Quality Assurance、品質保証)を担当しています。LINE Plusで働き始めて8年くらい経ち、オープンチャットのQAを担当してからは4年くらいになります。今回の記事では、オープンチャットとは何かを簡単に説明し、オープンチャットで進めたQAプロセスについてお話しします。その後、今回のテーマであるデュアルQAプロセスについて解説し、このプロセスをどのようにオープンチャットQAに適用したのか、適用した後の結果はどうなったのかについて紹介したいと思います。

オープンチャットとは

LINEのトークが、友だちとして登録されている知り合いとのチャットサービスだとしたら、オープンチャットは、同じ興味を持っている友だち以外とも自由にトークできるチャットサービスだといえます。オープンチャットは、トークとほぼ同じ機能と性能で提供されていますが、タイムラインへの投稿機能や、参加したいオープンチャットの検索機能やレコメンドも存在します。その他にも流入元となるオープンチャットのトップページ(Webメインと呼びます)も提供しています。現在はiOSとAndroidについてQAをサポートしており、非定期的にサーバーやWebについてのQAにも対応しています。

余談ですが、オープンチャットは現在、日本と台湾、インドネシア、タイでサービスしていますので、これらの地域の方にはオープンチャットをご利用いただければ幸いです。

オープンチャットのQAプロセスの変遷

ここからは、オープンチャットのQAプロセスがどのように変化してきたかについてお話しします。

プラットフォームごとの担当QAプロセス

オープンチャットの提供を開始したときは、LINEに各プラットフォームごとにQA担当者がいました。オープンチャットの初期には、チャット機能のみだったので、ありがたいことに通常のチャットのQA担当者にオープンチャットのQAまで行ってもらいました。AndroidとiOSの通常のチャットのQA担当者が、それぞれのプラットフォームのオープンチャットQAまで担当したのです。 

当時は、QA業務がプラットフォームごとに分離されており、テスト組織もプラットフォームごとに分離されていたため、本人が担当しているプラットフォームのQA日程や案件に、より集中できる環境でした。各プラットフォームごとに個性のあるプロセスやさまざまなテスト方法論を試みることができ、同じサービスを担当しているQA間の仕事のスタイルが異なっても大して問題はありませんでした。ただ、LINEアプリは2週ごとにクライアントをリリースしていますが、そのサイクルに合わせるには、現在のバージョンについてQAを行いながら次のバージョンを準備する必要があったため、時間の余裕はありませんでした。

シングルQAプロセス

次に採用した方式は、シングルQAプロセス方式でした。おそらく多くのサービスが今もこのような方式でQAを行っていると思います。

オープンチャットは、オープン後にノートやWebメインのようなさまざまな機能が追加され、通常のチャットとは少しずつ差が出たため、専従のサービスQA担当が必要になりました。そのときから私が本格的に進めることになりました。シングルQAプロセスは1人で担当するので、本人が希望する方向へプロセスを進めることができ、自分の日程だけ考慮すればいいので、 自分さえ良ければいつでも速やかに対応できました。ただ、担当者に急に業務が集中したり、担当者の不在時には代わりになるスタッフがいないため、サービスの面でも個人的な面でも不便がありました。

機能ごとの担当QAプロセス

3つめに採用した方式は、機能ごとに担当を分ける方式でした。少しずつ機能が増えていったオープンチャットは、サポートする国が増えるにつれ各国ごとに機能を差別化する過程を経て、いつの間にかボリュームが非常に大きくなりました。それに対応するために、もう1人のQAが追加で投入されました。QAが追加されてからは、2人のQAが機能ごとに業務を分けて担当しました。

しかし、その後サービス企画や政策の方向に変更が出て機能の片方だけ改善が続いてしまい、特定のQAに仕事が集中する状況になりました。また、業務を機能ごとに分けたため、同じサービスを担当しているのに自分が担当する機能でなければ、その機能の履歴をきちんと把握できず、1人が不在になるとまともに対応できない状況になりました。リソース管理の効率が良くなかったのです。

デュアルQAプロセス

こうしている中、残念なことに私のペアが転職してしまいました(もっといいところに…と言ってはいけませんよね? LINEが一番いい会社ですから (スマイル))。そのため、私は再びシングルQAに戻りました。この時期はちょっと短かったです。まもなく、LINEのQAであるNam JoongSeopさんがデュアルQAプロセスということを公開したためです。公開されたプロセスを見てみたらすぐ適用してみたいと思い、ちょうどチームに新しく入ってきたKim Woo Youngさんと一緒に進めることになりました。 

このプロセスを適用してみたかった理由の1つは、オープンチャットの特性のためです。オープンチャットは、LINEの他のサービスに大きく影響されます。トーク一覧やトークルーム、メッセージなどは、通常のトークと関係があり、ノートはタイムラインのコードベースなのでタイムラインのリファクタリングや機能の追加が自動的に反映されています。それ以外にもスタンプショップ、ホームタブ、アカウントなど、さまざまなサービスに関係があります。このように関連のサービスが多く、各サービスで何かの案件をリリースするたびに影響を受けています。その過程で、いろいろな事情で情報共有が遅くなるときもあったり、事前にきちんと共有されたとしてもいざ私のほうで準備する時間がない場合があります。そのため、このようなことを事前に把握してテストの計画やケースを作成し、テスト環境の構築が必要な業務環境が負担で困難な状況でした。そういうときにデュアルQAプロセスを適用すると、2週間という時間を稼ぐことができるそうなので、このプロセスを採用することにしました。

デュアルQAプロセスの紹介

まず、簡単にプロセスについて説明します。LINEアプリのクライアントのリリースサイクルは2週で、1つのサービスに担当QAが2人アサインされます。2人のQAがそれぞれ担当するバージョンを決めて交互にQAを行いますが、バージョンナンバーを基準に奇数の担当と偶数の担当がいるわけです。今回のバージョンをQA Aが担当したとしたら、次のバージョンはBが担当するパターンでプロセスが進められます。自分が担当するバージョンのQAが完了すると、翌日からは他のQAが作業するので2週間の時間が得られます。この2週間の間、自分が担当するバージョンに適用する企画や開発案件をレビューし、テストを準備します。以下は、デュアルQAプロセスを簡単に示した図です。 

上記の図で企画レビューは、次のバージョンに関する計画と関連文書をもらってレビューを行い、機能を確認した後、具体的にテスト計画を立ててペアにテスト計画のレビューを受ける段階です。次に開発レビューは、次のバージョンの開発進捗を確認し、開発者と一緒にテスト方法について議論して開発案件の範囲と影響、リスクを確認したうえでテストの計画を具体化する段階です。また、サ二ティー(sanity)テストを準備して、開発側と日程を調整しながら実施できるようにガイドを行い、開発側に相談が必要な部分は依頼することもあります。

上記の2つのレビューは、前述の他のQAが作業する2週間だけで進めることではありません。それより前もって行うことになります。デュアルQAプロセスで得た2週間には、企画レビューと開発レビューが完了した状態で、テストにより適した、QA期間により簡単で安全にバグを発見しやすい環境を構築するための作業を行います。もう一言付け加えると、デュアルQAプロセスを適用するとQAスタッフは2人がアサインされますが、テスターの人数は以前と変わらないため、QAがテストの準備をすべて完了する必要があります。

オープンチャットのデュアルQAプロセス適用事例

以下は、オープンチャットで行ったデュアルQAプロセスの適用事例です。 

前述のようにそれぞれ担当するバージョンを決めて交互に進めます。QA Aが偶数バージョンを担当すると決めた場合、1.0.0を担当した後は1.2.0を担当することになります。このとき、iOSとAndroidを両方とも担当することになり、もしその期間にサーバー側からQAを依頼されるとそちらも合わせて進めます。以下は、より具体的に業務を分けたものです。

基本的に、まずQAを行う仕様についてキックオフミーティングとレビュー、開発協議などが行われます。この際、QAが2人とも参加して一緒にレビューを行います。その後、1.0.0 QA期間になると当該バージョンの担当者Aは、2週間そのバージョンのQA状態を報告してサインオフ(QA Sign-off、QA完了)を行い、その間もう1人のQA Bは次のバージョンのテスト文書を準備します。Bは文書の作成を完了した後、QA Aにレビューをリクエストし、QA Aは1.0.0 QAを進めながらQA Bが作成した文書をBと一緒にレビューします。このとき、QA Aはすでに以前行った関連のミーティングにBと一緒に出席しているので、状況が全く把握できない状態でレビューを行うことにはなりません。この過程で自然にQA Aは次のバージョンのQA一覧まで確認でき、今行っているQA案件のうち次のバージョンに影響を与える案件をリアルタイムで確認できます。

以下は、業務一覧をまとめたサンプルです。

プロセスを開始する前に今回のバージョンと次のバージョンの担当者がお互いどのように業務を分担すればいいか定義しておいたほうがいいと思い、それをまとめて協議した結果です。この業務一覧は継続的に更新、管理しています。

デュアルQAプロセスを導入する際に必ず守るべき3つのポイント

デュアルQAプロセスを導入して実行するうえで、必ず守るべきだと思ったことが3つあります。

文書の品質を確保する

まず、2人のQAが作成する文書の基本的な品質が保証されるべきだと思います。1つのサービスを2人のQAが交互に実施するため、作成される文書の品質やスタイルにおいて大きく差が出ることもありますが、このような場合はレビューのときに時間が多くかかるなど業務に負担をかけることがあります。また、問題が発生して私が作成したテストケースが次のバージョンに延期され、次のバージョンを担当するQAが進めることもあります。このとき、テストケースがバージョンごとにあまりにも違うものになると、実際にテストを行うテスターからしても問題になると思います。そのため、その差をできるだけ縮めるようにQA文書のテンプレートを作成し、常に最新の状態で管理しています。以下はテストケースのテンプレートです。

テンプレートにはテストケースのステップとテストケースの既存の主な機能が含まれています。QAは、新しい機能についてテストケースを作成する際に、このテンプレートを基に作成を始めます。新しい機能が既存の機能に影響を与えないか、または既存のデータに影響を与えないどうかを、テンプレートに含まれているステップに沿って検討を行うことで、チェックリストとして活用できます。

以下は、私たちが行った回帰テストの計画の一部を抜粋したものです。

新しい機能が追加されたバージョンがリリースされ、その次のバージョンのQAを行う人のために、どのような変更があったか、どのような意図で追加されたかを管理し、常に最新の状態を維持します。上記のようなテンプレートは、すぐ使用できるように別途のダッシュボードで提供しています。

QAのペアレビュー

次に重要だと思うのは、ペアレビューです。ペアは、QA成果物のレビューをきちんと行う必要があります。私は、開発者が行うコードレビューがとても良い活動だと思います。開発者のコードレビューのようにQAも、QA活動や作成した文書についてお互い丁寧にレビューを行い、フィードバックするといいと思ったのでぜひ適用してみたかったです。それまでは、実際にそのサービスを担当するQAでなければテストケースの文書がどこにあるかさえすぐ把握できなかったため、丁寧にレビューすることは難しかったです。しかし、デュアルQAプロセスではこのようなレビューが可能でした。

レビューは時間がかかる作業です。そのため、レビューをリクエストして完了後の共有するプロセスを、なるべく簡単かつ便利にするように取り組みました。おそらく多くの方がすでにそのように行っていると思いますが、バグトラッキングシステムの日付管理とラベル、担当者アサインなどのような機能を最大限に活用しました。また、レビューに関する情報を業務カレンダーシステムに表示するなど、あらゆる方法を使ってレビュープロセスをできるだけ簡単で分かりやすくして、利用可能なリソースはすべてレビューそのものに集中できるように進めています。

共有

最後に、自分が担当するバージョンの履歴をペアにきちんと共有することです。サインオフ以外にも途中でペアに必要な情報があったら共有することがとても重要だと思います。情報をうまく共有するために使った2つの方法について説明します。

1つ目は、共有する内容はどのようなものがあるかをきちんと確認することです。例えば、既知の問題や次のバージョンに延期された問題はないか、レビューの前に更新すべきテストケースはないかなどをチェックリストにまとめ、共有するときに漏れないようにしました。以下の画像は、私たちが使用したチェックリストです。

2つ目は、機能にテスト履歴を残すことです。大きな機能の場合は、複数のバージョンに分けてリリースすることがあります。この際、機能の履歴をまとめた文書を別途作成して共有し、テスト方法やガイドなどもその都度テスターの方やペアのために分析して共有しました。バージョンごとに簡単に振り返りも行い、スクラムでも共有しました。以下の画像は、複数のバージョンに分けていたオープンチャットAD機能の履歴をまとめたものです。

ご覧のように、機能の履歴をまとめた文書には担当者や当時使用したコミュニケーションチャンネル、関連成果物のURL、使用したツールと使い方、ログの確認方法、使用したAPI、どこまでリリースされているか、残りの問題は何かなどの内容を次のバージョンを担当するQAが参考にできるようにすべてまとめておきました。 

皆さんもよくご存知のとおり、効率よく共有することは簡単ではありません。デュアルQAで進めると、お互い共有するためにコミュニケーションも増え、別途の文書も必要で打ち合わせも多くなります。それをできるだけ効率よく進めるには、その時その時文書を減らして不要だと判断したらすぐ止め、打ち合わせを別途に設けるのではなく、共有が必要な場合はスクラムでその都度すぐ共有することでスピードを上げたりしました。

このように共有することは簡単ではありませんが、共有に取り組んだのが後になって実を結ぶこともありました。他のサービスのQAと協業する際に、作成しておいた文書をそのまま渡すだけで済んだので、作業が楽になりました。また、開発チームでAPIを使用するとき、私たちがまとめておいた文書を活用することもありました。個人の成果を記録・管理するときも、すでに作っておいた文書のURLを添付するだけになり、だいぶ楽でした。

デュアルQAプロセスの利点と注意する点

ここからは、デュアルQAプロセスを進めて感じた利点と注意する点について紹介します。

利点

最も良かったのは、さまざまな面で透明性が確保できるという点でした。ペアレビューで使用される成果物の透明性が確保されることで、各個人の能力をより正確に把握できるようになりました。もちろん成果物に点数を付けたりはしなかったのですが、私の成果物がどうだったのかペアの視点で客観的に評価されることで、自分の能力を振り返ってみるきっかけとなりました。

また、成果物の改善を定期的に続けることも良かったです。同じサービスを2人のQAがバージョンごとに担当しているので、ペアとは常に最新の情報を共有しながらフィードバックをやり取りしましたが、そうしているうちに自然と成果物が続けて改善されました。

QAを担当しない2週間において、テスターとのコミュニケーションが大幅に減ったのも欠かせないことです。履歴の把握には届いたメッセージをまったく見ないわけにはいきませんが、少なくとも私が何かに集中している間はメッセージの確認で邪魔されることのない期間が確保されることが良かったのです。 

最後に話したい利点は、本当のバックアップができるということです。例えば、それまでは急な問題が発生すると申し込んだセミナーもキャンセルして対応することが多く、前もって計画を立てるのが非常に難しかったです。今は、後回しにしていたセミナーにも安心して参加できるようになりました。QA担当者が2人なので、テスターの方々により早く対応できることも利点だといえるでしょう。

注意する点

2人のQA担当者が非常に密接して仕事をするプロセスなので、QAのスタイルが異なったり能力のバランスが合わないと、デュアルQAプロセスを導入することは不可能だと思います。毎回意見の衝突が発生することがあったり、1人に業務が集中することもあります。また、前述のように作成する文書とコミュニケーション、打ち合わせが増えることが負担になることもあります。

もう1つ注意すべき点は、今私たちが置かれている状況でもありますが、サービスの業務が増えると、デュアルQAプロセスを進めるのは簡単ではないということです。デュアルQAプロセスは、2人がデュアルで仕事してそれぞれ2週間の時間を得て準備作業を行うのが重要なプロセスです。しかし、業務量が増えると、せっかく確保した2週間の時間が消えてしまうため、デュアルQAプロセスの魅力がなくなります。現在、オープンチャットもWebやサーバーのような非定期的な案件が多く増えており、今後のプロセスをどのように設定するかについて再度検討しています。

おわりに

ここまで、オープンチャットのQAプロセスの変遷についてお話ししました。私たちが過去に経験してきたプロセスも間違っていたわけではありません。最近導入したプロセスが、必ずしも最善や最高のプロセスであるとは限りません。すべてのプロセスには、それぞれの長所と短所があり、私たちみんなはそれぞれ状況が異なっているため、自分のサービスにどのようなプロセスがより合っているかをきちんと検討して決めるべきです。特定のプロセスを必ず全体に一気に適用しなくてもよいです。まず一部に適用してみてから判断しても構いません。

今この記事を読んでいる方々が、より簡単でスムーズに業務を進め、より楽しくお仕事できることを願って終わりにしたいと思います。長文でしたが、読んでいただきありがとうございました。