スタートアップの現場で実践しているテストマネジメント テックタッチ株式会社 QA エンジニア Michiya Maki JaSST'25 Kyushu 前夜祭 2025/10/23 

自己紹介 やきとりが焼ける QA エンジニア 巻　宙弥（まき　みちや） “ 馬と桜のまち” 、北海道新ひだか町出身 Saas スタートアップのテックタッチにフルリモートで勤務中 QA コーチとして、開発とQA 横断の仕組みづくり 専門領域はテストマネジメント 「やきとり」が大好き # 札幌串打同盟 で 力作をポストしてます 社外活動 JaSST Hokkaidoの実行委員として、テスト技法に関するワークショップを担当 ASTER会員としてDEOS主催のテスト技法の研修講師を担当 プロジェクトマネジメントのSaas「Backlog」のユーザーコミュニティ運営 デジタル名刺はこちら→ JaSST：Japan Symposium on Software Testing 、NPO法人ASTER （ソフトウェアテスト技術振興協会）が運営するソフトウェア業界全体のテスト技術力の向上と普及を目指すソフトウェアテストシンポジウム DEOS：北海道ソフトウェア技術開発機構、ITプロフェッショナルの育成を目的として、国、北海道、札幌市、民間の出資により設立 

2005 2012 2019 SE （ほぼ客先常駐） SE / マネージャー （ほぼ自社で受託開発） IT コンサルタント （ほぼ客先常駐） IT コンサルタント （リモート） QA エンジニア （フルリモート） クライアントの比率 2023 クライアントとは？ 労働力（≒価値）の提供先 受託開発、第三者検証を経てスタートアップのQA エンジニアに 経歴 SE ？（システムエンジニア） システム開発において要件定義や設 計、開発などを担うエンジニアの総称 我流の品質知識をアップデートしたく第三者 検証のテスト専門会社に転職 コロナで周囲の環境に大きな変化が起きて リモート主体の働き方が必要になる IT コンサルタント？ 企業のIT 戦略やシステム導入を支援 し、課題解決を行う専門家 フルリモートでプロダクトにコミットでき るスタートアップのQA エンジニアに転職 

本日話すこと 引用：https://jasst.jp/kyushu/25-about/ 現場で実践しているテストマネジメント デジタル名刺はこちら→ 

とつぜんですが 

テストマネジメントとは？ 

テスト戦略の定義、テスト活動の計画、 進捗のモニタリングとコントロール、結果の報告、 リスクや課題のマネジメントを含め、 プロジェクトの目的やステークホルダーのニーズと 整合させながらテスト全体を統括すること。 参考）JSTQB-Syllabus.Advanced_TM_VersionV3.0.J01.pdf 

なんのために？！ 

リスクを見つけて対処するため 

ちょっとおさらい 2 つのリスクって？ 

リスクとはなにか？ 顕在化すると悪影響をもたらす潜在的な事象、ハザード、または脅威のこと 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf 目的に対する不確かさの影響 引用）ソフトウェア品質知識体系ガイド （第3版） －SQuBOK Guide V3－ 不確実なイベントや状態で、発生すると プロジェクトの目標にプラスまたはマイナスの影響を与える可能性があるもの 引用）プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版 目的を達成しようとする過程で 想定外のことが起きて、結果に影響を与える可能性 リスクという言葉はよく使われますが、本発表では以下のように捉えています。 

プロジェクト リスク プロダクト リスク リスク？ リスク リスクには2 つの側面がある。 

プロジェクトリスクとは プロジェクトの目的を達成する能力に影響を与える可能性がある。 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf 要件の増加 スケジュール遅延 コスト増加 リスク要因 影響 

プロダクトリスクとは 以下のようなさまざまな負の結果をもたらす可能性がある。 ⚫ ユーザーの不満足 ⚫ 収益、信頼、評判の損失 ⚫ 第三者への損害賠償 ⚫ メンテナンスコストが高い、ヘルプデスクに負荷がかかる ⚫ 刑事罰 ⚫ 極端な場合、身体的な損傷、重傷、または死に至ることもある 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf 機能不足 不十分な応答時間 使いづらさ 脆弱性 

リスクを見つけるために 

プランニング テスト設計 実行結果 確認 テスト設計 レビュー ドキュメントデータベース テスト実装 テスト実行 テスト完了 テストプロセス リスク共有会（2週間に1回実施） データベースは プロジェクト毎に 自動作成 レビュー結果 テスト結果 機能性・使用性・テストプロセスに影響を与える可能性はあるか？ リスク共有会（プロダクトリスクを見分ける会） QAチーム内のドキュメントデータベースに情報を集約。 事前にテストベース、テストウェアを収集し、リスクを共有する。 テストベース テストウェア 共有 共有 共有 共有 リスク対処 リスク対処 リスク対処 リスク対処 

プランニング テスト設計 実行結果 確認 テスト設計 レビュー ドキュメントデータベース テスト実装 テスト実行 テスト完了 テストプロセス リスク共有会（2週間に1回実施） データベースは プロジェクト毎に 自動作成 レビュー結果 テスト結果 機能性・使用性・テストプロセスに影響を与える可能性はあるか？ リスク共有会（プロダクトリスクを見分ける会） QAチーム内のドキュメントデータベースに情報を集約。 事前にテストベース、テストウェアを収集し、リスクを共有する。 テストベース テストウェア 共有 共有 共有 共有 リスク対処 リスク対処 リスク対処 リスク対処 次テストへ 申し送り 探索的テスト 実施 テスト追加 因子・水準 追加 

リスク共有会 リスク共有会で発表するタイミング 何かしらのテストベース/テストウェアがある テストウェアが共有できる状態 共有できるプロダクトリスクを認識している 進行の流れ 担当者からテストベース/テストウェアを説明する 資料の読み込み時間を確保 リスクの共有/リスクに対するアクションの決定 （プロダクトリスクを見分ける会） プロジェクトに直接関与していない メンバーから気になるポイントをブレスト 

リスク共有会 プロジェクト名 テストベース テストウェア リスク共有会アジェンダ 開発資料 要求・要件定義書 テスト計画書 テスト設計書 事前に検知しているリスクなど 当日メモランダム プロジェクト名 プロジェクト名 プロジェクト名 プロジェクト名 プロジェクト名 プロジェクトの属性（プロパティ） プロジェクトの属性（プロパティ） プロジェクトの属性（プロパティ） プロジェクトの属性（プロパティ） プロジェクトの属性（プロパティ） トレーサビリティを確保する目的で、 テストベース・テストウェアへのリンクや、 事前に検知しているリスクなどの情報を集約 （プロダクトリスクを見分ける会） Notionデータベースのテンプレート 

プランニング 設計・実装・単体テスト ツール テスト （コンポーネントテスト、インテグレーションテスト） 統合テスト 開発フェーズ QAプランニング（1週間に1回実施） プロジェクト 完了 リリースサイクルに影響を与える可能性はないか？ QAプランニング（プロジェクトリスクを見分ける会） 目的に合わせ、ツールを活用、事前に定量・定性情報を収集＆報告し、 リスクの有無をモニタリングする。 開発状況 リソース状況 共有 リスク対処 リスク対処 テスト状況 リソース状況 共有 共有 リスク対処 プロジェクト状況 リソース状況 

プランニング 設計・実装・単体テスト ツール テスト （コンポーネントテスト、インテグレーションテスト） 統合テスト 開発フェーズ QAプランニング（1週間に1回実施） プロジェクト 完了 目的に合わせ、ツールを活用、事前に定量・定性情報を収集＆報告し、 リスクの有無をモニタリングする。 シフトレフト リソース追加 スケジュール調整 リリースサイクルに影響を与える可能性はないか？ QAプランニング（プロジェクトリスクを見分ける会） 開発状況 リソース状況 共有 リスク対処 リスク対処 テスト状況 リソース状況 共有 共有 リスク対処 プロジェクト状況 リソース状況 

QAプランニング リリースバージョン プロジェクト名 （プロジェクトリスクを見分ける会） マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL リリースバージョン プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト毎に QAに関わるマイルストーンに対する プロジェクトリスクを共有 

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担当者の リソース状況を可視化 担当予定の 工数内訳を集約 

「〜かもしれない」を現実にしない ためにあらゆる事を行う それがテストマネジメント デジタル名刺はこちら→ 

ご清聴ありがとうございました ご清聴ありがとうございました 

Appendix. 

テックタッチとは Webシステム画面上で操作に合わせてナビゲーションを表示する デジタルアダプションプラットフォーム（DAP）※ ※新たに利用するビジネス・アプリケーションやWebシステムなどの利用の定着を支援する製品・サービスのこと。 ブラウザ拡張を インストール ScriptをWebサイトに 埋め込む ノーコードで ガイダンスを実装 

開発体制 専門領域毎のチーム体制で開発 QAは各チームと協業してプロダクト・プロセスの品質を支える 

テスト テスト テスト プランニング テストを推進 ロードマップ策定 QAはプランニングから参加 開発プロセス スクラムをベースとしたプロセス 開発に関わるメンバーが一体となって進行 

リリース 機能開発 統合 テスト 機能開発 機能開発 プロダクトオーナー・デザイナー・エンジニア・QAが一体となって進める 要求・要件定義 開発フェーズ 開発に関わるメンバーが一体となって進行するプロセス リリース直前に各機能開発を統合したテストを実施 

リリースサイクル以外に リリースする場合もあります リリースサイクル 3ヶ月に1度、メインバージョンアップのリリース 

リリース 機能開発 設計・実装・単体テスト コンポーネントテスト インテグレーションテスト 統合 テスト 要求・要件定義 テストフェーズ テスト内容 テスト担当 単体テスト ロジックやクラス、モジュール単位の動作を確認する エンジニア コンポーネントテスト システムの最小要素（コンポーネント）の動作を確認する エンジニア & QA インテグレーションテスト コンポーネント間の結合、API間の結合を確認する エンジニア & QA 統合テスト 全ての機能変更を統合し、ユースケースや運用を想定した動作を確認する （E2Eテスト、リグレッションテスト、互換性テストなど） QA テストフェーズ QAはコンポーネントテストから担当、開発と協業してテストを進行する