はじめに
こんにちは。UUUOでQAテスターをしているさよりと申します。
前職ではネットワーク機器・サーバー機器の組込みソフトウェアテストを約1年半経験し、現在はUUUOでスマホアプリとWebアプリのQAを担当して1年3ヶ月ほどになります。
今年度は「QAテスターからQAエンジニアへ」を目標に掲げています。
ただ、日々の業務の中だけでは、自分のやり方が世の中のQAの標準から見てどうなのか、なかなか確かめる機会がありません。
そんな中、2026年7月3日に開催されたJaSST'26 Kansaiに参加してきました。あわせて、testingOsakaさん主催の「QAなんもわからん会関西'26」にも参加したので、記事の最後に番外編として紹介します。
想像以上にたくさんの持ち帰りがあったので、参加レポートとしてまとめます。
- はじめに
- イベント概要
- 基調講演 セッション S1-A『AIに負けない』より『AIと遊ぶ』〜ワクワクが最強のテスト・QA学習戦略〜
- テーマセッション S2-A「テスト設計の本質を改めて考えてみる」
- テクノロジーセッション S7「ふりかえりが「生存報告」から「未来の話」に変わるまで」
- その他の参加セッション
- おわりに
- 番外編:QAなんもわからん会関西'26 での体験
イベント概要
JaSST(ソフトウェアテストシンポジウム)は、NPO法人ASTERが主催する国内最大級のソフトウェアテストのシンポジウムです。全国各地で開催されていて、今回参加したのはその関西開催です。
多くのセッションに参加しましたが、この記事では特に印象に残った3つのセッションを中心に紹介します。
基調講演 セッション S1-A『AIに負けない』より『AIと遊ぶ』〜ワクワクが最強のテスト・QA学習戦略〜
DMM.com、ASTER 大段 智広さんによるセッションです。テスト設計コンテストの実行委員も務められている方で、ご自身の実践事例も交えた講演でした。
キーメッセージは「AIと遊ぶ」。
義務感や強制による学習は短期間しか続かない。「やってみたい」という自発的なワクワクこそが、長く学び続けるための鍵だという話でした。
印象的だったのは、AI時代の個人学習ロードマップです。「基礎を固める→AIを使いこなす→開発全体に波及させる→組織の仕組みを作る」の4ステップで、ステップを飛ばすと成長が止まってしまうとのこと。
特に刺さったのは、最初の「基礎を固める」の位置づけです。
テスト設計技法や共通語彙といった基礎は、AIの出力を論理的に評価するための基準になり、AIが使えるから基礎が要らなくなるのではなく、むしろ基礎が効いてくるそうです。
AIを使えば基礎がスキップできると勘違いしがちですが、AIを上手に使っていくためにも基礎を固めていく必要があるとひしひしと感じました。
デモではAIによるテスト環境のセットアップが従来の3時間から約3分に短縮され、仕様書から約80件のテストケースが自動生成される様子も紹介されました。一方で、仕様書と実システムの乖離により実装と合わないテストが生成されるなど、実践して初めて見える落とし穴も率直に共有されました。
「今日か明日から、AIを使ったテストを1つ試してみる」
講演で提案されたこの最初のアクションを私も持ち帰ることにし、まずは小さな1ケースから試してみようと考えています。
テーマセッション S2-A「テスト設計の本質を改めて考えてみる」
株式会社ベリサーブ 山崎 崇さんによるセッションで、今回一番刺さったセッションになります。
こんな経験はないでしょうか。テスト技法を勉強したのに、いざ実務になるとどこでどう使えばいいのかわからない。生成AIにテストケースを作らせてみたものの、それが妥当かどうかを自分の言葉で説明できない。
この講演は、そんな「あるある」な課題感から出発します。
テーマは「テストベース(仕様書など、テストの元になる資料)から『なぜこのテストでいいのか』を説明できる、説明性の高いテストケースをどう導くか」。
テストケースはある日突然ポンと出来上がるものではなく、本来は「テスト分析→テスト設計→テスト実装」という段階を経て作られるもの。この過程を省略せずに丁寧に踏むことこそが、「なぜこのテストでいいのか」を説明できるようになる道筋なのだと、順を追って解きほぐしていく内容でした。
聴き終えたとき、「説明性の高いテストケースを作れるようになりたい」と強く思いました。これは今の私の、今年度一番のテーマになりそうです。
「正しいテスト」は存在しない
一番印象に残ったのは、「正しいテストは存在しない。重要なのは『なぜこのテストで十分なのか』を説明して、関係者に納得してもらうこと」という考え方でした。
この視点は、私の今年度の目標にそのまま重なります。
確認手順書を整備してチームに共有するということは、「なぜこの確認で十分なのか」を自分以外の人にも伝わる形で言語化することに他なりません。説明できない手順書は、結局「書いた人に聞かないと使えない」属人的なものになってしまう。
属人化を防ぐ鍵は、手順の量ではなく説明性なのだと気づかされました。
PdMや開発と品質観点で対話することも、突き詰めれば「テストの根拠を説明して、関係者に納得してもらう力」です。バラバラに見えていた目標が、「説明できる」という一点で繋がった感覚がありました。
テスト設計の前に「テスト分析」
もうひとつの学びは、テスト設計の前段階である「テスト分析」の重要性です。設計の前に、どれだけ対象の解像度を高められるかが勝負、という話でした。
特に「テストベースは開発のために作られていて、テストに都合の良い構造にはなっていない。だからテスト視点で再構造化する必要がある」という指摘には考えさせられました。
テストベースを読みながら3色ボールペンで書き込み、積極的に“汚しながら”読む。そんな実践的な話も紹介されていて、明日から真似できそうだなと感じました。
私は普段コードを書かない立場なので、テストベースをどう読み解くかがQAとしての生命線になります。
「読む」から「分析して構造化する」への意識の切り替えが、説明性の高いテストケース作りの第一歩になりそうだと感じました。
生成AI時代のテスト開発プロセス
生成AIにテストベースを丸ごと渡してテストケースを出力させても、その妥当性を人間が判断できない。そんな問題提起もありました。
解決の方向性は、中間成果物を段階的に出力させて、その都度確認・修正するプロセスを設計することです。
私自身の業務でのAI活用は、まだ価格計算の検算を手伝ってもらう程度です。それでも、一度に全部を任せるのではなく、中間の結果を確認しながら進めるという考え方は、これからAI活用を広げていくうえでの指針になりそうです。
「プロセスが設計できていれば、AIにやらせる場合も人が自分でやる場合も道筋を描ける」。この言葉は、AI活用と自分のスキルアップを対立させずに考えるヒントになりました。
テクノロジーセッション S7「ふりかえりが「生存報告」から「未来の話」に変わるまで」
株式会社 bubo 小野 凌 さんによるセッションで、タイトルが気になって聴講しました。
皆さんのふりかえりは、「今週はこれをやりました」という“生存報告”になっていないでしょうか。私は正直、心当たりがありました。
印象に残ったのは、ふりかえりを未来の話に変えるためのAIとの組み合わせ方で、下記のように実施します。
- Fun Done Learnのふりかえり結果をAIに分析してもらう
- 日報もAIで分析し、「今の自分」を可視化する
- そこから成長のヒントを拾ってもらう
ふりかえりの記録を「書いて終わり」にしない。AIに分析させることで、自分では気づけないパターンや次の一歩が見えてくる。
過去の記録が「未来の話」の材料に変わる、というのが目から鱗でした。
そして、これを続けるための心構えとして語られたのが「小さくやる」「完璧を目指さない」「最小単位でやる」、そして「困った時は頼る」。
この言葉は、私にはふりかえり以上に、テスト設計の学び方へのヒントとして響きました。
テスト設計のセッションで「説明性の高いテストケースを作れるようになりたい」と思ったものの、正直、道のりは長そうに見えていました。でも、最初から大きな機能の完璧なテスト設計を目指す必要はない。
小さな機能をひとつ選んで、テスト分析から設計までを最小単位で回してみる。「説明できる範囲」を少しずつ広げていく。そして行き詰まったら一人で抱え込まずに頼る。
そう考えると、遠くに見えていた目標に向かう最初の一歩が具体的になった気がします。
その他の参加セッション
上記のほかにも、次のセッションに参加しました。簡単に概要と感想を紹介します。
コラボセッション S4-A-4 要求とテストのMIRAI～生成AI時代の開発における要求とテストの新しい関係
派生開発推進協議会 代表 ／ エクスモーション エグゼクティブコンサルタント 斎藤 賢一さんとJaSST Kansai 実行委員長／派生開発推進協議会 堀川 透陽さんのコラボセッションでした。
前半はテストの各工程でAIがどこまで使えるようになっているか、後半は要求を整理して書く記法「USDM」と生成AIの相性の良さについてのセッションでした。テストは要求を確認するだけの後工程ではなく、テストの視点が要求をより良くしていく、という関係の変化が語られました。
これからは仕様を「書ける人」より、AIが書いたものが正しいか「確認できる人」が大事になる。この言葉が心に深く残りました。
テクノロジーセッション S5-B-1 ブラックボックステスト偏重を超えて ―グレーボックステストから考える、これからのテスト設計―
株式会社iTest 田嶋 享平さんのセッションです。
仕様書だけを頼りにするブラックボックステストでは、内部の状態の切り替わりや機能同士の連携に潜む不具合を見つけにくい。そこで、設計情報を必要な範囲だけ取り入れる「グレーボックステスト」でリスクを捕まえよう、という内容でした。
仕様書だけで作ったテストにグレーボックスの視点を加えたら、実際の不具合につながり得る観点が見つかった、という実験結果も紹介されました。
前職が組込みテストだったこともあり、「仕様書をなぞるだけでなく、仕組みを理解して不具合を探しにいく」という考え方がとても身近に感じられました。
テクノロジーセッション S6 AI駆動開発におけるQAエンジニアの役割事例
JSTQB技術委員＆広報 小林 依光さんのセッションです。
テストの計画・設計・実行をAIが担い、人間は「AIがやったことをチェックしてOKを出す役」に変わりつつある。そんな時代にQAエンジニアはどこで価値を出すのか？という問いに、現場の実例で答える内容でした。
答えとして提案されていたのは、経験や勘でやっていた「どこが危なそうか」という判断を言葉やルールに書き出してAIでも判断できるようにする役割(QE)と、そのルールが自動で回る仕組みを作る役割(QAHE)へのシフト。たとえるなら、レシピを書く人と、そのレシピ通りに動くキッチンを作る人です。
AIに仕事を任せるには、まず自分の頭の中にある判断を言葉にできないといけない。テスト設計のセッションで感じた「説明できること」の大切さに、ここでもつながりました。締めくくりの「変化に対応するために基礎力をUP」というメッセージは、これからJSTQBを学ぼうとしている自分への応援のようにも聞こえました。
招待講演 S8 AI時代における最適なQA組織の作り方
freee株式会社 湯本 剛さんのセッションです。
約130名という大きなQA組織で、AI活用をどう広げてきたかの実践談です。仕事のやり方や成果物の形を揃える「型化」、AIに正しく判断させるための用語や仕様の整備、そして内製のAIアシスタントの運用まで、組織ぐるみの取り組みが紹介されました。
「型のある仕事ほどAIで速くできる」という話を聞いて、いま取り組んでいる手順書の整備が、将来のAI活用の土台にもなるのだと励まされました。
おわりに
JaSSTの各セッションから持ち帰ったことを、行動に落とすとこうなります。
- テスト設計の学びは、小さな機能ひとつのテスト分析から。完璧を目指さず最小単位で始めて、困ったら頼る
- 手順書の整備では、手順だけでなく「なぜこの確認で十分か」まで言語化して、属人化を防ぐ
- テストベースは“汚しながら”読み、テスト視点で構造化する練習をする
- 「AIと遊ぶ」気持ちで、まずAIを使ったテストを1つ小さく試してみる
- ふりかえりや日報のAI分析を試して、自分のふりかえりも「未来の話」にしていく
日々の業務の中だけでは確かめられなかった「世の中のQAの標準」に触れて、目標に向かう最初の一歩がいくつも具体的になった一日でした。
番外編:QAなんもわからん会関西'26 での体験
ここからは、JaSSTとは別のイベントの話です。
QAなんもわからん会関西'26は、大阪・関西のテスト系コミュニティtestingOsakaさんが主催する、「大きな声で『わからん』と言える場所を作る」がコンセプトのイベントです。
当日はOST(オープンスペーステクノロジー)形式で行われました。OSTとは、参加者がその場で話したいテーマを提案し、提案者自身がセッションを立てて自己組織的に進めていく形式です。
「ここにやってきた人はだれもが適任者である」という原則のおかげか、初参加でも自然に輪に入れました。
いくつかのテーマに参加した中で、特に気になったのが「QAテスターからQAエンジニアになるには」というテーマです。
まさに自分ごとのテーマ。ここでは思い切って「わからん」を口に出しながら、社外のQAの方々と語り合いました。
対話の中で特に心に残ったのは、次の2つの視点です。
- 全体感を持って、目的意識を持ってテストしている人は、テスト実行者であってもエンジニアと呼べるのではないか
- QAがCS(カスタマーサクセス)をやってもきちんと仕事ができるくらい、プロダクトへの解像度を持つ
2つ目の話は、個人的に特に刺さりました。というのも、私自身、テスト設計と業務理解のためにCSにチャレンジしてみたいと考えていたからです。
ユーザーからの問い合わせに答えられるくらいプロダクトを理解していれば、「ここで不具合が出たらユーザーはどう困るか」からテスト観点を考えられるはずです。
自分の中でなんとなく考えていたことが、社外の方の口からも出てきた。そのことで、進む方向に自信が持て、プロダクトへの解像度を上げるためのCSへのチャレンジも、持ち帰りリストに加わりました。
肩書きや役割の名前ではなく、「どういう視点で仕事をしているか」がテスターとエンジニアを分ける。この話は、テスト設計のセッションの「なぜこのテストで十分かを説明できること」ともつながっていると感じました。説明できるということは、目的から考えられているということだからです。
「わからん」と口に出せる場があること。そして、社外のQAの方々と話せることのありがたさ。それを実感した2つのイベントでした。
関西付近でQAに関わっている方には、JaSSTもtestingOsakaのイベントもとてもおすすめです！
