チーム内にもあった“ヤバい”空気感
メルペイチームが技術的負債をゼロにするためにやったこと

「メルペイスマート払い」の開発を担うCredit Design

櫻井みづき氏（以下、櫻井）：メルペイでQAエンジニアをしている櫻井みづきです。今日は「より良いサービスを継続的に届けるための新しい習慣ができるまで」というテーマでお話していきたいと思います。

まず本日のアジェンダです。今日は3つのことを中心にお話しします。今日のテーマを話すのにあたって、Credit Designというチームでの取り組みについて紹介していきたいと考えています。なのでCredit Designとは何かについて、まずはみなさんに理解してもらって、そのあとに具体的に取り組んでいったことをお話しします。最後に取り組みの中で私が大事にしてきた考え方や、意識していたことをお話できればと思います。

さっそくですが簡単に自己紹介をします。改めまして、私は今メルペイでQAエンジニアをしている櫻井みづきです。2018年7月にメルペイにQAエンジニアとして入社して、当時から現在に至るまでiD決済まわりの機能を主に担当してきました。2020年3月頃から与信領域も担当していて、QA技術の向上や組織づくりをしています。

趣味は旅行で日本全国を周った経験もありますが、今はこのような状況なので新しい趣味を探しているところです。

今日は私が担当している与信領域での中長期的な取り組みを振り返りながら、全員品質につなげて話をしたいと思います。与信領域についてですが、メルペイではCredit Designと呼ばれています。まずはCredit Designについてみなさんの理解を深めていきたいと思います。

Credit Designというのは「メルペイスマート払い」の開発をしているチームのことです。お客さまが商品を購入したあとで支払いができる機能などを提供しています。

次に歴史についてです。2019年4月に「メルペイあと払い」の機能をリリースして、同年にメルペイスマート払いという名称にリニューアルしました。2020年7月には、購入した商品をあとから定額払いに変更できる機能をリリースして、支払い方法を柔軟に選択できるようになりました。さらにシミュレーション機能を追加して、最適な支払いプランを選択できる機能もアップデートしています。

次はチームの構成についてです。ざっくりと3つのチームで構成されています。1つ目は新しいマイクロサービスや大型の案件などを機能開発する新機能開発のチームです。2つ目は既存機能のアップデートや改善、Growth施策の対応をするGrowthと呼ばれるチームです。3つ目にプロダクティビティやオートメーションなどに特化した保守や運用、改善などを担当するチームです。

チームのQAメンバーだけで30名ほどいた時期もありました。Credit Designがどれくらいの規模感のチームであるかはなんとなく把握してもらえると思います。このようなチームに私が参加してからの話をさっそく話していきたいと思います。

技術的負債が山積みのCredit Designチーム

私がCredit Designチームに入ったのは2020年3月頃でした。先ほどの歴史の図に当てはめるとすでにサービスとしてリリースをしていて、新しい大きな機能リリースを控えている時期に該当します。当時、私が感じていたCredit Designチームへのイメージはこんな感じでした。

2019年4月にメルペイスマート払いはリリースされています。Merpay Advent Calendarで、弊社のVPoEエンジニアの木村も触れていることなんですが、社内のビジネス的要件としてゴールデンウィークのキャンペーンに大きな投資をすることになっており、その効果を最大化するためにリリースが必須という背景がありました。

4月にリリースすることを優先したため、技術的な課題として本来であればマイクロサービスとして切り出してから進めるべきところを、いったん既存のシステムに実装を行い、あとから切り出すという技術的負債を負うことを意図的に選択しています。このリリースに伴う技術的負債が、チームにとって想定以上に大きな課題として残り続けました。それは私がチームに入って「メルペイあと払い」をリリースして1年以上経ったあとも残っている状況でした。

この課題の解消に向けて最初にやるべきだと私が考えたことが、現状を知るということでした。チーム内にもヤバイという空気感はあったんですが、それを測る基準がないと感じていました。目の前の課題が膨大だったため、そこまで手が回わらないのが正直なところでした。

この連鎖を断ち切るために、共有認識としての課題感の共有が必要と思いました。目に見えないものと向き合うことは非常に難しく、体感は人によって異なるので、同じ粒度をもって問題を問題として捉えられるようにすることから始めようと思いました。

課題解消のために取り組んだ3つのこと

私が実際に取り組んだことについて具体的にお話ししていきたいと思います。いくつかあるんですが、今日は主に3つお話ししていきたいと思います。1つ目は「目的の共有」です。共通認識の創出のために課題の見える化を行う目的を共有しました。なぜこれを行うのかをチームメンバーに理解してもらい、一緒に取り組んでいくことを明らかにしました。

見える化して課題感の共通認識をもつことで、プロジェクトを計画どおりに進行しお客さまにサービスを継続的に届けることや、今後顕在化するかもしれないリスクを洗い出すことにより、予防する効果があることを理解してもらい、チームで取り組む意義があることを理解してもらいました。

2つ目は課題を改善するために具体的に行ったアクションです。チームで力を入れて取り組んだことが、「ふりかえりのフローの徹底」です。これまで放置されがちだった問題を、みんな同じ粒度でわかる状況を作りました。障害のふりかえりができるように滞留している問題の見える化をして、発生時期や担当者の明確化など基本的な情報を整備しつつ、本質的に必要な課題解決のロジック改修やプロセス改善に取り組みました。

具体的には、これまで曖昧になっていたインシデントの内容をチームできちんとふりかえって、その情報を横断的に共有する体制や仕組み化を作りました。インシデントが発生したときにはインシデントレポートを作成するんですが、このレポートをきちんとタスクとして積んで、レポートがクローズされるまでの対応率を見える化しました。例えば4件のレポートがあり、その内2件しか対応していない場合は障害の対応率が50パーセントと定義しました。

ほかにも、問題が発生してから解消するまでのタスクの消化の対応率を数値化しました。何のチケットが進捗していて何のチケットができていないのかを見える状態を維持しました。

次は「自動テスト」です。メルペイのローンチ前に開始された機能のほとんどは自動テストが導入されていましたが、「メルペイスマート払い」は自動化の導入が当時できていないままリリースしている機能の1つでした。効率化、生産性の観点から、また定期的な品質保証ができていない状況を危惧して自動化を導入しました。

主な目的としては想定外の修正による考慮不備の削減などを目指していました。自動テストを書いたことがないメンバーで構成されていましたが、バックエンドのメンバーにもサポートしてもらいながら、QAメンバーを主体とする自動テストの導入に力を入れることができました。現在は、考慮不足による不具合の検知やアサインの最適化に寄与しています。

メンテナンスをし続けることはかなり大変ですが、一方で自動化を導入したメリットも大いにあったと感じています。これらの取り組みをした結果、どのように改善していったのかを話していきたいと思います。

結果としてチームに新しい文化や習慣が生まれた

結果としては、当たり前のことかもしれないですが、問題が起きたらすぐに課題と向き合い、根本的な改善策を考えるように改善していきました。何をすれば今後同じ問題が起きないかをチームで考える新しい文化や習慣が生まれました。

例えばインシデントレポートの対応率の話でいうと、計測当初は26パーセントほどの対応率で、つまりほとんどのインシデントがそのままの状態という状況でしたが、この取り組みを続けていった結果、負債の先送りも軽減され、放置される問題もなくなりました。

また、不具合の発生頻度自体も大きく変化しました。取り組みを始めた当初は滞留課題があり、課題発生頻度も多かったのですがリリース頻度は変わらず、むしろ難易度の高い大きめのリリースがあった半年後のほうが課題発生率が減少していることがわかります。

同じ期間での問題発生件数を見てみると、大幅に課題が減少していることがわかります。40パーセント程度の問題が抑制されてリリースの最適化につながり、新しい施策をお客さまに届けることができたと思っています。

リリース前に案件の不具合を分析して問題を抑制する

次に、今取り組んでいることについて少しだけお話ししたいと思います。現在は、リリース前の案件に対してもきちんと不具合分析を行っています。どんな要因によって問題が引き起っているのかをチームでふりかえりをして、問題抑制につなげています。

不具合分析を見える化して、新しい機能リリース時に負債をなるべく抱えずにリリースすることで、これまで以上の高い品質でのサービス提供を目指しています。また、問題の要因を分析して、予防や改善につながると考えています。必然的にメンバーの負荷も軽減して、新しい機能開発にリソースを使えるようになることを期待しています。

いろいろな取り組みをしてきましたが、私が大事に考えていたことを最後にお話ししていきたいと思います。1つ目は共通認識をもつということです。同じ基準と粒度で課題はもちろん、よかったポイントも不足なく共通認識をもてるように意識しました。そのためにサービス品質を継続的に可視化して、課題対応へのサイクルを形成し、どんな状態にあるのかが明らかになるアウトプットを出しました。

2つ目は長期的な視点を持ち、継続するということです。負債の解消や慣れ親しんだ文化は簡単にゼロにはならないということを常に意識しないといけないと思います。実際に、この取り組みで明確な結果が出るまで、約半年近くかけ習慣化していきました。こうしていきたいというゴールや意図を明確化した上で、QAメンバーがしっかりオーナーシップをもって進行しつつ、周りを巻き込むパワーと信頼関係がすごく大切なことだと思っています。

3つ目はみんなで成果や現状を分かち合うということです。同じ方向をみんなきちんと向いているかを定期的に意識していました。マネージャーやテックリード、エンジニアやPMといったメンバーと週に1度、現状や課題を共有して、定期的に大きな会議体の場でCredit Designチームの成果を伝えていました。

同じ目的意識で全員で品質と向き合う

最後になりますが、今日のテーマの「全員品質」にはチームメンバーや組織の協力体制があって初めて実現できることだと思っています。新規機能の開発と運用方針は別々に考えることはできず、むしろ目的意識が同じであれば必然的に全員で品質と向き合うことになると思っています。全員で品質を作ることを理解し、役割に関係なくサービスの価値向上に意識が向くようにQAエンジニアとしてどうやってプロセスやチームに関わっていくかをこれからも考えていく必要があると思っています。

これで発表を終わりにしたいと思います。ご清聴ありがとうございました。

司会者：ありがとうございました。

（一同拍手）

参加者1：1つ目、「リリース前の不具合分析ですが、具体的にどのように見て分析するのでしょうか？」という質問が来ています。今はどんな感じで分析していますか？

櫻井：まずQAで検知した不具合を優先度別でp0からp2まで分けています。実際に出た不具合が、p0のものがどれくらいあってみたいなことを数値化して、その不具合は何が要因で発生しているのかを分類しています。

具体的にいうとデザイン不備、仕様不備、表記不備のように、同じ不具合でも何が原因になったのかを分類しています。不具合の多くは、デザインや仕様の認識が違ったことによって起きていたみたいなことがわかったりしています。

その仕様の認識齟齬をどうやったら減らせるのか議論を持っていくようにして、次のプロジェクトや案件に入るときにそこを意識して取り組むことでリリース前のベースのラインの品質を全体的に向上しようとしています。

参加者1：こういう取り組みはけっこう開発側から「なんでするの？」とか聞かれると思うんですが、その辺は協力的にやれていますか？

櫻井：そうですね。リリース前の不具合を分析するよりも前に今発表したことを約半年かけてやってきているので、PM陣やエンジニア陣と一緒にその次のフェーズに進めました。

いきなり具体的な数字が見えるのがメリットでもありデメリットになると思っています。今回は具体的な数字を出したことによって、みんなが「これはヤバイ」と共通認識をもてたので、リソースなどに対する温度感を高く持っていけたんですが、使い方を間違えると反感も当然起きると思います。協力関係がすごく大事だなと思っていたので、協力関係を築くことをベースとして常に意識して、次はどこを一緒に考えていくべきなのかという意識は強くしています。

参加者1：不具合分析の数字の取り方ですが、どう不具合の検知をして分析のデータを作っていますか？

櫻井：JIRAでタスクの管理をしているんですが、どういう不具合が発生したらどういう分類をするかをチームで共通認識をもって、QAで検知した場合はそのラベルを貼って自動的に何の不具合がどれくらいあるのかがわかるようにしていますね。なのでJIRAのカンバンを使ってそこからスプレッドシートなどで情報を提供しています。

参加者1：「リリース後ではなくリリース前に不具合分析をしようと思ったきっかけは何ですか？」という質問が来ています。

櫻井：リリースの後に対応するということは、お客さまに何かしらの影響があったあとにトライしていることになるので、できる限り高い品質でリリースしたいとはもともと思っていたんですが、今お話ししたとおり、当初はかなりの問題がそのまま山積みの状態でした。

なのでリリース前の品質を高めていくことを中長期的に考えて、まずは負債をゼロにするのを計画立ててそこを達成できたので、リリース前にトライをQAから提案をしてチームとして受け入れられるフェーズになったところかなと思います。

参加者1：すばらしいですね。ありがとうございます。

司会者：ありがとうございます。