メルカリ ハロ リリースのQA戦略

こんにちは。メルカリのQAエンジニアリングマネージャーの@____rina____ です。今回は、連載『Mercari Hallo, World! -メルカリ ハロ 開発の裏側-』の第4回を担当します。

本記事では、メルカリ ハロのサービスローンチまでのQAプロセスを通じて、私たちはどのようにして安心・安全なプロダクトを迅速にリリースするための戦略を実行したか、具体的な方法とともに詳述しています。
この記事を通じて、以下の点についての理解を深めていただけることを目指しています：

• QAの役割とプロジェクト概要
• 効率的なQAアサイン戦略
• 成果物の透明性と管理ツールの効果的な活用方法

また、この記事を書くにあたり、私自身が学んだことや得た教訓についても触れています。これらの経験は、今後のプロジェクトにおいて更なる品質向上と効率化を目指す上で非常に貴重なものとなりました。

プロジェクト概要とQAの役割

「メルカリ ハロ」は、事業者や店舗である”パートナー”と、働き手である”クルー”を結びつけるサービスです。クルーは自身のスキルや時間を活用して働くことができます。「メルカリ ハロ」はメルカリのWorkチームという組織で開発をおこないました。また、このサービスにはWorkチーム以外にも多くのチームが密接に関わっています。例えば、事業者アカウントの作成やKYC、給与振込などはメルペイが担当し、経理はホールディングスのチームが、問い合わせ対応はメルカリが担当しています。
　このサービスにおけるQAの役割は、サービスローンチまでに開発を最短かつ安心・安全に進めるための戦略を実行することです。具体的には、品質保証アプローチを駆使し、プロダクトの全体的な品質を高めるとともに、スムーズなリリースを実現することです。

QAエンジニアのアサイン戦略

サービスローンチの当初の計画では、私がすべてのQA活動およびテスト実行を担当する予定でした。しかし、組織や開発の規模が想定以上に大きくなったため、追加のメンバーが必要となりました。その結果、QAエンジニアの採用に加え、業務委託と外部ベンダーの協力を得て、QA活動を以下の3つの主要な役割に分けて進行することにしました。
なお、メルカリアプリにある「はたらくタブ」の開発はメルカリのメンバーが開発しました。

メルカリ（Workチーム）のQAエンジニア

WorkチームのQAエンジニアは、テストプロセス全般に加え、以下のタスクを担当しました：

• オンボーディング資料の作成：これから参画するQAエンジニアやチームのために、オンボーディング資料を作成しました。
• テスト設計：各ユーザーストーリーにAcceptance Criteriaを追加しました。Acceptance Criteriaについては、こちらのブログもご参照ください。参照：QAがAcceptance Criteriaにテストしたい項目を追加して、みんなでいつ何をつくるのか考えたよ
• プロジェクト進捗把握：QAの進捗だけでなく、開発の進捗も管理することで、スムーズなリリースを支援しました。開発の進捗はJIRAで把握したかったので、チケットも率先して作成しました。
• 各種ドキュメント作成：テスト計画書、テスト完了報告書などを作成しました。
• 他カンパニーのQAとの連携：今回のサービスでは他のカンパニーとのシステム連携が多かったため、障害を未然に防ぎ、スムーズに開発を進めるためにQA間での連携が必要不可欠でした。定期的なミーティングやドキュメントの認識共有、進捗確認などを通じてコミュニケーションを密に行うことを心掛け、カンパニー間で連携の齟齬が発生しないよう努めました。
  各詳細については、後で詳しく説明します。

アルムナイの業務委託のQAエンジニア

メルカリのことをよく知るアルムナイ（元社員）のQAエンジニアに業務を委託しました。本業との兼ね合いで時間が限られていたため、時間を最大限に活かしてもらう必要がありました。主に以下の役割を担いました。：

• オンボーディング資料の更新と作成：新しいチームメンバーがスムーズに参加できるよう、オンボーディング資料を作成および更新しました。
• エピック単位のテストと探索的テスト：エピックとは、機能のまとまりを表す単位です。私たちはそれぞれのエピックにユーザーストーリーを紐づけます。通常はユーザーストーリーごとにテストを行いますが、業務委託のメンバーは稼働時間が限られているため、彼らの能力を最大限に活かすために探索的テストを中心に実行しました。
  この際、エピックごとにテストを実施し、エピックに対応するユーザーストーリーのテストを行いました。こうして、各機能がうまく連携して動作するかを確認しました。また、Acceptance Criteriaに縛られずに、探索的にテストすることで予期しないバグや問題を早期に発見することを目指しました。
• リグレッションテストの作成：サービスローンチ前に多くの機種やOSでも正常に動作することを保証するためにリグレッションテストを実施する必要があります。また、開発中は一貫した開発環境が整っていなかったため、リリース前に一貫した環境で動作することも目的としています。サービスローンチ前の状況では、機能開発に追われてリグレッションテストのケースを作成する時間が取れません。また、記載に一定のルールがないと、テスト実行が難しくなってしまいます。業務委託のメンバーはアルムナイのため、メルカリ時代の知見があり、機能開発に引っ張られずにリグレッションテストの方針を理解し、作成することができます。これにより、多くの人が一緒にテストを実行できる体制を整えました。
• テスト設計レビュー：Acceptance Criteriaのレビューおよび修正を行いました。

ベンダーのQAエンジニア

以前メルカリに参画していたメンバーを中心に、外部ベンダーに参画していただき、以下の活動を行いました：

• テスト設計からテスト実行：テスト設計から実行を担当し、特定の分野における専門知識を活用しました。今回は開発期間もタイトであったため、ユーザーストーリー単位に実行できるものからテスト実行しました。また、他カンパニーとのシステム統合テストもキャッチアップからテスト実行まで実施しました。
• リグレッションテストの設計から実行：システム全体の安定性を維持するためにリグレッションテストを実施しました。

以上のように、多様なメンバーと役割分担を用いたQA戦略を採用し、組織の規模と開発の複雑さに対応しました。QA活動の効率化と品質の確保を両立させるために、このような工夫を取り入れました。

成果物の透明性と管理ツールの利用

ここでいう成果物とは、QA活動において作成したドキュメント類を指します。今回は主に以下の成果物を作成しました。

• テスト計画書
• オンボーディング資料
• テスト設計時のAcceptance Criteria
• リグレッションテストのためのテストケース
• QAダッシュボード
• プロジェクト管理ダッシュボード
• テスト完了報告書

これらの管理はJIRA、Confluence、TestRail、およびGoogle Spreadsheetsを使用して行いました。すべての成果物はクラウド上に保存され、社内で誰でも参照できるようにしました。これにより、現在の状況などにアクセスしやすくし、いつでも参照できる環境を整えました。
このようにして、成果物の透明性を高め、プロジェクト管理ツールを効果的に利用することで、プロジェクト管理の効率化と円滑なコミュニケーションを実現しました。
次にそれぞれの成果物について具体的に紹介します。

テスト計画書

テスト計画は、サービスローンチの成功に不可欠です。前述のとおり、QAに関しても共通して参照できるドキュメントが必要でした。そのひとつがテスト計画書です。
テスト計画書の作成には、国際標準であるISO/IEC/IEEE 29119のPart3を参考にしました。ISO/IEC/IEEE 29119はソフトウェアテストの国際規格で、ソフトウェアテストに関するプロセス、ドキュメント、技術などを定義しています。Part3はドキュメントについて定義しています。今回は、主に以下の構成で作成しました：

• 用語集: プロジェクト内で使用される専門用語や略語の明確な定義を提供し、プロジェクト関係者間の誤解を防ぐためです。社内で使用されている他の用語集にないQA特有の用語も含めました。
• テストの成果物: テストケース仕様、テストスクリプト、テストレポートなど、生成されるすべてのドキュメントをリストアップしました。
• テスト環境: 「メルカリ ハロ」はリリース前ということもあり、開発中のコードはmainにマージして、開発（＝テスト）環境でテスト実行をしました。一方で、事業アカウントや給与振り込みを担当するメルペイはすでにリリースされているサービスで、各開発チームで使用する環境を設定する必要がありました。そのため、「メルカリ ハロ」とのシステム統合テストで利用する環境は厳密に設定する必要がありました。そこで、テスト計画書に「いつからどの環境を使うか」を明確に記載しました。これにより、テスト環境の設定を誤ることのないようにしました。
• テストの完了条件: テストが正式に完了するための具体的基準を定義しました。特にメルペイとのシステム統合テストにおけるテスト計画書は、多くのチームメンバーが参照する重要なドキュメントとなりました。

オンボーディング資料

オンボーディング資料はいくつかのパートに分けて作成しました。ドキュメントは「オンボーディングクエスト」という名前で、参画したメンバーが各自で進められるようにしています。また、ドキュメントが古くならないように、参画したメンバーがいつでも更新できる仕組みを整えました。オンボーディングクエストについては以下も参考にしてください。参考：Notionを活用したエンジニア向けオンボーディング

オンボーディング資料には以下の種類があります：

• 全社共通のオンボーディング資料：会社全体で必要となる基本的な情報を提供します。
• プロダクトに関わるメンバー用のオンボーディング資料：各プロダクトに関する詳細な情報を提供します。
• QAエンジニア用のオンボーディング資料：QAエンジニアがテスト実行に使うための設定ページや、不具合発生時のチケット起票ルールなどを含みます。

QAエンジニア用の資料には、主に以下の内容が含まれています：

• 設定ページ：テスト実行に必要な設定方法を詳細に説明します。
• チケット起票ルール：不具合発生時のチケット起票方法やルールを説明します。

テスト設計時のAcceptance Criteria

テストケースはAcceptance Criteriaとして、すべてストーリーチケットに直接記載しました。これにより、エンジニアがセルフチェックに利用できるほか、ストーリー完了後のより大きなまとまり（エピック）単位でのテスト実行にも活用できます。テスト実行が完了した後には、QAレビューを行いますが、ストーリー単位でのレビューが可能なため、効率的に進めることができました。

リグレッションテストのためのテストケース

今回QAでは、ストーリー単位でも、エピック単位でも、それぞれでテスト実行をしてきましたが、サービスローンチ前にさまざまなOSやOSバージョンでの動作も担保する必要がありました。
そのため、基本的なシナリオに基づいたテストを実施する必要があり、これを達成するためにリグレッションテストケースを作成しました。このリグレッションテストケースを用いることで、多くの環境での一貫性と安定性を確保しながら、テストを効率的に実行することができます。

QAダッシュボード

QAダッシュボードでは、進捗やバグの発生、解決状況を把握することを目的としています。このダッシュボードはJIRAのダッシュボード機能を使用して作成しました。主に以下の内容を表示しています：

• ユーザーストーリー毎のテストのステータス状況
• システム統合テストの進捗状況
• ユーザーストーリー毎の不具合対応状況
• システム統合テストの不具合対応状況

プロジェクト管理ダッシュボード

全体の進捗状況や各タスクの進捗はJIRAのチケットに記載し、ダッシュボードも作成しました。このダッシュボードでは、全体の予定工数、現在の開発ステータス、週ごとの完了工数などを表示できるようにしています。さらに、これらのデータをGoogle SpreadSheetsでシンプルなグラフに変換し、全社ミーティングで進捗を報告するようにしました。このようにすることで、各ロールの進捗を把握するだけでなく、他のロールの予定や課題も共有しやすくなりました。

テスト完了報告書

テスト完了報告書はConfluenceで作成しました。テスト完了報告書はリリース判定会議でも使用されます。リリース判定会議とは、新しいサービスや大規模なプロジェクトの際に行われる会議で、私はプロダクトの品質を機能面で評価し、報告する役割を担っていました。最終的な承認はエンジニアリングのVPが行います。事前に承認条件を設定し、テスト完了報告書を使用して適切な評価を提供することで、スムーズに承認を得ることができました。
テスト完了報告書の項目の選定には、ISO/IEC/IEEE 29119のPart3を利用しました。この標準を採用することで、評価項目が適切に盛り込まれ、全体のテストプロセスの一貫性と透明性が確保されました。また、この報告書はJIRAと連携し、データが自動更新される仕組みを取り入れることで、報告の正確性とタイムリーな情報更新を実現しました。

おわりに

今回紹介した取り組みにより、「メルカリ ハロ」は大きな問題や遅延もなくサービスローンチをすることができました。今回の活動を通して、短い期間で様々な環境の変化に耐えうるQAの戦略を取ることができたのは大きな収穫でした。QAの役割は単なるテストの実施に留まらず、プロジェクト全体の品質と効率を向上させるための重要な貢献を果たしています。
　また、今までのQA活動の経験から得た知識に加えて、JIRAを駆使することでタスクの管理と進捗の可視化を効果的に行うことができました。そして、今まできちんと取り組んだことがなかったISO/IEC 29119標準を用いたドキュメント作成を行い、運用に支障をきたさずに混乱もなくプロジェクトを遂行できたことも大きな学びとなりました。このようなツールと標準の活用が、開発の成功に寄与したと確信しています。
サービスリリース後、QAの役割は少しずつ変化していきました。各QAエンジニアは特定の領域を担当するようになり、Acceptance Criteriaの読み合わせを開始しました。
Acceptance Criteriaの読み合わせを行うことで、PM、デザイナー、エンジニア、QAの間で、Specレビュー（要件レビュー）よりもさらに詳細な議論が可能になります。また、UIのエンドツーエンド（E2E）テストの自動化にも取り組み始めています。

今後も、今回得た経験や学びを今後の開発に活かし、さらなる品質向上と効率化を目指して取り組んでいきたいと思います。

Links

連載：Mercari Hallo, world! -メルカリ ハロ 開発の裏側-

メルカリではメンバーを大募集中です。メルカリ ハロの開発やメルカリに興味を持った方がいればぜひご応募お待ちしています。詳しくは以下のページをご覧ください。
Software Engineer, Frontend – Mercari/HR領域新規事業 (Mercari Hallo)
Software Engineer, Backend – Mercari/HR領域新規事業 (Mercari Hallo)
Software Engineer, iOS/Android (Flutter) – Mercari/HR領域新規事業 (Mercari Hallo)
Software Engineer, Site Reliability – Mercari/HR領域新規事業 (Mercari Hallo)
QA Engineer – Mercari/HR領域新規事業 (Mercari Hallo)
Engineering Manager – Mercari/HR領域新規事業 (Mercari Hallo)