「全員品質」を実現するためのメルペイにおけるDevOpsの取り組み / Best practices to support quality of service

2021年5月13日に開催された「各社のサービス品質を支えるベストプラクティス-EngineeringTeamPresentation」で発表した資料です。
https://sansan.connpass.com/event/209357/

「全員品質」を実現するためのメルペイにおけるDevOpsの取り組み

Transcript

1. 1 「全員品質」を実現するための メルペイにおけるDevOpsの取り組み 2021年5月13日 株式会社メルペイ 櫻井みづき(miisan)
2. 2 本日のゴール Today's goal
3. 3 本日のゴール メルペイの文化である 「全員品質」形成の過程と思想の理解
4. 4 文化とは 「物事がその中で実際にどう行われているか」
 カール・E・ウィーガーズ（2005）『ソフトウェア開発の持つべき文化』翔泳社
5. 5 「全員品質」 メルペイにおける文化 役割や立場を越境し、 One Teamで品質を作り上げること
6. 6 メルペイサービスの歴史 本日のアジェンダ DevOpsについて 協働的チームを作った事例 全員品質について 02 03 04 01 自己紹介 05
7. 7 自己紹介 introduction
8. 8 自己紹介 株式会社メルペイ QA Engineer Mizuki Sakurai /@mii________san 2018年7月よりメルペイにQAエンジニアとして参画。入社直後より iD決済領域を主に担 当する。 キャンペーン、メルペイスマート払い、定額払い機能やバーチャルカード (オンライン決済) のリリースなどにも関わり、メルペイの決済全般のサービスリリースに数多く携わる。 「金融系テックカンパニーの QAになること」をミッションに、日々サービスの品質向上、開 発プロセス改善、QA技術向上、組織作りをリードし、より良いサービスをお客さまへ届け るために奮闘中。 趣味はカメラと旅行。日本 47/47都道府県制覇、海外 20ヶ国以上旅してます。 以前は週末トラベラーとしていろんな場所にフラッと旅してました✈
9. 9 メルペイサービスの歴史 History of Merpay service
10. 10 ミッション 信用を創造して、
 なめらかな社会を創る

11. 11 数字で見るメルペイの今 サービス開始は、2019年2月。サービスローンチから約2年。 「メルペイ」の利用者数（※1）は1000万人を突破🎉 利用者数 1000万人 決済対応加盟店 206万ヶ所 ※1　メルペイ「電子マネー」の登録を行ったユーザーと、「メルペイコード決済」、「ネット決済」、「メルペイスマート払い」等の利用者の合計（重複を除く） 2021年4月21日時点
12. 12 メルペイのフェーズの変化 サービスをリリースすること　⇒　価値を継続的に届けること 
 
 新しい価値を作る
 ゼロから、新しい価値を 
 作ろうとうする
 集まったばかりの様子見 
 事業フェーズ
 0 -> 1フェーズ
 形成期
 
 
 仕組みを作る
 最初に作った価値を、繰り返し提供 できる状態を目指す 
 1 -> 10フェーズ
 仕組みを大きくする
 一度作った仕組みを繰り返しなが ら大きくしていく
 10 -> 100フェーズ
 組織フェーズ
 色んな議論や対立が起きる 
 混乱期
 基準やルールが整備される 
 統一期
 標準や基準が組織内で 
 浸透する
 機能期

13. 13 安心して利用できるサービス開発、サービス運用体制を構築して、 プランニングからリリースまでのサイクルを継続的に行える構造へ メルペイのフェーズの変化
14. 14 DevOpsについて About DevOps
15. 15 Development(開発とテスト)とOperations(デプロイメントとモニタリング)を組み 合わせた組織文化であり、開発・運用を推進するための開発モデル DevOpsとは
16. 16 開発チームと運用チームの関係 　開発チーム ▪▪▪▪▪▪▪▪常に新しい機能やサービスのリリースを考え、開発を進める 　運用チーム ▪▪▪▪▪▪▪▪サービスの安定稼働や利便性の維持を目指し、開発を進める 開発チームと運用チームの主な役割
17. 17 開発チームと運用チームの関係 　開発チーム ▪▪▪▪▪▪▪▪「運用チームはサービスリリースの重要性を理解していない」 　運用チーム ▪▪▪▪▪▪▪▪「開発チームは運用の重要性を理解していない」 開発チームと運用チームの対立関係 VS
18. 18 開発チームと運用チームの関係 　開発チーム ▪▪▪▪▪▪▪▪「良いサービス」をお客さまに提供したい 　　　　　 　　　　　　　　　　 　運用チーム ▪▪▪▪▪▪▪▪「良いサービス」をお客さまに提供したい 開発チームと運用チームの協力関係 = 同じ目的を持つ仲間
19. 19 なぜメルペイはDevOpsに取り組むのか • 協力体制 ◦ 役割に関係なく、サービスの価値向上に目的意識が向き、プロダクト全体 に対して活動できる。 • 信頼性向上 ◦ 責任範囲をいい意味でわけないことで、開発フェーズの中に、多くのテスト が組み込まれやすく、品質の向上につながる。 • 生産性向上 ◦ 自動テストが開発フェーズに組み込まれることで、検証フェーズでのテスト を効率化することができる。また不具合を早期に検出できるので、開発プロ セス全体の生産性が向上し迅速なリリースが可能。 お客さまにより早く、より確実に、より良いサービスを継続的に届けるため
20. 20 DevOpsにおける品質活動 断続的な開発サイクルにおいて、すべての活動の中でQAや改善活動を行う 最後にテストする　⇒　ずっとテストし続ける
21. 21 協働的チームを作った事例 An example of creating a collaborative team
22. 22 メルペイが抱えていた課題 背景：リリースラッシュによってカオスな状況(負債の累積)を招いていた 必要だったこと： • 継続的に価値を提供できる状態を目指すための技術的負債の返済 • 同じことを引き起こさないための新しい仕組み作り（文化的負債の返済）
23. 23 取り組み 目的の共有 01 課題把握・課題整理 02 課題の定義 03 課題の振り返り 04 課題解消フローの徹底 05
24. 24 目的の共有 「ゴール」を共有し、なぜ課題解消に向き合う必要があるのか理解を得る 1. プロジェクトを計画通りに進行し、お客さまにサービスを継続的に届ける 2. 今後顕在化するかもしれないリスクを洗い出し、それを事前に予防する ⇒ チームで取り組む意義のあるもの • どんな目的があるかが明確であれば、何故それをやらなければいけないのか理 解しやすい • そのうえでどのような課題があるのか明らかにして取り組むことで、課題が解消 していく
25. 25 課題把握・課題整理 共通認識として「課題感」の共有が必要 • 曖昧なもの、雰囲気で理解していたことを明確化する ◦ 粒度が異なる ◦ 温度感が違う ◦ 優先度の認識齟齬 　⇒ 課題意識は人、立場、役割によって異なるもの • 明確にすべきこと ◦ いま何が起きているかについて同じ視点で把握できる指標が必要
26. 26 課題の定義 実際にチームで同じ視点によって課題を把握するために整理した指標 • インシデントの内容 • インシデントの発生頻度 • インシデントの発生原因 • インシデントの対応状況・対応率 • 滞留課題 ◦ 経過日数 ◦ ブロッカーの確認 • インシデントの振り返り状況
27. 27 課題の振り返り 発生したインシデントの振り返りを横断的に共有する体制と仕組みを導入 • どのチームでどんなインシデントが発生したのか • インシデントに対してどのような対応をとったか • 暫定、恒久対応はなにか 　⇒　 整理した課題を振り返り、知見をチーム全員にシェアする インシデント検知
 課題管理登録
 ・Blameless
 ・JIRA 
 チーム振り返り
 ・暫定対応
 ・恒久対応
 
 振り返りの共有
 ・原因、影響範囲
 ・対応、再発防止策 
 ・alert検知
 ・CSお問い合わせ 

28. 28 課題解消フローの徹底 体制や仕組みを作っても、はじめはワークしない。習慣化するまでオーナーシップを 明確にしてフローを繰り返し実施する。 • 役割分担の明確化 ◦ だれがどんな情報をアウトプットするのか ◦ 課題整理をしたらだれに、いつ情報を展開するのか • 週次チェックを行い、課題感の変化や数値的変化を確認する ◦ インシデントの発生率 ◦ 滞留課題や負債の解消率 • 各チームの課題をシェアすることで互いのチーム状況を理解し合う ◦ 新規開発チームも運用保守チームが協力し合う「One Team体制」
29. 29 振り返りフローの結果 メルペイにおける効果 • インシデントレポートの対応率 ◦ 課題整理当初：26% ◦ 半年後：94% • インシデント発生率 ◦ 47%軽減 before after 26%
 ・滞留課題を見える化し、毎週チェックインすること で、ほとんどの課題が2週間以内に解消されるよう になった ・課題の原因と再発防止策を検討すること、他チー ムにも共有することで知見の浸透 94%

30. 30 メルペイがたどり着いた「イマ」 価値を繰り返し提供するためには、協力してプロダクトと向き合う必要があるという共 通理解を得る • 仕組みを繰り返し続けることで新しい習慣が出来上がり、「全員で品質と向き合 う」というマインドセットが浸透 ◦ Go Bold：担当領域にとらわれず、チーム全体に対して成果創出する ◦ All for one：自発的・主体的な参加と連携 ◦ Be a Pro：プロセス以外にも自動化や共通プラットフォーム化などテクニカ ルな部分のサポート 全員品質 と呼んでいる
31. 31 全員品質について About all quality
32. 32 全員品質とは プロダクト開発・運用に関わるすべてのメンバーが、立場や役割を超え、より良い サービスをお客さまに届けるために、全員で品質を作り上げていくこと Process Product Team
33. 33 全員品質の考え方 テストチームの責任と考えず、品質に対するチームの責任と捉える テスト ちゃんとした？ 「不具合」が発生した時の対応方法 問題を一緒に 振り返ろう！！！ Bad case😥 Good case😊
34. 34 全員品質を実現するために必要なこと どうしたら全員で品質と向き合うことができるのか 現状把握
 01 02 03 課題に対する共通認識を持つことで、個々人が主体的に考えられる。また同じ温度感でプロダクトに向き 合うことができるため、認識齟齬などが起きづらくなる。 持続すること
 負債の累積や慣れ親しんだ文化は簡単になくすことはできない。そのため、いろんな取り組みからフィード バックを得ることや粘り強く継続することが重要となる。
 互いを理解し合うこと
 チームの成果を知ってもらうこと、チームで成果を分かち合うことは価値があり、信頼関係を築きながら進 めていくことで強いチームとなる。

35. 35 全員で品質と向き合う意味 プロジェクトを計画通りに進行し、お客さまにサービスを継続的に届ける 安心安全リリース 新しい価値提供 リソース増加 保守運用コストの低減
36. 36 「全員品質」 本日のゴール 役割や立場を越境し、 One Teamで品質を作り上げること
37. 37 「品質」とは、だれもの？
38. 38 良いサービスは全員で創る。 DevOps時代の新しいあり方
39. 39 Thank you !!