リスクを見分けるために意識していること #QaaS

QA engineer at a Startup vol.22 の発表資料です。
https://qaengineeratastartup.connpass.com/event/373950/

Transcript

1. リスクを見分けるために意識していること テックタッチ株式会社 QA エンジニア Michiya Maki QA engineer at a Startup vol.22 2025/11/17
2. やきとりが焼ける QA エンジニア 自己紹介 巻　宙弥（まき　みちや） デジタル名刺 “ 馬と桜のまち” 、北海道新ひだか町出身 テックタッチ株式会社のQA エンジニア 札幌のコワーキングスペースと自宅、7:3 でフルリモート勤務中 QA コーチとしてチーム＆プロジェクト横断でQA 活動中
3. 自己紹介 JaSST Hokkaidoの実行委員として、テスト技法に関するワークショップを担当 ASTER会員としてDEOS主催のテスト技法の研修講師を担当 JaSST：Japan Symposium on Software Testing 、NPO法人ASTER （ソフトウェアテスト技術振興協会）が運営するソフトウェア業界全体のテスト技術力の向上と普及を目指すソフトウェアテストシンポジウム DEOS：北海道ソフトウェア技術開発機構、ITプロフェッショナルの育成を目的として、国、北海道、札幌市、民間の出資により設立 社外活動 https://jasst.jp/hokkaido/ JaSST’26 Hokkaidoも ☆絶賛企画中☆
4. 2005 2012 2019 SE （ほぼ客先常駐） SE / マネージャー （ほぼ自社で受託開発） IT コンサルタント （ほぼ客先常駐） IT コンサルタント （リモート） QA エンジニア （フルリモート） 2023 受託開発、第三者検証を経てスタートアップのQA エンジニアに 経歴 SE ？（システムエンジニア） システム開発において要件定義や設 計、開発などを担うエンジニアの総称 我流の品質知識をアップデートしたく第三者 検証のテスト専門会社に転職 コロナで周囲の環境に大きな変化が起きて リモート主体の働き方が必要になる IT コンサルタント？ 企業のIT 戦略やシステム導入を支援 し、課題解決を行う専門家 フルリモートでプロダクトにコミットでき るスタートアップのQA エンジニアに転職 QA エンジニア？（Quality Assurance ） プロダクトの品質を仕組みで支えるエ ンジニア
5. 本日話すこと 1. プロダクトと体制のお話 2.QA コーチとは？ 3. リスクを見分けるために工夫していること 4. まとめ
6. 1. プロダクトと体制のお話
7. テックタッチとは Webシステム画面上で操作に合わせてナビゲーションを表示する デジタルアダプションプラットフォーム（DAP）※ ※新たに利用するビジネス・アプリケーションやWebシステムなどの利用の定着を支援する製品・サービスのこと。 ブラウザ拡張を インストール ScriptをWebサイトに 埋め込む ノーコードで ガイダンスを実装
8. 開発体制 専門領域毎のチーム体制で開発 QAは各チームと協業してプロダクト・プロセスの品質を支える
9. テスト テスト テスト プランニング テストを推進 ロードマップ策定 QAはプランニングから参加 開発プロセス スクラムをベースとしたプロセス 開発に関わるメンバーが一体となって進行
10. リリース 機能開発 統合 テスト 機能開発 機能開発 プロダクトオーナー・デザイナー・エンジニア・QAが一体となって進める 要求・要件定義 開発フェーズ 開発に関わるメンバーが一体となって進行するプロセス リリース直前に各機能開発を統合したテストを実施 リリースサイクル は約3ヶ月
11. 2. QA コーチとは？
12. テックタッチのQA 引用）品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版） https://www.slideshare.net/slideshow/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties/249498558 P3 インプロセスQAとQAコーチ、QAプロジェクトマネージャで構成 QAファンネルを参考に役割を定義 イメージです
13. インプロセスQA 引用）品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版） https://www.slideshare.net/slideshow/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties/249498558 P3 チームと併走してテストプロセスを実践するインプロセスQA 立ち上がったプロジェクトにQAチームからアサイン
14. QA コーチ 引用）品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版） https://www.slideshare.net/slideshow/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties/249498558 P3 特定チームに属さず、チーム横断に品質をマネジメントするQAコーチ テスト技術のレクチャ、テストプロセスやテストウェアのレビューを行う
15. Mickey の業務 引用）品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版） https://www.slideshare.net/slideshow/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties/249498558 P3 テストの仕組みづくりや品質マネジメントの実践、関連ノウハウの共有が中心 時にはインプロセスQAとして動くこともある QA内外へのソフトウェアテストのノウハウ共有（例：テスト設計の技術向上） QAプロジェクトマネージャ として動くことも イメージです
16. 3. リスクを見分けるために工夫していること
17. まず、おさらい
18. リスクとはなにか？
19. リスクとはなにか？ 顕在化すると悪影響をもたらす潜在的な事象、ハザード、または脅威のこと 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf 目的に対する不確かさの影響 引用）ソフトウェア品質知識体系ガイド （第3版） －SQuBOK Guide V3－ 不確実なイベントや状態で、発生すると プロジェクトの目標にプラスまたはマイナスの影響を与える可能性があるもの 引用）プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版 目的を達成しようとする過程で 想定外のことが起きて、結果に影響を与える可能性 リスクという言葉はよく使われますが、本発表では以下のように捉えています。
20. プロジェクト リスク プロダクト リスク リスク？ リスク リスクには2 つの側面がある。
21. プロジェクトリスクとは プロジェクトの目的を達成する能力に影響を与える可能性がある。 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf 要件の増加 スケジュール遅延 コスト増加 リスク要因 影響
22. プロダクトリスクとは 以下のようなさまざまな負の結果をもたらす可能性がある。 ⚫ ユーザーの不満足 ⚫ 収益、信頼、評判の損失 ⚫ 第三者への損害賠償 ⚫ メンテナンスコストが高い、ヘルプデスクに負荷がかかる ⚫ 刑事罰 ⚫ 極端な場合、身体的な損傷、重傷、または死に至ることもある 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf 機能不足 不十分な応答時間 使いづらさ 脆弱性
23. リスクを見つけるために
24. リスクを見つけるために工夫していること リスク共有会 QA プランニング テストスクラム 不具合分析 （時間があれば）生成AI の活用 テックタッチのQAコーチとして推進し、 特に注力している取り組みを紹介します。
25. リスク共有会
26. プランニング テスト設計 実行結果 確認 テスト設計 レビュー ドキュメントデータベース テスト実装 テスト実行 テスト完了 テストプロセス リスク共有会（2週間に1回実施） データベースは プロジェクト毎に 自動作成 レビュー結果 テスト結果 機能性・使用性・テストプロセスに影響を与える可能性はあるか？ リスク共有会（プロダクトリスクを見分ける会） QAチーム内のドキュメントデータベースに情報を集約。 事前にテストベース、テストウェアを収集し、リスクを共有する。 テストベース テストウェア 共有 共有 共有 共有 リスク対処 リスク対処 リスク対処 リスク対処
27. プランニング テスト設計 実行結果 確認 テスト設計 レビュー ドキュメントデータベース テスト実装 テスト実行 テスト完了 テストプロセス リスク共有会（2週間に1回実施） データベースは プロジェクト毎に 自動作成 レビュー結果 テスト結果 機能性・使用性・テストプロセスに影響を与える可能性はあるか？ リスク共有会（プロダクトリスクを見分ける会） QAチーム内のドキュメントデータベースに情報を集約。 事前にテストベース、テストウェアを収集し、リスクを共有する。 テストベース テストウェア 共有 共有 共有 共有 リスク対処 リスク対処 リスク対処 リスク対処 次テストへ 申し送り 探索的テスト 実施 テスト追加 因子・水準 追加
28. リスク共有会 リスク共有会で発表するタイミング 何かしらのテストベース/テストウェアがある テストウェアが共有できる状態 共有できるプロダクトリスクを認識している 進行の流れ 担当者からテストベース/テストウェアを説明する 資料の読み込み時間を確保 リスクの共有/リスクに対するアクションの決定 （プロダクトリスクを見分ける会） プロジェクトに直接関与していない メンバーから気になるポイントをブレスト
29. リスク共有会 プロジェクト名 テストベース テストウェア リスク共有会アジェンダ 開発資料 要求・要件定義書 テスト計画書 テスト設計書 事前に検知しているリスクなど 当日メモランダム プロジェクト名 プロジェクト名 プロジェクト名 プロジェクト名 プロジェクト名 プロジェクトの属性（プロパティ） プロジェクトの属性（プロパティ） プロジェクトの属性（プロパティ） プロジェクトの属性（プロパティ） プロジェクトの属性（プロパティ） トレーサビリティを確保する目的で、 テストベース・テストウェアへのリンクや、 事前に検知しているリスクなどの情報を集約 （プロダクトリスクを見分ける会） Notionデータベースのテンプレート
30. QA プランニング
31. プランニング 設計・実装・単体テスト ツール テスト （コンポーネントテスト、インテグレーションテスト） 統合テスト 開発フェーズ QAプランニング（1週間に1回実施） プロジェクト 完了 リリースサイクルに影響を与える可能性はないか？ QAプランニング（プロジェクトリスクを見分ける会） 目的に合わせ、ツールを活用、事前に定量・定性情報を収集＆報告し、 リスクの有無をモニタリングする。 開発状況 リソース状況 共有 リスク対処 リスク対処 テスト状況 リソース状況 共有 共有 リスク対処 プロジェクト状況 リソース状況
32. プランニング 設計・実装・単体テスト ツール テスト （コンポーネントテスト、インテグレーションテスト） 統合テスト 開発フェーズ QAプランニング（1週間に1回実施） プロジェクト 完了 目的に合わせ、ツールを活用、事前に定量・定性情報を収集＆報告し、 リスクの有無をモニタリングする。 シフトレフト リソース追加 スケジュール調整 リリースサイクルに影響を与える可能性はないか？ QAプランニング（プロジェクトリスクを見分ける会） 開発状況 リソース状況 共有 リスク対処 リスク対処 テスト状況 リソース状況 共有 共有 リスク対処 プロジェクト状況 リソース状況
33. QAプランニング リリースバージョン プロジェクト名 （プロジェクトリスクを見分ける会） マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL リリースバージョン プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト毎に QAに関わるマイルストーンに対する プロジェクトリスクを共有
34. ResourceSummary Cycle 週 担当者 非稼働時間 稼働時間 予定作業時間 Capacity 稼働率 97 2025/7/30 担当A 0 67.5 60.75 6.75 90.00% 97 2025/7/30 担当B 0 67.5 28.5 39 42.00% 97 2025/7/30 担当C 7.5 60 22 38 36.00% 98 2025/8/13 担当A 0 75 16.75 58.25 22.00% 98 2025/8/13 担当B 7.5 67.5 18 49.5 26.00% 98 2025/8/13 担当C 17 50.5 0 50.5 0.00% Resource A Cycle 日付 非稼働時間 稼働時間 テストプロセス 改善活動 MTG その他 予定 Capacity 100 2025/9/5 7.5 4.25 2.25 1 7.50 h 0.00 h 100 2025/9/6 7.5 0.00 h 0.00 h 100 2025/9/7 7.5 0.00 h 0.00 h 100 2025/9/8 7.5 2 0.25 2.25 h 5.25 h 100 2025/9/9 7.5 3 0 1 0.5 4.50 h 3.00 h 101 2025/9/10 7.5 2 1.75 1 4.75 h 2.75 h QAプランニング（プロジェクトリスクを見分ける会） 週次でQA担当者の リソース状況を可視化 担当予定の 工数内訳を集約
35. テストスクラム
36. テストスクラムとは？ QA と開発者が協力し、共にテストについて考え、 手動テストの負荷を抑えながら継続的に品質を作り込む施策。
37. 仕様策定 プランニング テストリスト 実行結果 レビュー テスト分析・設計 テスト実装 自動テスト 実行 テストリスト レビュー 運用 開発者 QA テスト実装 テスト実装 手動テスト 実施 テストスクラムのプロセス テストを自動テストとして作り切るまでの一連の流れを実現 連携 参照 通常のテストプロセス
38. ユニットテスト テストスクラムのスコープ コンポーネントテスト インテグレーションテスト E2E テスト UI を必要としないロジックのテスト UI コンポーネントを対象としたテスト バックエンドAPI はモック、それ以外は実際の動作環境と同じ 実際に動作するバックエンドAPI 使ったテスト 例）バリデーション処理（文字種、形式チェックなど） 例）入力の境界値、エラーメッセージ表示など 例）状態遷移、API のエラーケース、意図しないデータパターンなど 例）ユースケーステスト、設定や権限など前提条件を含んだ動作確認 テストスクラムのスコープはコンポーネントテスト
39. テストリストとは？ UI コンポーネントを対象としたテストをリスト化 自動テストの可否をマーキング テスト管理ツールへの関連付け レビューコメントを記録 テストリスト
40. 半年間のトライ・アンド・エラーの結果 手動テストを6 割削減（130 件中80 件） 手動テスト開始までに検出された不具合の増加 開発者がテストリスト作成中に不具合を検出 テスト分析後にハイレベルテストケースで探索的テストを実施 テストの分類により自動化できるコンポーネントテストが明らかになった 開発中に確認されるテストを、手動テストとして設計する必要がなくなった
41. 不具合分析
42. 不具合分析 テストレポートの作成 不具合の分類項目を定期的に収集 リリースバージョン毎にプロダクトリスクを検討 今後）生成AI で定量分析を半自動化したい
43. テストレポートに不具合の状況を掲載
44. 不具合分析 不具合に関する情報を地道に収集し続ける 毎週リマインドを実施 担当を明確にし 入力を働きかける
45. テストレポート作成の過程でリスクの最小化を図る 潜在している不具合を検出 追加のテストを検討 リリースサイクル毎に 作成、共有 不具合が期待値どおり 検出できているか？ 検出すべき テストレベルが低い 不具合がないか？
46. 4. まとめ
47. プロジェクト リスク プロダクト リスク まとめ 変化の激しい時代、QAは不確実な「〜かもしれない」という予測に向き合うことが大事だと思いま す。そのためには、リスクを見逃さず、適切にリスク対処することが大事です。 テックタッチではリスクを「プロジェクトリスク」と「プロダクトリスク」にわけ、 紹介した工夫により見分けやすくしています。 開発チームと早期にリスクを共有し、早い段階から品質に向き合えるようにアプローチしてきました。 本日の内容が、皆さまの現場において、何かしらのヒントになれば幸いです。
48. 「〜かもしれない」を現実にしない ためにあらゆる事を行う QAコーチの日常 それが
49. ご清聴ありがとうございました ご清聴ありがとうございました ☆絶賛カジュアル面談受付中☆ 続きはWebで→
50. Appendix.
51. 生成AI の活用
52. 仕様策定 プランニング テストリスト 実行結果 レビュー テスト分析・設計 テスト実装 自動テスト 実行 テストリスト レビュー 運用 開発者 QA テスト実装 テスト実装 手動テスト 実施 問題解決に生成AI を活用し “ よう” 生成AI の活用 テストリスト作成からテスト設計の作成支援に活用（したい） 連携 参照 通常のテストプロセス
53. 生成AI の活用例（レビュー） テストリストから状態遷移図、因子・水準を抽出 一般的な仕組みとのギャップや、 意図したテストアプローチとのギャップを確認し、 テスト分析・設計に活用 生成AI の活用
54. 生成AI の活用例（Ask Devin ） ソースコードから考慮すべきエラーケースを導出 設計されたエラーケースをコードベースで確認し、 インテグレーションテストの過不足をチェック 生成AI の活用
55. 仕様策定 プランニング テストリスト 実行結果 レビュー テスト分析・設計 テスト実装 自動テスト 実行 テストリスト レビュー 運用 開発者 QA テスト実装 テスト実装 手動テスト 実施 テストスクラムの問題 ドキュメンテーションに関わるプロセスに負担 連携 参照 通常のテストプロセス ドキュメントの変更管理が大変 上位ドキュメントとの重複で冗長に 案件によってテストリスト作成の向き不向きがある テスト設計の作成＆レビューの難易度が高くなった
56. 仕様策定 プランニング テストリスト 実行結果 レビュー テスト分析・設計 テスト実装 自動テスト 実行 テストリスト レビュー 運用 開発者 QA テスト実装 テスト実装 手動テスト 実施 ドキュメンテーションのプロセスを効率化 テストリスト作成 及び テスト設計書のベースを生成AI で作成・汎化したい 連携 参照 通常のテストプロセス 生成AI の活用
57. 用途毎にGems を作成＆公開 地道に個人で試したプロンプトからGems を作成＆公開 生成AI の活用
58. 生成AI 活用ポータルで情報収集 テストプロセス毎の生成AI 関連情報を集約
59. 会社概要
60. 会社概要
61. サービスの活躍の場 2025年6月時点、弊社調べ、MAU換算