「最後の砦」にならないQAエンジニア。プロダクト開発における新しい品質保証のかたち / QA engineer who doesn't become the "last fort"

by miisan

Slide 1

Slide 1 text

1 「最後の砦」にならないQAエンジニア。プロダクト開発における新しい品質保証のかたち miisan @メルペイ

Slide 2

Slide 2 text

2 より良い品質を届けるために本日のアジェンダ品質・QAエンジニアについて身のまわりの変化サービス提供に求められること 02 03 04 01 自己紹介 05

Slide 3

Slide 3 text

About me  自己紹介

Slide 4

Slide 4 text

自己紹介 miisan @mii________san 2018年7月よりメルペイに QAエンジニアとして参画。入社直後から iD決済領域を主に担当し、信用・与信領域など、メルペイサービスの多くの機能に携わる。現在はエンジニアリングマネージャーとしてプロダクト全体の品質向上や個人としては女性エンジニアの推進やスタートアップの QA チーム立ち上げなどにも関わっている。趣味はカメラと旅行。以前は週末トラベラーとしていろんな場所にフラッと旅してました ✈ QA歴：5年 Merpay歴：3年 QA Engineer Manager at Merpay, Inc.

Slide 5

Slide 5 text

Today’s goal  本日のお持ちかえり

Slide 6

Slide 6 text

本日のお持ちかえり  1 2 3 チーム全員の役割の大切さ  「新しい価値」を継続的に届けるために大切なこと  全員品質 

Slide 7

Slide 7 text

What’s Quality?  品質ってなに？

Slide 8

Slide 8 text

品質とは  本来備わっている特性の集まりが、要求事項を満たす程度  品物やサービスの顧客からの要求事項や、ニーズに合っているかを決める特性  信頼性が高い状態  バグがない状態 

Slide 9

Slide 9 text

品質とは  ● 致命的な不具合が無い ● 使いやすい、分かりやすい（時間を奪わない） ● 止まらない(すぐ復旧可能)、間違えない、不正に使われない (安全・安心) これが充足されれば当たり前と受け止められるが、不充足であれば顧客の不満を引き起こす品質これが充足されなくても顧客が不満にならないが、充足されれば、顧客に満足を与え、喜びをもたらす品質 ● 他社に無い機能 / 分かり易さ / 直感で操作できる ● 初めての体験の提供（素早い変化） / 継続的にお客さまへサービスが提供される体験魅力的品質当り前品質 ※品質が良いとは、仕様通りに動くことやバグが無いサービスだけをさすわけではない。

Slide 10

Slide 10 text

What’s QA Engineer?  QA Engineerってなに？

Slide 11

Slide 11 text

QA Engineerとは  Quality Assurance (品質保証) 品質保証に特化したソフトウェアエンジニア

Slide 12

Slide 12 text

QA Engineerのイメージ 

Slide 13

Slide 13 text

QA Engineerのイメージ 

Slide 14

Slide 14 text

QA Engineerのイメージ 

Slide 15

Slide 15 text

QA Engineerのイメージ  品質を”守る”「最後の砦」

Slide 16

Slide 16 text

本日のテーマ  「最後の砦」にならないQAエンジニア...???? 

Slide 17

Slide 17 text

Any changes around you  身のまわりの変化

Slide 18

Slide 18 text

身のまわりの変化  開発手法の発展  DXの進化  1 2

Slide 19

Slide 19 text

開発手法の発展  ウォーターフォール・モデル  アジャイル開発  プロトタイプ・モデル  スパイラル・モデル 

Slide 20

Slide 20 text

DXの進化  DX：Digital Transformation   ITの浸透が、人々の生活をあらゆる面でより良い方向に変化させる。ウメオ大学（スウェーデン）のエリック・ストルターマン教授が2004年に提唱した概念。企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること。デジタルトランスフォーメーションを推進するためのガイドライン（DX推進ガイドライン） Ver. 1.0　経済産業省

Slide 21

Slide 21 text

生活スタイルの変化  これまでなかった日常体験の実現買い物/注文支払い/資産管理家電操作コミュニケーション SNS 医療問診移動手段

Slide 22

Slide 22 text

業務スタイルの変化  これまでなかった仕事・業務体験の実現会議コミュニケーション情報管理/セキュリティー契約書/請求書問い合わせ会計/経費管理 AI・bot

Slide 23

Slide 23 text

DXの本質  ”体験価値”を問い直すこと一人ひとりの価値を捉え、個別化と包摂を実現する体験を提供する

Slide 24

Slide 24 text

DXの本質  ”体験価値”を問い直すこと一人ひとりの価値を捉え、個別化と包摂を実現する体験を提供するユーザー体験を「揺らす」個々が何を大切にしているかを知り、寄り添いつつ、既存サービスを超えた新しい体験の提供をしていく ※尾原和啓宮田裕章山口周（2021）『ソフトウェア開発の持つべき文化 DX進化　つながりがリブートされた世界の先』 MdN

Slide 25

Slide 25 text

Important things for providing services  サービス提供に求められること

Slide 26

Slide 26 text

お客さまにより早く、より確実に、より良いサービスを継続的に届けること  サービス提供に求められること  顧客の要求スピード変化不確実性が高いニーズモノの価値基準の変化

Slide 27

Slide 27 text

How to Build Quality  より良い品質を届けるために

Slide 28

Slide 28 text

全てのプロジェクト・サービスで品質の定義は常に変化する。条件により常に変化する品質の中でベストプラクティスを追い求める。顧客満足度変化しない定義：「品質」とは「誰かに対する価値」 What’s Quality?

Slide 29

Slide 29 text

「品質」を作り上げるには、プロセス・チーム・プロダクトの相互向上が必須  3つの視点  Process Product Team

Slide 30

Slide 30 text

「お客さまへの価値」をつくるための取り組み  Factから目をそらさない 1 全員でゴールを握る 2 原因分析から振り返る 3 習慣化するまで繰り返す 4

Slide 31

Slide 31 text

さまざまな課題  リリースサイクルがうまくまわらない技術的負債の返済が追いつかない... 初期品質が低い優先度がわからず着手すべきタスクがわからない

Slide 32

Slide 32 text

現状を誰が見ても同じ認識で理解できる状態にする Factから目をそらさない  リリースサイクルが回らない・どんなフローが標準になっている？・何にどれくらい時間がかかっているのか？負債の蓄積初期品質が低い・不具合発生率は？・開発期間は？・どんな要因で不具合が発生したのか？作業効率の改善・真のブロッカーになりうる負債とは何か？・いつまでに対応すべき問題があるのか？・情報が分散していないか？・タスクの見える化、タスクの一元管理はできているか？

Slide 33

Slide 33 text

現状を誰が見ても同じ認識で理解できる状態にする Factから目をそらさない  共通認識としての「課題感」が必要曖昧なもの、雰囲気で理解していたことを明確にすることで、立場や役割、個人によって異なって見えていたものが1つに重なり合っていく。 - 粒度が異なる - 温度感が違う - 優先度の認識齟齬ポイント課題の”やばさ”を定量的な指標に落としてみる (チームみんなで把握できる指標 )

Slide 34

Slide 34 text

新しい文化を作り上げていくためには組織内で連携・協調する姿勢が必要全員でゴールを握る  個人型チーム協業型チーム個人目標共通目標

Slide 35

Slide 35 text

新しい文化を作り上げていくためには組織内で連携・協調する姿勢が必要全員でゴールを握る  チームで取り組む意味を理解するどんな目的があるのか明確であれば、なぜやらなければいけないのか理解しやすい。 Factが明確になっていれば、どのような課題があるのか把握できているため課題解消しやすい。ポイントプロジェクトやサービスは個人のものではない。ゴールテープの切り方がわかっていればそれぞれが進むべき道も自ずと決まる。

Slide 36

Slide 36 text

整理した課題を振り返り、具体的な知見をチーム全員にシェアする原因分析から振り返る  振り返りフローやサイクルの構築・KPT プロダクトや案件の定期的な振り返りの実施・Postmortem インシデントから学び、再発防止策を決める具体的なバグ分析・分析問題や事象をカテゴリーに分ける・優先度期日や事象の温度感を分ける

Slide 37

Slide 37 text

Slide 38

Slide 38 text

振り返りフローやサイクルの構築について原因分析から振り返る  KPT K：keep ＝良かったこと(今後も続ける) P：problem＝悪かったこと(今後はやめる) T：try ＝次に挑戦すること -> 課題を放置しないように可視化する Postmortem インシデントを検知したら課題管理ツールに問題を報告し周知するその後、問題が収束したらチームで振り返り、ポストモーテムを作成する

Slide 39

Slide 39 text

Slide 40

Slide 40 text

具体的なバグ分析について原因分析から振り返る  分析・仕様漏れ/仕様考慮漏れ/仕様不備・表記/デザイン不備・運用/オペレーションミス・機能改善・実装不備 -> 要素をカテゴリーに分類する優先度・対応期限がある場合「期日あり」と明確化、未定のものには「期日なし」と明記する・温度感を明確にするための基準/ルールを設け、プライオリティーをタスクや問題に定義

Slide 41

Slide 41 text

整理した課題を振り返り、具体的な知見をチーム全員にシェアする原因分析から振り返る  同じ問題を繰り返さないための背景を知る振り返りは誰かを責めるためのものではなく、あくまで ”失敗から学ぶ”活動である。新しく発見した知見や再発防止策は別チームにも共有し、同じことが起きないように全員で習慣化していく。ここで重要なことは、人ではなく「仕組み」で解決すること。関係者に閉じず全体に対して共有し仕組み化することで、人が変化しても同じことが起こらないようにする。ポイント Factは常に変わる。定期的に変わっていく Factを振り返り、事実にそったソリューションに取り組む必要がある。

Slide 42

Slide 42 text

長期的な視点を持ち、継続すること習慣化するまで繰り返す  プロジェクト・案件良かった点・改善点新しいトライ振り返り

Slide 43

Slide 43 text

長期的な視点を持ち、継続すること習慣化するまで繰り返す  課題の累積や慣れ親しんだ文化は、簡単にはなくならない品質とは「誰かにとっての価値」であり、この価値は常に変化していく。だからこそ条件によって常に変化する中で、実際に手を動かし、いろんな取り組みからフィードバックを得ることや粘り強く継続することで新しいプロセスが生まれる。ポイント長期的な視点をもって作られた新しい文化は、組織の資産となり簡単に失われない。

Slide 44

Slide 44 text

「お客さまへの価値」をつくるための取り組み  問題が一つの要因だけで構成されていることは少ない問題を多角的に見つめ、定量的に分析する良い点も改善点も客観視し、継続して取り組むお客さまへの価値はチームでつくる

Slide 45

Slide 45 text

「お客さまへの価値」をつくるための取り組み -QA ver.-  要件定義 1 設計・実施 2 探索的テスト 3 不具合分析 4

Slide 46

Slide 46 text

不具合を見つけるのではなく、不具合をつくらない取り組み要件定義  ● お客さま視点の要件チェック・レビュー ● 他のマイクロサービスや他チームへの影響範囲の考慮 ● 新しい仕様追加による既存システムへの影響 ● 過去経験から考慮すべき観点の提案 ○ 過去にあった類似の障害、不具合に対する考慮がされているか ● PMやディレクターの相談役として並走上流工程で仕様の考慮漏れなどを検出することで手戻り工数を削減できる関係者で細かい認識合わせができることで認識齟齬による不具合を防げる

Slide 47

Slide 47 text

認識齟齬を減らし、より早く確実にテスト実施できる方法を模索する設計・実施  ● 全体のテスト計画およびテスト自動化計画 ● テストケースの作成 ○ テストケースレビュー ○ テストコードの実装 ● リグレッションテスト ○ APIテスト・UIテスト ○ リグレッションテスト自動化テストケースという詳細イメージを共有し、認識齟齬を早期に解消する手動テストと自動テストを組み合わせリリースサイクルを早める

Slide 48

Slide 48 text

お客さま体験を知り、仕様を超えた体験を追求する探索的テスト  ● ドッグフーディング（dogfooding） ○ 完成されたプロダクトを関係者で動かし、認識齟齬や魅力的品質の　向上につながるポイントを探す ● おさわり会 ○ チームの垣根を超え、1ユーザーとしてプロダクトをさわる ○ 多角的で異なる意見をフィードバックしあう仕様以上の「価値」提供を追求することができるデザインや仕様の小さなズレも関係者ですり合わせることができる

Slide 49

Slide 49 text

網（さまざまな取り組み）をすり抜け発生した問題の深堀りによる改善不具合分析  ● 問題の背景・原因を分析する ○ 仕様の認識不足：kick offの重要性・仕様変更時の連携強化 ○ 人的オペレーション：人員不足・手動オペレーションの改善 ● 情報は誰でもいつでもアクセスできるようにする ○ 不具合分析ボードを管理し、定期的に情報を更新していく ○ 問題発生率の変化や分析結果の改善についてはチームに展開するデータドリブンな品質保証を行うことで、効果的な品質改善につながる目には見えない品質を可視化し、定量的にはかることができる

Slide 50

Slide 50 text

「お客さまへの価値」をつくるための取り組み -QA ver.-    テストすること以外で品質を向上させる ● テスト以外のすべての工程に関わる ● 最後にテストするのではなく、ずっとテストし続ける

Slide 51

Slide 51 text

Summary  まとめ

Slide 52

Slide 52 text

「不具合」が発生した時の対応    テストはちゃんとした？なんでその問題を見つけられなかったの？ QAチームに問題の原因を尋ねていませんか？・・・。

Slide 53

Slide 53 text

ポイント1  「最後の砦」としてのQAのポジション  テストすることがQAの主な役割とすると、関わる領域範囲が狭い。また、工程の最後になりリリース直前での「守り」しかできない。 Design Requirements Specing Coding Deploy Testing QAの役割 

Slide 54

Slide 54 text

ポイント2  どんなに強固な「網」でも完全なものはない  テストだけを強化しても、ソフトウェア開発は「テスト」と「その他」と、2つのプロセスにわけられるほど単純なものではない。 Design Requirements Specing Coding Deploy Testing

Slide 55

Slide 55 text

大事なポイント  テストという「網」は最終工程にある  「網」に完全なものはない  1 2 品質保証するには、 1つのステップや個人などですべてを担保できるものではない。”完璧なテスト”は存在しないので、不具合がないことは証明できない。つまり、ソフトウェアをリリースする際は、常に何らかのリスクがつきまとうことを念頭にいれておく必要がある。

Slide 56

Slide 56 text

まとめ  品質に対するチーム全体のオーナーシップ「全員品質」  「網」（= テスト）は完全でない   ⇔ 特定の工程（例えばテスト）に依存せず、「全プロセス（全員）」で信頼性の総和を向上させる必要がある      「不具合を見つける」から「不具合を未然に防ぐ」  ⇔ 仕様・影響範囲・運用想定すべてを鑑み、不具合をテストフェーズで見つけるのではなく、開発プロセス全体から生まれうる不具合の種をつんでおく 

Slide 57

Slide 57 text

全員品質とは  役割や立場を越境し、 One Teamで品質を作り上げること

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Look back  振り返り

Slide 61

Slide 61 text

本日のテーマの振り返り  「最後の砦」にならないQAエンジニア...???? 

Slide 62

Slide 62 text

本日のテーマの振り返り  「最後の砦」にならず、One teamで作り上げる品質保証をリードする 

Slide 63

Slide 63 text

本日のテーマの振り返り  「最後の砦」にならず、One teamで作り上げる品質保証をリードする 

Slide 64

Slide 64 text

Last message  QAエンジニアの皆さんへ

Slide 65

Slide 65 text

QAエンジニアに必要なこと  QA活動には終わりがない  すべてのフェーズに関わるため、QA活動には終わりがない  開発プロセスすべてでQA活動を行うためのエンジニアスキルが求められる！  だからこそ私たちはあらゆるスキルを身につける必要がある    役割や立場を越境し、あらゆる境界線を越えていこう✈  「信頼」の重要性  QAエンジニアの仕事は”信頼の先”に成り立つ  お客さまとの信頼関係、プロダクトメンバーとの信頼関係の先により良い品質保証活動がある    最後の「守り」だけでなく、「守り」も「攻め」も　できるQAエンジニアになろう！ 

Slide 66

Slide 66 text

QAエンジニアに必要なこと QAエンジニアは、お客さまに選ばれる品質のサービスを継続的に提供するために関係者と協力しあらゆることをする！誰かにとっての価値を作る活動を行う！

Slide 67

Slide 67 text

Thank you  by @mii________san