こんにちは！ソフトウェアエンジニアの中田です。
少し前になりますが、2025年3月に開催された「JaSST'25 Tokyo（ソフトウェアテストシンポジウム 2025東京）」に参加しました。今回は、AIを活用したテスト手法、テストプロセスの改善、テストコードの可読性向上、モバイルアプリケーションのテスト戦略など、実践的なテーマが数多く取り上げられていました。
この記事では、いくつかのセッションについて筆者のメモを残しています。
- JaSST'25 Tokyo について
- B6：AIによるソフトウェア品質保証の現在地点とこれから
- A5：「保証するための品質基準」がQAには必要か？
- A3：テストだけでは終わらない！継続的な品質向上を実現するために、事業会社、ツールベンダー、第三者検証の3社が考えるアプローチとは？
- B7：現場からお届けします〜モバイルアプリテストにおける工夫と挑戦〜
- B3：Agile TPIを活用した品質改善事例
- A9：リーダブルテストコード〜メンテナンスしやすいテストコードを作成する方法を考える〜
- まとめ：JaSST'25 Tokyoから得られた学び
JaSST'25 Tokyo について
JaSST'25 Tokyo（ソフトウェアテストシンポジウム 2025 東京）は、2025年3月27日(木)〜28日(金)に開催された、日本のソフトウェアテストに関する主要なシンポジウムです。シンポジウムには約2550名の参加者が集まり、盛況のうちに終了したことが報告されています *1
詳しくは JaSST'25 Tokyo ご確認ください。
B6：AIによるソフトウェア品質保証の現在地点とこれから
生成AIとソフトウェアテストの関係を、産業界と学術界それぞれの立場から議論し、現在地と未来を見通すことを目的にしたトークセッションです。登壇者には、学術的視点から石川さん（国立情報学研究所）、産業界からは松浦さんと守屋さん（ともにAutify）が参加。モデレーターは末村さん（Autify）です。
特に Autify 松浦さんが開発されている「Autify Genesis」に興味を持ったため、本記事ではその内容をピックアップしました。
Genesisは、仕様書などの文書から自動でテストケース・テストシナリオ・テストコードを生成するツールで、AIが何を・どうテストするかを提案し、必要に応じてユーザーと対話しながらコード等を出力するそうです。
次のようなプロセスで進む：
- 仕様書や設計書などを読み込み、テスト観点を抽出
- ユーザーがレビューし、問題がなければテストシナリオに変換
- シナリオに基づき、E2Eテストコードを自動生成
- 不明点があればユーザーに質問し、回答を反映
入出力の課題：
- 生成されたテストシナリオ・コードの正確性は人間のレビューが必要
- 入力文書の品質（網羅性/明確さ/記述形式）に大きく依存
- 曖昧や矛盾した仕様では、AIも間違ったテストを生成してしまう
Genesis開発から得られた学びとして：
- 生成AIは「入力」が全て。良い出力には良い入力が不可欠
- 曖昧さのない仕様を書く力が重要。AIを活かすには「明示的に、構造的に仕様を書く力」が必須
A5：「保証するための品質基準」がQAには必要か？
このセッションでは3名のパネリスト、湯本さん（yttelab）、末村さん（Autify）、河野さん（ナレッジワーク）が、QAゼミでの議論を基に「ソフトウェアQAにおける品質基準の必要性」について深く議論されています。
問題提起として「ソフトウェアのQAとして、何を保証しているのか」という疑問と、「品質保証と言いながら、顧客に対する明確な約束（品質基準）がないケースが多い」という現状認識から始まりました。
品質基準は「ユーザーにとっての価値を何らかの尺度で捉え、どの程度であれば達成できるのかを定めたもの」と定義され、ソフトウェアを以下のように分類して考察が進められました。
製品特性による分類
- 左下：製品性が強く変更困難なもの（パッケージソフト） → 品質基準が向いている
- 右下：アート性が強く変更困難なもの（昔のゲームなど） → 品質基準はやや向かない
- 左上：製品性が強く変更容易なもの（SaaS toB） → SLAが重要
- 右上：アート性が強く変更容易なもの（エンタメ系アプリ） → 品質基準は向かない
変更容易性／変更困難性
- 変更が容易なソフトウェアは厳格な品質基準より、変更を前提とした基準が適切
- 変更が困難なソフトウェアには明確な品質基準が必要
一つのプロダクトでも機能ごとに分解して考える
また、プロダクト分解によるアプローチも提案され、一つのプロダクトでも機能ごとに分解して考えるべきという視点です。
- ログイン機能：製品性が高く、変更困難→厳格な品質基準が必要
- データ処理部分：製品性が高く、変更容易→基盤としての品質基準が必要
- 製品名/機能名：変更困難で製品性が高い→明確な基準が必要
- 画面レイアウト：変更困難だがアート性もある→デザイナーとの協業が必要
- 画面デザイン：アート性が高く変更も可能→柔軟な基準でよい
重篤度による考え方
重篤度による考え方も紹介され、重篤度が高い部分（変更困難で製品性が高い部分）には特に明確な品質基準を設け、重篤度が低い部分は相対的に基準を緩くしてもよいとされました。
Production Readiness Checklist
最後に、Production Readiness Checklistとの関係にも触れられ、これをサービスをデプロイする前に確認するチェックリストとして、特に非機能要件の観点から品質基準の一部として捉える考え方が示されました。
A3：テストだけでは終わらない！継続的な品質向上を実現するために、事業会社、ツールベンダー、第三者検証の3社が考えるアプローチとは？
事業会社（KINTOテクノロジーズ：橋爪さん）、ツールベンダー（MagicPod：伊藤さん）、第三者検証会社（ポールトゥウィン：木川さん、尾崎さん）の3社のトークセッション。「テスト」だけではなく「品質向上」を目指すための具体的な取り組みが共有されました。
テストは目的ではなく手段
- テスト実施がゴールではなく、プロダクト全体の品質を向上させるために、テスト・自動化・文化形成を活用する意識が必要
- 「テスト完了」ではなく「品質向上」がゴール
継続的な品質向上には「自動・手動の組み合わせ」が重要
- 手動テストと自動テストはどちらか一方では不十分
- プロジェクト特性に応じて柔軟に組み合わせることが成果につながる
自動化成功のカギは「日常的な運用」
- 自動テストは毎日回して成功率を維持することで真価を発揮する
- リリース直前だけテストする運用では効果が限定的
- 自動テストの結果を継続的に分析し、テスト自体の品質も向上させる
第三者検証会社は「作業者」ではなく「品質パートナー」として伴走
- 従来のテスト実施者ではなく、品質向上に伴走する存在と位置づけるべき
- 上流から巻き込んで、テスト設計や改善にも関与してもらう
- コミュニケーションを密にし、お互いの状況や課題を共有する関係性が重要
品質文化は「自社で育てる」もの
- 開発者・QA・第三者検証が一体となって品質への意識を醸成する
- 品質に対する共通理解を持ち、開発全体を巻き込んでいくことが重要
- 長期的な視点で、品質を重視する文化を作り上げる
B7：現場からお届けします〜モバイルアプリテストにおける工夫と挑戦〜
Voicy（森田さん）、メルカリ（梅津さん）、マネーフォワード（藤さん）のQA担当者が、モバイルアプリテストの現場課題と工夫について紹介されました。共通テーマは「リリーススピードと品質のバランスをいかに保つか」です。
スピードと品質のバランス
メルカリ ハロ
- 「リリース判定テスト」として最低限守りたい機能に絞った手動テストを実施
- テストケースは増やさない方針で、必要最小限を週次で見直し
- PRマージ時に一部自動テストも実行し、継続的な品質担保を図る
マネーフォワード
- MagicPodで毎晩自動テストを実行し、判定会議を簡素化することでスピードを確保
- 品質基準は「変更規模に対してバグ件数○件以内」といった指標ベースで客観的に判断
- フロントエンドよりバックエンドで検証可能なロジックは、バックエンド側に集約しテストを効率化
Voicy
- 人力によるリグレッションが主だが、常に改善を模索
- 「1日で終わる」ことを基準に、テストケースを大幅整理し、本当に必要なテストに集中
- リリース頻度を調整（収録アプリと再生アプリを隔週でリリース）することで改善余地を確保
E2E自動テストの運用
メルカリ ハロ（Flutterによるクロスプラットフォーム開発）
- WebView画面にPlaywrightでE2Eを実装
- マージ時と毎朝に自動実行する仕組みを構築
- 優先度（ビジネス影響度）に基づきテストケースを段階的に拡充中
- 単一コードベースのメリットを活かして一方のOSで通れば、もう一方をスキップする工夫
- ただし、OS 依存の機能や不具合のリスクに注意が必要
マネーフォワード（ネイティブ開発）
- 自動テストは全件、リリース対象ブランチに対して毎晩実行
- 実行時間は問題になっておらず、幅広くカバレッジを確保
- 疑陽性のチェックも含めて1日15分程度のメンテナンスで運用できている
- Android/iOS 別だが、バックエンドとの切り分けを徹底し、無駄なUIテストは省略
QA改善のためのリソース捻出工夫
- リリース頻度を調整し QA 改善工数を捻出（Voicy）
- チームの目標に QA 施策を入れることで、開発者の巻き込みを促進（共通）
- 改善文化は組織構造に左右されるため、開発チームとの距離感が重要な鍵
B3：Agile TPIを活用した品質改善事例
Agile TPIを活用した品質改善事例 - Speaker Deck
ヒューマンクレストの浅黄さんによるセッションでは、Agile Test Practice Improvement（Agile TPI）を活用してテスター不在の開発チームの品質を劇的に改善した事例が紹介されました。セッションの最後に、生成AIによるテストプロセスへの影響についても触れられています。
なお「Agile TPI」の日本語翻訳版は Agile Test Practice Improvement (Agile TPI) | TMap からダウンロードできるようです。
Agile TPIの仕組み
基本構造：
- 16のキーエリア：改善すべき領域（人との関係性、テスト関連、テストツール関連）
- 3つのカテゴリー：プロフェッショナル（個人）、チーム、組織
- 108のチェックポイント：Yes/Noで答える質問形式
- 優先度とクラスター：どこから改善すべきかの指針
実践方法：
- 現状評価：優先度の高いキーエリア、かつクラスタAのチェックポイントを確認し、Noになっている項目を特定
- 問題点の洗い出し
- 改善施策の立案・実行
- 3ヶ月ごとに評価・振り返り
具体的な改善施策
開発チーム内の品質意識の向上
- 週1回のQAセミナー実施（全員参加、営業も含む）
- テスト技術の学習会（ISTQB教材使用、アジャイルQAの輪読会、BDD/TDD学習など）
- 狩野モデル（当たり前品質・魅力的品質）についてのディスカッション
- 自社サービスの品質分類ワークショップ
テストケース作成をシフトレフト
- コーディング前にテスト設計・テストケース作成を完了する
- 開発者自身がテストケースをバックログに記入し、スクラムマスターやPOが確認後に実装
- テストケースの書き方を統一（標準フォーマット導入）
事例：Greenwich社での取り組み
初期の課題として、
- QA体制がなく、テスターが不在で開発者がテストを実施していた
- 新機能のテストはできてもリグレッションテストができておらず、ユーザーから不具合報告が上がる状況だった
最初にヒアリングして「メンバーの品質意識を高める」「より良いサービスを提供する」という目標を設定。その結果、予想以上のテストスキル向上が見られた。
- 開発者のテストスキル向上：基本的なテストだけでなく、網羅率の高いテスト設計や影響範囲を意識したテスト設計が可能に
- サポートメンバーも巻き込み：開発者作成のテストケースをサポートメンバーが実行するプロセスにより、顧客視点のフィードバックが開発側に還元される好循環が生まれた
AIによるテストプロセスへの影響
テストプロセスへのAI導入事例
- 画面仕様書からテストケース自動生成（1ヶ月 → 2日に短縮）
- 音声入力によるバグチケット作成（1時間 → 数分に短縮）
- プロダクトバックログの影響分析（新機能と既存システムの影響関係を分析）
重要なポイント
- AIは「ツール」であり、最終責任はQAエンジニアにある
- AIの出力を鵜呑みにせず、専門知識で検証することが重要
- QAエンジニアには従来のテスト技術、ドメイン知識に加え、生成AIの特性理解と批判的思考力が必要
A9：リーダブルテストコード〜メンテナンスしやすいテストコードを作成する方法を考える〜
このセッションでは、和田さん（タワーズ・クエスト、t_wadaさん）、末村さん（Autify）、風間さん（B-Testing / 10X、ブロッコリーさん）が、テストコードの可読性と保守性向上に焦点を当て、異なる視点から実践的なアプローチを紹介されました。
テストコードの認知負荷を下げる（和田さん）
認知負荷の概念を用いてテストコードの問題点を分析し、次のように整理されています：
課題内在性負荷（対象の複雑さ）
- 対象の世界そのものが持っている複雑さに起因する認知負荷
- 問題領域が本質的に持っている複雑さ
- この負荷は下げることを目指さない（対象の本質的な複雑さだから）
課題外在性負荷（書き方の問題）
- 本質的な負荷とは別に発生する、不必要な認知負荷
- テストコードの書き方の問題に起因する負荷
- 発生要因：不適切なテストコードの構造、不明確な変数名、抽象的なテストケース名、テストの意図が不明確な実装
改善アプローチとして：
- 課題外在性負荷を最小限に抑える
- テストの本質に関係ないものはヘルパー関数などに外出しする
- Arrange-Act-Assertの構造を明確にする
- 適切な名前付けを行う
書籍『Googleのソフトウェアエンジニアリング』の引用も紹介。
テストの本体部分は、重要でない情報や紛らわしい情報は全く含まずに、テストを理解するのに必要な情報を全部含むべきである
コンテキストを明示化する（末村さん）
エンドツーエンドテストが特に手続き的になりがちな点に着目し、次の工夫を提案されています：
- ログイン状態などのコンテキストを関数化（例：
I.amStoreStaff()） - あるページにいるというコンテキストを明確化（例：
I.shouldBeOnItemDetailPage()） - データ準備を抽象化（例：
I.haveItem()）
これらの工夫により、テストコードが自己説明的になり、認知負荷が軽減される。
テストコードにテストの意図を込める（ブロッコリーさん）
テストコードの可読性向上によって、次の品質が向上するという考えを示されました。
- 修正容易性・変更容易性（リファクタリングが高める）
- 理解容易性
- 説明容易性（ブロッコリーさんオリジナルの用語）
特に「説明容易性」という新しい概念を用いて「このテストが何をやっているのか、他の人に説明しやすいかどうか」という指標を提案。これがテストコードの品質を考える上での重要な視点だと強調されました。
テストの意図を明確にする利点として：
- 特別な設定値とそうでない値が区別できる
- 仕様変更時にテストの削除判断が容易になる
- コードの説明容易性が向上する
「手動設定ありのパターン」→「手動設定の値があれば必ず最終的な在庫数として上書き設定する」と改善された例を挙げ、会話を通じてテストの真の意図を引き出し、それをメソッド名に反映することで、誰が見ても「このテストで何を確認したいのか」が一目瞭然になると説明されました。
パネルディスカッションのハイライト
テストピラミッドの戦略
- E2Eテスト: 正常系の主要導線、ユーザー体験の保証。E2Eテストですべてをカバーしようとしない（代表値のみ）
- ユニットテスト: 詳細な検証、例外系の網羅。ユニットテストは速度と安定性を活かして網羅的に
- 正常系は各レベルで重複してもよい
AIリーダブルの重要性
- 最新の傾向として、アクセシビリティの高いUIはテスタビリティも高い
- 生成AI（Playwright MCP等）への対応が進んでいる
- 意図が明確なテストコードは生成AIにも理解しやすい
テストデータ管理の重要性
- テストごとに適切なデータを準備する（テストの独立性を担保）
- 本番データは、テスト観点に合致する場合に使用する
- テストの意図を明確にするためにデータを適切に設計
- テストデータ管理はテストコード管理以上に難しい領域
- テストシナリオは5行程度に収める（BRIEFの原則 *2 ）
まとめ：JaSST'25 Tokyoから得られた学び
初めてJaSSTに参加しましたが、品質基準の考え方、テストコードの可読性、生成AIの活用など、実践的な知見に溢れた充実した内容でした。現場で即活かせる学びが多く、次回の参加が今から楽しみです。
以下にJaSSTから得た気づきをまとめます。
- 生成AIとの共存が進む
- 生成AIは強力なツールだが、人間の専門知識と組み合わせることで最大の効果を発揮する
- 良質なインプット（仕様書等）があってこそ、AIの出力も質が高くなる
- 生成AIツールの導入により、1ヶ月 → 2日など劇的な効率化も可能になりつつある
- ただし、AIはあくまでツールであり、最終責任はQAエンジニアにある。AIの出力を鵜呑みにせず、専門知識で検証する姿勢が重要
- 柔軟に品質基準を設ける
- 一律の基準ではなく、製品特性（アート性/製品性）や変更容易性に応じた品質基準の設計が重要
- プロダクト内でも機能ごとに分解して考えるアプローチが効果的
- 重篤度が高い部分には明確な品質基準を、低い部分は相対的に基準を緩くする柔軟性が必要
- テスト戦略
- 自動化は手段であり目的ではない、日常的な運用が真価を発揮する
- 手動テストと自動テストの最適な組み合わせがプロジェクト成功の鍵
- 毎日テストを実行し、成功率を維持する継続的な取り組みが効果的
- 可読性の高いテストコードは理解容易性、説明容易性、変更容易性につながる
- テストの意図を明確にすることで、コードのメンテナンス性が向上する
Goodpatchではデザイン好きなエンジニアの仲間を募集しています。 少しでもご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！
