テストの完了をゴールにしない！～仮説検証を繰り返し、開発・QA・ユーザーが交流しながら開発することで見えてくる理想の姿～ - #RSGT2024 #DevSumi / Shift left and Shift right

by 10xinc

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

9 プロダクトマネジメントの”罠”を回避しようより引用（元の図はOutput vs Outcome vs Impactより引用）

Slide 10

Slide 10 text

10 アウトプットを意識してしまいがち図の引用:「プロダクトマネジメントの”罠”を回避しよう」※元の図はOutput vs Outcome vs Impactより引用

Slide 11

Slide 11 text

11 アウトカムを意識する図の引用:「プロダクトマネジメントの”罠”を回避しよう」※元の図はOutput vs Outcome vs Impactより引用

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

©2023 10X, Inc. アウトカムに繋げるためのテスト活動とは？ ● 継続的テストモデルの考え方を用いる ○ コード実装後にテストするだけでなく、設計段階からテスト活動を行う（シフトレフトテスト） ○ コード実装後、デプロイ前にテストするだけでなく、デプロイやリリースした以降にもテスト活動を行う（シフトライトテスト） ● 次ページ以降では、具体的な事例で紹介する 19 「テスト完了をゴールにしない」とは？

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

23 今回のお話

Slide 24

Slide 24 text

Slide 25

Slide 25 text

25 今回のお話

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

©2023 10X, Inc. 事例紹介をより理解してもらうための前提知識まとめ ● チェーンストアECに特化したEC/DXプラットフォーム「Stailer」を開発している ● 今回の事例はその中でも「お届け領域」である ● ピッキング…実店舗の陳列棚から、　　　　　　注文のあった商品を選ぶこと　　　　　　→選んだ商品はバックヤードへ運ぶ ● パッキング…商品を注文ごとに梱包すること 33 事例紹介をより理解してもらうための前提知識

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

©2023 10X, Inc. 修正後の受け入れ基準 hogehogeメソッドが注文の締切時間の前に呼ばれているので対応する ⇨ ・注文変更の締切時間の前の場合、パッキング画面で　　「完了」ボタンを押したときにエラーにする。　　かつ、エラーを表示したあと前画面に戻る。　・注文変更の締切時間の前の場合、パッキング画面で　　「完了」ボタンを押さなくても15秒後にエラーを返す。　　かつ、エラーを表示したあと前画面に戻る。 43 受け入れ基準作成時のテスト活動

Slide 44

Slide 44 text

©2023 10X, Inc. 修正後の受け入れ基準 hogehogeメソッドが注文の締切時間の前に呼ばれているので対応する ⇨ ・注文の締切時間の前の場合、パッキング画面で　　「完了」ボタンを押したときにエラーにする。　　かつ、エラーを表示したあと前画面に戻る。　・注文の締切時間の前の場合、パッキング画面で　　「完了」ボタンを押さなくても15秒後にエラーを返す。　　かつ、エラーを表示したあと前画面に戻る。 44 受け入れ基準作成時のテスト活動何をもって、このタスクが完了となるのかハッキリした

Slide 45

Slide 45 text

©2023 10X, Inc. 余談：シフトレフトの活動を行うと良いこと ● 早い段階で行うべきことがハッキリしていると、バグが混入されづらくなり、追加コストが不要になる ○ バグチケット起票のコスト ○ 開発内容を思い出すコスト ○ 修正するコスト ○ もう一度テストするコスト ○ 関連部分にデグレードが無いか確認するコスト ○ 起票したバグチケットを完了にするコスト 45 受け入れ基準作成時のテスト活動

Slide 46

Slide 46 text

©2023 10X, Inc. その他のシフトレフトテストの事例 46 受け入れ基準作成時のテスト活動 https://speakerdeck.com/nihonbuson/example-mapping https://speakerdeck.com/nihonbuson/tddbc-2020-online-lt https://speakerdeck.com/nihonbuson/testing-is-the-creative-activity

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

©2023 10X, Inc. 疑問点 ● 注文変更の締切時間の前の場合、パッキング画面で「完了」ボタンを押したときにエラーにする。かつ、エラーを表示したあと前画面に戻る。 ● 注文変更の締切時間の前の場合、パッキング画面で「完了」ボタンを押さなくても15秒後にエラーを返す。かつ、エラーを表示したあと前画面に戻る。 →注文の締切時間の前に対象画面を開く頻度はどれぐらい？ 52 計画的にログを仕込み、効果が高そうか確認する

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

©2023 10X, Inc. 補足：効果が高そうか確認する手段 ● ログを仕込む ● 適用範囲を絞る ○ Feature Flag(Toggle)による適用範囲の指定 ■ 特定の対象に絞って適用したい場合に有効 ○ 段階的リリース（iOS: Phased Releases, Android: Staged Rollout）による適用範囲の制限 ■ 少数の適用範囲で試したい場合に有効（カナリアリリース） ○ A/Bテストによるランダムな適用 ■ 現行と改善案のどちらが優れているか統計的に調べたい場合に有効 59 計画的にログを仕込み、効果が高そうか確認する

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

©2023 10X, Inc. 現場リサーチで見えてくるもの ● 運用でカバーしている点 ○ アプリでは解決が難しいものも含む ○ プロダクトの仕様やプロダクトに残るin/outのデータだけ見ても、極めて断片的な理解・情報にしかならない ● リサーチした店舗特有の課題点 ○ 同じパートナーであっても、店舗によって課題は異なる ● 自分たちが開発した機能がどのように使われているか 64 実際のオペレーションの様子を観察する

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

©2023 10X, Inc. 現場リサーチで得られる副次的な効果 ● よりアウトカムが意識できるようになる ○ 一般的に、お客様からくるお問い合わせのほとんどは、現状のアプリで不便だと認識している点 ○ 以下の点はお問い合わせからは分からない ■ お客様が便利だと感じている点 ■ お客様が暗黙的に不便だと感じている点 ● 実際の使われ方を見ることで、よりリリースに意識が向く ○ 「機能を作って終わり！」とならなくなる ○ 「どうすれば如何に早く、如何に効果的にリリースできるか」と考えるようになる 70 実際のオペレーションの様子を観察する

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

©2023 10X, Inc. 分割リリースにして良かったこと ● パートナーのフィードバックを貰いながら調整できた ● パートナーの機能理解度が高い状態でリリースできた ○ パートナーが新機能に対してビックリしない ● 「オペレーションを効率的かつ確実に行う」というお届け領域の特徴を損なわないようにできた ● リリースから数ヶ月経過しているが、この機能に関する障害発生0件！お問い合わせも数件！ 77 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する

Slide 78

Slide 78 text

©2023 10X, Inc. 補足：重視した品質について ● 分割リリースの中で、重要視した品質をそれぞれ定義した ○ 1回目…業務遂行性 ○ 2回目…業務遂行性＋習得性、運用操作性 ○ 3回目…業務遂行性、習得性、運用操作性＋機能正確性 ● 品質特性や狩野モデルなどから単に引用する形ではない ○ 今回は議論した上で当てはめてみた結果 ○ 議論せずに単に引用だけすると、それっぽく聞こえるけど何も表現できていないものになってしまうかも ■ 例…「当たり前品質って重要だよね！」　　→何がプロダクトにとって「当たり前」なのか？ 78 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する

Slide 79

Slide 79 text

©2023 10X, Inc. 補足：経営チームも含めた自分たちで品質を定義する 79 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する最も大きなGapは「保守性」であるという結論に。更に保守性を深掘りしていくと、「運営自律性」や「システム運用効率性」、「テスト容易性」といった独自のキーワードが浮かび上がりました(By CTO)。（中略）こういった独自の用語で品質をキャプチャしていくこと自体が、品質に向き合う第1歩で重要なことだ！というのを品質管理部のブロッコリーさんからバックアップいただけたことは私個人としても自信になりました。 yamotty（弊社CEO）のブログ記事「プラットフォーム化ヘの歩み」より

Slide 80

Slide 80 text

Slide 81

Slide 81 text

©2023 10X, Inc. 81 おわりにまとめ ● アウトカムに繋げるためのテスト活動として、継続的テストモデルがある ● シフトレフトテストの事例 ○ 受け入れ基準作成時のテスト活動によって、タスク完了の定義をハッキリさせた ● シフトライトテストの事例 ○ 計画的にログを仕込み、効果が高いか検証して進めた ○ 現場リサーチによって、運用時の工夫に気付けた ○ 分割リリースを実施し、機能理解度が高い状態を作った