Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

事業ポートフォリオ 3

Slide 4

Slide 4 text

事業ポートフォリオ 4

Slide 5

Slide 5 text

事業ポートフォリオ

Slide 6

Slide 6 text

事業ポートフォリオ QC1G QC2G

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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


Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

実例紹介 16

Slide 17

Slide 17 text

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


Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

①ユースケース理解を深め、「想定外」を防止していく 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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

成果 58

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

成果 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件 ２４件 ５件 ピーク


Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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


Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

65 次につなげる

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

69 おわりに

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

73