QAについて 今日話したいこと・考えたいこと

Transcript

1. スマレジ x KDDIアジャイル開発センター meet up みんなで考えるQA・テストの関わり方 QAについて 今日話したいこと・考えたいこと 2026.8.27. THU 福⽥ ⿓宙｜ Tatsuoki Fukuda 株式会社スマレジ 開発本部 品質管理チーム（QA）
2. ⼀先ず...昨⽇じゃなくて良かった、、
3. ⾃⼰紹介 福⽥ ⿓宙 ｜ Tatsuoki Fukuda 株式会社スマレジ 開発本部 品質管理チーム（QA） 経歴 パーソナル 受託のWeb系 (東京) 出⾝ PHP開発 2年 / テスター 3年 作る ⇒ 触る‧知る...へ 愛知県 海部郡 蟹江町 印刷会社 (福岡) お酒 / ⾟い料理 / 電⼦⾳楽 / DJ 野球(阪神) / ⽔曜どうでしょう PM / 保守運⽤ + QA 5年 お客さんの近くで関わりたい！ スマレジ (福岡) 2025年 3⽉⼊社 QA 1年半 最近は採⽤、イベント企画も プロダクト愛を極めたい！ 好きなもの 苦⼿なもの 梅⼲し / 冷房の⾵ 性格 たぶん優しい
4. 初のイベント企画！！ ‧【2025.03】スマレジに⼊社して「LT」というワードを初めて知る。 ‧【2025.04】イベントに参加し始める。コミュニティの⾯⽩さに惹かれる ‧【2025.12】LTに初登壇（いつか⾃分でも主催したいな〜思うように） （ちょっと冬眠、、） ‧【2026.04】KAGさんと出会う。イベント開催に向けて動く ‧【2026.07〜08】⾊々LTにも登壇 ‧【2026.08.27】ついに今⽇QAイベントを開催！！！
5. スマレジ x KDDIアジャイル開発センター meet up みんなで考えるQA・テストの関わり方 QAについて 今日話したいこと・考えたいこと 2026.8.27. THU 福⽥ ⿓宙｜ Tatsuoki Fukuda 株式会社スマレジ 開発本部 品質管理チーム（QA）
6. なんでこのタイトルにしたのか？ QAについて 今日話したいこと・考えたいこと ‧中々多くない福岡でのQAイベント最初のLT ‧ネタが浅く広く浮かびすぎて収集付かなくなった...
7. なんでこのタイトルにしたのか？ QAについて 今日話したいこと・考えたいこと ‧中々多くない福岡でのQAイベント最初のLT ‧ネタが浅く広く浮かびすぎて収集付かなくなった...
8. なんでこのタイトルにしたのか？ QAについて 今日話したいこと・考えたいこと ‧中々多くない福岡でのQAイベント最初のLT ‧ネタが浅く広く浮かびすぎて収集付かなくなった... ‧この後のパネルディスカッションや懇親会に繋がる ガイダンス的なLTにしよう！
9. QAについて 今⽇話したい‧考えたいこと 💬 問いかけ 🏢 スマレジのQAチーム 1. QA‧テストとは？ 3. QAチームの課題と⽬標 2. 良い品質のプロダクトは？ ✨ 魅⼒と楽しさ 4. QAの何が⾯⽩い？楽しい？
10. このあと パネルディスカッション 懇親会もありますので 今日話したい・考えたいこと 1. QA・テストとは？
11. QA‧テストとは？ QA Quality Assurance：品質保証 テスト ≒ QC (Quality Control：品質管理) 悪いものが出ない「仕組み」を作る 悪いものが無いか「確かめる」 • 予防的なアプローチで、プロセス全体の品 質を担保する • 実際に動かして、バグや不具合を検出する 💡 因みに「品質」とは？ ユーザーが期待する条件や基準をどれくらい満たしているか？ 単にバグがないだけでなく、ユーザーの満足度や期待に応える度合いも指します。
12. QA‧テストとは？ QA：Quality Assurance 項⽬ テスト ≒ QC：Quality Control ⽇本語 品質保証 品質管理 主な⽬的 良い品質を作れる仕組みをつくる 作られたものの品質を確認‧管理する 対象 プロセス‧組織‧プロダクト全体 主に成果物‧プロダクト 活動時期 企画〜開発〜リリース〜運⽤まで 主に開発‧製造されたものに対して 代表的な活動 開発プロセス改善、品質基準策定 レビュー、品質戦略など テスト、検査、不具合検出、品質測定など 考え⽅ 予防的 検出的‧是正的 ただし、各々の定義は会社によって異なっていたりもするのでは？
13. QA‧テストとは？（リリースサイクルで⾒ると） 本来のQAは、開発プロセスのすべてのフェーズへ主体的に関わることが出来る！      要件定義 設計 実装 テスト リリース 上流⼯程からの品質視点の 注⼊ テストの容易性を考慮した 設計レビュー ⾃動テストの実装と継続的 検証 ユーザー価値に基づいた最 終的な品質確認 サービス公開とリリース後 品質の監視 ただし、活動範囲は会社によって異なっていたりするのでは？ ‧‧‧皆さまの現場では如何でしょうか？
14. このあと パネルディスカッション 懇親会もありますので 今日話したい・考えたいこと 2. 良い品質のプロダクトとは
15. 良い品質のプロダクトとは？  バグの件数が少ない  ユーザーが喜ぶ  ステークホルダーが満⾜  障害が後から起きない  内部品質が良い (コードが整理されている)  費⽤対効果が⾼い  チーム体制が整っている（開発‧QA‧営業）  みんなが定時で帰れる🍻 こうやってみると色々あるなあと思います。 (これも⼤事！！！)
16. 良い品質のプロダクトとは？ プロダクトの種類で⾒てみると。 Webアプリ ⾦融‧決済システム ⾃動⾞‧医療機器 • 使いやすさ • 正確性 • 安全性 • 応答速度 • 可⽤性 • 信頼性 • 変更のしやすさ • セキュリティ • 故障しにくさ ⇒ 使いやすい‧速い‧楽しい ⇒ 間違えない‧⽌まらない ⇒ 安全‧確実に動く 求められる品質の定義は、そのプロダクトの「⽬的」によって形を変えます。 ‧‧‧皆さまのところは如何でしょうか？
17. 良い品質のプロダクトとは？（私にとって）  チーム体制が整っている（開発‧QA‧営業） 例）ユーザーの期待とビジネス⽬標を話す  ⾜並みを揃えて同じ⽅向を向く • 開発‧QA‧営業の全メンバーで！ • 「ユーザー期待」と「ビジネス⽬標」を対話 ⇒ その後の開発⼯程での⼿戻りがない ⇒ リリース後も思い描いた通りになるのでは？ 良く無さそうな体制  ⾜並みが揃わず、対話ができない • 上の⼈間が丸投げするケース 現場に⽅針が共有されず、意思決定が機能しない • 誰が主導か分からないケース 責任領域が曖昧で、各部⾨が混乱する 「MTGしてみたけど、そのあと動きがな い、、、」 【極端な話】スタートの体制は、ゴールの品質につながるのでは！
18. このあと パネルディスカッション 懇親会もありますので 今日話したい・考えたいこと 3. スマレジのQAチーム 課題、目指すところ
19. スマレジのQAチームについて 👥 チーム構成‧環境 📱 担当プロダクト 拠点内訳 全50以上のプロダクト ‧⼤阪：18名 （主任3、パート1、委託1） スマレジPOS、Timecard、Waiterアプリ.. ‧福岡：2名 気づけば全部で50超え （プロダクトにより対応の頻度は異なる） チーム連携 ‧毎朝、オンラインMTGで顔合わせ ‧Slackでも常に連絡出来る環境
20. スマレジのQAチームの仕事 🤖 技術的な取り組み ✅ プロダクトのテスト AI活⽤ • QAの2週間〜2ヶ⽉前 ‧営業からユーザの要望や問い合わせを聞く。 ‧対応⽅針やスケジュールを決める（営業‧開発‧QA） • QA前週の後半 ‧次週のQA担当が、正式にアサイン ‧改めて仕様を確認。テスト分析/設計も ‧開発からデプロイ完了(テスト環境)の連絡 Codex、NotebookLM 等 テストプロセス（設計‧実施）の⾃動化を推進中。 💡 新規プロダクトの仕様決め‧改善提案 ‧上流からプロジェクトに参画。 ‧要件を聞いて、テスト⼯数や観点の洗い出し。 • ⽉〜⾦（5営業⽇） ‧テスト分析/設計/実⾏（テスト環境） ‧開発やQAとコミュニケーション取りながら • 翌週より後 ‧リリース後の本番確認（⽕〜⽔） ‧バグ集計 ‧開発との振り返り会 💼 プロセス改善 ＆ 組織作り ‧QAプロセスや、組織改善MTGの推進。 ‧書類選考や⾯接などの採⽤も
21. QAの業務フロー（要望からリリース後まで） ① QAの2週間〜2ヶ⽉前 ② QA前週の後半 ③ ⽉〜⾦（5営業⽇） ④ 翌週より後 STEP 01 STEP 02 STEP 03 STEP 04 要望を聞く‧調整 アサイン‧準備 テスト実⾏ 本番リリース‧振返り [チーム全体MTG] ‧次週のQA担当が決まる ‧テスト分析‧設計 ‧営業から要望を聞く ‧仕様を把握する ‧テスト実⾏ [⽕〜⽔曜] ‧リリース後の本番確認 ‧スケジュールを決める （開発‧テスト） ‧テスト分析‧設計 ‧不具合 -> 開発に報告 修正 -> 再び⾒る ‧開発がデプロイ完了 テスト出来る状態に。 ‧全体の影響確認 （リグレッションテスト） ‧テスト完了/リリースOK [その後...] ‧開発との振り返り会 ‧バグ集計 ‧ナレッジを追記
22. スマレジQAチームに出てる課題 ⚠ AI開発に沿わねば 🤖 AI活⽤⽅法が個別 🔑 上流⼯程への道のり... ▲ 圧倒的なプロダクト数 ▲ 各々個別のやり⽅に... ▲ コミットメントの遅れ ‧18名に対して50プロダクト ‧CodexやNotebookLM個別で探りな がら導⼊している段階。 ‧仕様決めや改善提案などの上流⼯程 に、⼗分な介⼊とは⾔えない。 ▼ AIによる開発加速への追従 ▼ 組織レベルでの活⽤するには ▼ テスト実⾏に追われない為には ‧開発スピードが爆速化する中、 QAはどう付いていくか？ ‧成果の出るAI活⽤をチーム全体へど う統⼀化‧展開するか？ ‧下流のテスト分析‧設計‧実施の負 荷をどう軽減していくか？ （プロダクトによってリリース頻度は 異なる...） 直近⽬指すところ‧‧‧‧ 【QAチーム】QAが開発サイクルのボトルネックにならないこと
23. QAが開発サイクルのボトルネックにならない為の今後の対策 🤖 QAチームで的確なAI活⽤を 🎯 リスクベースドテストの導⼊ 💻 チームが共通で使えるリポジトリを構築 🔍 リスクが⾼い部分に重きを置く ‧属⼈化を防ぐ、全体で共有‧利⽤する ‧リスク分析、テスト設計‧実⾏にフォーカス ‧全領域を網羅しない ‧影響度や頻度が⾼いコア機能へリソースを集中投下 ‧AIによるリスク分析が判断材料に 📟 ⾃動テストの拡充 ‧テスト⾃動化の仕組みを開発プロセスに
24. QAチームで的確なAI活⽤を ▪ チーム共通のAI基盤を構築 ▪ AIが担うプロセス AIの精度を最⼤化する AI基盤を活⽤した⾃動化‧最適化 ① テスト観点‧設計ルール • - 何をどうテストするのか？ ② 品質基準‧判定基準 - 何をリスクと捉え、どう判断するのか？ リスク分析 ◦ ④をもとに評価 • テスト設計 • テスト実⾏ ③ プロダクトのドメイン知識 - 仕様‧⽤語‧どこで利⽤されるか？ ④ 過去あった不具合の履歴 - これまでの失敗や経験を次のテストに活かす ※ソースコードと同じでver管理する 💡 AIにルールや知識を蓄える ⇒ リスク分析〜テスト実⾏まで⾏う。
25. リスクベースドテストの導⼊ 緊急/最⾼ ⾼リスク 中リスク 低リスク 影響度と発⽣確率の組み合わせで「どこをメインでテストするか」を判定 🎯 なぜ導⼊するのか 単なる⼯数削減だけでなく 重要領域を可視化する。 影響度 (IMPACT) 重点検証 最重点テスト 即時対応‧ブロック 異常系‧リカバリ確認 シナリオ‧境界値‧⾃動化 全⼿法を集中投与 基本確認 標準テスト 優先検証エリア 主要パステストのみ 標準ケース‧回帰テスト ⾼頻度利⽤‧UX‧負荷 最⼩限 / 省略可 簡易確認 条件付きテスト 探索的‧アドホック確認 表⽰‧レイアウトチェック 頻出する軽微バグの防⽌ 📊 リスクの判断材料 • AIによるリスク分析 過去の不具合を分析し、潜在バ グを特定。 • ドメイン知識の活⽤ ユーザーの利⽤頻度や、不具合 発⽣時の費⽤対効果を加味。 …ここは⼈間の⼒が重要 発⽣確率 (PROBABILITY)
26. 私の⽬標はその後の「シフトレフト」実現 🤖 QAチームで的確なAI活⽤を ‧チーム共通のAI基盤：知識の構造化と再利⽤ ‧⾃動テスト拡充：継続的な実⾏プロセス化 🚀 上流⼯程へのアプローチ 真のQAに進化するチャンス ‧仕様決めや設計段階（上流）からQAが参画 ‧ビジネス視点、ユーザー理解に沿った品質提案 ‧全員で最初から品質を育てる！ 🛠 リスクベースドテストの導⼊ 2. リスクベースドテストの導⼊ 🎯 ‧リスクが⾼い部分に重きを置く ‧コア領域へのリソース集中投下による最適化 💡 ⾃動化‧AI化でリソースを空け、【QA】の真価を上流⼯程で発揮する
27. このあと パネルディスカッション 懇親会もありますので 今日話したい・考えたいこと 4. QAの何が面白い？楽しい？ 明るい話もしたい...
28. QA‧テストの何が⾯⽩い？楽しい？ 🔍 探求と発⾒のオモシロさ 🚀 プロダクト成⻑とコラボレーション テストの⾯⽩み 品質向上とチームのやり取り • バグを⾒つけたときの「⾒つけた！」感 • ⾃分の指摘でプロダクトが少し良くなる実感 • そんな使い⽅する！？を考える楽しさ • 開発と「あーでもない、こーでもない」と議論 • 「誰もやらんやろ」という操作ほどやりたくなる • ユーザー‧開発‧ビジネスの視点を廻ったり • 最近では採⽤で⾊んなQAと出会えたり 笑いながら話したいです（＾＾）
29. このあと パネルディスカッション 懇親会もありますので 今日話したい・考えたいこと ①～④のまとめ
30. まとめ：QAについて、今⽇話したい‧考えたいこと 💬 問いかけ 🏢 スマレジのQAチーム ① QA‧テストとは？ ③ QAチームの課題と⽬標 ‧皆さんの定義は何ですか？ ‧ボトルネックにならないこと ② 良い品質のプロダクトは？ ‧私は「チーム体制の良さ」 - チームで適切なAI活⽤ - リスクベースドテスト ‧私は「上流へのシフトレフト」 ✨ 魅⼒と楽しさ ④ QAの何が⾯⽩い？楽しい？ ‧探求と発⾒の⾯⽩さ ‧プロダクトの確かな成⻑ ‧開発チームとの深い議論 ‧QAの採⽤