Struggling with Agile Testing, in Rakuten
May 26, 2023
Mitsuo Hangai
Business Support Development Department
Commerce & Marketing Company
Rakuten Group, Inc.

⾃⼰紹介

Mitsuo Hangai(@bangucs)• Manager, Business Communication Platform Group• From Fukushima, Japan• Joined Rakuten as Producer, 2010/09• SelectDB(Hadoop DWH), Internal tool, R-Karte, R-Messe, …
• In my free time:

My Son(14)He likes: King Gnu,Mac, iPhone, Splatoon2

楽天仙台⽀社のご紹介
楽天市場- ECコンサルタント- 店舗開発- Tech- コールセンター向けツール- データウェアハウス開発・運⽤- ユーザー・店舗向け機能開発
楽天トラベル- コンサルタント
楽天GORA- 営業
楽天コールセンター3

Product: R-Messe
ユーザーと店舗さんの間のコミュニケーションを促すためのプラットフォーム。

ユーザー側

店舗さん側

楽天市場・RMS

2023/05/10 閲覧42019年リリース
開発したときの話はRSGT 2020で発表しました
https://speakerdeck.com/bangucs/we-released-a-service-released-with-forming-product-discovery-team
Product Discovery作って開発しました。川⼝さんに教えてもらったとおりにやるとリリースできます。

5

半年でリリース出来た
この規模でこのスピードは、かなり早い⽅

利⽤急増による過負荷などのトラブルを解決しながら、機能としては⾮常に好評。
機能改善も隔週くらいリリースでガンガンやってた。

6

2020年2⽉・・・

7

2020年2⽉・・・

8

役員まで報告・・・
なんてひどいトラブルだ︕︕
QAしてないとは何事だ︕︕全リリース必須にせよ︕︕対策をプランニングして報告せよ︕
︕

申し訳ございません︕︕※実態はこんな昭和な感じではありません
https://www.irasutoya.com/2015/07/blog-post_847.html「部下をどなりつけている上司のイラスト」いらすとや 2023/05/16閲覧

9実施した品質向上策• 開発案件を全部⽌め、Unit testを書く•

C1(分岐網羅) 90%書く•

単体レベルのバグだったので全部の送信パターンをテストしていれば防げた• QA⼯程を全プロジェクト必須にする•

ユーザーに影響がある、⼤規模のプロジェクトだけQAを実施していた••

外部組織なので、予算取り・説明・リソース確保・・・など⼤変でボトルネックになりがち「QAがこの時期になるのでリリースは1ヶ⽉先になります」• 異常検知の仕組みを追加

10

品質向上策の結果

トラブル頻度プロジェクト
リードタイムリリース頻度11

聖典︓LeanとDevOpsの科学項⽬

ハイパフォーマー

ミディアムパフォーマー

ローパフォーマー

デプロイの頻度

オンデマンド(1⽇複数回)

週1-⽉1

週1-⽉1

変更のリードタイム

1時間未満

1週間から1ヶ⽉

1週間から1ヶ⽉

MTTR(Mean Time ToRestore)

1時間未満1⽇未満

1⽇から1週間

変更失敗率

0-15%

0-15%

31-45%

LeanとDevOpsの科学を元に筆者作成
12品質向上策の結果

トラブル頻度プロジェクト
リードタイムリリース頻度13なんとかしたい
DevOpsにおける継続的テスト。素晴らしい。これを⽬指したかった。

https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/“Continuous Testing in DevOps…” By Dan Ashby 2023/05/16 閲覧

14

QAチームの中村さんと意気投合
以前別の仕事でご⼀緒したことがあって、同じ⽅向を向いてる⼈だなーと思っていた。推し。
同じDepartmentになれたのでざっくり相談
こんなふうにしたいんす︕どうすればいいすか︕︕

良いですね︕QAエンジニア採⽤してチーム内に⼊れちゃうのがいいかもですね︕

15

ここで中村さんにマイクをパスします︕

16

⾃⼰紹介

中村 祐輔 （Yusuke Nakamura）
My Career
2010.10 新卒で楽天に⼊社
2010.10 – 2015.12 アプリケーションエンジニア(Shopblog, S4, Video PF)
2016.01 テストエンジニアのキャリアスタート
2021.07 – Assistant Manager, Test engineer at Service Quality Management Group

Personal
Hometown: Shizuoka-shi, Shizuoka

Hobby
Listening to Radio / Kōdan (講談)
-Making Soba (蕎⻨打ち)

神⽥伯⼭・松鯉
問わず語り神⽥伯⼭
Junk
バナナムーンGOLD
おぎやはぎのメガネびいき
爆笑問題カーボーイ

17

課題
QAは独⽴した組織。プロジェクト毎に、各サービスからテストの依頼が来る
以前

PDM/PJM

開発

テストしました
品質に問題ないです
リリースOKです

QA

サービスA

サービスB

ユーザの購⼊情報を表⽰する機能を追加したからテストしてサービスC• QA依頼がきて初めて案件を知る• リソースの調整がプロジェクト毎発⽣する• 同じ⼈をアサインできない• ドメインナレッジをうまく共有できない• ⾒積もり・コスト承認・発注と。テスト設計開始までに2週間は最低必要• 開発チームはいつもQAを待つ形になった

18

課題に対するQA組織からの提案
ドメインナレッジを有し、開発ーPDMと⼀緒に品質を向上させることができる⼈材を置く

PDM/
PJM

開発

PDM/
PJM

開発

コミュニケーション
テストしました
品質に問題ないです
リリースOKです

QA

ユーザの購⼊情報を表⽰する機能を追加したからテストして前に、IEブラウザだとデザイン崩れがあったから、最初に確認しよう点から線へ。
プロジェクト品質から、サービス品質へ

QA

ユーザの購⼊情報を表⽰する機能を追加する際に、XXパターンを考慮するのを忘れないで。

19

Engマネージャと採⽤活動スタート
テストエンジニアとしてのナレッジ・経験がある• テストを⾃分で設計・実⾏できるひと• 受け⾝ではなく積極的にコミュニケーションが取れる⼈• 品質を改善しようという意欲がある⼈• エンジニア経験がある⼈（開発者の気持ちがわかる⼈）

20

Engマネージャと採⽤活動スタート• エンジニア経験がある⼈（開発者の気持ちがわかる⼈）開発• リリーススケジュールに合わすために忙しい• テストをする時間がない• 何をテストすればいいのかわからない• テストをするデータがない• 環境が不安定• QAチームからバグばかり押し付けられてる21

Engマネージャと採⽤活動スタート• エンジニア経験がある⼈（開発者の気持ちがわかる⼈）

QA

開発• こういう時に、XXをしてあげたら、嬉しいだろうなぁ• 助かるだろうなぁを考えられる⼈(これまでの経験から）品質向上は、QA組織だけではできない
QA組織は品質向上するための、攻めたサポーターにならないといけない• リリーススケジュールに合わすために忙しい• テストをする時間がない• 何をテストすればいいのかわからない• テストをするデータがない• 環境が不安定• QAチームからバグばかり押し付けられてる
22

QAチームからのアクション
QA

Shift-Leftの活動からスタート• 仕様の検討段階からQAメンバーが⼊る• 仕様の不明点を聞く（確認する）（≠ 指摘）• 他サービスでのテスト観点のシェア• 他サービスでのトラブルのシェア• 開発側のMTGに混ぜてもらう• Daily Huddleへの参加• 開発組織からの情報キャッチ• テスト進捗や、気になる点の共有• トラブルの振り返りへの参加

Kick off

Final
Report

Test
Execution

Estimation

Test
Design• 開発テストへの参加
開発とより近い距離でありながら、従来のQAプロセスにのせる
23

Shift Leftの活動
QAチーム

開発チーム
Bug Information

ユーザ要求
機能仕様

アーキテクチャ詳細設計
実装

UT / IT

ユーザ受け⼊れテスト

View point
Trouble Info
Spec Inspection

24

開発とより近い距離でありながら、従来のQAプロセスにのせるそれにより⾒えてきたこと• QA側から仕様の不明点を確認することは、開発・QA・PDM間での、認識合わせの機会を⽣む• ドキュメントバグ（仕様バグ）を早期に検出できる• 他サービスでのトラブル・バグを共有することで、”気をつける”観点を開発前に知らせることができる

QA
Kick off

Final
Report

Test
Execution

Estimation

TestDesign25

開発とより近い距離でありながら、従来のQAプロセスにのせるQA

本⽇のMTGで共有しました、QA共通のテスト観点です。
他案件の本番障害を元に作成しています。
こちら、随時更新しておきますね。

QA - 開発チームの関係性を向上ありがとうございます︕
Rakuten全社のノウハウをもらえるのは、⾮常にありがたい。
開発26

開発とより近い距離でありながら、従来のQAプロセスにのせるそれにより⾒えてきたこと• QA側から仕様を不明点を確認することは、開発・QA・PDM間での、認識合わせの機会を⽣む• ドキュメントバグ（仕様バグ）を早期に検出できる• 他サービスでのトラブル・バグを開発前に共有することで、”気をつける”観点を開発前に知らせることができる
QA側のメリット• ⾒積もり・リソース確保が早期に⾏える• テスト計画をDEV開発中に⾏える• 開発者テストへの参加で、プロジェクトの仕様・機能をより理解した形で、QAメンバーに共有できる

QA
Kick off

Final
ReportTest
Execution

Estimation

Test
Design27

テストエンジニアの強みを活かす
あるプロジェクトの例
店舗の営業⽇・営業時間に合わせて、応答メッセージを変える

営業⽇・営業時間の設定⽅法
••
•

営業⽇設定
営業⽇の内訳
曜⽇を指定• 休業⽇• お問合せ業務のみ• 発送業務のみ
⽇にちを指定• 休業⽇• お問合せ業務のみ• 発送業務のみ
祝⽇指定
営業時間指定• メッセージ受信当⽇の営業時間• メッセージ受信の前⽇の営業時間

営業⽇・営業時間の組み合わせが複雑で、どの場合にどういうメッセージを出せばいいか、整理できない。

テストエンジニア
組み合わせのナレッジがある︕

28

テストエンジニアの強みを活かす
パターンをテストエンジ
ニアが記載

期待値をPDMが⼊⼒

PDM・開発・QAの3者で仕様決定フェーズで認識を合わせる

29

テストエンジニアの強みを活かす＿APIテストパターン表の作成
新規APIを作成する際に、開発側が⾏うべきテストパターンをQA側から共有

全パターンの組み合わせから、プライオリティをつけ、最適化させる

組み合わせテスト技法︓直交表、オールペア

30

テストデータの⾃動作成ツールの提供メッセージデータユーザー
ユーザー・店舗間のメッセージを⾃動で⽣成できる

店舗

商品データ・受注データ

複数の商品データを⾃動作成

ユーザ情報を⼊⼒すると、該当ユーザで複数の受注データを⾃動作成

必要な時に、QAだけでなく、PDM/開発もテストできる︕

31

ただ、問題が出てきた
QAフェーズでのバグ検出率が低くなった• 要件定義フェーズ、開発テストフェーズにテストメンバーが⼊ることで、バグが早期に発⾒できる反⾯、QAフェーズでのバグは⾒つからなくなった• 開発者テスト・QAフェーズでのテストスコープが重複している

開発

QA

開発者がカバーしているテストスコープが広い
QAは、開発者テストの保証をしている︖

32

UT-IT-STを通して確認、QAフェーズでのテストスコープを⾒直しRegressionテストの⾒直し
開発

QA

複数ブラウザ・複数端末・探索テストの実施
QAは重要機能を抑えつつ、エラー・エッジケースを踏まえた探索テストを⾏う

開発

QA

重要機能、リスク⾼のものは両者でテスト
テスト結果は相互に参照可能

QAフェーズでのバグ検出率が増えてきた

33

4半期に⼀度の品質レポート

QAフェーズでのバグ率、本番不具合、サービス品質に対しての⾒解を共有

開発・PDM・QA
間でサービス品質に対しての認識合わせの機会をつくる

今後は、誰でもデータにアクセスできるように、品質ポータルサイトを作成
34

3 Amigosの導⼊
役割分担

3 Amigosの勉強・認識合わせからスタート

コミュニケーション•

毎⽇のハドル•
•

PDM

QA

情報共有
•

•

Zatsudan Time

フィードバック

Teams Groupに関係者全員参加
•
•
•

•

DEV

その⽇のタスクを共有
困っていることの共有

トラブル・バグ情報の共有
リリースステータスの共有
ユーザからの問い合わせ共有•

開発・QAから仕様のフィードバックを⾏う•

振り返り(Retrospective)への全員参加• 各フェーズでの振り返り

QA Kick offでの仕様の再確認

35

3 Amigosの導⼊後•開発段階での仕様・スケジュールに対する認識間違いが少なくなった•••

早期に意⾒を擦り合わすことができる
潜在的なリスクやバグをみつけ、対処できる気軽に相談できる関係性の構築••

コミュニケーションをより密に⾏える
同じ情報に基づいて、議論できるプロセスを監視し、アウトプットデータを収集しながら、3Amigosによる効果を測り、改善につなげていく

36

これから

1. Shift-Leftの活動継続
2. ⾃動化を含めた、テストの⽣産性の向上
3. データ作成⾃動化・データ提供
4. Qualityの⾒える化（誰もがサービス品質の”今”にアクセスできる）

37

これから

1. Shift-Leftの活動継続
2. ⾃動化を含めた、テストの⽣産性の向上
3. データ作成⾃動化・データ提供
4. Qualityの⾒える化（誰もがサービス品質の”今”にアクセスできる）
5. PDM/開発/QAが品質向上の活動を協働する 体制を維持

38

Join our team
• 品質保証業務全体の実施計画を⽴案および遂⾏し、各関係部⾨とコミュニケーションを図りながら、リスク軽減や改善および標準化を⾏い、⾼⽔準の品質保証業務の維持。
• 品質管理部⾨における、リーダー／マネージャーとしての管理業務。例えば、採⽤業務、メンバーの⽬標設定、業績評価、1 on 1ミーティングの実施、予算管理、パートナースタッフのリソース管理、担当チームのリソース管理など。
• メンバー及び所属部⾨における業務改善活動を推進し、業務全般のプロセス及び費⽤を分析し、標準化やコーチングを通して常に前進するハイパフォーマン
スカルチャーを醸成し、設定されたKPIの改善を⾏う
私たちの部署(Business Support Development
Department (BSD)
中村・半⾕にお気軽に声かけてください。
部署・サービス説明します

QA Manager

Test Engineer

Application
Engineer(Sendai)

39