フルリモートでも品質は作れる #seb_summit

2026/02/22に開催された SEBSUMMIT で発表した資料です。
https://summit.sapporo-engineer-base.dev/

Transcript

1. フルリモートでも品質は作れる 〜SaaS スタートアップでの仕組み化の⼯夫〜 Sapporo Engineer Base SUMMIT テックタッチ株式会社 2026/2/22 Sun. 巻 宙弥（まき みちや） QA エンジニア
2. 出身 略歴 IT 業界 20 年 ⾃⼰紹介 巻 宙弥 （まき みちや） 馬と桜の町、北海道新ひだか町 札幌市内企業 エンジニア・マネージャ 東証プライム上場企業 ITコンサルタント Saasスタートアップ テックタッチ 品質保証エンジニア（QA） Saas ベンダー テックタッチ( 株) のQA エンジニア Mickey
3. 社外活動 JaSST ：Japan Symposium on Software Testing 、NPO 法人ASTER （ソフトウェアテスト技術振興協会）が運営するソフトウェア業界全体のテスト技術⼒の向上と普及を⽬指すソフトウェアテストシンポジウム DEOS ：北海道ソフトウェア技術開発機構、IT プロフェッショナルの育成を⽬的として、国、北海道、札幌市、民間の出資により設立 JBUG ：Japan Backlog User Group 、プロジェクト・タスク管理ツールBacklog のユーザーコミュニティ JaSST Hokkaido の実⾏委員として、 テスト技法に関するワークショップを担当 今年は 7 ⽉24 ⽇開催予定！ プロジェクトマネジメントのSaas アプリ「Backlog 」の ユーザーコミュニティ JBUG の札幌を運営 ASTER （ソフトウェアテスト技術振興協会）会員として、 ソフトウェアテストの研修講師を担当
4. テックタッチとは Web システム画⾯上で操作に合わせてナビゲーションを表⽰する デジタルアダプションプラットフォーム（DAP ） ブラウザ拡張を インストール Script をWeb サイトに 埋め込む ノーコードで ガイダンスを実装 ※ 新たに利⽤するビジネス・アプリケーションやWeb システムなどの利⽤の定着を支援する製品・サービスのこと。 ※
5. 本⽇話すこと 1. 働き方の変化 2.QA エンジニアの話 3. 品質を作る仕組み化の⼯夫 4. フルリモートで成果を出す心得
6. 1. 働き方の変化 2.QA エンジニアの話 3. 品質を作る仕組み化の⼯夫 4. フルリモートで成果を出す心得
7. 2005 2012 2019 SE （ほぼ客先常駐） SE / マネージャー （ほぼ⾃社で受託開発） IT コンサルタント （ほぼ客先常駐） IT コンサルタント （リモート） QA エンジニア （フルリモート） 2023 受託開発、第三者検証を経てスタートアップのQA エンジニアに フルリモートまでの流れ SE ？（システムエンジニア） システム開発において要件定義や設 計、開発などを担うエンジニアの総称 我流の品質知識をアップデートしたく第三者 検証のテスト専⾨会社に転職 コロナで周囲の環境に⼤きな変化が起きて リモート主体の働き方が必要になる IT コンサルタント？ 企業のIT 戦略やシステム導入を支援 し、課題解決を⾏う専⾨家 フルリモートでプロダクトにコミットでき るスタートアップのQA エンジニアに転職
8. 親族との関わり 家庭とのバランス 時間の有効活⽤ 距離の問題は 解決できず 働き方を変えた結果
9. 1. 働き方の変化 2.QA エンジニアの話 3. 品質を作る仕組み化の⼯夫 4. フルリモートで成果を出す心得
10. QA エンジニアとは？ ソフトウェアやシステムの品質を保証するために、 プロセスと成果物の両方に責任を持つ専⾨職です。 単なる「テスト担当者」ではなく、品質を“ 作り込む” 役割を担います。 「ソフトウェアの品質を保証し、 ユーザーに最高の価値を届ける仕組みを作る専⾨家」です。 単に「バグを⾒つける人（テスター） 」だと思われがちですが、 現代のQA エンジニアの役割はもっと広く、 開発の最上流からリリース後の改善まで多岐にわたります。
11. 企画 要件定義 設計 実装 テスト リリース QA エンジニアの⼀般的なイメージ テスト⼯程 担当者
12. 企画 要件定義 設計 実装 テスト リリース QA エンジニアに期待する役割 品質保証 テスト⼯程 も担当
13. 引⽤）品質を加速させるために、テスターを増やす前から考えるべきQM ファンネルの話（3D 版） https://www.slideshare.net/slideshow/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties/249498558 P3 インプロセスQA とQA コーチ、QA プロジェクトマネージャで構成 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 として動くこともある QA 内外へのソフトウェアテストのノウハウ共有
15. 開発体制
16. 開発の進め方
17. 1. 働き方の変化 2.QA エンジニアの話 3. 品質を作る仕組み化の⼯夫 4. フルリモートで成果を出す心得
18. 海外 要件に対する適合である。 Phlip B.Crosby 誰かにとっての価値である。 Gerald M. Weinberg 1. プロダクトの特性が顧客のニーズに応えることにより満⾜を提供する。 2. 障害や誤りなどの不備から免れる Joseph M.Juran 国内 （狭義） 製品そのものの品質を指す。 （広義） 仕事の質、サービスの質、情報の質など、すべてを含めた品質を指す ⽯川 馨氏 「魅⼒的品質」 「⼀元的品質」 「当たり前品質」がある。 狩野 紀昭氏 規格 対象に本来備わっている特性の集まりが、要求事項を満たす程度である。 ISO 9000 明⽰された条件下で利⽤するとき、 明⽰的ニーズまたは暗黙のニーズを満たすためのソフトウェア製品の能⼒。 ISO/IEC 25000 シリーズ 品質とはなにか？ 参考）ソフトウェア品質知識体系ガイド （第3 版） −SQuBOK Guide V3 −
19. 海外 要件に対する適合である。 Phlip B.Crosby 誰かにとっての価値である。 Gerald M. Weinberg 1. プロダクトの特性が顧客のニーズに応えることにより満⾜を提供する。 2. 障害や誤りなどの不備から免れる Joseph M.Juran 国内 （狭義） 製品そのものの品質を指す。 （広義） 仕事の質、サービスの質、情報の質など、すべてを含めた品質を指す ⽯川 馨氏 「魅⼒的品質」 「⼀元的品質」 「当たり前品質」がある。 狩野 紀昭氏 規格 対象に本来備わっている特性の集まりが、要求事項を満たす程度である。 ISO 9000 明⽰された条件下で利⽤するとき、 明⽰的ニーズまたは暗黙のニーズを満たすためのソフトウェア製品の能⼒。 ISO/IEC 25000 シリーズ 品質とはなにか？ 個人的には好きな表現で理想だなと思う定義
20. 誰かにとっての価値を満たすために 品質を作り込み続ける 私のミッション
21. 私が3 年間実践してきたこと
22. シフトレフト
23. シフトレフトとは 企画 要件定義 設計 実装 テスト リリース より早い⼯程で テストを⾏う テスト戦略やテスト計画を立てる 要件や設計資料をレビューする 例）
24. なぜシフトレフトか
25. 要件定義 不具合修正にかかるコストを低減したい 時間軸 設計 実装 テスト 保守 後⼯程に⾒つかるほどコストがかかる 修 正 に か か る コ ス ト 参考）Barry Boehm “Software Engineering Economics” (Prentice Hall, 1981)
26. 3 ヶ⽉に1 度、メインバージョンアップのリリースがある。 もちろん、リリースサイクル以外に不定期のリリースもある。 定期リリースを守り、不定期リリースを多くしたい
27. Saas スタートアップで再現性がある   仕組み リスクを⾒分けるプロセス 開発者とテストを協業するプロセス （と思っている）
28. Saas スタートアップで再現性がある   仕組み リスクを⾒分けるプロセス 開発者とテストを協業するプロセス （と思っている）
29. リスクとはなにか？ 顕在化すると悪影響をもたらす潜在的な事象、ハザード、または脅威のこと 引⽤）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf ⽬的に対する不確かさの影響 引⽤）ソフトウェア品質知識体系ガイド （第3 版） −SQuBOK Guide V3 − 不確実なイベントや状態で、発⽣すると プロジェクトの⽬標にプラスまたはマイナスの影響を与える可能性があるもの 引⽤）プロジェクトマネジメント知識体系ガイド（PMBOK ガイド）第7 版 ⽬的を達成するまでに起きうる 「〜かもしれない」とう可能性のこと 教科書的な定義
30. 会議体 ⽬的 議題に上がる情報・状況 リスク共有会 プロダクトリスクの⾒極め 「〜」という表現は顧客が誤解しそうだ 「〜」の⼿順は使⽤性を損なう可能性がある 「〜」のようなケースは検討されているか？ この機能はテスト設計が難しそうだ QA プランニング プロジェクトリスクの⾒極め テストに必要なドメイン知識が不⾜する テストに必要なスキルが不⾜する スケジュールに対しQA のリソースが不⾜する 要件定義や設計に時間がかかりそう リスクを⾒分けるプロセス ※ 参加者はQA チームメンバー（業務委託＋第三者検証会社を含む） 「リスクの早期発⾒・対応」に着⽬、⽬的毎にQA チーム内のミーティングを運営。
31. 会議体 ⽬的 議題に上がる情報・状況 リスク共有会 プロダクトリスクの⾒極め 「〜」という表現は顧客が誤解しそうだ 「〜」の⼿順は使⽤性を損なう可能性がある 「〜」のようなケースは検討されているか？ この機能はテスト設計が難しそうだ QA プランニング プロジェクトリスクの⾒極め テストに必要なドメイン知識が不⾜する テストに必要なスキルが不⾜する スケジュールに対しQA のリソースが不⾜する 要件定義や設計に時間がかかりそう リスクを⾒分けるプロセス ※ 参加者はQA チームメンバー（業務委託＋第三者検証会社を含む） 「リスクの早期発⾒・対応」に着⽬、⽬的毎にQA チーム内のミーティングを運営。
32. プロジェクトリスクとは プロジェクトの⽬的を達成する能⼒に影響を与える可能性がある。 引⽤）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf 要件の増加 スケジュール遅延 コスト増加 リスク要因 影響
33. プロダクトリスクとは 以下のようなさまざまな負の結果をもたらす可能性がある。 ⚫ ユーザーの不満⾜ ⚫ 収益、信頼、評判の損失 ⚫ 第三者への損害賠償 ⚫ メンテナンスコストが高い、ヘルプデスクに負荷がかかる ⚫ 刑事罰 ⚫ 極端な場合、身体的な損傷、重傷、または死に至ることもある 引⽤）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf 機能不⾜ 不⼗分な応答時間 使いづらさ 脆弱性
34. 会議体 ⽬的 議題に上がる情報・状況 リスク共有会 プロダクトリスクの⾒極め 「〜」という表現は顧客が誤解しそうだ 「〜」の⼿順は使⽤性を損なう可能性がある 「〜」のようなケースは検討されているか？ この機能はテスト設計が難しそうだ QA プランニング プロジェクトリスクの⾒極め テストに必要なドメイン知識が不⾜する テストに必要なスキルが不⾜する スケジュールに対しQA のリソースが不⾜する 要件定義や設計に時間がかかりそう リスク共有会 ※ 参加者はQA チームメンバー（業務委託＋第三者検証会社を含む） 「プロダクトの品質に直結するリスク」を⾒極める会。
35. プランニング テスト設計 実⾏結果 確認 テスト設計 レビュー ドキュメントデータベース テスト実装 テスト実⾏ テスト完了 テストプロセス リスク共有会（2 週間に1 回実施） データベースは プロジェクト毎に ⾃動作成 レビュー結果 テスト結果 テスト追加 テスト観点 追加 機能性・使⽤性・テストプロセスに影響を与える可能性はあるか？ リスク共有会（プロダクトリスクを⾒分ける会） ドキュメントデータベースに情報を集約。 事前に収集した要件や仕様、テスト設計書を元にリスクを共有する。 要件・仕様 テスト設計書 共有 共有 共有 共有 リスク対処 リスク対処 リスク対処 リスク対処
36. リスク共有会 プロジェクト名 要件・仕様 テスト リスク共有会アジェンダ 開発資料 要求・要件定義書 テスト計画書 テスト設計書 事前に検知しているリスクなど 当⽇メモランダム プロジェクト名 プロジェクト名 プロジェクト名 プロジェクト名 プロジェクト名 プロジェクトの属性（プロパティ） プロジェクトの属性（プロパティ） プロジェクトの属性（プロパティ） プロジェクトの属性（プロパティ） プロジェクトの属性（プロパティ） トレーサビリティを確保する⽬的で、 各ドキュメントへのリンクや、 事前に検知しているリスクなどの情報を集約 （プロダクトリスクを⾒分ける会） Notion データベースのテンプレート
37. 会議体 ⽬的 議題に上がる情報・状況 リスク共有会 プロダクトリスクの⾒極め 「〜」という表現は顧客が誤解しそうだ 「〜」の⼿順は使⽤性を損なう可能性がある 「〜」のようなケースは検討されているか？ この機能はテスト設計が難しそうだ QA プランニング プロジェクトリスクの⾒極め テストに必要なドメイン知識が不⾜する テストに必要なスキルが不⾜する スケジュールに対しQA のリソースが不⾜する 要件定義や設計に時間がかかりそう QA プランニング ※ 参加者はQA チームメンバー（業務委託＋第三者検証会社を含む） 「リリースサイクルの遅延に直結するリスク」を⾒極める会。
38. プランニング 設計・実装・単体テスト ツール テスト （コンポーネントテスト、インテグレーションテスト） リリース前 テスト 開発フェーズ QA プランニング（1 週間に1 回実施） プロジェクト 完了 シフトレフト リソース追加 リリースサイクルに影響を与える可能性はないか？ QA プランニング（プロジェクトリスクを⾒分ける会） 事前にツールで定量・定性情報をチーム内で共有し、 プロジェクトリスクの有無をモニタリングする。 開発状況 リソース状況 共有 リスク対処 リスク対処 テスト状況 リソース状況 共有 共有 リスク対処 プロジェクト状況 リソース状況
39. QA プランニング リリースバージョン プロジェクト名 （プロジェクトリスクを⾒分ける会） マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL リリースバージョン プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト名 マイルストーンに対する進捗状況など 進捗状況・優先度・担当PL プロジェクト毎のマイルストーンに対し 「思ったとおりではない」 プロジェクトリスクを共有する
40. 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 担当者の リソース状況を可視化 担当予定の ⼯数内訳を集約
41. QA プランニング（プロジェクトリスクを⾒分ける会） 作業実績をトラッキングし、モニタリング
42. 仕組み化の結果（⼀例 QA が要因の定期リリース遅延がゼロに シ フ ト レ フ ト の 効 果 事前のリスク対処によりリリースへの影響を回避できるようになった 早期の妥当性検証ができる 他チームのQA エンジニアから客観的なコメントがもらえるようになった リリース前テストの⼯数が減少傾向 定量・定性な品質コントロールによりテスト⼯数が最適化
43. Saas スタートアップで再現性がある   仕組み リスクを⾒分けるプロセス 開発者とテストを協業するプロセス （と思っている）
44. 仕様策定 プランニング テストリスト 実⾏結果 レビュー テスト分析・設計 テスト実装 ⾃動テスト 実⾏ テストリスト レビュー 運⽤ 開発者 QA テスト実装 テスト実装 ⼿動テスト 実施 開発者とテストを協業するプロセス テストを⾃動テストとして作り切るまでの⼀連の流れを実現 連携 参照 通常のテストプロセス
45. ユニットテスト スコープ コンポーネントテスト インテグレーションテスト E2E テスト UI を必要としないロジックのテスト UI コンポーネントを対象としたテスト バックエンドAPI はモック、それ以外は実際の動作環境と同じ 実際に動作するバックエンドAPI 使ったテスト 例）バリデーション処理（文字種、形式チェックなど） 例）入⼒の境界値、エラーメッセージ表⽰など 例）状態遷移、API のエラーケース、意図しないデータパターンなど 例）ユースケーステスト、設定や権限など前提条件を含んだ動作確認 このプロセスのスコープはコンポーネントテスト
46. テストリストとは？ UI コンポーネントを対象としたテストをリスト化、開発者と共有する ⾃動テストの可否をマーキング テスト管理ツールへの関連付け レビューコメントを記録
47. 仕組み化の結果（⼀例 QA のテスト開始までに検出された不具合の増加 開発者がテストリスト作成中に不具合を検出 不定期リリースの回数が増加傾向に 柔軟なQA の関わりと開発者の協業で効率的なテストが実施できるようになった シ フ ト レ フ ト の 効 果 QA のテストを6 割削減（130 件中80 件） テストの分類により⾃動化できるコンポーネントテストが明らかになった 開発中に確認されるテストを、⼿動テストとして設計する必要がなくなった
48. 「〜かもしれない」を現実にしない ためにあらゆる事を⾏う 仕組み化する それを
49. 1. 働き方の変化 2.QA エンジニアの話 3. 品質を作る仕組み化の⼯夫 4. フルリモートで成果を出す心得
50. チームや役割にこだわらない QA と開発者が協⼒し、共にテストについて考え、 ⼿動テストの負荷を抑えながら継続的に品質を作り込んでいく
51. 常に再現性を高めるアウトプットを残す アウトプットを⼤事にするのはもちろん、 「他の誰か」が再利⽤できるように最初から⼯夫する。
52. 早いリアクション 思ったことはその場ですぐに発言する。 リアクションは人⼀倍、⼤げさくらいがちょうどよい。
53. まとめ 現代は、変化が激しく、スピードが要求される時代です。それはもっともっと加速します。 エンジニアは、誰かにとっての価値を追求し、 技術をフル活⽤して、愉しみながら開発することが⼤事だと思います。 エンジニアが愉しく、誰よりもユーザーのことを考えて作ったプロダクトは、 必ず誰かを幸せにすると思います。 そのために、 「〜かもしれない」というリスクに向き合い、 働く場所に関係なく対処してくことが重要です。 今回は、早い段階から品質に向き合えるような仕組みづくりの実例を紹介しました。 本⽇の内容が、皆さまの現場において、何かしらのヒントになれば幸いです。
54. フルリモートでも品質は作り込める
55. ご清聴ありがとうございました ご清聴ありがとうございました