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

Regional Scrum Gathering Tokyo 2024および Developers Summit 2024での発表資料になります。

Transcript

1. ©2024 10X, Inc. テストの完了をゴールにしない！ ～仮説検証を繰り返し、開発・QA・ユーザーが 交流しながら開発することで見えてくる理想の姿～ Developers Summit 2024 風間 裕也（ブロッコリー） #DevSumiC
2. ©2023 10X, Inc. 2 自己紹介 • 風間裕也（ブロッコリー） • 所属 ◦ 株式会社10X 品質管理部 ◦ 株式会社iCARE フェロー（QAE技術顧問） ◦ B-Testing（個人事業主） • 社外活動 ◦ JaSST Review実行委員長 ▪ ソフトウェアレビューシンポジウム ◦ WACATE実行委員長 ▪ ソフトウェアテストの合宿型ワークショップ形式勉強会
3. ©2023 10X, Inc. 過去のDevelopers Summit登壇 3 自己紹介 Developers Summit 2020 （話題賞） Developers Summit 2022 （ベストスピーカー賞[第6位]）
4. ©2023 10X, Inc. 翻訳書籍 4 自己紹介
5. ©2023 10X, Inc. 宣伝：雑誌『Software Design』に寄稿しました 第1特集「テストの設計してますか？」 第1章「ソフトウェアテストとは何か」 を担当 1/18発売 https://gihyo.jp/magazine/SD/archive/2024/202402 5 自己紹介
6. ©2023 10X, Inc. 6 自己紹介 https://event.shoeisha.jp/cza/agile-testing
7. ©2023 10X, Inc. 7 はじめに
8. ©2023 10X, Inc. 8 はじめに こんな経験はありませんか？ 機能開発はしたけど、これは本当に ユーザーの解決したいことに繋がっているのかな…？
9. 9 プロダクトマネジメントの”罠”を回避しよう より引用 （元の図はOutput vs Outcome vs Impactより引用）
10. 10 アウトプットを 意識してしまいがち 図の引用:「プロダクトマネジメントの”罠”を回避しよう」※元の図はOutput vs Outcome vs Impactより引用
11. 11 アウトカムを意識する 図の引用:「プロダクトマネジメントの”罠”を回避しよう」※元の図はOutput vs Outcome vs Impactより引用
12. ©2023 10X, Inc. 本発表でお伝えしたいこと • 「一般的なテストの完了＝ゴール」ではないことを 実感してもらう • テストの側面から、アウトカムの獲得を試みる • テスト活動を用いた、アウトカムに繋がる事例を紹介する • QAも含めた開発チーム全体で ステークホルダー（特にパートナー）と向き合って 開発を続けてきた事例を紹介する 12 はじめに
13. ©2023 10X, Inc. 13 「テスト完了をゴールにしない」とは？
14. ©2023 10X, Inc. 継続的テストモデル 14 「テスト完了をゴールにしない」とは？ Continuous Testing in DevOps… に掲載の画像を元に発表者が翻訳
15. ©2023 10X, Inc. 継続的テストモデル 15 「テスト完了をゴールにしない」とは？ Continuous Testing in DevOps… に掲載の画像を元に発表者が翻訳 テストの 範囲に なりがち
16. ©2023 10X, Inc. シフトレフトテスト 16 「テスト完了をゴールにしない」とは？ Continuous Testing in DevOps… に掲載の画像を元に発表者が翻訳 コード実装前 に行う テストがある
17. ©2023 10X, Inc. シフトライトテスト 17 「テスト完了をゴールにしない」とは？ Continuous Testing in DevOps… に掲載の画像を元に発表者が翻訳 リリース後 に行う テストがある
18. ©2023 10X, Inc. 継続的テストモデル 18 「テスト完了をゴールにしない」とは？ テストはフェーズ ではなく アクティビティである
19. ©2023 10X, Inc. アウトカムに繋げるためのテスト活動とは？ • 継続的テストモデルの考え方を用いる ◦ コード実装後にテストするだけでなく、 設計段階からテスト活動を行う（シフトレフトテスト） ◦ コード実装後、デプロイ前にテストするだけでなく、 デプロイやリリースした以降にもテスト活動を行う （シフトライトテスト） • 次ページ以降では、具体的な事例で紹介する 19 「テスト完了をゴールにしない」とは？
20. ©2023 10X, Inc. 20 事例紹介を より理解してもらうための前提知識： 事業概要
23. 23 今回のお話
25. 25 今回のお話
26. ©2023 10X, Inc. 26 事例紹介を より理解してもらうための前提知識： ピッキング・パッキングとは何か？
27. ©2023 10X, Inc. ネットスーパーのサービスの一連の流れ 27 事例紹介をより理解してもらうための前提知識：ピッキング・パッキングとは何か？ お客様 店舗 スタッフ 配達 スタッフ 注文実行 注文変更 締め切り ピッキング パッキング 配達 売り場から 商品を集める 注文ごとに 商品を梱包する
28. ©2023 10X, Inc. ネットスーパーのサービスの一連の流れ 28 事例紹介をより理解してもらうための前提知識：ピッキング・パッキングとは何か？ お客様 店舗 スタッフ 配達 スタッフ 注文実行 注文変更 締め切り ピッキング パッキング 配達 売り場から 商品を集める 注文ごとに 商品を梱包する 注文実行 注文変更 締め切り
29. ©2023 10X, Inc. ネットスーパーのサービスの一連の流れ 29 事例紹介をより理解してもらうための前提知識：ピッキング・パッキングとは何か？ お客様 店舗 スタッフ 配達 スタッフ 注文実行 注文変更 締め切り ピッキング パッキング 配達 売り場から 商品を集める 注文ごとに 商品を梱包する ピッキング 売り場から 商品を集める
30. ©2023 10X, Inc. ピッキングする様子 30 事例紹介をより理解してもらうための前提知識 • カメラを用いて、 バーコードをスキャンする • 注文の商品と異なる場合は すぐに分かる仕組み
31. ©2023 10X, Inc. ネットスーパーのサービスの一連の流れ 31 事例紹介をより理解してもらうための前提知識：ピッキング・パッキングとは何か？ お客様 店舗 スタッフ 配達 スタッフ 注文実行 注文変更 締め切り ピッキング パッキング 配達 売り場から 商品を集める 注文ごとに 商品を梱包する パッキング 注文ごとに 商品を梱包する
32. ©2023 10X, Inc. 注文ごとに 商品を梱包する ネットスーパーのサービスの一連の流れ 32 事例紹介をより理解してもらうための前提知識：ピッキング・パッキングとは何か？ お客様 店舗 スタッフ 配達 スタッフ 注文実行 注文変更 締め切り ピッキング パッキング 配達 売り場から 商品を集める 注文ごとに 商品を梱包する 配達
33. ©2023 10X, Inc. 事例紹介をより理解してもらうための前提知識まとめ • チェーンストアECに特化したEC/DXプラットフォーム 「Stailer」を開発している • 今回の事例はその中でも「お届け領域」である • ピッキング…実店舗の陳列棚から、 　　　　　　注文のあった商品を選ぶこと 　　　　　　→選んだ商品はバックヤードへ運ぶ • パッキング…商品を注文ごとに梱包すること 33 事例紹介をより理解してもらうための前提知識
34. ©2023 10X, Inc. 34 シフトレフトテストの例
35. ©2023 10X, Inc. シフトレフトテスト 35 シフトレフトテストの例 Continuous Testing in DevOps… に掲載の画像を元に発表者が翻訳 コード実装前 に行う テストがある
36. ©2023 10X, Inc. CODE時点でのテスト活動（今回は話しません） 36 シフトレフトテストの例 TDD など
37. ©2023 10X, Inc. PLANやBRANCH時点でのテスト活動 37 シフトレフトテストの例 今回の 事例
38. ©2023 10X, Inc. 38 受け入れ基準作成時のテスト活動
39. ©2023 10X, Inc. 適用したタイミング 39 受け入れ基準作成時のテスト活動 スプリント プランニング レトロ スペク ティブ リファイン メント スクラムとは（オージス総研） を参考に一部書き換え ※リファインメントは 　スクラムイベントではない
40. ©2023 10X, Inc. 40 受け入れ基準作成時のテスト活動 スリーアミーゴスの考え方を用いる 引用：Agile Testingのエッセンス #devsumi
41. ©2023 10X, Inc. 元々の受け入れ基準 • hogehogeメソッドが注文の締め切り時間の前に 呼ばれているので対応する 41 受け入れ基準作成時のテスト活動
42. ©2023 10X, Inc. 出てきた疑問点 • hogehogeメソッドが注文の締め切り時間の前に 呼ばれているので対応する 42 受け入れ基準作成時のテスト活動 これって、アプリの振る舞いで言うと、 どの画面のどんな操作なんですかね？ QA
43. ©2023 10X, Inc. 修正後の受け入れ基準 hogehogeメソッドが注文の締切時間の前に 呼ばれているので対応する ⇨ ・注文変更の締切時間の前の場合、パッキング画面で 　 　 「完了」ボタンを押したときにエラーにする。 　 　 かつ、エラーを表示したあと前画面に戻る。 　 ・注文変更の締切時間の前の場合、パッキング画面で 　 　 「完了」ボタンを押さなくても15秒後にエラーを返す。 　 　 かつ、エラーを表示したあと前画面に戻る。 43 受け入れ基準作成時のテスト活動
44. ©2023 10X, Inc. 修正後の受け入れ基準 hogehogeメソッドが注文の締切時間の前に 呼ばれているので対応する ⇨ ・注文の締切時間の前の場合、パッキング画面で 　 　 「完了」ボタンを押したときにエラーにする。 　 　 かつ、エラーを表示したあと前画面に戻る。 　 ・注文の締切時間の前の場合、パッキング画面で 　 　 「完了」ボタンを押さなくても15秒後にエラーを返す。 　 　 かつ、エラーを表示したあと前画面に戻る。 44 受け入れ基準作成時のテスト活動 何をもって、 このタスクが完了となるのか ハッキリした
45. ©2023 10X, Inc. 余談：シフトレフトの活動を行うと良いこと • 早い段階で行うべきことがハッキリしていると、 バグが混入されづらくなり、追加コストが不要になる ◦ バグチケット起票のコスト ◦ 開発内容を思い出すコスト ◦ 修正するコスト ◦ もう一度テストするコスト ◦ 関連部分にデグレードが無いか確認するコスト ◦ 起票したバグチケットを完了にするコスト 45 受け入れ基準作成時のテスト活動
46. ©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
47. ©2023 10X, Inc. 47 シフトライトテストの例
48. ©2023 10X, Inc. シフトライトテスト 48 シフトライトテストの例 Continuous Testing in DevOps… に掲載の画像を元に発表者が翻訳 リリース後 に行う テストがある
49. ©2023 10X, Inc. シフトライトの事例を3つ紹介 1. 計画的にログを仕込み、効果が高そうか確認する 2. 実際のオペレーションの様子を観察する 3. ユーザーと協力して、実際にオペレーションが 問題なく進行できるか確認する 49 シフトライトテストの例
50. ©2023 10X, Inc. 50 シフトライトテストの事例1： 計画的にログを仕込み、 効果が高そうか確認する
51. ©2023 10X, Inc. 今回の事例の対象 • 注文変更の締切時間の前の場合、パッキング画面で 「完了」ボタンを押したときにエラーにする。 かつ、エラーを表示したあと前画面に戻る。 • 注文変更の締切時間の前の場合、パッキング画面で 「完了」ボタンを押さなくても15秒後にエラーを返す。 かつ、エラーを表示したあと前画面に戻る。 51 計画的にログを仕込み、効果が高そうか確認する
52. ©2023 10X, Inc. 疑問点 • 注文変更の締切時間の前の場合、パッキング画面で 「完了」ボタンを押したときにエラーにする。 かつ、エラーを表示したあと前画面に戻る。 • 注文変更の締切時間の前の場合、パッキング画面で 「完了」ボタンを押さなくても15秒後にエラーを返す。 かつ、エラーを表示したあと前画面に戻る。 →注文の締切時間の前に対象画面を開く頻度はどれぐらい？ 52 計画的にログを仕込み、効果が高そうか確認する
53. ©2023 10X, Inc. 疑問点の検討 注文変更の締切時間の前にパッキング画面を 開く頻度はどれぐらい？ • 15秒に1回エラーを表示している • 対象画面を開く頻度が高いと、業務の妨げになる • どれくらいの頻度で開いているか見当もつかない 53 計画的にログを仕込み、効果が高そうか確認する
54. ©2023 10X, Inc. 疑問点の検討 注文変更の締切時間の前にパッキング画面を 開く頻度はどれぐらい？ • 15秒に1回エラーを表示している • 対象画面を開く頻度が高いと、業務の妨げになる • どれくらいの頻度で開いているか見当もつかない 　→　対象部分にログを仕込もう！ 54 計画的にログを仕込み、効果が高そうか確認する
55. ©2023 10X, Inc. ログを仕込む 55 計画的にログを仕込み、効果が高そうか確認する static String hogehoge(Datetime deadline){ … if ( now < deadline){ // (今回追加するログを記載) } … }
56. ©2023 10X, Inc. ログを仕込んだ状態で1回リリース • ログを仕込むだけの差分でリリースする • リリース後に、そのログがどれだけ出たのか調べる ◦ ログが頻発する ▪ 今回の修正を入れると業務の妨げになる ◦ ログが頻発しない ▪ 今回の修正を入れる価値がある 56 計画的にログを仕込み、効果が高そうか確認する
57. ©2023 10X, Inc. ログの代わりに修正を入れる 57 計画的にログを仕込み、効果が高そうか確認する static String hogehoge(Datetime deadline){ … if ( now < deadline ){ // (今回追加するログを記載) → (今回の修正を入れる) } … }
58. ©2023 10X, Inc. 進め方の注意点 デプロイ前に計測内容を確定しておくことが大事 58 計画的にログを仕込み、効果が高そうか確認する
59. ©2023 10X, Inc. 補足：効果が高そうか確認する手段 • ログを仕込む • 適用範囲を絞る ◦ Feature Flag(Toggle)による適用範囲の指定 ▪ 特定の対象に絞って適用したい場合に有効 ◦ 段階的リリース（iOS: Phased Releases, Android: Staged Rollout） による適用範囲の制限 ▪ 少数の適用範囲で試したい場合に有効（カナリアリリース） ◦ A/Bテストによるランダムな適用 ▪ 現行と改善案のどちらが優れているか統計的に調べたい場合に有効 59 計画的にログを仕込み、効果が高そうか確認する
60. ©2023 10X, Inc. シフトライトテストの事例2： 実際のオペレーションの様子を 観察する 60
61. ©2023 10X, Inc. お届け領域の特徴 • お届け領域は、オペレーションを効率的かつ 確実に行うために存在している • より最適なオペレーションを実現するために プロダクトがどうあるべきか認識することが重要 ◦ プロダクトで解決しないことも含めて認識 61 実際のオペレーションの様子を観察する
62. ©2023 10X, Inc. 現場リサーチという取り組み • いわゆるフィールド調査やユーザーインタビューを ミックスした形式 • 概ね月1回、チームの全員が1回以上、 各パートナー1回以上を目指してリサーチ活動を実施 62 実際のオペレーションの様子を観察する
63. ©2023 10X, Inc. 現場リサーチの様子 • 店舗スタッフが ピッキングやパッキングを 行っている様子を、 すぐそばから観察 • 気になった点をメモする ◦ 時には録画・録音もする • 使い方を教えない 63 実際のオペレーションの様子を観察する ←10X社員 ↑店舗スタッフ
64. ©2023 10X, Inc. 現場リサーチで見えてくるもの • 運用でカバーしている点 ◦ アプリでは解決が難しいものも含む ◦ プロダクトの仕様やプロダクトに残るin/outのデータだけ 見ても、極めて断片的な理解・情報にしかならない • リサーチした店舗特有の課題点 ◦ 同じパートナーであっても、店舗によって課題は異なる • 自分たちが開発した機能がどのように使われているか 64 実際のオペレーションの様子を観察する
65. ©2023 10X, Inc. • 全く同じ商品の2ℓペットボトルのお茶1ケースが 入ったダンボールが2つ置かれていた。 現場リサーチで気付いた例 65 実際のオペレーションの様子を観察する
66. ©2023 10X, Inc. 現場リサーチで気付いた例 66 実際のオペレーションの様子を観察する • 一方のダンボールには「大型」が貼られていた ◦ 大型…配達用のコンテナに入らないような大きな商品の区分 • もう一方のダンボールには「常温」が貼られていた。 ◦ 常温…冷やす必要のない、コンテナに入る大きさの商品の区分
67. ©2023 10X, Inc. 現場リサーチで気付いた例 67 実際のオペレーションの様子を観察する • 「大型」…お茶1ケースを注文した • 「常温」…お茶6本を注文した ◦ 1ケースと同じため、配達ではダンボールごと運ぶ
68. ©2023 10X, Inc. 現場リサーチで気付いた例 68 実際のオペレーションの様子を観察する • 「大型」…お茶1ケースを注文した • 「常温」…お茶6本を注文した ◦ 1ケースと同じため、配達ではダンボールごと運ぶ Stailerのデータだけでは 気付けない運用時の工夫だった
69. ©2023 10X, Inc. 現場リサーチで得られた知見を活かす • 現場リサーチの結果から、個別の課題を把握する • 個別の課題群から 共通の課題を 見つけ出す • プラットフォーム としての解決策を 模索する 69 実際のオペレーションの様子を観察する
70. ©2023 10X, Inc. 現場リサーチで得られる副次的な効果 • よりアウトカムが意識できるようになる ◦ 一般的に、お客様からくるお問い合わせのほとんどは、 現状のアプリで不便だと認識している点 ◦ 以下の点はお問い合わせからは分からない ▪ お客様が便利だと感じている点 ▪ お客様が暗黙的に不便だと感じている点 • 実際の使われ方を見ることで、よりリリースに意識が向く ◦ 「機能を作って終わり！」とならなくなる ◦ 「どうすれば如何に早く、如何に効果的にリリースできるか」 と考えるようになる 70 実際のオペレーションの様子を観察する
71. ©2023 10X, Inc. 71 シフトライトテストの事例3： ユーザーと協力して、 実際にオペレーションが 問題なく進行できるか確認する
72. ©2023 10X, Inc. オペレーションを気にしながら分割リリースを実施 • ピッキングに関する大きな新機能についての リリースを行った • リリースを3回に分割した • 開発がある程度進行した時点で、 新機能が入ったStailerをパートナーのところへ持ち込み、 試す場を提供していただいた。 72 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する
73. ©2023 10X, Inc. 分割リリースの内容 • 1回目のリリース…10X社員が実店舗で試す • 2回目のリリース…店舗スタッフが研修の中で試す • 3回目のリリース…正式リリース 73 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する
74. ©2023 10X, Inc. 1回目のリリース • 実店舗に開発したアプリ持ち込んで 10X社員が擬似的にピッキングを試した • 問題なくオペレーションが進行するかの確度を高めた 大事な観点 74 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する 業務遂行性
75. ©2023 10X, Inc. 2回目のリリース • スタッフ研修に同席した • パートナーが運用を問題なく進行できるかの確度を高めた • 機能理解・オンボーディングにかかるコストを確認した 大事な観点 75 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する 業務遂行性 習得性 運用操作性
76. ©2023 10X, Inc. 3回目のリリース • 正式リリース • 実店舗で実際に活用いただく 大事な観点 76 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する 業務遂行性 習得性 運用操作性 機能正確性
77. ©2023 10X, Inc. 分割リリースにして良かったこと • パートナーのフィードバックを貰いながら調整できた • パートナーの機能理解度が高い状態でリリースできた ◦ パートナーが新機能に対してビックリしない • 「オペレーションを効率的かつ確実に行う」という お届け領域の特徴を損なわないようにできた • リリースから数ヶ月経過しているが、 この機能に関する障害発生0件！ お問い合わせも数件！ 77 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する
78. ©2023 10X, Inc. 補足：重視した品質について • 分割リリースの中で、重要視した品質をそれぞれ定義した ◦ 1回目…業務遂行性 ◦ 2回目…業務遂行性＋習得性、運用操作性 ◦ 3回目…業務遂行性、習得性、運用操作性＋機能正確性 • 品質特性や狩野モデルなどから単に引用する形ではない ◦ 今回は議論した上で当てはめてみた結果 ◦ 議論せずに単に引用だけすると、それっぽく聞こえるけど 何も表現できていないものになってしまうかも ▪ 例…「当たり前品質って重要だよね！」 　　→何がプロダクトにとって「当たり前」なのか？ 78 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する
79. ©2023 10X, Inc. 補足：経営チームも含めた自分たちで品質を定義する 79 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する 最も大きなGapは「保守性」であるという結論に。 更に保守性を深掘りしていくと、「運営自律性」や 「システム運用効率性」、「テスト容易性」といった 独自のキーワードが浮かび上がりました(By CTO)。 （中略） こういった独自の用語で品質をキャプチャしていくこと自体が、品質に 向き合う第1歩で重要なことだ！というのを品質管理部のブロッコリーさん からバックアップいただけたことは私個人としても自信になりました。 yamotty（弊社CEO）のブログ記事「プラットフォーム化ヘの歩み」より
80. ©2023 10X, Inc. 80 おわりに
81. ©2023 10X, Inc. 81 おわりに まとめ • アウトカムに繋げるためのテスト活動として、 継続的テストモデルがある • シフトレフトテストの事例 ◦ 受け入れ基準作成時のテスト活動によって、 タスク完了の定義をハッキリさせた • シフトライトテストの事例 ◦ 計画的にログを仕込み、効果が高いか検証して進めた ◦ 現場リサーチによって、運用時の工夫に気付けた ◦ 分割リリースを実施し、機能理解度が高い状態を作った
82. ©2023 10X, Inc. 継続的テストモデル（再掲） 82 おわりに
83. ©2024 10X, Inc. Developers Summit 2024 風間 裕也（ブロッコリー） #DevSumiC テストの完了をゴールにしない！ ～仮説検証を繰り返し、開発・QA・ユーザーが 交流しながら開発することで見えてくる理想の姿～
84. ©2023 10X, Inc. 84 ご清聴ありがとうございました おしまい