- 2026/3/20
- https://jasst.jp/tokyo/26-about/
曖昧な要求は仕様かバグか？―AI時代の仕様とテストを考える
苅田 蓮さん(freee)
栗田 太郎さん(freee)
- 要求工学
- 機能要求/非機能要求
- プロセス/獲得/仕様/妥当性確認/変更
- 用語
- 要求
- 具体的な要求だけでなく課題やアイデア制約なども
- 仕様
- 何を作るか考えた後の内容やその文書
- 外から見えるもの
- 設計
- どう作るのか
- 仕様が設計に踏み込まないようにするのが重要
- 外には影響のない中のもの
- 要件という言葉は英語だと出てこない
- requirementsを要件と訳する世界線もあった
- 要求
- 要求の種類
- ビジネス要求/プロダクト要求
- ユーザ要求
- 移行要求/運用要求
- システム要求/ソフトウェア要求
- これらを機能要求と非機能要求に
- そこから機能仕様と非機能仕様ができる
- ISO/IEC 25010:2011
- 製品の品質特性
- 機能適合性
- 完全性/正確性/適切性
- 明示的ニーズと暗黙的ニーズを満足させる機能の提供度合い
- 性能効率性
- 互換性
- 仕様性
- 信頼性
- セキュリティ
- 保守性
- 移植性
- 用語
- Verification
- 検証
- 正しく作っているか
- Validation
- 妥当性確認
- 正しいものを作っているか
- Verification
- 要求獲得
- Requirements Elicitation
- インタビュー
- エスノグラフィー
- 要求の仕様化
- 要求仕様/SRS(Software Requirements Specification)
- 自然言語
- 図表や図記法
- 数学的記法
- 形式手法
- 形式仕様記述
- どんな時にでも必ず成り立つ
- 仕様に何を書くか
- 機能名
- 概要
- 入力
- 出力
- 事前条件
- 実行される前に保証されるべき条件
- 事後条件
- 事前条件が満たされる時に機能の実行後に保証される条件
- 不変条件
- 事前が満たされれば事後が保証されるという関係
- LLMと要求工学
- 実務導入は初期段階
- 90%以上はコンセプトレベルかPoC段階
- 仕様の妥当性確認でのLLM活用
- LLMがステークホルダーの要求表現を支援
- 暗黙知を引き出すことにつながる
- 人とLLMで並行して作業
- 差分を見て取り込んでいく
- 要求の仕様化でのLLM活用
- エピックやユーザストーリーを含む仕様書を自動生成
- 効率化にはなる
- 曖昧な要求を誤解したりハルシネーションもまだ多い
- 人間の監督は必要
- 仕様の検証でのLLM活用
- LLMに仕様記述とドメイン知識と要求を与え仕様が要求を満たすか判定
- 仕様の妥当性確認でのLLM活用
- ユーザに見せる文言のレビュー
今日から始められるテスト自動化
伊藤 由貴さん(MagicPod)
- テスト自動化
- 広義
- テストレベル/テストタイプを問わず自動化
- 狭義
- テスト実行の自動化
- 広義
- なぜテスト自動化するのか
- 効率性の向上
- 総テストコストの削減
- カバレッジの向上
- 組織でシステムテスト自動化
- 目的設定 - ツール選択検証 - 導入 - 運用
- テスト自動化の目的の設定
- なぜ取り組むか共通認識を
- 方向性がブレるのを防ぐ
- 効果検証する時の指針に
- As-Is/To-Beから理想と現実のギャップを整理
- それを埋めるための対策の1つ
- テスト自動化が手段として本当に有効なのか
- なぜ取り組むか共通認識を
- システムテストツール選定
- 単体テスト/結合テスト/非機能テストは選択肢が絞られてるから迷いづらい
- システムテストはツールの選定から
- 大前提
- 自分たちのサービスが動かせるものか
- 社内のルールに適合しているか
- セキュリティ的なところとかも
- 選択の軸
- 有料なのか無料なのか
- サポートの有無
- 学習コスト
- ローコード/ノーコードなのかコーディングするのか
- 誰が作成/実行/メンテするか
- まずは試してみる
- 有料ツールもトライアルとかある
- テスト自動化の導入
- スモールスタートから
- 属人化させずに誰でもメンテできるように
- メンテナンスを当番制にするとか
- テストを日々実行する
- テスト自動化の運用
- これが一番だいじなフェーズ
- どう始めるかに意識が向きがち
- 日々のサイクル
- 実行 - 結果確認 - メンテナンス
- 失敗が多くて対応が間に合わないとか
- アプリではなくてテスト起因とか
- 失敗が続くとオオカミ少年化する
- バグを検知しても信じてもらえない
- 自動テストの修正の優先度が下がる
- テストはメンテナンスが必要
- テスト対象に変更があったら対応が必要
- 何もしてないのに壊れることがある
- テストを上手に作る
- E2Eなど細かくたくさん作りすぎない
- 生成AI活用
- テストコードを生成させるとか
- たくさん作りすぎたり
- メンテナンスはスキルのある人が必要
- テストコードを生成させるとか
AIがQAエンジニアの仕事を奪うのか？
安野 貴博さん(チームみらい)
豊田 悠太さん(テクバン)
長島 貴雄さん(テクバン)
- コーディングの変化
- ここ1年で大きく変わった
- AIコーディングエージェントを使わないことが考えられない
- AIとセキュリティ
- 国政政党として海外製のツールを使っていいのか
- チャットやメールのツールは海外の製品をすでに使ってる
- 学習に使われないなら問題なしの判断
- 人のQAじゃないとできないこと
- 使い心地など感覚的なところ
- アニメーションとか時間経過を伴うようなところはまだAIは苦手
- 人とAIの組み合わせ
- AIで偽陽性は許容して広く検知
- それを人がチェック
- これからQAエンジニアは何をするべきか
- 開発エンジニアもキャッチアップの速度は人それぞれ
- まずはさわってみるところから始めていく
- 実世界の情報をどれだけ広く見えているかが人が勝ってるところ
- 暗黙知を形式知にできる組織が有利になってくる
- QAのしごとはAIに置き換わるのか
- ジュニアレベルのQAは今もうAIができている
- ジュニアレベルは不要になるがその先のレベルにいきなり挑戦できる状態
- 信頼のおけるAIの基準
- 人の期待に対するベンチマークを積み上げる
- 問題が起きたことを検知できるオブザーバビリティ
- 間違ったことをした時のリカバリーやフォールバックの仕組み
- ケンタウルス状態
- AIに人が介在する方がいい状態
- この状態は一定期間ある
- AIだけの方がよくなる時は来るがそれまでの間の付き合い方をよく考えるといい
Beyond Quality Assurance -AIと拓くQAの未来像-
池之上 あかりさん(LINEヤフーコミュニケーションズ)
平田 香織さん(LINEヤフーコミュニケーションズ)
- ニューロロジカルレベル
- 自己認識
- 信念/価値観
- 能力/スキル
- 行動
- 環境
- 上の層ほど舌のそうに対する影響が大きい
- 上の層同士で摩擦があると下の層が機能しなくなる
- QAエンジニアのAIに対する向き合い方もニューロロジカルレベルに当てはめていい方向にする必要がある
- 今までやってきたことはレベルの下の3層
- ブレーキは上の層
- 自分たちは何者か
- これまではプロダクトの品質を保証する人
- これからは多角的にみてプロダクトの価値を認める共創者
- 自己認識の変化は知るだけでは変わらない
- 業務を通してインストールしていく必要がある
- 当てはまらない活動は手放してAIに任せる
- やるべきことは人に問うようにプロンプトを調整
- AIによる能力拡張の成功体験
人と関わるロボットの研究開発
石黒浩さん(大阪大学)
- ロボットが社会に入る研究
- 1997年からやっている
- ロボットの人間らしさの重要性
- 人間向けの信頼をもたらす
- 人間らしさの品質保証はどうなるのか
- 人間とロボットは区別すべきものなのか
JISマーク認証のその先へ
伊藤 潤平さん(ウイングアーク１ｓｔ)
永井 潤也さん(ウイングアーク１ｓｔ)
安田 昂平さん(ウイングアーク１ｓｔ)
https://speakerdeck.com/sadonosake/jismakuren-zheng-nosonoxian-he-shi-ye-tosite-mai-reru-sabisunopin-zhi-bao-zheng-tohahe-ka-zong-wu-da-chen-ren-ding-taimusutanpusabisunoli-ce
品質を経営にどう語るか
kyon_mmさん(デロイトトーマツ)
naco_mmさん(キャディ)
moriyuyaさん(witch&wizards)
https://speakerdeck.com/kyonmm/communicating-the-strategic-value-of-quality-to-executive-leadership
めちゃくちゃ開発するQAエンジニアになって感じたメリットとこれからの課題感
山本 龍平さん(estie)
https://speakerdeck.com/ryuhei0000yamamoto/metiyakutiyakai-fa-suruqaenzinianinatutegan-zitameritutotokorekaranoke-ti-gan
QAプロセス AI支援ツールキットの導入とその効果について
引持 力哉さん(LegalOn Technologies)
https://speakerdeck.com/legalontechnologies/qa-process-ai-toolkit
主体的に活躍する内製QA組織の作り方と組織文化の醸成
金子 佳樹さん(ラクス)
https://speakerdeck.com/rakus_dev/how-to-build-a-proactive-in-house-qa-organization-and-foster-its-culture
事例から紐解くSHIFT流QA支援
纐纈 望さん(SHIFT)
https://speakerdeck.com/shift_evolve/20260320-nozomu-koketsu
仕様漏れ実装漏れをなくすトレーサビリティAI基盤のご紹介
国分 佑樹さん(コインチェック)
https://speakerdeck.com/orgachem/shi-yang-lou-reshi-zhuang-lou-rewonakusutoresabiriteiaiji-pan-nogoshao-jie
体験しながら作るクラシフィケーションツリーテスト
風間 裕也さん(10X)
https://speakerdeck.com/nihonbuson/classificationtreetechnique2025
欠陥分析（ODC分析）における生成AIの活用プロセスと実践事例
石井 優さん(SHIFT)
山腰 直樹さん(SHIFT)
吉澤 麻由さん(SHIFT)
https://speakerdeck.com/shift_evolve/20260320-suguru-ishii-and-naoki-yamakoshi-and-mayu-yoshizawa
あなたのシステムの壊し方
末村 拓也さん(Ubie)
https://speakerdeck.com/tsuemura/breaking-your-system
SIerの大規模案件で探索的テストを続けてみたら
吉村 優さん(NTTドコモソリューションズ)
https://speakerdeck.com/y_yoshi_m/siernoda-gui-mo-an-jian-detan-suo-de-tesutowosok-ketemitara
ビルドトラップを脱却し、真に顧客満足を実現するチームへ
赤﨑 光さん(カオナビ)
https://speakerdeck.com/pikazakipika/birudotoratupuwotuo-que-si-zhen-nigu-ke-man-zu-woshi-xian-surutimuhe
境界メルトモードへの道
徳田 紗矢香さん(アジャイルウェア)
水島 友利絵さん(アジャイルウェア)
山田 恭平さん(アジャイルウェア)
https://www.docswell.com/s/1821441/59N8W9-2026-03-20-114027
LLMでもいつものテスト技術
水谷 太一さん(サイボウズ)
https://speakerdeck.com/cybozuinsideout/jasst2026tokyo_mizutani
生成AIで速度と品質を両立する、QAエンジニア・開発者連携のAI協調型テストプロセス
生成AI活用でQAエンジニアにどのような仕事が生まれるか
井芹 洋輝さん(SigSQA)
https://speakerdeck.com/goyoki/support-required-of-qa-engineers-for-generative-ai
生成AI時代、ソフトウェア品質保証のロールと組織はどこへ向かうのか？
井芹 洋輝さん(SigSQA)
伊藤 潤平さん(ウイングアーク１ｓｔ)
小島 直毅さん(Adobe)
常盤 香央里さん(グロース・アーキテクチャ＆チームス)
三輪 東さん(SCSK)
山本 久仁朗さん(Omiai)
https://speakerdeck.com/sadonosake/aishi-dai-noqaenzinianojia-zhi-toha
スケールアップ企業でQA組織が機能し続けるための組織設計と仕組み
テストプロセスにおけるAI活用：人間とAIの共存
蛯子 将樹さん(hacomono)
滝田 啓介さん(hacomono)
https://speakerdeck.com/hacomono/tesutopurosesuniokeruaihuo-yong-ren-jian-toainogong-cun
