スクラム開発でアジャイルテスティングを実施し、リリースサイクルを早めた話

1. Copyright (C) nohana, Inc. All rights reserved.
Copyright (C) nohana, Inc. All rights reserved.
2022/02/10
スクラム開発でアジャイルテスティングを
実施し、リリースサイクルを早めた話

2. Copyright (C) nohana, Inc. All rights reserved.
自己紹介
Copyright (C) nohana, Inc. All rights reserved.
田井 康平
● 株式会社ノハナ サービスデザイン部 品質管理グループ
● 趣味はドライブ、読書(戦国時代が特に好き)
● オンラインでのLTは初めて・・・
● QA業務をしつつ、スクラムマスターになるため、日々勉強中
● ASTER テストプロセス改善技術研究会メンバー(参加は随時募集中)

3. Copyright (C) nohana, Inc. All rights reserved.
ノハナの紹介
Copyright (C) nohana, Inc. All rights reserved.
● フォトブックアプリ、年賀状アプリの開発
通常フォトブック
毎月1冊無料でつくれるスタンダードタイプ。
高画質仕上げ、表紙デザインやギフト包装など、用途で選べ
るオプションも豊富にご用意しています。
定期的な写真のまとめや、月齢アルバムにおすすめです。
プレミアムフォトブック
高精細な写真画質仕上げの銀塩ハードカバータイプ。
レイフラット製本で迫力の見開き写真が実現、最大89枚（表
紙含む）の写真が入ります。
特別なイベントや、1年ごとの思い出の記録におすすめです。

4. Copyright (C) nohana, Inc. All rights reserved.
トピック
● スクラム開発導入前(オフショアでテストをしていたとき)
● スクラム開発導入後(開発期間とテスト期間でスプリントをわけていたとき)
● スクラム開発の現状
● 最後に

5. Copyright (C) nohana, Inc. All rights reserved.
スクラム開発導入前
(オフショアでテストをしていたとき)

6. Copyright (C) nohana, Inc. All rights reserved.
スクラム開発導入前(オフショアでテストをしていたとき)
Copyright (C) nohana, Inc. All rights reserved.
● 数年前まで内製でテストをしていたがコスト削減を重視し、オフショアでの
テストに移行(よくあるパターン)
● 開発期間中にテスト準備
○ テスト観点はノハナ側で作成
○ テストケース作成、テスト実行はオフショアで行い、ノハナ側がレビュ
ーを行う
● リリースまで大体1ヶ月ぐらいで、この体制を数年続けていた

7. Copyright (C) nohana, Inc. All rights reserved.
しかし・・・
スクラム開発導入前(オフショアでテストをしていたとき)

8. Copyright (C) nohana, Inc. All rights reserved.
スクラム開発導入前(オフショアでテストをしていたとき)
Copyright (C) nohana, Inc. All rights reserved.
● 全ての開発が完了してからテストするので、バグ発見時の手戻りが大きい
● 開発状況やテストが完了するのを待つので、リリースのタイミングが固定で
きない(マーケやCSへの共有が直前になってしまう(共有漏れ)など)
● リリースのインターバルが長い(大体1ヶ月)
● ノハナ側もレビュー等でそれなりに工数を取られてしまう
● コストは安いが、テスト効率は若干低いのでテスト期間は長くなってしまう
● 日本語は話せるけど、細かいニュアンスや指摘が伝わりにくい
○ その結果、テスト実行時のミスやインシデントなどにつながることも

9. Copyright (C) nohana, Inc. All rights reserved.
スクラム開発導入前(オフショアでテストをしていたとき)
Copyright (C) nohana, Inc. All rights reserved.
いろいろな課題が出てきたことと、会社の方向性としてリリースサイクルを短期
間にして安定させ、施策をより多く出す方向にシフト

10. Copyright (C) nohana, Inc. All rights reserved.
スクラム開発導入後
(開発とテストでスプリントをわけていたとき)

11. Copyright (C) nohana, Inc. All rights reserved.
しかし・・・
いきなり開発とテストをスクラムでやるにはノウハウがない。。
スクラム開発導入後(開発期間とテスト期間でスプリントをわけていたとき)

12. Copyright (C) nohana, Inc. All rights reserved.
スクラム開発導入後(開発期間とテスト期間でスプリントをわけていたとき)
Copyright (C) nohana, Inc. All rights reserved.
● 導入において、途中までアジャイルコーチにサポートを依頼！
● チーム内でスクラムの説明会を開き、認識合わせを行った
● 開発スプリントとリリーススプリントと2つに分けることに
● 施策はプロダクトバックログ(以降PBIとする)単位で管理

13. Copyright (C) nohana, Inc. All rights reserved.
スクラム開発導入後(開発期間とテスト期間でスプリントをわけていたとき)
Copyright (C) nohana, Inc. All rights reserved.
● 開発スプリントは2週間
● 開発完了したPBIからプレテストを行い、ブロッキングとなりそうなバグを早め
に検知
● 間に合わないPBIは次のスプリントへ持ち越し(QAのリソースや優先度によっては、
実施することもあり)
● リリーススプリントは1週間
● 合計3週間でサイクルをまわしていた
● レトロスペクティブで課題出しを行い、改善策を次のスプリントでやることで、
少しずつ課題を改善していった

14. Copyright (C) nohana, Inc. All rights reserved.
Copyright (C) nohana, Inc. All rights reserved.
半年ぐらいこの状態で運用し、
いよいよ、1スプリントで開発とテストを終わらせることに！！
スクラム開発導入後(開発期間とテスト期間でスプリントをわけていたとき)

15. Copyright (C) nohana, Inc. All rights reserved.
スクラム開発の現状

16. Copyright (C) nohana, Inc. All rights reserved.
スクラム開発の現状
● 去年の4月ぐらいから移行
● 開発とテストを2週間サイクルで行う(月2回リリース)
● 開発凍結日やリリース日が固定されたので
○ PBI単位でテストするので、バグ発生時の手戻りが大幅に減った
○ 間に合わないPBIは次のスプリントへ持ち越しやすくなった
○ マーケやCSとの認識合わせがほぼなくなった(共通認識を持てるようになっ
た)

17. Copyright (C) nohana, Inc. All rights reserved.
スクラム開発の現状
● 2週間のスプリントのため、テストケース作成をしていると間に合わない
○ 探索的テストとテスト自動化を活用したアジャイルテスティングを実施
■ 担当者によるブレを減らすため、テスト観点を作成し、レビューも行う
■ 回帰テストやライブチェックも一部自動化し工数削減
■ スクリプトテストは全く実施していない
● PBI単位でテストするので、QAからのフィードバックが早い
● インシデントが増えたということはない
● 施策をよりスピーディーにユーザー様へ提供できるようになった

18. Copyright (C) nohana, Inc. All rights reserved.
最後に
Copyright (C) nohana, Inc. All rights reserved.
● スクラム開発がベストというのではなく
○ ノハナでは、スクラム開発を適用できた
■ 会社の方針や体制にあった手法を取り入れるのが良い！
○ でも、まずは試してみることが大切！！
■ 失敗したら他の手法を試すなど(会社の文化的に許されるなら。。)
■ やってみないと、うまくいくかなんてわからない
● 今日お話しした内容のブログも公開していますので、ご覧ください！！
● ノハナではサーバーエンジニアを絶賛募集しています！！詳しく
kohei_tai@nohana.co.jpまで！