品質のために手段を追求してみた【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第二グループ 品質管理部 品質本部 株式会社ディー・エヌ・エー
2. 2 事業ポートフォリオ DeNAは何を生業とする会社？
3. 事業ポートフォリオ 3
4. 事業ポートフォリオ 4
5. 事業ポートフォリオ
6. 事業ポートフォリオ QC1G QC2G
7. 7 品質本部・品質管理部 品質本部・品質管理部
8. 品質本部・品質管理部 ★
 8 ├品質管理部 ├・・・ └・・・
9. 9 • 品質管理部のバリュー（行動指針） ◦ 品質のために手段を追求する ▪ 品質の高いプロダクトを素早く提供するために、あらゆる手段を追求する ◦ 基礎を大事にする ▪ 基礎を大事にし、その上で組織にあった形にカスタマイズする ◦ 学び、進化する ▪ 自らの学びと他者の事例（失敗も成功も）から、常に進化しつづける習慣をつける ◦ 信頼を築く ▪ 組織の壁を越え積極的に巻き込み、品質を全員で実現するという理念をDeNA全体で実 現できるよう心がける ◦ 最後の砦となる ▪ DeNAとして譲れない品質を守り抜く 品質本部・品質管理部
10. 10 • 品質管理部のバリュー（行動指針） ◦ 品質のために手段を追求する ▪ 品質の高いプロダクトを素早く提供するために、あらゆる手段を追求する ◦ 基礎を大事にする ▪ 基礎を大事にし、その上で組織にあった形にカスタマイズする ◦ 学び、進化する ▪ 自らの学びと他者の事例（失敗も成功も）から、常に進化しつづける習慣をつける ◦ 信頼を築く ▪ 組織の壁を越え積極的に巻き込み、品質を全員で実現するという理念をDeNA全体で実 現できるよう心がける ◦ 最後の砦となる ▪ DeNAとして譲れない品質を守り抜く 品質本部・品質管理部
11. 品管の活動 DeNAサービスのテスト QA依頼 ★
 11
12. 品管の活動 コーポレートサイト検証 競合他社サービスの調査 仕様書インスペクション サインオフ 品質分析レポート 12 仕様書の内容をQAがレビュー リリース可能かQA目線でジャッジ 倫理チェック ：

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 今年取っておきたい資格
14. パーソナリティ 17年を掛けた私の考え方の変遷 1) 優秀なテストチームがいたら、完璧なプロダクトをリリースできる！ 2) 下流から手を入れても既に手遅れで、上流から手を入れないといけない 3) 上流から、全員を巻き込まなければ良い品質のプロダクトは作れない 14
15. 15 再掲 品質のために手段を追求
16. 実例紹介 16
17. 新ベイチケをデジタルチケット化する案件のQA依頼 17 ×

18. FY21 新ベイチケ ※横浜DeNAベイスターズの 　チケット販売システム FY22 デジタルチケット化 新ベイチケをデジタルチケット化する案件のQA依頼 QA依頼 18 開発ベンダ 開発依頼 開発依頼 要連携
19. QAがJoinするまでの打ち合わせの流れ 19 ① 依頼 ② 精査 ③ 体制 検討 ④ 事業部と 打ち合わ せ ⑤ 見積もり ⑥ 合意 ⑦ Join 事 業 部 Q A Email
 Slack Zoom Slack
20. QAがJoinするまでの打ち合わせの流れ 20 ◆見えてきたリスク 　①ユースケースが特殊（多量の来場者、大音量、残存させる手運用） 　②開発に関連する会社が多く、混乱をきたす（3社4組織） 　③仕様合意の深さが足りず、開発中の仕様追加が発生する 案件の難易度は高いことが予想された ① 依頼 ② 精査 ③ 体制 検討 ④ 事業部と 打ち合わ せ ⑤ 見積もり ⑥ 合意 ⑦ Join 事 業 部 Q A Zoom Email
 Slack
 Slack
21. QAがJoinするまでの打ち合わせの流れ 21 QA 難易度が高い時は、QAの早期参画が鉄則 ココカラ
22. QAがJoinするまでの打ち合わせの流れ 22 ❏ QAが上流から入るための、口説き文句集 ❏ 上流からQAが入ると手戻り防止出来て、開発コストを低減できますよ！ ❏ プロセス整備をお手伝い出来るので、無用なストレスが軽減されます！ ❏ 無駄バグ抑えて、開発に人増やしてQA人員を削減しちゃいましょう！ 試験によく出る
23. QAがJoinするまでの打ち合わせの流れ 23 QA 要件定義からQAするためには、その前に依頼が必要 昔 今
24. 品質のために手段を追求 24
25. 品質のために手段を追求 25 https://engineering.dena.com/team/quality/quality-control/
26. 品質のために手段を追求 26 イ ン ス ペ ク シ ョ ン テ ス ト 設 計 テ ス ト 実 行 品 質 分 析 普段なら・・・ テ ス ト 計 画 サ イ ン オ フ
27. 品質のために手段を追求 27 ◆見えてきたリスク 　①ユースケースが特殊（多量の来場者、大音量、残存させる手運用） 　②開発に関連する会社が多く、混乱をきたす（4つの組織） 　③仕様合意の深さが足りず、開発中の仕様追加が発生する 特殊なユースケースを相手に、「想定外」のトラブルが懸念された ユースケース理解を深め、「想定外」を防止していく ①／２
28. 品質のために手段を追求 28 ◆見えてきたリスク 　①ユースケースが特殊（多量の来場者、大音量、残存させる手運用） 　②開発に関連する会社が多く、混乱をきたす（4つの組織） 　③仕様合意の深さが足りず、開発中の仕様追加が発生する 認識違い・段取り漏れの「行き違い」のトラブルが懸念された 共通認識を増やし、「行き違い」を防止していく ②／２
29. 29 ユースケース理解を深め、「想定外」を防止していく 共通認識を増やし、「行き違い」を防止していく
30. ①ユースケース理解を深め、「想定外」を防止していく 30 一般的なシステム開発のユースケース このプロダクトだからこそのユースケース 一般的なので、記載除外 こちらを記載していく ・ペルソナ ・CJM
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
32. ①ユースケース理解を深め、「想定外」を防止していく 32 地図を見る 現地を視察 ユーザーストーリーに細分化 チケット購入 デジタルチケット入手 試合前日まで 試合開始案内 入場 試合成立 昔行った際に自身で撮影！
33. ①ユースケース理解を深め、「想定外」を防止していく 33 日付 対戦チーム 開場前 開始前 試合成立前 試合成立 4/8 阪神タイガース ✖ 7/15 ヤクルトスワローズ 〇 ✖ 8/4 広島カープ 〇 〇 ✖ 8/16 阪神タイガース 〇 〇 〇 〇 払い戻し要否 必要 必要 必要 不要 備考 ５回裏終了 試合の中止を想定
34. ①ユースケース理解を深め、「想定外」を防止していく 34 日付 対戦チーム 開場前 開始前 試合成立前 試合成立 4/8 中日ドラゴンズ ✖ 7/15 ヤクルトスワローズ 〇 ✖ 8/4 広島カープ 〇 〇 ✖ 8/16 読売ジャイアンツ 〇 〇 〇 〇 払い戻し要否 必要 必要 必要 不要 備考 ５回裏終了 ※　✖：雨天中止が決まったタイミング ※　この成績により「雨男」という称号を獲得 試合の中止を想定
35. ①ユースケース理解を深め、「想定外」を防止していく 35 整理 展開 見解 合議 ユースケース 叩き台は 自分たちが作る 気付きに気付きを重ねていく
36. ①ユースケース理解を深め、「想定外」を防止していく 36 こうした活動を「ユースケース分析」と呼称 ユースケース分析 ユースケース分析書
37. ①ユースケース理解を深め、「想定外」を防止していく 37 PdM QA エンジニア ユースケース分析書 PjM ユーザー 全員（各ステークホルダ）に確認をして頂きユースケースをブラッシュアップ 全員（各ステークホルダ）の成果物に反映
38. ①ユースケース理解を深め、「想定外」を防止していく イ ン ス ペ ク シ ョ ン テ ス ト 設 計 テ ス ト 実 行 テ ス ト 計 画 ユ ｜ ス ケ ｜ ス 分 析 品 質 分 析 サ イ ン オ フ ここまでの活動により、ユースケース分析がQAプロセスに追加 38
39. ①ユースケース理解を深め、「想定外」を防止していく イ ン ス ペ ク シ ョ ン テ ス ト 設 計 テ ス ト 実 行 テ ス ト 計 画 ユ ｜ ス ケ ｜ ス 分 析 品 質 分 析 サ イ ン オ フ 実 利 用 検 証 ここまでの活動により、ユースケース分析がQAプロセスに追加 副産物として「実利用検証」を必要と判断 39
40. ①ユースケース理解を深め、「想定外」を防止していく サインオフ レポート テスト 仕様書イン スペクショ ン 40
41. ①ユースケース理解を深め、「想定外」を防止していく 41 サインオフ レポート 紙チケット の損傷 現地調査 テスト ユースケー ス分析 仕様書イン スペクショ ン デジタルチ ケット発行 ライムラグ 多人数入場 モギリ端末 の電池持ち 実利用調査 41
42. 42 ユースケース理解を深め、「想定外」を防止していく 共通認識を増やし、「行き違い」を防止していく
43. ②共通認識を増やし、「行き違い」を防止していく Q.開発側は、テストをしてくれるのか？ 43
44. ②共通認識を増やし、「行き違い」を防止していく Q.開発側は、テストをしてくれるのか？ A.期待するテストとなるようにQA側で取り計らう 44
45. テスト計画書でテストタイプ毎に調整 ②共通認識を増やし、「行き違い」を防止していく 45 ※〇×はサンプル どんなテストをしてほしいか
46. PFDで開発側のテストタイミングと内容を調整 ②共通認識を増やし、「行き違い」を防止していく 46 いつ・どのような方法のテストをしてほしいか
47. ②共通認識を増やし、「行き違い」を防止していく Q.仕様書は、分かりやすく、充分な内容か？ 47
48. ②共通認識を増やし、「行き違い」を防止していく Q.仕様書は、分かりやすく、充分な内容か？ A.期待する仕様書となるようにQA側で取り計らう 48
49. 仕様書フォーマット ②共通認識を増やし、「行き違い」を防止していく 仕様書ツリー フォーマット ディスクリプション OK ここが気になった→ 仕様書インスペクションで対応 QA見解 仕様書構成 49
50. ②共通認識を増やし、「行き違い」を防止していく ◇課題 　画面仕様書の画面パーツは分かるが、操作可否、可変/固定文言かが読み取れない ◇対策 　画面仕様に、ラベルを埋め込んで頂き、仕様規定する 50
51. もう１個、仕様書フォーマット ②共通認識を増やし、「行き違い」を防止していく 仕様書ツリー フォーマット ディスクリプション OK もう１個、ここが気になった→ 仕様書インスペクションで対応 QA見解 仕様書構成 51
52. ②共通認識を増やし、「行き違い」を防止していく ◇課題 　表記ゆれが、あった ◇対策 　表記の仕様は、一ヶ所で集中管理する 修正前 修正後 本券は、XXX デジタルチケットは、XXX XXXはチケットに記載の通り、 XXXはデジタルチケットに記載の通り、 電子チケット デジタルチケット 52 ＊表記統一のイメージ
53. ①ユースケース理解を深め、「想定外」を防止していく サインオフ レポート テスト 仕様書イン スペクショ ン 53
54. ①ユースケース理解を深め、「想定外」を防止していく サインオフ レポート 紙チケット の損傷 現地調査 テスト ユースケー ス分析 仕様書イン スペクショ ン デジタルチ ケット発行 ライムラグ 多人数入場 モギリ端末 の電池持ち 実利用調査 54
55. ②共通認識を増やし、「行き違い」を防止していく サインオフ レポート テスト ユースケー ス分析 仕様書イン スペクショ ン 仕様書 フォーマッ ト 実利用調査 開発品質向 上合意 Process Flow Diagram 紙チケット の損傷 現地調査 デジタルチ ケット発行 ライムラグ 多人数入場 モギリ端末 の電池持ち 55
56. ②共通認識を増やし、「行き違い」を防止していく Q.テスト項目書は、正しく作られているか Q.ユーザーの期待するプロダクトはどういうものか Q.どの機能から作っていくのか Q.工程終了後の品質基準はどの程度か 　　　　　　　： 　　　　　　　： 56
57. ②共通認識を増やし、「行き違い」を防止していく サインオフ レポート 紙チケット の損傷 現地調査 QA成果物レ ビュー依頼 開発品質向 上合意 ユーザーア ンケート テスト Process Flow Diagram ユースケー ス分析 仕様書イン スペクショ ン 仕様書 フォーマッ ト デジタルチ ケット発行 ライムラグ 多人数入場 電池持ち 実利用調査 57 改善提案
58. 成果 58
59. 成果 59 分類 項目数 不具合数 不具合率 備考 QAテスト （結合・総合） 1593項目 80件 5.0% 新規プロダクト平均 ＜見積もり＞ ＜　実績　＞
60. 成果 60 分類 項目数 不具合数 不具合率 備考 QAテスト （結合・総合） 1593項目 80件 5.0% 新規プロダクト平均 分類 項目数 不具合数 不具合率 備考 QAテスト （結合・総合） 1593項目 32件 2.0% QAでの検出 受入テスト 6人日 0件 0.0％ YDB/QAで実施 本番環境 - 0件 0.0％ ファンフェスで実証実験 ＜見積もり＞ ＜　実績　＞
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件 ２４件 ５件 ピーク

62. 成果 62 レイリーモデルに当てはめて、少し「シフトレフト」出来たと仮定して、 取り組み効果を算出をしていく 上流工程から頑張ったので、 サンプルのc=2.5→2.0と仮定
63. 成果 63 基 本 設 計 詳 細 設 計 コ ー デ ィ ン グ 単 体 テ ス ト 結 合 テ ス ト シ ス テ ム テ ス ト 本 番 基本設計 32件 詳細設計 76件 コーディング 76件 単体テスト 51件 結合テスト 24件 システムテスト 8件 本番 2件 合計 269件 QAで検出せずに済んだ 235件 QAで検出した 32件 QAで見逃した （見つかっていない） 2件 今回、結合テスト・システムテストでの不具合数は32件 ピークは、コーディング工程の少し前（C=2.0）と仮定 ここから逆算すると、不具合269件が内在した開発であることが分かる ８件
 ２４件
 ピーク

64. 成果 64 もし、不具合数が同一で、検出ピークが「結合テスト」と仮定 本番不具合：２件 本番不具合：３０件 ピーク ピーク 基 本 設 計 詳 細 設 計 コ ー デ ィ ン グ 単 体 テ ス ト 結 合 テ ス ト シ ス テ ム テ ス ト 本 番
65. 65 次につなげる
66. 今後のために 66 QA 昔 今 今後も、早期に声掛けを頂ける関係性を築きたい
67. 今後のために 67 サインオフ＆振り返り • 参加者は広めに、高めに • 経緯、結果に対してフィードバックを頂く 全員の責任で、リリースを行う QAのプレゼンスも高める
68. 今後のために 68 改善提案 • 最初か、サインオフ後に改善提案を行う • 改善提案は、改善活動の「きっかけ」作り • なるべくイメージ感が伝わるようなビジュアルで
69. 69 おわりに
70. おわりに 70 品質のために手段を追求
71. 早期参画 おわりに 71 ←効果のある手段が望ましい QA目線の 供給 品質の 安定 良い 振り返り
72. 品質のために手段を追求 72 • QAの完成系は無い ◦ だからこそこれからも手段を追求して、品質を全員で高めていきたい