品質のために手段を追求してみた【DeNA QA Night #4】

You Tube：https://youtu.be/17D3FNQPeLc

概要：
本資料は 2023/2/10(金) に開催された DeNA QA Night #4 で発表された資料です。

◆ DeNA QA Night
https://dena-qa-night.connpass.com/

◆ チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

Transcript

1. DeNA QA Night
   品質のために手段を追求してみた
   藤﨑 隆
   QC第二グループ
   品質管理部
   品質本部
   株式会社ディー・エヌ・エー
   

   View Slide

2. 2
   事業ポートフォリオ
   DeNAは何を生業とする会社？
   

   View Slide

3. 事業ポートフォリオ
   3
   

   View Slide

4. 事業ポートフォリオ
   4
   

   View Slide

5. 事業ポートフォリオ
   

   View Slide

6. 事業ポートフォリオ
   QC1G QC2G
   

   View Slide

7. 7
   品質本部・品質管理部
   品質本部・品質管理部
   

   View Slide

8. 品質本部・品質管理部
   ★

   8
   ├品質管理部
   ├・・・
   └・・・
   

   View Slide

9. 9
   ● 品質管理部のバリュー（行動指針）
   ○ 品質のために手段を追求する
   ■ 品質の高いプロダクトを素早く提供するために、あらゆる手段を追求する
   ○ 基礎を大事にする
   ■ 基礎を大事にし、その上で組織にあった形にカスタマイズする
   ○ 学び、進化する
   ■ 自らの学びと他者の事例（失敗も成功も）から、常に進化しつづける習慣をつける
   ○ 信頼を築く
   ■ 組織の壁を越え積極的に巻き込み、品質を全員で実現するという理念をDeNA全体で実
   現できるよう心がける
   ○ 最後の砦となる
   ■ DeNAとして譲れない品質を守り抜く
   品質本部・品質管理部
   

   View Slide

10. 10
    ● 品質管理部のバリュー（行動指針）
    ○ 品質のために手段を追求する
    ■ 品質の高いプロダクトを素早く提供するために、あらゆる手段を追求する
    ○ 基礎を大事にする
    ■ 基礎を大事にし、その上で組織にあった形にカスタマイズする
    ○ 学び、進化する
    ■ 自らの学びと他者の事例（失敗も成功も）から、常に進化しつづける習慣をつける
    ○ 信頼を築く
    ■ 組織の壁を越え積極的に巻き込み、品質を全員で実現するという理念をDeNA全体で実
    現できるよう心がける
    ○ 最後の砦となる
    ■ DeNAとして譲れない品質を守り抜く
    品質本部・品質管理部
    

    View Slide

11. 品管の活動
    DeNAサービスのテスト
    QA依頼
    ★

    11
    

    View Slide

12. 品管の活動
    コーポレートサイト検証
    競合他社サービスの調査 仕様書インスペクション
    サインオフ
    品質分析レポート
    12
    仕様書の内容をQAがレビュー
    リリース可能かQA目線でジャッジ
    倫理チェック
    ：

    

    View Slide

13. パーソナリティ
    ● 藤﨑 隆
    ● QC2G 社会課題領域（SS）を担当
    ● QA/テスト 17年目
    ● 多方面から関われるQAになりたい
    ● ベイスターズの優勝を間近で見たくて入社
    ○ 2014年からファンクラブ
    管理 テスト 技術 その他
    プロジェクトマネージャー
    認定スクラムマスター
    システム監査技術者
    JSTQB FL
    IVEC L2
    JSTQB AL
    IVEC L5
    Comptia Network+
    MCPC 2級
    応用情報技術者
    AWS ソリューションアー
    キテクト アソシエイト
    秘書検定2級
    知的財産管理技能検定2級
    宅地建物取引主任者
    FP3級
    社会保険労務士
    統計検定2級
    持っている資格

    13
    今年取っておきたい資格
    

    View Slide

14. パーソナリティ
    17年を掛けた私の考え方の変遷
    1) 優秀なテストチームがいたら、完璧なプロダクトをリリースできる！
    2) 下流から手を入れても既に手遅れで、上流から手を入れないといけない
    3) 上流から、全員を巻き込まなければ良い品質のプロダクトは作れない
    14
    

    View Slide

15. 15
    再掲
    品質のために手段を追求
    

    View Slide

16. 実例紹介
    16
    

    View Slide

17. 新ベイチケをデジタルチケット化する案件のQA依頼
    17
    ×

    

    View Slide

18. FY21 新ベイチケ
    ※横浜DeNAベイスターズの
    　チケット販売システム
    FY22 デジタルチケット化
    新ベイチケをデジタルチケット化する案件のQA依頼
    QA依頼
    18
    開発ベンダ
    開発依頼
    開発依頼
    要連携
    

    View Slide

19. QAがJoinするまでの打ち合わせの流れ
    19
    ①
    依頼
    ②
    精査
    ③
    体制
    検討
    ④
    事業部と
    打ち合わ
    せ ⑤
    見積もり
    ⑥
    合意
    ⑦
    Join
    事
    業
    部
    Q
    A
    Email

    Slack
    Zoom Slack
    

    View Slide

20. QAがJoinするまでの打ち合わせの流れ
    20
    ◆見えてきたリスク
    　①ユースケースが特殊（多量の来場者、大音量、残存させる手運用）
    　②開発に関連する会社が多く、混乱をきたす（3社4組織）
    　③仕様合意の深さが足りず、開発中の仕様追加が発生する
    案件の難易度は高いことが予想された
    ①
    依頼
    ②
    精査
    ③
    体制
    検討
    ④
    事業部と
    打ち合わ
    せ ⑤
    見積もり
    ⑥
    合意
    ⑦
    Join
    事
    業
    部
    Q
    A
    Zoom
    Email

    Slack

    Slack
    

    View Slide

21. QAがJoinするまでの打ち合わせの流れ
    21
    QA
    難易度が高い時は、QAの早期参画が鉄則
    ココカラ
    

    View Slide

22. QAがJoinするまでの打ち合わせの流れ
    22
    ❏ QAが上流から入るための、口説き文句集
    ❏ 上流からQAが入ると手戻り防止出来て、開発コストを低減できますよ！
    ❏ プロセス整備をお手伝い出来るので、無用なストレスが軽減されます！
    ❏ 無駄バグ抑えて、開発に人増やしてQA人員を削減しちゃいましょう！
    試験によく出る
    

    View Slide

23. QAがJoinするまでの打ち合わせの流れ
    23
    QA
    要件定義からQAするためには、その前に依頼が必要
    昔
    今
    

    View Slide

24. 品質のために手段を追求
    24
    

    View Slide

25. 品質のために手段を追求
    25
    https://engineering.dena.com/team/quality/quality-control/
    

    View Slide

26. 品質のために手段を追求
    26
    イ
    ン
    ス
    ペ
    ク
    シ
    ョ
    ン
    テ
    ス
    ト
    設
    計
    テ
    ス
    ト
    実
    行
    品
    質
    分
    析
    普段なら・・・
    テ
    ス
    ト
    計
    画
    サ
    イ
    ン
    オ
    フ
    

    View Slide

27. 品質のために手段を追求
    27
    ◆見えてきたリスク
    　①ユースケースが特殊（多量の来場者、大音量、残存させる手運用）
    　②開発に関連する会社が多く、混乱をきたす（4つの組織）
    　③仕様合意の深さが足りず、開発中の仕様追加が発生する
    特殊なユースケースを相手に、「想定外」のトラブルが懸念された
    ユースケース理解を深め、「想定外」を防止していく
    ①／２
    

    View Slide

28. 品質のために手段を追求
    28
    ◆見えてきたリスク
    　①ユースケースが特殊（多量の来場者、大音量、残存させる手運用）
    　②開発に関連する会社が多く、混乱をきたす（4つの組織）
    　③仕様合意の深さが足りず、開発中の仕様追加が発生する
    認識違い・段取り漏れの「行き違い」のトラブルが懸念された
    共通認識を増やし、「行き違い」を防止していく
    ②／２
    

    View Slide

29. 29
    ユースケース理解を深め、「想定外」を防止していく
    共通認識を増やし、「行き違い」を防止していく
    

    View Slide

30. ①ユースケース理解を深め、「想定外」を防止していく
    30
    一般的なシステム開発のユースケース
    このプロダクトだからこそのユースケース
    一般的なので、記載除外
    こちらを記載していく
    ・ペルソナ
    ・CJM
    

    View Slide

31. ①ユースケース理解を深め、「想定外」を防止していく
    31
    来場者数を調査
    年間来場者数 平均来場者数 1回の販売 稼働率：試合数
    2,283,524人
    ※NPB情報
    31,716人
    ※年間来場者数/試合数
    約390,000枚
    ※チケット販売情報から推定
    98%：72試合
    ※NPB情報から推定
    2019年度セ・リーグ入場者数・平均試合時間（公式戦全日程終了）
    https://npb.jp/statistics/2019/atttime_cl0930.pdf
    2023年公式戦（横浜スタジアム開催）チケット発売スケジュール 全体概要
    https://sp.baystars.co.jp/ticket/regular/game.html
    

    View Slide

32. ①ユースケース理解を深め、「想定外」を防止していく
    32
    地図を見る 現地を視察 ユーザーストーリーに細分化
    チケット購入
    デジタルチケット入手
    試合前日まで
    試合開始案内
    入場
    試合成立
    昔行った際に自身で撮影！
    

    View Slide

33. ①ユースケース理解を深め、「想定外」を防止していく
    33
    日付 対戦チーム 開場前 開始前 試合成立前 試合成立
    4/8 阪神タイガース ✖
    7/15 ヤクルトスワローズ 〇 ✖
    8/4 広島カープ 〇 〇 ✖
    8/16 阪神タイガース 〇 〇 〇 〇
    払い戻し要否 必要 必要 必要 不要
    備考 ５回裏終了
    試合の中止を想定
    

    View Slide

34. ①ユースケース理解を深め、「想定外」を防止していく
    34
    日付 対戦チーム 開場前 開始前 試合成立前 試合成立
    4/8 中日ドラゴンズ ✖
    7/15 ヤクルトスワローズ 〇 ✖
    8/4 広島カープ 〇 〇 ✖
    8/16 読売ジャイアンツ 〇 〇 〇 〇
    払い戻し要否 必要 必要 必要 不要
    備考 ５回裏終了
    ※　✖：雨天中止が決まったタイミング
    ※　この成績により「雨男」という称号を獲得
    試合の中止を想定
    

    View Slide

35. ①ユースケース理解を深め、「想定外」を防止していく
    35
    整理 展開 見解 合議
    ユースケース
    叩き台は
    自分たちが作る
    気付きに気付きを重ねていく
    

    View Slide

36. ①ユースケース理解を深め、「想定外」を防止していく
    36
    こうした活動を「ユースケース分析」と呼称
    ユースケース分析
    ユースケース分析書
    

    View Slide

37. ①ユースケース理解を深め、「想定外」を防止していく
    37
    PdM
    QA
    エンジニア
    ユースケース分析書
    PjM ユーザー
    全員（各ステークホルダ）に確認をして頂きユースケースをブラッシュアップ
    全員（各ステークホルダ）の成果物に反映
    

    View Slide

38. ①ユースケース理解を深め、「想定外」を防止していく
    イ
    ン
    ス
    ペ
    ク
    シ
    ョ
    ン
    テ
    ス
    ト
    設
    計
    テ
    ス
    ト
    実
    行
    テ
    ス
    ト
    計
    画
    ユ
    ｜
    ス
    ケ
    ｜
    ス
    分
    析
    品
    質
    分
    析
    サ
    イ
    ン
    オ
    フ
    ここまでの活動により、ユースケース分析がQAプロセスに追加
    38
    

    View Slide

39. ①ユースケース理解を深め、「想定外」を防止していく
    イ
    ン
    ス
    ペ
    ク
    シ
    ョ
    ン
    テ
    ス
    ト
    設
    計
    テ
    ス
    ト
    実
    行
    テ
    ス
    ト
    計
    画
    ユ
    ｜
    ス
    ケ
    ｜
    ス
    分
    析
    品
    質
    分
    析
    サ
    イ
    ン
    オ
    フ
    実
    利
    用
    検
    証
    ここまでの活動により、ユースケース分析がQAプロセスに追加
    副産物として「実利用検証」を必要と判断
    39
    

    View Slide

40. ①ユースケース理解を深め、「想定外」を防止していく
    サインオフ
    レポート
    テスト
    仕様書イン
    スペクショ
    ン
    40
    

    View Slide

41. ①ユースケース理解を深め、「想定外」を防止していく
    41
    サインオフ
    レポート
    紙チケット
    の損傷
    現地調査
    テスト
    ユースケー
    ス分析
    仕様書イン
    スペクショ
    ン
    デジタルチ
    ケット発行
    ライムラグ
    多人数入場
    モギリ端末
    の電池持ち
    実利用調査
    41
    

    View Slide

42. 42
    ユースケース理解を深め、「想定外」を防止していく
    共通認識を増やし、「行き違い」を防止していく
    

    View Slide

43. ②共通認識を増やし、「行き違い」を防止していく
    Q.開発側は、テストをしてくれるのか？
    43
    

    View Slide

44. ②共通認識を増やし、「行き違い」を防止していく
    Q.開発側は、テストをしてくれるのか？
    A.期待するテストとなるようにQA側で取り計らう
    44
    

    View Slide

45. テスト計画書でテストタイプ毎に調整
    ②共通認識を増やし、「行き違い」を防止していく
    45
    ※〇×はサンプル
    どんなテストをしてほしいか
    

    View Slide

46. PFDで開発側のテストタイミングと内容を調整
    ②共通認識を増やし、「行き違い」を防止していく
    46
    いつ・どのような方法のテストをしてほしいか
    

    View Slide

47. ②共通認識を増やし、「行き違い」を防止していく
    Q.仕様書は、分かりやすく、充分な内容か？
    47
    

    View Slide

48. ②共通認識を増やし、「行き違い」を防止していく
    Q.仕様書は、分かりやすく、充分な内容か？
    A.期待する仕様書となるようにQA側で取り計らう
    48
    

    View Slide

49. 仕様書フォーマット
    ②共通認識を増やし、「行き違い」を防止していく
    仕様書ツリー
    フォーマット
    ディスクリプション
    OK
    ここが気になった→
    仕様書インスペクションで対応
    QA見解 仕様書構成
    49
    

    View Slide

50. ②共通認識を増やし、「行き違い」を防止していく
    ◇課題
    　画面仕様書の画面パーツは分かるが、操作可否、可変/固定文言かが読み取れない
    ◇対策
    　画面仕様に、ラベルを埋め込んで頂き、仕様規定する
    50
    

    View Slide

51. もう１個、仕様書フォーマット
    ②共通認識を増やし、「行き違い」を防止していく
    仕様書ツリー
    フォーマット
    ディスクリプション
    OK
    もう１個、ここが気になった→
    仕様書インスペクションで対応
    QA見解 仕様書構成
    51
    

    View Slide

52. ②共通認識を増やし、「行き違い」を防止していく
    ◇課題
    　表記ゆれが、あった
    ◇対策
    　表記の仕様は、一ヶ所で集中管理する
    修正前 修正後
    本券は、XXX デジタルチケットは、XXX
    XXXはチケットに記載の通り、 XXXはデジタルチケットに記載の通り、
    電子チケット デジタルチケット
    52
    ＊表記統一のイメージ
    

    View Slide

53. ①ユースケース理解を深め、「想定外」を防止していく
    サインオフ
    レポート
    テスト
    仕様書イン
    スペクショ
    ン
    53
    

    View Slide

54. ①ユースケース理解を深め、「想定外」を防止していく
    サインオフ
    レポート
    紙チケット
    の損傷
    現地調査
    テスト
    ユースケー
    ス分析
    仕様書イン
    スペクショ
    ン
    デジタルチ
    ケット発行
    ライムラグ
    多人数入場
    モギリ端末
    の電池持ち
    実利用調査
    54
    

    View Slide

55. ②共通認識を増やし、「行き違い」を防止していく
    サインオフ
    レポート
    テスト
    ユースケー
    ス分析
    仕様書イン
    スペクショ
    ン
    仕様書
    フォーマッ
    ト 実利用調査
    開発品質向
    上合意
    Process Flow
    Diagram
    紙チケット
    の損傷
    現地調査
    デジタルチ
    ケット発行
    ライムラグ
    多人数入場
    モギリ端末
    の電池持ち
    55
    

    View Slide

56. ②共通認識を増やし、「行き違い」を防止していく
    Q.テスト項目書は、正しく作られているか
    Q.ユーザーの期待するプロダクトはどういうものか
    Q.どの機能から作っていくのか
    Q.工程終了後の品質基準はどの程度か
    　　　　　　　：
    　　　　　　　：
    56
    

    View Slide

57. ②共通認識を増やし、「行き違い」を防止していく
    サインオフ
    レポート
    紙チケット
    の損傷
    現地調査
    QA成果物レ
    ビュー依頼
    開発品質向
    上合意
    ユーザーア
    ンケート
    テスト
    Process Flow
    Diagram
    ユースケー
    ス分析
    仕様書イン
    スペクショ
    ン
    仕様書
    フォーマッ
    ト
    デジタルチ
    ケット発行
    ライムラグ
    多人数入場
    電池持ち
    実利用調査
    57
    改善提案
    

    View Slide

58. 成果
    58
    

    View Slide

59. 成果
    59
    分類 項目数 不具合数 不具合率 備考
    QAテスト
    （結合・総合）
    1593項目 80件 5.0% 新規プロダクト平均
    ＜見積もり＞
    ＜　実績　＞
    

    View Slide

60. 成果
    60
    分類 項目数 不具合数 不具合率 備考
    QAテスト
    （結合・総合）
    1593項目 80件 5.0% 新規プロダクト平均
    分類 項目数 不具合数 不具合率 備考
    QAテスト
    （結合・総合）
    1593項目 32件 2.0% QAでの検出
    受入テスト 6人日 0件 0.0％ YDB/QAで実施
    本番環境 - 0件 0.0％ ファンフェスで実証実験
    ＜見積もり＞
    ＜　実績　＞
    

    View Slide

61. 成果
    61
    レイリーモデル
    　ソフトウェア開発プロセスすべてにおける障害率を表したグラフ
    基
    本
    設
    計
    詳
    細
    設
    計
    コ
    ー
    デ
    ィ
    ン
    グ
    単
    体
    テ
    ス
    ト
    結
    合
    テ
    ス
    ト
    シ
    ス
    テ
    ム
    テ
    ス
    ト
    本
    番
    不具合検出ピークと不具合数を定めると、
    工程別の障害率が分かる
    例）全不具合K=100件
    　　検出ピークをコーディング工程（c=2.5）
    基本設計 c=0.5 8件
    詳細設計 1.5 20件
    コーディング 2.5 24件
    単体テスト 3.5 21件
    結合テスト 4.5 14件
    システムテスト 5.5 8件
    本番 6.5 5件
    ２４件 ５件
    ピーク

    

    View Slide

62. 成果
    62
    レイリーモデルに当てはめて、少し「シフトレフト」出来たと仮定して、
    取り組み効果を算出をしていく
    上流工程から頑張ったので、
    サンプルのc=2.5→2.0と仮定
    

    View Slide

63. 成果
    63
    基
    本
    設
    計
    詳
    細
    設
    計
    コ
    ー
    デ
    ィ
    ン
    グ
    単
    体
    テ
    ス
    ト
    結
    合
    テ
    ス
    ト
    シ
    ス
    テ
    ム
    テ
    ス
    ト
    本
    番
    基本設計 32件
    詳細設計 76件
    コーディング 76件
    単体テスト 51件
    結合テスト 24件
    システムテスト 8件
    本番 2件
    合計 269件
    QAで検出せずに済んだ 235件
    QAで検出した 32件
    QAで見逃した
    （見つかっていない）
    2件
    今回、結合テスト・システムテストでの不具合数は32件
    ピークは、コーディング工程の少し前（C=2.0）と仮定
    ここから逆算すると、不具合269件が内在した開発であることが分かる
    ８件

    ２４件

    ピーク

    

    View Slide

64. 成果
    64
    もし、不具合数が同一で、検出ピークが「結合テスト」と仮定
    本番不具合：２件
    本番不具合：３０件
    ピーク
    ピーク
    基
    本
    設
    計
    詳
    細
    設
    計
    コ
    ー
    デ
    ィ
    ン
    グ
    単
    体
    テ
    ス
    ト
    結
    合
    テ
    ス
    ト
    シ
    ス
    テ
    ム
    テ
    ス
    ト
    本
    番
    

    View Slide

65. 65
    次につなげる
    

    View Slide

66. 今後のために
    66
    QA
    昔
    今
    今後も、早期に声掛けを頂ける関係性を築きたい
    

    View Slide

67. 今後のために
    67
    サインオフ＆振り返り
    ● 参加者は広めに、高めに
    ● 経緯、結果に対してフィードバックを頂く
    全員の責任で、リリースを行う
    QAのプレゼンスも高める
    

    View Slide

68. 今後のために
    68
    改善提案
    ● 最初か、サインオフ後に改善提案を行う
    ● 改善提案は、改善活動の「きっかけ」作り
    ● なるべくイメージ感が伝わるようなビジュアルで
    

    View Slide

69. 69
    おわりに
    

    View Slide

70. おわりに
    70
    品質のために手段を追求
    

    View Slide

71. 早期参画
    おわりに
    71
    ←効果のある手段が望ましい
    QA目線の
    供給
    品質の
    安定
    良い
    振り返り
    

    View Slide

72. 品質のために手段を追求
    72
    ● QAの完成系は無い
    ○ だからこそこれからも手段を追求して、品質を全員で高めていきたい
    

    View Slide

73. View Slide