はじめまして。ソウゾウQAチームのマネージャーをしています@matsuです。連載：メルカリShops 開発の裏側 Vol.2の12日目を担当させていただきます。

この記事ではメルカリShopsの品質を牽引するソウゾウQAチームのミッション・バリューを紹介させていただきます。

なぜミッションを作ったのか？

QAメンバーが集まり今後のソウゾウQAをどういった組織にしたいか話す「QAの未来を考える会」が発端になります。そこではQAエンジニアの目指すべき姿や、自分たちが働きやすい環境とはなにかといった話を隔週のMTGで話していました。お互いの理解が高まることで信頼が生まれ、チームとしての練度みたいなものが上がっていったと思います。しかし、そこでの議論は一時的なもので、今後増えていくメンバーには伝わりづらい内容になってしまったので、ミッション・バリューという形で残すことにしました。

Souzoh QA Mission「2時間で企画して2時間で実装して1時間でテストしてリリースする」

「2時間で企画して2時間で実装して1時間でテストしてリリースする」をソウゾウQAのミッションとして掲げることにしました。わたしたちが考えるプロダクトの価値とお客さまが実際に体験して感じる価値は必ずしも一致するとは限らず、さまざまなことを試しながらお客さまから得たフィードバックをもとによりよい体験の提供をすることが必要だと考えています。そのためプロダクト自体の品質だけでなく、企画からリリースまでのプロセス全体の品質保証を行うことをミッションとしています。

また、ミッション達成のための行動指針としてバリューの作成も行いました。ソウゾウのバリューにもある「All for One」「Be a Pro」「Move Fast」を使い、よりQAの活動にフォーカスした内容で議論し決めていきました。

• All for One ：スクラムチーム全員で品質保証活動を行います
• Be a Pro: 柔軟なテスト
• Move Fast: 短いサイクルのリリースを実現します

All for One ：スクラムチーム全員で品質保証活動を行います

わたしたちQAチームはお客さまへ正しい価値を提供する必要があります。前述したようにわたしたちが考えるプロダクトの価値とお客さまが実際に体験して感じる価値は必ずしも一致しません。プロダクトの価値を正しく評価するためには定量的な評価をすると同時にお客さまからのフィードバックを得た上で定性的な評価を継続的に行うことが大事だと考えています。

定性評価をするためには、チームの誰かだけがすればいいものではなく、開発に携わる全員が行う必要があります。
わたしたち開発に携わるメンバーは開発するプロダクトの価値をみんなで考えています。誰か一人が決めるものではありません。そして、みんなでリリースするプロダクトの価値を考える活動を繰り返すことで、必然的にプロダクトへの品質についても考える機会が増えてきます。
また、そのような品質への期待が高くなると自ずとプロダクトについてのプライドといったものが芽生え、よりよいプロダクトづくりにつながると考えています。

これらの活動は、開発に関わるみんなでする必要がありますが、その活動を促すのはソウゾウのQAチームの役割です。

Be a Pro: 柔軟なテスト

テストについて、わたしたちはマニュアルテストとE2Eテストの２つを軸におこなっています。また、これらのテスト以外にもSpecレビューや、ソウゾウのみんなで行うおさわりかいも主導しておこなっています。これら全てのテストを常に実施するわけではなく、複数用意しておくことで柔軟なテストの手段を選択できることを目指しています。テストの手段を複数用意するにはQAとして専門的な知識や経験が必要になります。

マニュアルテスト（テスト設計、テスト実施）

マニュアルテストは、QAチームとして決められたプロセスはあまりありません。そのため、それぞれのQAエンジニアがテスト対象に最適なテストを考えながら実施します。
例えば、事前に仕様書（Spec）をもとにテスト設計をしているQAエンジニアもいますし、Specレビューである程度のテスト戦略を考えておき、最初にSpecに書いてある機能が動いていることを確認して、そのあと不具合が起こりそうな操作をしているQAエンジニアもいます。
また、つねにすべての機能が揃った状態でテスト出来るわけではありません。開発の進捗によってはフロントエンドやバックエンドの一部が実装されていない状態でテストすることもありますし、そもそもフロントエンドが存在しない機能もあります。その場合、各エンドポイントに沿って開発内容や既存機能の影響範囲をエンジニアとコミュニケーションをとりながら、テストを実施します。
フロントエンドの機能が揃った状態でテストする場合でも、バックエンドの通信を確認します。エラーなどが発生した場合はエラーログを確認することもあります。
また、PRのコードを読むことも、Suggest commentをすることもあります。
特定の機能で障害があった場合に、どのマイクロサービスに不具合があるかをQAエンジニア自身も切り分けるようにしています。そのためには、ある程度マイクロサービスのアーキテクチャの理解も必要です。

E2Eテスト

継続的なデリバリーをするために繰り返しテストを行う必要があります。繰り返しテストを行うのは時間もかかるため、自動化できるものは自動化する必要があります。E2EテストはQAエンジニアだけでなく、開発チーム（主にエンジニア）と一緒に実装しています。
開発プロセスの中で、マニュアルテストと平行して自動テストの実装をおこない、リリースが完了したときには、そのフィーチャーの自動化も完了することを目指しています。

Move Fast: 短いサイクルのリリースを実現します

わたしたちは２つの目的で、短いサイクルのリリースを実施しています。
１つ目の目的は、リリースするための最小単位をなるべく小さくし影響範囲を限定することで、品質の向上を目指します。
２つ目の目的は、少しでもはやくお客さまに価値を届けたいからです。わたしたちは新しい機能を作るときに、少しでも完成度をあげようと機能を詰め込もうとすることがあります。しかしながら、お客さまにとってはシンプルでも最低限の機能を少しでもはやく提供することのほうが価値であることもあります。
そのため、プロダクトの機能を最短でリリースするための計画をたて、少しずつ提供することでお客さまにとっての価値も提供できるようになります。
また、イテレーションを短くすることで、最適な価値の改善を行うことができます。
これらの活動を実現するためにソウゾウのQAエンジニアはスクラムマスターとして開発チームに関わることも少なくありません。

まとめ

今回ミッション・バリューを決めることでソウゾウQAチームひとりひとりの行動指針となり、間違った意思決定が起こりづらくなると考えています。また、QAチーム全員で決めたことで納得感のあるミッションの設定をできたと思います。今後のわたしたちの行動でミッションを意味あるものにできたら良いなと思います。

ソウゾウのミッションに共感できた、ソウゾウQAに興味ができた方はぜひカジュアル面談などでお話しましょう！

---

ソウゾウではメンバーを大募集中です。ソウゾウに興味を持った方がいればぜひご応募お待ちしています。詳しくは以下のページをご覧ください。

• 連載：メルカリShops 開発の裏側 Vol.2
• Software Engineer
• Software Engineer, Site Reliability
• Software Engineer, Machine Learning
• Software Engineer, QA Test

またカジュアルに話だけ聞いてみたい、といった方も大歓迎です。こちらの申し込みフォームよりぜひご連絡ください。