こんにちは、メルペイでQAエンジニアチームに所属している @miisan です。
今回は、2021/02/18に開催されたmerpay Tech Talk 〜「全員品質」を目指し、メルペイQAが取り組んでいること〜のLTで発表した内容について、改めて文章で公開したいと思います。
私が所属しているCredit Designチームで取り組んできた、お客さまにより良いサービスを継続的に届けるための新しい習慣ができるまでの様子を共有します。この試行錯誤は大変なことも多かったですが、サービスをより良くしていきたいと思ってチャレンジした内容です。
Credit Designとは
Credit Designというのは、メルペイスマート払いを開発している部門で、信用や与信領域における機能開発を主に担当しています。メルペイスマート払いとは、チャージ不要で、使った分だけを、翌月にまとめて支払うことができるサービスです。
Credit Designの歴史
簡単にCredit Designチームが開発してきた支払い手段について紹介します。
2019年4月に「メルペイあと払い」として使った分だけを、翌月にまとめて支払うことができる後払いサービスをリリースしました。その後、同年11月に現在の「メルペイスマート払い」としてリニューアルリリースしました。
最近だと2020年7月に、購入した個々の商品の清算を月々に分けることができる「メルペイスマート払い（定額払い）」をリリースし、お客さまに合ったお支払い方法をより柔軟に選択できる機能を提供しました。
他にも、新しい機能のリリースや、細やかな機能改善のアップデートも行っています。
Credit Designのチーム構成
現在のチーム構成を紹介します。
大きく分けると3つのチームで構成されています。
- 新規機能開発チーム : 新しいマイクロサービスや大型の新規案件を担当
- Growthチーム : 既存機能の改善やグロース施策を担当
- 運用・保守・改善チーム ： productivity（運用・保守）やオートメーションの仕組み、CI/CDの保守などを担当
このように、Credit Designチーム全体の規模は大きく、プロジェクトに関わっているQAメンバーは30名程いた時期もありました。
Credit Designの課題
私がこのチームに参加した2020年3月頃は、すでにサービスはリリースされていたため運用・保守を行いながら、大きな新機能のリリースも控えているような時期でした。このチームに私が参加してすぐに課題が見えてきました。
私が参加した2020年3月の段階で技術的負債が想像以上に膨らんでいる状態だったのです。
説明のためにCredit Designの抱える背景を振り返ります。メルペイ VPoE による2019年の振り返りにある通り、2019年4月はゴールデンウィークを目前に控え、メルペイスマート払い（リリース当時はメルペイあと払い）はキャンペーン実施のために必要な機能でした。
その結果、2019年4月にリリースを優先するため、たとえば技術的な課題として、本来であればマイクロサービスとして切り出して進めるべきところを、一旦既存システムに実装を行い技術的負債を負う選択をしました。
この決断によりサービス提供を開始することはできたものの、この時生まれた負債がこの後もCredit Designチームには、想定以上に大きな課題として残り続けました。
私は「技術的負債」の堆積が、新しい取り組みのブロッカーになったり、保守・運用に過剰なリソースを要する原因だと考え、この課題の解消に取り組むことにしました。
Credit Designでの取り組み
今回は取り組んだものの中からいくつかをピックアップして紹介します。
課題解消に向けて
まず、課題解消に向けて最初にやろうと考えたのは『現状を知る』ことでした。
当時、なんとなくチームとしても「やばいぞ…」という空気はあったものの、そうと明確にわかる材料がなく、課題をこのまま先送りにしても問題ないかどうかを判断できない状態でした。
そこで始めたことは、チーム内で課題を見える化して共通認識を持つことです。
目に見えないものと向き合うことは難しく、チームで同じ粒度と物差しをもって、問題と向き合うことから始めました。
目的の共有
チーム内で、課題の見える化を行う目的を説明しました。
- プロジェクトを計画通りに進行し、お客さまにサービスを継続的に届ける
- 今後顕在化するかもしれないリスクを洗い出し、それを事前に予防する
どんな目的があるかが明確であれば、何故それをやらなければいけないのか理解しやすいです。
さらに課題の見える化を行うことで
- 残存リスクの明確化
- 新たな課題発生の予防、課題の対策や検討
- アサイン、リソースの最適化
につながることを理解してもらい、これからトライする内容がチームで取り組む意義のあるものだと共有しました。
振り返りフローの徹底
次に、課題を改善するために具体的に行ったアクションについてです。
負債をかかえながら開発を進めていくことはリスクも伴うことであり、障害がおきると新しい機能開発にも影響をあたえます。課題を減らすために、障害の振り返りフローを徹底しました。
これまで放置されがちだった課題を整理するときに意識していたポイントがあります。それは課題をだれもが同じ粒度で理解できる状況を整備することです。
障害発生に伴う振り返りができるように、滞留している課題（滞留課題）の見える化や発生時期、対応者の明確化など基本的な情報を整備しつつ、本質的な課題解消に必要なロジック改修やプロセス改善に取り組みました。
具体的には、
- 発生した障害の振り返り・共有
これまで曖昧になっていた障害内容をチームで振り返り、その情報を横断的に共有する体制と仕組みを導入 - 障害発生から解消までの対応率の数値化
障害発生時に作成される「インシデントレポート」の対応率を見える化 （たとえば、4件のインシデントレポートがあり、2件しか対応できていなければ対応率50%） - 暫定対応などチケットの対応率を数値化
チケットを「暫定対応」や「恒久対応」などラベル付けし、問題発生から解消までに必要なタスクの対応率や、どのタスクが完了していて、どのタスクが未完了な状態であるかを見える化
このように障害の振り返りができるように、障害のモニタリングを定期的に実施し、継続的に開発チーム一丸となり、問題と向き合い続けました。
自動テスト
前提として、メルペイサービスローンチ前に開発されたマイクロサービスのほとんどは、自動テストが実装されています。しかし、Credit Designチームでは、当時スケジュールや工数の問題もあり、自動テストの実装ができないままリリースしていました。
テスト効率・生産性が悪い状態、また定期的な品質保証ができていない状態になっていたため、他マイクロサービスと同様に、自動テストの実装に取り組みました。
主な目的として、
- 想定外の影響を及ぼすような修正が加わっていないか、機械的にチェックできる状態を作ること
- 無影響リリースにおける必要なQAリソースの削減
を目指しました。
実装当初はシナリオの選定や実装方法など難しい箇所はありました。今では、これまで自動テストを書いたことのなかったメンバーも、バックエンドエンジニアのサポートをもらいつつ自動テストの実装が行えるようになりました。
自動テストをメンテナンスし続けることは大変な側面もありますが、一方で自動化を導入したメリットも大いにあったと感じています。
現在は当初の狙い通り、リリース前に考慮漏れによる不具合の検知やアサインの最適化に寄与しています。
結果
上記までの取り組みを続けた結果、問題が起きたらすぐに問題と向き合い、根本的な対応策を考えられるようになりました。また、チームとして何をすれば、今後同じ問題が起きないのかを考える新しい文化や習慣が生まれました。
- インシデントレポートの対応率の改善
たとえば、インシデントレポートの対応率は、計測当初 26% ほど、つまりほとんどの障害の振り返りが未対応の状態（74%）にあったわけですが、取り組みを続けた結果、課題の先送りも削減され、放置される問題も無くなってきました。
- 不具合の発生頻度の改善
不具合の発生頻度も大きく変化しています。
取り組みを始めた当初は、滞留課題もあり、不具合発生頻度も多くありました。その後、取り組みを続けていった結果、リリース頻度を変えず、むしろ難度の高い大きな機能のリリースがあった半年後の方が、不具合の発生頻度は減少しています。
- 不具合件数の改善
同じ期間で不具合の新規発生件数を比べてみても、大幅に不具合が減少していることがわかりました。
結果として、約40%程度も抑制されていました。そのため、チーム内のリソース最適化につながり、新しい施策をお客さまに届けることができました。
いま取り組んでいること
ここまで実際に取り組んできた内容について紹介させていただきました。
過去の負債を返済し、新しいフェーズに立たされた今、より良いサービスをお客さまに届けるために取り組んでいることについて少しだけ共有します。
不具合分析
現在はリリース前のフェーズに対して不具合分析を行い、チームで振り返って問題抑制を目指しています。
どんな要因によって引き起こっている問題が多く存在するのか具体的に知ることで、サービスの品質向上につなげています。問題の原因を理解することで、プロセスを改善すべきなのか、技術向上が必要なのか、また組織のあり方から考えるべきなのかなど、問題の本質を理解することで、課題解消へのアプローチがしやすくなる取り組みができると私は考えています。
不具合分析の見える化
不具合分析の見える化をすることで、新しい機能のリリース時に、負債をなるべく抱えない形でリリースし、これまで以上に高い品質でのサービス提供が可能になることを目指しています。
不具合の分析はつぎのように分類しています。
- 機能に関する不具合（実装ミス・外部要因）
- 仕様に関する不具合（要件漏れ・仕様書ミス・仕様理解不足）
- 表示に関する不具合
- デザインに関する不具合
- 運用に関する不具合
- デグレ
不具合分析から問題の発生要素として割合が高いものについて、チームで対策を取り、改善していくというアプローチで進めています。
この取り組みをしてまだ日は浅いですが、具体的なエビデンスをもとに振り返りを行うことで、改善ポイントが明確になってきています。
モニタリング途中ではありますが、不具合の発生頻度が30%ほど減っており、運用・保守のリソースを新規開発のリソースにあてることもできるようになってきました。
大切なこと
次に、プロジェクトチームで1つの新しい文化や習慣を作るために、私が個人的に大切にしていたことを3つ紹介します。
共通認識を持つ
特に関係するメンバーが多いチームの場合は、認識の齟齬が大きな問題につながることがあります。
ですので課題はもちろん、良かったポイントも齟齬なく共通認識を持てるように同じ基準と粒度をつかう点を意識していました。QAメンバーという立場から継続的にサービス品質を可視化することや、プロセスを可視化することで、プロジェクトの状況を明らかにしました。
長期的な視点を持ち、継続すること
残念なことに負債の累積や慣れ親しんだ文化というのは、簡単にはなくなりません。背景にはそれを生み出した組織構造や組織文化があるからです。品質とは「誰かにとっての価値」であり、この価値は常に変化していくものです。条件により常に変化する品質の中で、実際に手を動かし、いろんな取り組みからフィードバックを得ることや粘り強く継続することが重要です。
今回の取り組みも明確な結果が出るまで、半年近くかけ新しい習慣を作りました。長期的な視点をもって作られた新しい文化は、簡単に失われることがない、きっと素晴らしい組織の資産になると信じています。
「こうしていきたい！」「こうあるべきだ！」というゴールや意図を明確にした上で、QAメンバーとしてしっかりオーナーシップをもち進行することが大切だと思います。そして、周りを巻き込むパワーと何より大切にしてきたことは、メンバーとの信頼関係です。信頼関係を築きながら進めていくことで、一人ではできないことを形にできたと思っています。
チームで分かち合うこと
チームの間できちんと同じ方向をみんなで向いているか、ということを定期的に意識していました。週に1度、マネージャーやエンジニアと今のプロジェクトの状況や課題を共有し、またCredit Design全体での会議体でも状況を伝えていました。
共通認識を持つことは情報の共有から始まります。チームの成果を知ってもらうこと、周りと成果を分かち合うことは十分に価値があります。
新しいサービスをリリースしても障害が起きていないことや、運用・保守に関する課題がきちんと消化できていることが明確になると、単純にちょっとうれしい気持ちにもなります。
そして、向き合う課題を一緒に考える機会が定期的にあることは、潜在的にメンバー全員の意識の中に、問題に対する注目をひきつけることにもつながります。
「全員品質」 = One Team
私たちメルペイでは「全員品質」を目指しています。これは、プロダクト開発・運用に関わるすべてのメンバーが、立場や役割を超え、より良いサービスをお客さまに届けるために、全員で品質を作り上げていくことを指しています。
「全員品質」は、チームメンバーや組織の協力体制があって、はじめて実現できることです。
当然、新規機能の開発と運用・保守は別々に考えることはできず、むしろ目的意識が同じであれば、必然的に全員で品質と向き合うことになるはずです。
Credit Designチームでの取り組みは、「全員品質」を目指す過程での、ごく一部のプロジェクトの紹介でした。
これからもQAエンジニアとして、全員で品質を作ることを理解し、役割に関係なくサービスの価値向上に意識が向くように、何をしていくべきか考えていきたいと思います。
終わりに
今回紹介させていただいた「全員品質」のマインドセットに共感したり、興味を持ってくださった方は、カジュアルにお話することができますので、ぜひご連絡ください！
またメルペイではミッション・バリューに共感できるQAエンジニアを募集しています。一緒に働ける仲間をお待ちしております！
