$30 off During Our Annual Pro Sale. View Details »

テストの完了をゴールにしない! ~仮説検証を繰り返し、開発・QA・ユーザーが交流しながら開発す...

10xinc
January 11, 2024

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

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

10xinc

January 11, 2024
Tweet

More Decks by 10xinc

Other Decks in Technology

Transcript

  1. ©2023 10X, Inc. 2 自己紹介 • 風間裕也(ブロッコリー) • 所属 ◦

    株式会社10X 品質管理部 ◦ 株式会社iCARE フェロー(QAE技術顧問) ◦ B-Testing(個人事業主) • 社外活動 ◦ JaSST Review実行委員長 ▪ ソフトウェアレビューシンポジウム ◦ WACATE実行委員長 ▪ ソフトウェアテストの合宿型ワークショップ形式勉強会
  2. ©2023 10X, Inc. 過去のDevelopers Summit登壇 3 自己紹介 Developers Summit 2020

    (話題賞) Developers Summit 2022 (ベストスピーカー賞[第6位])
  3. ©2023 10X, Inc. 本発表でお伝えしたいこと • 「一般的なテストの完了=ゴール」ではないことを 実感してもらう • テストの側面から、アウトカムの獲得を試みる •

    テスト活動を用いた、アウトカムに繋がる事例を紹介する • QAも含めた開発チーム全体で ステークホルダー(特にパートナー)と向き合って 開発を続けてきた事例を紹介する 12 はじめに
  4. ©2023 10X, Inc. シフトレフトテスト 16 「テスト完了をゴールにしない」とは? Continuous Testing in DevOps…

    に掲載の画像を元に発表者が翻訳 コード実装前 に行う テストがある
  5. ©2023 10X, Inc. シフトライトテスト 17 「テスト完了をゴールにしない」とは? Continuous Testing in DevOps…

    に掲載の画像を元に発表者が翻訳 リリース後 に行う テストがある
  6. ©2023 10X, Inc. アウトカムに繋げるためのテスト活動とは? • 継続的テストモデルの考え方を用いる ◦ コード実装後にテストするだけでなく、 設計段階からテスト活動を行う(シフトレフトテスト) ◦

    コード実装後、デプロイ前にテストするだけでなく、 デプロイやリリースした以降にもテスト活動を行う (シフトライトテスト) • 次ページ以降では、具体的な事例で紹介する 19 「テスト完了をゴールにしない」とは?
  7. 21

  8. 22

  9. 24

  10. ©2023 10X, Inc. ネットスーパーのサービスの一連の流れ 27 事例紹介をより理解してもらうための前提知識:ピッキング・パッキングとは何か? お客様 店舗 スタッフ 配達

    スタッフ 注文実行 注文変更 締め切り ピッキング パッキング 配達 売り場から 商品を集める 注文ごとに 商品を梱包する
  11. ©2023 10X, Inc. ネットスーパーのサービスの一連の流れ 28 事例紹介をより理解してもらうための前提知識:ピッキング・パッキングとは何か? お客様 店舗 スタッフ 配達

    スタッフ 注文実行 注文変更 締め切り ピッキング パッキング 配達 売り場から 商品を集める 注文ごとに 商品を梱包する 注文実行 注文変更 締め切り
  12. ©2023 10X, Inc. ネットスーパーのサービスの一連の流れ 29 事例紹介をより理解してもらうための前提知識:ピッキング・パッキングとは何か? お客様 店舗 スタッフ 配達

    スタッフ 注文実行 注文変更 締め切り ピッキング パッキング 配達 売り場から 商品を集める 注文ごとに 商品を梱包する ピッキング 売り場から 商品を集める
  13. ©2023 10X, Inc. ネットスーパーのサービスの一連の流れ 31 事例紹介をより理解してもらうための前提知識:ピッキング・パッキングとは何か? お客様 店舗 スタッフ 配達

    スタッフ 注文実行 注文変更 締め切り ピッキング パッキング 配達 売り場から 商品を集める 注文ごとに 商品を梱包する パッキング 注文ごとに 商品を梱包する
  14. ©2023 10X, Inc. 注文ごとに 商品を梱包する ネットスーパーのサービスの一連の流れ 32 事例紹介をより理解してもらうための前提知識:ピッキング・パッキングとは何か? お客様 店舗

    スタッフ 配達 スタッフ 注文実行 注文変更 締め切り ピッキング パッキング 配達 売り場から 商品を集める 注文ごとに 商品を梱包する 配達
  15. ©2023 10X, Inc. 事例紹介をより理解してもらうための前提知識まとめ • チェーンストアECに特化したEC/DXプラットフォーム 「Stailer」を開発している • 今回の事例はその中でも「お届け領域」である •

    ピッキング…実店舗の陳列棚から、       注文のあった商品を選ぶこと       →選んだ商品はバックヤードへ運ぶ • パッキング…商品を注文ごとに梱包すること 33 事例紹介をより理解してもらうための前提知識
  16. ©2023 10X, Inc. シフトレフトテスト 35 シフトレフトテストの例 Continuous Testing in DevOps…

    に掲載の画像を元に発表者が翻訳 コード実装前 に行う テストがある
  17. ©2023 10X, Inc. 適用したタイミング 39 受け入れ基準作成時のテスト活動 スプリント プランニング レトロ スペク

    ティブ リファイン メント スクラムとは(オージス総研) を参考に一部書き換え ※リファインメントは  スクラムイベントではない
  18. ©2023 10X, Inc. 修正後の受け入れ基準 hogehogeメソッドが注文の締切時間の前に 呼ばれているので対応する ⇨ ・注文変更の締切時間の前の場合、パッキング画面で    

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

    「完了」ボタンを押したときにエラーにする。     かつ、エラーを表示したあと前画面に戻る。   ・注文の締切時間の前の場合、パッキング画面で     「完了」ボタンを押さなくても15秒後にエラーを返す。     かつ、エラーを表示したあと前画面に戻る。 44 受け入れ基準作成時のテスト活動 何をもって、 このタスクが完了となるのか ハッキリした
  20. ©2023 10X, Inc. 余談:シフトレフトの活動を行うと良いこと • 早い段階で行うべきことがハッキリしていると、 バグが混入されづらくなり、追加コストが不要になる ◦ バグチケット起票のコスト ◦

    開発内容を思い出すコスト ◦ 修正するコスト ◦ もう一度テストするコスト ◦ 関連部分にデグレードが無いか確認するコスト ◦ 起票したバグチケットを完了にするコスト 45 受け入れ基準作成時のテスト活動
  21. ©2023 10X, Inc. シフトライトテスト 48 シフトライトテストの例 Continuous Testing in DevOps…

    に掲載の画像を元に発表者が翻訳 リリース後 に行う テストがある
  22. ©2023 10X, Inc. 疑問点 • 注文変更の締切時間の前の場合、パッキング画面で 「完了」ボタンを押したときにエラーにする。 かつ、エラーを表示したあと前画面に戻る。 • 注文変更の締切時間の前の場合、パッキング画面で

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

    • どれくらいの頻度で開いているか見当もつかない  → 対象部分にログを仕込もう! 54 計画的にログを仕込み、効果が高そうか確認する
  24. ©2023 10X, Inc. ログを仕込んだ状態で1回リリース • ログを仕込むだけの差分でリリースする • リリース後に、そのログがどれだけ出たのか調べる ◦ ログが頻発する

    ▪ 今回の修正を入れると業務の妨げになる ◦ ログが頻発しない ▪ 今回の修正を入れる価値がある 56 計画的にログを仕込み、効果が高そうか確認する
  25. ©2023 10X, Inc. 補足:効果が高そうか確認する手段 • ログを仕込む • 適用範囲を絞る ◦ Feature

    Flag(Toggle)による適用範囲の指定 ▪ 特定の対象に絞って適用したい場合に有効 ◦ 段階的リリース(iOS: Phased Releases, Android: Staged Rollout) による適用範囲の制限 ▪ 少数の適用範囲で試したい場合に有効(カナリアリリース) ◦ A/Bテストによるランダムな適用 ▪ 現行と改善案のどちらが優れているか統計的に調べたい場合に有効 59 計画的にログを仕込み、効果が高そうか確認する
  26. ©2023 10X, Inc. 現場リサーチの様子 • 店舗スタッフが ピッキングやパッキングを 行っている様子を、 すぐそばから観察 •

    気になった点をメモする ◦ 時には録画・録音もする • 使い方を教えない 63 実際のオペレーションの様子を観察する ←10X社員 ↑店舗スタッフ
  27. ©2023 10X, Inc. 現場リサーチで見えてくるもの • 運用でカバーしている点 ◦ アプリでは解決が難しいものも含む ◦ プロダクトの仕様やプロダクトに残るin/outのデータだけ

    見ても、極めて断片的な理解・情報にしかならない • リサーチした店舗特有の課題点 ◦ 同じパートナーであっても、店舗によって課題は異なる • 自分たちが開発した機能がどのように使われているか 64 実際のオペレーションの様子を観察する
  28. ©2023 10X, Inc. 現場リサーチで気付いた例 68 実際のオペレーションの様子を観察する • 「大型」…お茶1ケースを注文した • 「常温」…お茶6本を注文した

    ◦ 1ケースと同じため、配達ではダンボールごと運ぶ Stailerのデータだけでは 気付けない運用時の工夫だった
  29. ©2023 10X, Inc. 現場リサーチで得られる副次的な効果 • よりアウトカムが意識できるようになる ◦ 一般的に、お客様からくるお問い合わせのほとんどは、 現状のアプリで不便だと認識している点 ◦

    以下の点はお問い合わせからは分からない ▪ お客様が便利だと感じている点 ▪ お客様が暗黙的に不便だと感じている点 • 実際の使われ方を見ることで、よりリリースに意識が向く ◦ 「機能を作って終わり!」とならなくなる ◦ 「どうすれば如何に早く、如何に効果的にリリースできるか」 と考えるようになる 70 実際のオペレーションの様子を観察する
  30. ©2023 10X, Inc. オペレーションを気にしながら分割リリースを実施 • ピッキングに関する大きな新機能についての リリースを行った • リリースを3回に分割した •

    開発がある程度進行した時点で、 新機能が入ったStailerをパートナーのところへ持ち込み、 試す場を提供していただいた。 72 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する
  31. ©2023 10X, Inc. 2回目のリリース • スタッフ研修に同席した • パートナーが運用を問題なく進行できるかの確度を高めた • 機能理解・オンボーディングにかかるコストを確認した

    大事な観点 75 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する 業務遂行性 習得性 運用操作性
  32. ©2023 10X, Inc. 3回目のリリース • 正式リリース • 実店舗で実際に活用いただく 大事な観点 76

    ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する 業務遂行性 習得性 運用操作性 機能正確性
  33. ©2023 10X, Inc. 分割リリースにして良かったこと • パートナーのフィードバックを貰いながら調整できた • パートナーの機能理解度が高い状態でリリースできた ◦ パートナーが新機能に対してビックリしない

    • 「オペレーションを効率的かつ確実に行う」という お届け領域の特徴を損なわないようにできた • リリースから数ヶ月経過しているが、 この機能に関する障害発生0件! お問い合わせも数件! 77 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する
  34. ©2023 10X, Inc. 補足:重視した品質について • 分割リリースの中で、重要視した品質をそれぞれ定義した ◦ 1回目…業務遂行性 ◦ 2回目…業務遂行性+習得性、運用操作性

    ◦ 3回目…業務遂行性、習得性、運用操作性+機能正確性 • 品質特性や狩野モデルなどから単に引用する形ではない ◦ 今回は議論した上で当てはめてみた結果 ◦ 議論せずに単に引用だけすると、それっぽく聞こえるけど 何も表現できていないものになってしまうかも ▪ 例…「当たり前品質って重要だよね!」   →何がプロダクトにとって「当たり前」なのか? 78 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する
  35. ©2023 10X, Inc. 補足:経営チームも含めた自分たちで品質を定義する 79 ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する 最も大きなGapは「保守性」であるという結論に。 更に保守性を深掘りしていくと、「運営自律性」や 「システム運用効率性」、「テスト容易性」といった 独自のキーワードが浮かび上がりました(By

    CTO)。 (中略) こういった独自の用語で品質をキャプチャしていくこと自体が、品質に 向き合う第1歩で重要なことだ!というのを品質管理部のブロッコリーさん からバックアップいただけたことは私個人としても自信になりました。 yamotty(弊社CEO)のブログ記事「プラットフォーム化ヘの歩み」より
  36. ©2023 10X, Inc. 81 おわりに まとめ • アウトカムに繋げるためのテスト活動として、 継続的テストモデルがある •

    シフトレフトテストの事例 ◦ 受け入れ基準作成時のテスト活動によって、 タスク完了の定義をハッキリさせた • シフトライトテストの事例 ◦ 計画的にログを仕込み、効果が高いか検証して進めた ◦ 現場リサーチによって、運用時の工夫に気付けた ◦ 分割リリースを実施し、機能理解度が高い状態を作った
  37. ©2024 10X, Inc. Developers Summit 2024 風間 裕也(ブロッコリー) #DevSumiC テストの完了をゴールにしない!

    ~仮説検証を繰り返し、開発・QA・ユーザーが 交流しながら開発することで見えてくる理想の姿~