Merpay Advent Calendar 2020 の18日目は、QAエンジニアチームの @miisan がお送りします。
昨年のMerpay Advent Calendar 2019で 「メルペイQAの今と未来と私の日常」 というTech Blogを書かせていただいてから約1年たちました。メルペイではこの1年で、さらに多くの機能をスピード感を持って、お客さまに届けてきました。
今回は、メルペイQAがDevOpsサイクルの中で、普段どのような取り組みを行い、プロダクトを支えているかについて紹介したいと思います。
なぜメルペイQAはDevOpsに取り組むのか？
最初に結論をお伝えしてしまいます。ひとことで表すと、「お客さまにより早く、より確実に、より良いサービスを継続的に届けるため」です。
DevOpsの良いところ
- 協力体制：役割に関係なく、サービスの価値向上に目的意識が向き、プロダクト全体に対して活動できる。
- 信頼性向上：責任範囲をいい意味でわけないことで、開発フェーズの中に、多くのテストが組み込まれやすく、品質の向上につながる。
- 生産性向上：自動テストが開発フェーズに組み込まれることで、検証フェーズでのテストを効率化することができる。また不具合を早期に検出できるので、開発プロセス全体の生産性が向上し迅速なリリースが可能となる。
QAエンジニアから見るDevOpsとは、「全員品質( = 全員で品質を作ること)」を実現できる仕組みだと言えます。
当たり前ですが、QAエンジニアはサービスの品質を保証し、プロダクトを最高の状態でお客さまに届けるミッションを担っています。ですがこれは、チームメンバーや組織の協力体制があってはじめて実現できるものです。
※DevOpsの概念について参考
https://engineering.mercari.com/blog/entry/20201214-bea4717e9a/
QAエンジニアに必要なこと
「品質」というものは、常に一定ではなく、変化するものと言えます。
そのため、
- 状況により変化する品質に対して、スピード感を持ちながら柔軟に対応しなければならない( = 断続的テストの実現)
- 常に効率的に、品質を向上させる必要がある( = 継続的な改善活動)
- お客さまにとって、より良い体験や価値を届けるタイミングを逃さず、安全にリリースすること( = 断続的デリバリの実現)
などが必要になります。
新しい機能の開発と、運用・保守の両輪が継続的に回っていることで、わたしたちのミッションははじめて達成できると考えています。
メルペイでは新規開発プロジェクト、運用・保守プロジェクトに対して、QAエンジニアが兼務し品質保証活動をしているため、新規開発と運用の両方に対して品質改善のプロセスを回すこともできます。
効率的かつ安心・安全な品質保証を行うことで、もっとも価値を最大化できるタイミングに、より良いサービスを提供し続けたいと思っています。そのため、DevOpsという仕組みを用いてサービスの開発を進めています。
具体的な品質保証プロセス、フィードバックループについて
品質保証プロセス
まず品質保証プロセスについてです。マイクロサービスごとにわかれているFunctionと呼ばれる横串とProjectと呼ばれる縦串によってチームは構成され、QAメンバーは各チームにそれぞれアサインされます。具体的には下記のような体制イメージです。
チームの大小に関わらず、基本的にQAメンバーは、企画段階や仕様変更フェーズから参画し、想定されうるユースケースから仕様の考慮漏れや欠陥を指摘していきます。その後、仕様をインプットしたらテスト計画を立てます。そしてプロジェクトの目的やプロダクトに求められている品質に対して、より迅速かつ安全にリリースできる方法を検討します。
たとえば、自動化の検討、課題・問題点を可視化するためのドキュメント整備、またテスト実行を効率化させるためのツールを開発者と一緒に検討したりします。
その上で検証フェーズに入り、開発者と並走しながら不具合を検出し、サービスの品質向上を目指します。その過程においては、コンポーネントテスト・結合テスト・探索的テストや不具合分析・改善活動なども並行して進めていきます。
メルペイQAの品質保証プロセスは、上流から下流工程まですべてに関わり、テスト設計、実施、レビュー、テスト自動化、分析、、、あらゆる角度からプロジェクトへ関わっていきます。
フィードバックループ
つぎにDevOpsにおけるフィードバックループについて、紹介したいと思います。
基本的には、プロジェクトごとのスクラムチームで、2週間スプリントを回しています。
なので、2週間ごとにKPTのフレームワーク(Keep・Problem・Try)を用いて振り返りを行い、現状分析を実施します。ここで出たTry( = つぎにトライしたいこと)を次のスプリントで活かし、改善活動を行います。
最近はオンラインで実施することが多いので、Jamboardを用いて振り返りをしています。
(例)
振り返りは、自身の活動やチーム全体の活動に対して行いますが、その他に、実際にお客さまに使っていただいた情報から得たフィードバックや、今後の方針を共有する機会でもあります。
また2週間の振り返りだけでなく、よりクイックに意思決定をしていかなければいけない場面もあるため、各チームで朝会と呼ばれるチームミーティングを毎朝実施します。ここでは課題やつまづきポイントの解消、プロジェクトの進行状況の共有を目的として開催されます。
たとえば検証フェーズに入ると、仕様としては正しいが、実際に機能をさわってみると「お客さま体験」として改善が必要なものを見つけることがあります。こういった場合、すぐにプロジェクト内でPMやデザイナー、開発者と相談し、改めて仕様を見直すべきか、このままリリースして早くお客さまに提供すべきなのか、あらゆる可能性を検討し、方針を決定していきます。
他にも、お客さまに対して「より良い体験」の提供を求めるあまり、リリース直前まで仕様を変更したり、機能を改善していくため、チームとしての柔軟性が必要になります。さらにQAエンジニアとしては、金融サービスを扱っている以上、安全にサービスを提供できるかを、しっかり判断する必要があります。
そのため、安全にサービスを提供できるか判断するために、常にリスクマネジメントを行い、問題を可視化させておく必要があります。
DevOpsにおけるリスクマネジメントについて
サービスの安定運用と新規機能の継続的かつ迅速なリリースには、問題を管理した上でのリスクヘッジにて成り立つと考えています。
サービスをリリースするプロセスにおいて、QAチームは最終工程にいるため、スケジュール遅延や仕様変更などあらゆる影響を大きく受けるチームでもあります。そんな苦しい状況下でも「どうしたらリリースできるのか」を考えるためにもリスクを把握し、リスクコントロールする必要があります。
ここでは「定額払い」という機能のリリース前後に実施した
- リスクマネジメントの目的
- リリース前のプロダクトリスクマネジメント
- リリース後のプロダクトリスクマネジメント
について紹介します。
なおこの機能は、メルペイ VPoE の hidekさんがメルペイ VPoE による2020年の振り返りにて赤裸々に反省していたプロジェクトです。
1.リスクマネジメントの目的
- 残存リスクの明確化
- 課題の予防・対策・検討
- アサイン・リソースの最適化
課題を「見える化」することで、プロジェクトの「深刻度」をだれにでも同じレベルで理解してもらうことができます。
さらに今後顕在化するかもしれないリスクを洗い出し、それを予防をすることで、プロジェクトを計画通りに進行し、プロジェクトの成功確率を高めることに貢献できます。
2.リリース前のプロダクトリスクマネジメント
まず、プロジェクト全体でもリスク管理は行われており、課題把握されている状態にありました。通称「やばリス(すでに名前からしてやばそう)」を用いて、このプロジェクトに関連するあらゆる課題をリスト化していました。その名の通り「やばリス」とは、「やばいことを寄せ集めたリスト」のことで、誰でも「やばい！」と思ったことをシートに書き込むことができ、毎朝各役割のリーダー陣で集まり、この「やばリス」と向き合い問題解決をし続けました。
※正直「やばリス」が毎朝あるのはメンタル的につらかったです。笑
「xxまでに開発完了していないといけなかったが遅れそう」「開発を進めていったら○○も対応しなければいけない」「設計不足があった」など、次から次に降りかかる「やばリス」をひとつずつ対応し、リリースターゲットを変えず、なおかつ品質を維持した状態でリリースできるようなリスクコントロールを行いました。
その中で、QAとして意識していた具体例を、ここでは3つあげたいと思います。
・不具合情報の見える化
QAエンジニアが検出した不具合チケットにプライオリティーをP0からP2まで振り分け、どこの機能でどれだけ問題が発生しているかを可視化しました。また、はじめにリリースできる許容範囲を決めておき、課題のプライオリティーとリリースできるラインの共通認識を持ちました。
実施した結果、
- リリース前の不具合数を把握することでリスクをはかることができた
- 残課題を提供し、リリースジャッジメントに利用することができた
といった効果を得ました。
リリース直前まで、いまどんな不具合が何件あるかを経営層にも共有し、リリースターゲットの適正を判断する情報として提供しました。
・テスト進捗の見える化
テストターゲットごとに進行状況が視覚的にわかりやすい状況を作りました。設定したマイルストーンまでに目標の完了率に到達していない場合、その原因を話し合い、PMや開発者にも協力していただき問題解消に動きました。
またテスト消化率とパスレートもモニタリングしておき、不具合の発生傾向の分析や改善活動に活用しました。
実施した結果、
- テスト進行が予定通り進行しているか定量的に観測することができた
- テスト進捗、不具合発生率を予見することで、早めにアラートをあげることができ、適正な体制構築が可能性になった
といった効果を得ました。
QA期間中、毎日プロジェクトメンバーに情報を共有することで、どこに課題があるのか理解してもらいやすく、問題解決までのスピードを早めることができました。
またQAメンバーからも早い段階でアラートがあがってきていたため、チームマネジメントを進めやすかったです。
・ドッグフーディングによる期待値の認識合わせ
開発期間中、リリース前後、より多くの人にあらゆる角度からサービスをさわってもらうためにドッグフーディング( = 社内テスト)を複数回実施しました。
一般のお客さまに開放する前に社内メンバーに機能をさわってもらうことで、致命的な問題を事前に拾い上げることが目的でした。
さらにQAエンジニア以外のメンバーやエグゼクティブメンバーにもプロダクトをさわってもらうことで、新しい発見や想定外の気づきを得ることができました。
「不具合」「意見」「提案」のタイプで報告を受け、機能の品質や使いやすさについて、多くの意見が寄せられました。リリース前後にたくさんのフィードバックが得られたことは、QAチームとしては本当にありがたいことでした。
3.リリース後のプロダクトリスクマネジメント
「定額払い」のリリースは、メルペイローンチ以来の大きな機能開発であり、また既存機能への影響も大きなもので、リリース後の運用・保守を万全な体制で対応する必要がありました。そこで発足されたのが、通常の開発チームとは別の「reliability team」です。reliability teamはその名の通り、信頼性を担うチームで、「定額払い」やスマート払いドメインに特化した運用・保守チームとして構成されました。
このチームでは主に、予期せぬ問題の対応や、 潜在的なインシデントリスクの排除、監視強化などを担当しました。さらにこのチームで対応するタスクを4タイプにわけ、タスク対応の進行状況を可視化しました。
-
暫定対応
障害の一次調査・対応など -
恒久対応
バグの根本解決 -
システム改善
自動化、ロギング、モニタリング、リファクタリングなど -
システム改修
新規機能追加(プライオリティーの低い残タスク、新規要件、要件漏れなど)
まずタスクタイプをカテゴリ分けし、対応状況や対応率をモニタリングしていきました。
この図からわかるように分析当初はもっとも優先度の高い暫定対応に時間を費やす必要があり、その他のタスク進捗が低かったことがわかります。しかし、粘り強く目の前の問題を解決していったことで、暫定対応チケットが滞留することがなくなり、徐々に恒久対応やシステム改修のタスク対応率が上がっていきました。
こうしてreliability teamがチーム一丸となり、各タイプの対応率を向上させていくことと並行して、インシデントの数も減少していきました。
もちろんインシデントが発生したら、その内容を即時対応しつつ、恒久的にどのような対策を取れば今後問題が発生しにくい状況をチームとして作り出せるかを振り返ります( = ポストモーテム)。またインシデントの傾向からテスト項目や観点を補充していき、さらにインシデント発生率を軽減させるサイクルを作りました。
その後、インシデントの発生頻度が減り、reliability teamの目的が達成されたため、このチームは通常の運用体制に統合されました。
リリース後の見える化を行ったことで得られた成果は、
- リソースの最適化ができたこと
- 問題を可視化させることで放置される問題が減り、負債を軽減できた
- 改善や改修対応へリソースをさける循環を作り出し、インシデントを抑制できた
などがあげられると感じています。
「定額払い」機能に関する事例はあくまで一例にすぎませんが、メルペイが断続的に新しい機能をリリースできているのは、既存機能を安心・安全にお客さまが利用できる状態を、各チームが維持する努力を行っているからです。
わたしたちメルペイQAが目指す「価値提供」
先日、merpay Tech Talk〜DevOpsxQA、マイクロサービスxQA、BackendxQA〜 を開催した際に、「お客さまへ価値を届けると言ってもどう評価するの？」といった質問を受けました。
そのときは「KPIや予測していた数値との乖離などから、お客さまにその機能が受け入れられたか、反対に利用されなかったのはなぜなのか分析し評価する」といったことをお話しました。
ただ「それだけがすべてなのか？」とも思い、あれから「お客さまへの価値」について考えてみました。
まず一番大切な姿勢は「お客さまファースト」であることだと考えています。
そのうえで品質は不変的なものではないので、「これが価値だ！」と言えるものがないのですが、だからこそ継続的に「これが最高のサービスだ！」と言える品質のサービスを常にわたしたちはお客さまに届けなければいけません。
たしかに定量的に判断できる数字が持つ力は大きいですが、わたしたちはそれだけに固執することなく、お客さまの視点やライフスタイルに寄り添い、数値化できない生活の質を高められるような機能かどうかを見極め、サービスを届ける必要があります。
QAエンジニアは、機能充足だけでなく、お客さまに満足いただける魅力的なサービスを「品質」つまりは「価値」としてお客さまに届けていると思います。
そしてこれはQAエンジニアだけで作り出すものではなく、プロダクトに関わる全員で作り上げていく品質です。
DevOps開発では、QAエンジニアは役割を超え、「良いサービス」をお客さまに提供するために、あらゆるスキルが必要になってきます。そのため、エンジニアの継続的なスキル向上とチーム品質も向上させる必要があります。
そして「お客さまファースト」の思想のもと、個人個人が考え、行動していかなければDevOpsの早いサイクルは回していくことができません。
わたしたちメルペイQAは、「誰かの価値」を生み出すために、多くのことにチャレンジしていくQAエンジニアをこれからも目指していきます。
終わりに
先日行った merpay Tech Talk〜DevOpsxQA、マイクロサービスxQA、BackendxQA〜 というイベントではたくさんの質問やコメントをいただきました。さらに、第2弾のイベント merpay Tech Talk｜QAx DevOps/マイクロサービス/Backend vol.2 が12/22 20:30から開催されます。
イベントではかなりざっくばらんに現場の素直な声をお伝えしているので、もしも興味がある方はイベントに参加してみてください。この記事の質問やツッコミもあれば、ぜひリアルタイムにお話できると嬉しいです！
さらにメルペイではミッション・バリューに共感できるQAエンジニアを募集しています。一緒に働ける仲間をお待ちしております。興味のある方のご連絡、お待ちしています！
ソフトウェアエンジニア (QA Test) [Merpay]
明日のMerpay Advent Calendar 2020 執筆担当は、 iOS Engineer の stamaki さんです。引き続きお楽しみください。
