チームで一つのゴールに向き合うために “品質”のあり方を考える / Thinking about "quality" in order to face the goal as a team

2022年11月2日に開催されたWomen Developers Summit に登壇した際に使用した資料となります。
https://event.shoeisha.jp/devsumi/20221102/session/4029/

私たちは日々お客さまにより良い価値のサービスを届けるために、チームでプロダクト開発を行っています。このセッションでは、スピードを落とさず、チームで同じゴールに向かい、より早くゴールに近づけるか“品質”という観点から取り組んだ実例やQAエンジニアの役割などを紹介します。また、QAエンジニアのいない組織における品質向上のアプローチ方法や考え方を紹介します。このセッションを通して、QA（品質保証）のあり方、チームや役割をこえた“品質”との向き合い方について一緒に考えていきましょう。

Transcript

1. Toward The Goal ～チームで一つのゴールに向き合うために “品質”のあり方を考える～ 株式会社令和トラベル QA Engineer miisan
2. 本日のアジェンダ 02 03 01 自己紹介 プロダクト品質の向上のために チームで品質と向き合う ＜取り組み＞ 04 チームで品質と向き合う ＜マインド＞
3. Self introduction 自己紹介
4. 自己紹介 株式会社令和トラベル QA Engineer (QA GM) miisan /@mii________san 新卒でERPパッケージの開発・ QAを担当し、その後 2018年よりメルペイに QA エンジニアとして参画し、コアローンチにも携わる。 Lead QA Engineerを経 て、Engineering Managerとしてサービス全体の品質向上、開発プロセス改 善、組織作りをリードする。 現在は、今年の 4月にNEWTをローンチした令和トラベルで 1人目QA Engineerとして、QA組織の立ち上げ、品質保証の文化づくりを担う。 個人としてはスタートアップ企業の QAアドバイザーやWomen Techmakers Ambassadorなど女性エンジニアの推進活動に取り組む。 日本47/47都道府県制覇、海外 20ヶ国以上。世界遺産や海底 40mのダイビン グなど、陸海問わずあたらしい世界をもとめ旅する✈
5. Today’s thema 本日のテーマ
6. ゴール
 品質

7. ゴールについて ゴール：努力などの目標点。最終目的。※デジタル大辞泉 最終的な目的地 行動理由 目的を達成するため の目印 目的 目標 ゴール
8. ゴールについて 私たちは、チームでさまざまな視点や観点を持ちながらゴールに向かって プロダクト開発を行っている ・企業のミッション ・プロジェクト推進 ・機能開発 ・課題やタスク 　・・・
9. ゴールについて 私たちは、チームでさまざまな視点や観点を持ちながらゴールに向かって プロダクト開発を行っている ゴールを達成したい！ Q：品質 C：コスト D：デリバリー（納期） S：サービス・スコープ etc. トレードオフのジレンマ
10. ゴールについて プロダクト開発における共通点： お客さまにとって価値あるプロダクトを継続的に届けること トレードオフのジレンマに抗う 「Aという機能を作る」というゴール達成 ⇄ 誰にも使われない 　=> ただ作っただけの機能に意味があるのか？ 「Bというプロダクトを期日までにリリースする」⇄ 問題だらけの機能 => スピードだけを重視することに価値はあるのか？ ポイント 価値のない作業や見せかけの機能を作ることには意味がない
11. • 品質
 • コスト
 • 納期
 • スコープ
 • 安全性
 ・・・
 壁

12. 品質について プロダクト開発における共通点： お客さまにとって価値あるプロダクトを継続的に届けること 品質とは： 誰かにとっての価値である　by G.M.Weinberg 売り手(企業) お客さま 社会
13. 本日のテーマ 「品質」に着目し、トレードオンで チームでゴールに向かう
14. 本日のテーマ ビジネスとIT の関係性 年代 Softwareの役割 Softwareへの要求 手法・概念 => ビジネスバリューの最大化 が求められる
 ※参考:DXを妨げる要因と実現へのアプローチ /20211022 (https://speakerdeck.com/yuzutas0/20211022?slide=13) ~’90年代 S/W As a Sysyem 高い品質 Waterfall ~’00年代 S/W As a Service 短納期・低コスト Agile・Offshore ~’10年代 S/W As a Business ビジネスバリュー Lean Startup DevOps
15. 本日のテーマ 「品質」に着目し、トレードオンでチーム でビジネスバリューの最大化 というゴールに向かう
16. For improvement of product quality プロダクト品質の向上のために
17. 「品質」を作り上げるには、プロセス・チーム・プロダクトの相互向上が必須 前提：3つの視点 Process Product Team
18. NEWTコアローンチから半年間のゴール設定 (エンジニアチーム編) 令和トラベルでのゴール（OKR)
19. プロダクト品質向上における取り組み 見出し step2
 step1
 共通認識を揃える・現状を把 握する：
 品質・QAについて共通認識を 作る・標準化
 • PM
 • Backend Engineer
 • Client Engineer
 • Frontend Engineer
 • QA Engineer
 • Designer
 • Machine Learning Engineer
 
 改善活動の繰り返し： 
 問題の可視化によって見えた 課題の解消と現状を更新して いく
 step3
 問題の可視化・定量的なモニ タリング：
 プロダクト品質を定量的には かり、見える化
 当たり前品質の向上 問題点の可視化 改善サイクル
20. プロダクト品質向上における取り組み 1. 共通認識を揃える 品質・QAについて共通認識を作る・標準化 ①QAチームの役割やチームで品質を作ることについての整理 - 品質を守るだけでなく、品質をプロダクト全体で育む - 正しいプロダクトを、正しい人に、正しいタイミングで届ける ②品質指標の明示化と優先度を決めた取り組み実施 - 当たり前品質向上：リグレッションテスト・テストケースの情報資産化 - 魅力的品質の向上：探索的テスト・お触り会の取り組みと交通整備 ③品質基準を定義 - リリース基準を定義 - プライオリティ・優先順位の可視化 - 開発完了基準の設定
21. プロダクト品質における取り組み 2. 定量的な品質管理 プロダクト品質を定量的にはかり、見える化 ①新機能開発における不具合分析 - QAフェーズにおける不具合の傾向を可視化 ②インシデント分析 - インシデント数とリリースの変更失敗率を可視化
22. プロダクト品質における取り組み 3. 改善活動の繰り返し 定常リリースの安定化によるプロダクトの品質の向上 ①QAフェーズにおける不具合の傾向を可視化・分析
23. プロダクト品質における取り組み 3. 改善活動の繰り返し 定常リリースの安定化によるプロダクトの品質の向上 ①QAフェーズにおける不具合の傾向を可視化・分析 上流部分で改善できる取組み （Specの整備方法・コミュニ ケーションの取り方）
24. プロダクト品質における取り組み 3. 改善活動の繰り返し 定常リリースの安定化によるプロダクトの品質の向上 ②インシデント数とリリースの変更失敗率を見える化 - チームのモニタリング指標 = 品質とスピード • デプロイ頻度 • 変更のリードタイム • 平均修復時間（Mean Time to Repair） • 変更失敗率 を設定し、継続モニタリング
25. 継続的なモニタリングと振り返りのサイクルの結果 -> リリース回数は増加し、インシデントの発生回数は減少した プロダクト品質における取り組み 3. 改善活動の繰り返し
26. プロダクト品質における取り組み 3. 改善活動の繰り返し NEWTコアローンチから半年間のゴール設定はどうなった...??
27. プロダクト品質における取り組み 3. 改善活動の繰り返し NEWTコアローンチから半年間のゴール設定はどうなった...?? 達成！！！！
28. プロダクト品質における取り組み 　　　重要な気づき アラートをキャッチできる情報管理、品質管理の重要性 2 共通認識を持つことでチームの課題として改善活動に つながる 1 継続的な改善・反復学習のできる柔軟性のあるチーム👍 3
29. Facing quality with team チームで品質と向き合う ＜取り組み＞
30. 品質へのチームでの取り組み 心理的安全性の高い環境 それぞれの視点でギャップを埋める 1 2
31. 品質へのチームでの取り組み 心理的安全性の高い環境 それぞれの視点でギャップを埋める 1 2
32. 品質へのチームでの取り組み 心理的安全性の高い環境 オープンで正直な議論が許される環境であることで問題 が大きくなる前に防ぐことができる
33. 品質へのチームでの取り組み 心理的安全性の高い環境 それぞれの視点でギャップを埋める 1 2
34. 品質へのチームでの取り組み それぞれの視点でギャップを埋める PO・エンジニア・CSそれぞれが意識することで ギャップの発生を防ぐ • 仕様とのギャップ ◦ 背景にあるものの理解、何を解決したいのか？のチームで理解する ◦ デザインや要件がそこからブレていないか確認する • ただしい挙動と不具合 ◦ 影響範囲の考慮 ◦ 不整合な状態が発生しないかの確認 • 実現したいお客さま体験 ◦ カスタマーに向けて届けたい価値になっているか ◦ WhatよりWhoやWhyに意識を向ける
35. Facing quality with team チームで品質と向き合う ＜マインド＞
36. 品質へのチームでの向き合い方 “不具合”は差し込みタスクなのか？ 品質を”犠牲”にしてスピードをあげるのか？ 1 2
37. 品質へのチームでの向き合い方 “不具合”は差し込みタスクなのか？ 品質を”犠牲”にしてスピードをあげるのか？ 1 2
38. 品質へのチームでの向き合い方 “不具合”は差し込みタスクなのか？ その問題を放棄しても、達成したいゴールが満たされるか チームで議論する 不確実性の高い不具合対応も想定し、プランニングする
39. 品質へのチームでの向き合い方 “不具合”は差し込みタスクなのか？ 品質を”犠牲”にしてスピードをあげるのか？ 1 2
40. 品質へのチームでの向き合い方 品質を”犠牲”にしてスピードをあげるのか？ 品質が劣化すれば手戻りが発生するため、 結局リードタイムは長くなる 品質を下げる スコープを削る 増員する リリース日の延期
41. 品質へのチームでの向き合い方 これらの指標を維持・向上させるには、品質を犠牲にでき ない。つまり品質は犠牲にすべきものではない！ 品質を”犠牲”にしてスピードをあげるのか？ ※短期的に犠牲にしなければいけない時は、改善活動とセット で考える
42. Looking back 振り返り
43. 振り返り アジャイルテスティングにおいて大切なこと 機能性のチェックよりもチームが理解している価値 をテストすること 1 目的・ゴールから考え、品質・価値を考える テスターの責任よりも、品質に対するチームの責任 2 プロダクトの価値を作っているのは誰なのか？
44. 振り返り 品質がスピードをつくる 品質を測定可能な情報に変え、継続的に改善する 1 問題は、小さく早く、適切なタイミングで返していく 品質とスピードはトレード・オンできる 2 コードの品質を高く保っていた「にも関わらず」速いのではない。 コードの品質を高く保っていた「からこそ」速いのだ。 ※レガシーコードからの脱却 ソフトウェアの寿命を延ばし価値を高める 9つのプラクティス (オライリージャパン・ 2019/9/19)
45. Today’s thema 本日のテーマ
46. 品質

47. ゴール
 品質

48. ゴール
 品質
 チーム

49. Thank you !!
 何かあれば @mii________san まで