Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

miisan
May 13, 2021

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

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

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

miisan

May 13, 2021
Tweet

More Decks by miisan

Other Decks in Technology

Transcript

  1. 1
    「全員品質」を実現するための
    メルペイにおけるDevOpsの取り組み
    2021年5月13日 株式会社メルペイ 櫻井みづき(miisan)

    View full-size slide

  2. 2
    本日のゴール
    Today's goal

    View full-size slide

  3. 3
    本日のゴール
    メルペイの文化である
    「全員品質」形成の過程と思想の理解

    View full-size slide

  4. 4
    文化とは
    「物事がその中で実際にどう行われているか」

    カール・E・ウィーガーズ(2005)『ソフトウェア開発の持つべき文化』翔泳社

    View full-size slide

  5. 5
    「全員品質」
    メルペイにおける文化
    役割や立場を越境し、
    One Teamで品質を作り上げること

    View full-size slide

  6. 6
    メルペイサービスの歴史
    本日のアジェンダ
    DevOpsについて
    協働的チームを作った事例
    全員品質について
    02
    03
    04
    01 自己紹介
    05

    View full-size slide

  7. 7
    自己紹介
    introduction

    View full-size slide

  8. 8
    自己紹介
    株式会社メルペイ QA Engineer
    Mizuki Sakurai /@mii________san
    2018年7月よりメルペイにQAエンジニアとして参画。入社直後より
    iD決済領域を主に担
    当する。
    キャンペーン、メルペイスマート払い、定額払い機能やバーチャルカード
    (オンライン決済)
    のリリースなどにも関わり、メルペイの決済全般のサービスリリースに数多く携わる。
    「金融系テックカンパニーの
    QAになること」をミッションに、日々サービスの品質向上、開
    発プロセス改善、QA技術向上、組織作りをリードし、より良いサービスをお客さまへ届け
    るために奮闘中。
    趣味はカメラと旅行。日本
    47/47都道府県制覇、海外
    20ヶ国以上旅してます。
    以前は週末トラベラーとしていろんな場所にフラッと旅してました✈

    View full-size slide

  9. 9
    メルペイサービスの歴史
    History of Merpay service

    View full-size slide

  10. 10
    ミッション
    信用を創造して、

    なめらかな社会を創る


    View full-size slide

  11. 11
    数字で見るメルペイの今
    サービス開始は、2019年2月。サービスローンチから約2年。
    「メルペイ」の利用者数(※1)は1000万人を突破🎉
    利用者数
    1000万人
    決済対応加盟店
    206万ヶ所
    ※1 メルペイ「電子マネー」の登録を行ったユーザーと、「メルペイコード決済」、「ネット決済」、「メルペイスマート払い」等の利用者の合計(重複を除く)
    2021年4月21日時点

    View full-size slide

  12. 12
    メルペイのフェーズの変化
    サービスをリリースすること ⇒ 価値を継続的に届けること


    新しい価値を作る

    ゼロから、新しい価値を

    作ろうとうする

    集まったばかりの様子見

    事業フェーズ

    0 -> 1フェーズ

    形成期



    仕組みを作る

    最初に作った価値を、繰り返し提供
    できる状態を目指す

    1 -> 10フェーズ

    仕組みを大きくする

    一度作った仕組みを繰り返しなが
    ら大きくしていく

    10 -> 100フェーズ

    組織フェーズ

    色んな議論や対立が起きる

    混乱期

    基準やルールが整備される

    統一期

    標準や基準が組織内で

    浸透する

    機能期


    View full-size slide

  13. 13
    安心して利用できるサービス開発、サービス運用体制を構築して、
    プランニングからリリースまでのサイクルを継続的に行える構造へ
    メルペイのフェーズの変化

    View full-size slide

  14. 14
    DevOpsについて
    About DevOps

    View full-size slide

  15. 15
    Development(開発とテスト)とOperations(デプロイメントとモニタリング)を組み
    合わせた組織文化であり、開発・運用を推進するための開発モデル
    DevOpsとは

    View full-size slide

  16. 16
    開発チームと運用チームの関係
     開発チーム
    ■■■■■■■■常に新しい機能やサービスのリリースを考え、開発を進める
     運用チーム
    ■■■■■■■■サービスの安定稼働や利便性の維持を目指し、開発を進める
    開発チームと運用チームの主な役割

    View full-size slide

  17. 17
    開発チームと運用チームの関係
     開発チーム
    ■■■■■■■■「運用チームはサービスリリースの重要性を理解していない」
     運用チーム
    ■■■■■■■■「開発チームは運用の重要性を理解していない」
    開発チームと運用チームの対立関係
    VS

    View full-size slide

  18. 18
    開発チームと運用チームの関係
     開発チーム
    ■■■■■■■■「良いサービス」をお客さまに提供したい
         
              
     運用チーム
    ■■■■■■■■「良いサービス」をお客さまに提供したい
    開発チームと運用チームの協力関係
    = 同じ目的を持つ仲間

    View full-size slide

  19. 19
    なぜメルペイはDevOpsに取り組むのか
    ● 協力体制
    ○ 役割に関係なく、サービスの価値向上に目的意識が向き、プロダクト全体
    に対して活動できる。
    ● 信頼性向上
    ○ 責任範囲をいい意味でわけないことで、開発フェーズの中に、多くのテスト
    が組み込まれやすく、品質の向上につながる。
    ● 生産性向上
    ○ 自動テストが開発フェーズに組み込まれることで、検証フェーズでのテスト
    を効率化することができる。また不具合を早期に検出できるので、開発プロ
    セス全体の生産性が向上し迅速なリリースが可能。
    お客さまにより早く、より確実に、より良いサービスを継続的に届けるため

    View full-size slide

  20. 20
    DevOpsにおける品質活動
    断続的な開発サイクルにおいて、すべての活動の中でQAや改善活動を行う
    最後にテストする ⇒ ずっとテストし続ける

    View full-size slide

  21. 21
    協働的チームを作った事例
    An example of creating a collaborative team

    View full-size slide

  22. 22
    メルペイが抱えていた課題
    背景:リリースラッシュによってカオスな状況(負債の累積)を招いていた
    必要だったこと:
    ● 継続的に価値を提供できる状態を目指すための技術的負債の返済
    ● 同じことを引き起こさないための新しい仕組み作り(文化的負債の返済)

    View full-size slide

  23. 23
    取り組み
    目的の共有
    01
    課題把握・課題整理
    02
    課題の定義
    03
    課題の振り返り
    04
    課題解消フローの徹底
    05

    View full-size slide

  24. 24
    目的の共有
    「ゴール」を共有し、なぜ課題解消に向き合う必要があるのか理解を得る
    1. プロジェクトを計画通りに進行し、お客さまにサービスを継続的に届ける
    2. 今後顕在化するかもしれないリスクを洗い出し、それを事前に予防する
    ⇒ チームで取り組む意義のあるもの
    ● どんな目的があるかが明確であれば、何故それをやらなければいけないのか理
    解しやすい
    ● そのうえでどのような課題があるのか明らかにして取り組むことで、課題が解消
    していく

    View full-size slide

  25. 25
    課題把握・課題整理
    共通認識として「課題感」の共有が必要
    ● 曖昧なもの、雰囲気で理解していたことを明確化する
    ○ 粒度が異なる
    ○ 温度感が違う
    ○ 優先度の認識齟齬
     ⇒ 課題意識は人、立場、役割によって異なるもの
    ● 明確にすべきこと
    ○ いま何が起きているかについて同じ視点で把握できる指標が必要

    View full-size slide

  26. 26
    課題の定義
    実際にチームで同じ視点によって課題を把握するために整理した指標
    ● インシデントの内容
    ● インシデントの発生頻度
    ● インシデントの発生原因
    ● インシデントの対応状況・対応率
    ● 滞留課題
    ○ 経過日数
    ○ ブロッカーの確認
    ● インシデントの振り返り状況

    View full-size slide

  27. 27
    課題の振り返り
    発生したインシデントの振り返りを横断的に共有する体制と仕組みを導入
    ● どのチームでどんなインシデントが発生したのか
    ● インシデントに対してどのような対応をとったか
    ● 暫定、恒久対応はなにか
     ⇒  整理した課題を振り返り、知見をチーム全員にシェアする
    インシデント検知
 課題管理登録

    ・Blameless

    ・JIRA

    チーム振り返り

    ・暫定対応

    ・恒久対応


    振り返りの共有

    ・原因、影響範囲

    ・対応、再発防止策

    ・alert検知

    ・CSお問い合わせ

    View full-size slide

  28. 28
    課題解消フローの徹底
    体制や仕組みを作っても、はじめはワークしない。習慣化するまでオーナーシップを
    明確にしてフローを繰り返し実施する。
    ● 役割分担の明確化
    ○ だれがどんな情報をアウトプットするのか
    ○ 課題整理をしたらだれに、いつ情報を展開するのか
    ● 週次チェックを行い、課題感の変化や数値的変化を確認する
    ○ インシデントの発生率
    ○ 滞留課題や負債の解消率
    ● 各チームの課題をシェアすることで互いのチーム状況を理解し合う
    ○ 新規開発チームも運用保守チームが協力し合う「One Team体制」

    View full-size slide

  29. 29
    振り返りフローの結果
    メルペイにおける効果
    ● インシデントレポートの対応率
    ○ 課題整理当初:26%
    ○ 半年後:94%
    ● インシデント発生率
    ○ 47%軽減
    before after
    26%

    ・滞留課題を見える化し、毎週チェックインすること
    で、ほとんどの課題が2週間以内に解消されるよう
    になった
    ・課題の原因と再発防止策を検討すること、他チー
    ムにも共有することで知見の浸透
    94%


    View full-size slide

  30. 30
    メルペイがたどり着いた「イマ」
    価値を繰り返し提供するためには、協力してプロダクトと向き合う必要があるという共
    通理解を得る
    ● 仕組みを繰り返し続けることで新しい習慣が出来上がり、「全員で品質と向き合
    う」というマインドセットが浸透
    ○ Go Bold:担当領域にとらわれず、チーム全体に対して成果創出する
    ○ All for one:自発的・主体的な参加と連携
    ○ Be a Pro:プロセス以外にも自動化や共通プラットフォーム化などテクニカ
    ルな部分のサポート
    全員品質 と呼んでいる

    View full-size slide

  31. 31
    全員品質について
    About all quality

    View full-size slide

  32. 32
    全員品質とは
    プロダクト開発・運用に関わるすべてのメンバーが、立場や役割を超え、より良い
    サービスをお客さまに届けるために、全員で品質を作り上げていくこと
    Process
    Product
    Team

    View full-size slide

  33. 33
    全員品質の考え方
    テストチームの責任と考えず、品質に対するチームの責任と捉える
    テスト
    ちゃんとした?
    「不具合」が発生した時の対応方法
    問題を一緒に
    振り返ろう!!!
    Bad case😥 Good case😊

    View full-size slide

  34. 34
    全員品質を実現するために必要なこと
    どうしたら全員で品質と向き合うことができるのか
    現状把握

    01
    02
    03
    課題に対する共通認識を持つことで、個々人が主体的に考えられる。また同じ温度感でプロダクトに向き
    合うことができるため、認識齟齬などが起きづらくなる。
    持続すること

    負債の累積や慣れ親しんだ文化は簡単になくすことはできない。そのため、いろんな取り組みからフィード
    バックを得ることや粘り強く継続することが重要となる。

    互いを理解し合うこと

    チームの成果を知ってもらうこと、チームで成果を分かち合うことは価値があり、信頼関係を築きながら進
    めていくことで強いチームとなる。


    View full-size slide

  35. 35
    全員で品質と向き合う意味
    プロジェクトを計画通りに進行し、お客さまにサービスを継続的に届ける
    安心安全リリース
    新しい価値提供
    リソース増加
    保守運用コストの低減

    View full-size slide

  36. 36
    「全員品質」
    本日のゴール
    役割や立場を越境し、
    One Teamで品質を作り上げること

    View full-size slide

  37. 37
    「品質」とは、だれもの?

    View full-size slide

  38. 38
    良いサービスは全員で創る。
    DevOps時代の新しいあり方

    View full-size slide

  39. 39
    Thank you !!

    View full-size slide