「明日のテストを楽にしたい」から始まった小さな一歩！「自分たちには活かせないかも」を越えて、カンファレンスの学びを現場へ

スクラムフェス札幌2026
https://www.scrumfestsapporo.org/
yuuki（サイボウズ株式会社）

1. 「明日のテストを楽にしたい」から始まった小さな一歩！ 「自分たちには活かせないかも」を越えて、 カンファレンスの学びを現場へ 2026.11.14 スクラムフェ ス札幌2026 yuuki （ QAエンジニア） 1
2. 自己紹介 yuuki （ QAエンジニア /サイボウズ株式会社・サイボウズ Office 、メールワイズ担当） 北海道札幌市出身 / 小樽商科大学卒業 千葉県在住 スクラムフェス新潟実行委員 所属しているチームと担当製品のことが大好き！ テスト、品質に関することも好き、カンファレンスも好き！ 2
3. 所属しているチームについて ・サイボウズ Office （ 1997 年発売）、メールワイズ（ 2004 年発売）の開発を担当するチーム ・スクラムを実践しているチームではない ・（ ※私個人の話）スクラムマスターがいるチームで働いたことも、 スプリントを経験したこともない 3
4. カンファレンスに参加してセッションを聴講したり 参加者と対話したりしたとき、 自分のチームとの間に距離を感じた経験はありますか？ 4
5. 以前の自分 自分のチームとは前提が違うから、この話は自分たちには活かせないのかもしれない スクラムを実践していない自分がスクラムフェスに参加しても、場違いなのではないか 話についていけないことで、疎外感を感じてしまうのではないか 5
6. 2026 年5月に参加した JaSST’26 Tohoku をきっかけに 「カンファレンスで得た学びの捉え方」が変わった 6
7. 「スクラムを実践しているかどうかにかかわらず 、 カンファレンス で共有される経験や現地での対話 から 自分たちの現場をよりよくするヒントを 持ち帰ることはできる」 7
8. 今日の発表 1. チームの課題と自分の課題「テストや品質の 問題は、 QAでなんとか する」 2. 変化「エネルギーとヒント」 3. 改善「自分たちの現場に合わせて、どう実践したか」 4. 最後に「自分たちには活かせないかも」を越える 8
9. 1. チームの課題と自分の課題 「テストや品質の 問題は、 QAでなんとか する」 9
10. 10 年以上続く 製品・ 固定された メンバー・ 慣れたプロセス チームの課題 ・テストに時間がかかっている ・長く続けてきたことを時間やコストをかけて変えるべきなのか 、 この まま 継続した ほうが いい のか、 判断が難しい ・文化的に、テストや品質の 問題は「 QAでなんとか する」が強かった 個人の課題 ・アジャイルな 開発プロセスではないので、 チームを アジャイルの 考え方に 当てはめて 改善する ことは 違うのではないか？と考えていた 10
11. 2. 変化 「エネルギーとヒント」 11
12. 2回目のJaSST 東北参加 https://jasst.jp/tohoku/26 -about/ ・今年のテーマは「生成 AIと歩むテスト設計 〜AIはもう 1人の仲間〜」 ・今日の発表タイトルにも入れた、「明日のテストを楽にする」というモットーは 一貫している（ここが好きだな、と思っている） ・テストが大好きな自分にとって、楽しみにしているとても大切な場所 12
13. 一日を通して、エネルギーに後押ししてもらった 実行委員、登壇者、参加者の熱量が伝播した日 現在の状況を 変えたい、 もっと 明日のテストを 楽にしたい、 と思った日 世の中が目まぐるしく変化し続けるなかでも、自分の大好きな「 テストが好きな気持ちを 1日かけて肯定してもらえたと感じた日 QAエンジニア」という仕事、 13
14. ヒントを得た 「内製開発組織における QAと生成 AIとの関わり方」 阿部 将太郎さん（東急 URBAN HACKS QAエンジニア） https://jasst.jp/wp_download/jasst26tohoku/26tohoku_report_s2 -3.pdf 開発メンバーに実装段階でテスト観点を共有する取り組みを聴いた →QAが品質をリードすることについて、参加者や登壇者の方と対話が進んだ 自分たちとは開発プロセスが違っていても、「テスト観点を開発者と共有する という 考え方は取り入れられるかもしれない。 「同じやり方はできない」ではなく 、 「 自分たちのチームならどう 取り入れられる だろう？」と考えた。 」 14
15. 自分も、明日のテストを楽にしたい！ 15
16. 誰の「明日のテスト」を楽にしたいのか？ 考えを深めた 16
17. QAだけでなく、開発者にとっての「明日のテスト」も 楽にしたい 17
18. 3. 改善 「自分たちの現場に合わせて、どう実践したか」 18
19. これまでの自動テスト（ ※一部） 正常系と異常系のメインケースにおける自動テスト 開発者が テスト観点を考えて 自動テストを実装 QAの手動テスト。 自動テストがすべて 自動テストで PASSになる 不足している観点を 補う 19
20. JaSST 東北で得たヒントを、 チームの自動テストの実態に合わせてアレンジした 20
21. 進めるうえで大切にしたポイント ポイント なぜやったか どうだったか まずは正常系と異常系の メインケースから （ ×すべてのテストで 一気に進める） 狭い範囲で試してみることで うまくいかなくても 元のやり方 に戻しやすい と 思った 試す範囲が限定的なので、 従来のやり方とも比較しながら どんな効果があるか 観察しやすかった まずは相談しやすい 開発者と個人で対話 （ ×チーム全体 MTGで 開発者全員に相談） 定例のふりかえりなどがなく、 全員が集まる機会が少ない いきなり全員招集するよりも 相談のハードルが低いと思った ぜひやりましょう！と 言ってくれた 今すぐ試せる形から （ ×最初から QAが自動テストの 実装まで挑戦） できれば実装まで挑戦したかっ たが、環境準備などにある程度 時間がかかりそうだと考えた 今あるスキルや役割を活かし 改善を早く始められた 21
22. 実践した結果、何が変わったか QA 手動でテストしていたテストの実施時間が 平均6割程度削減 （ ※取り組み前後の同程度の機能の比較） 自動テストで実装できなかったテストと、探索的テストのみ実施 開発者 観点を洗い出す時間の短縮と、観点漏れの防止につながった 進めていくうち に開発者から フィードバック もいただき、 Mindmap で自動テストの 観点を 渡していたのを Markdown で渡すようさらに改善 22
23. 4. 最後に 「自分たちには活かせないかも」を越える 23
24. 今回の改善も含め、少しずつ開発者との協働が 広がっている 4年ぶりのチームビルディング開催！ 2026/07 私たちがどうやってテストをしているのか、 テスト技法を紹介しながら説明 2026/09 2026/11 QAだけでやっていたふりかえりを、開発者や PMと一緒に実施 Playwright と Claude Code を使用しながら、 QAが自動テストの実装に挑戦 24
25. QAエンジニアとして「自分ができること」に ずっと向き合ってきた QAとして信頼してもらえるように、全力を出している ・丁寧に テストして、 不具合を 見つける ・根拠を 持って不具合や 懸念を 伝える ・チーム、製品の 品質に貢献したいと いう 気持ちを 言葉や行動で伝える ・適切な タイミングで、 問いを わかりやすく 出す 今回は、「 QAだけでなんとかする」から 1歩先に出た 25
26. 開発者と一緒に改善する あまりやってこなかったことに踏み出した ・頼ってみる ・提案を する ・役割の 境界を 越えて 相談する 本で読んだりカンファレンスで聞いたことがあったりするだけ で、あまり自分事にならなかった 「 みんなで 品質を 作る」と いうのは、 こういう ことなのかも しれない と感じている 26
27. カンファレンスに参加してセッションを聴講したり 参加者と対話したりして、 自分のチームとの間に距離を感じるとき … （自分のチームの課題はまだまだ山積みで伸びしろがたくさんあるので こう感じることは、日々あります） 27
28. 「自分たちとは違う」 「自分たちには活かせないかも」 「自分たちならどう活かせるだろう？」 周りの仲間、参加者と対話してみる →同じことはできなくても 自分たちなり の取り入れ方（ アレンジ ） を して 、 改善のための一歩を 踏み出すことはできる と 考えています！ 28
29. 自分にとって、 JaSST 東北は 「自分たちには活かせないかも」を越えさせてくれた 大切な場所！ 次は自分がJaSST 東北からもらったパワーを伝播させていく番だと思い、 その1歩としてこの発表に挑戦しています 29
30. 自分たちなりの方法で「明日のテストを楽にする」ための 学びと挑戦は、これからも続いていく 30