Share
Embed
Slide 1
Slide 1 text
No content
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
3
ユニファ株式会社って、どんな会社？
保育施設向けの総合ICTサービス「ルクミー」を提供している会社です
Slide 4
Slide 4 text
4
ユニファ株式会社って、どんな会社？
Slide 5
Slide 5 text
5
ユニファ株式会社って、どんな会社？
Slide 6
Slide 6 text
今⽇のセッションの流れ（ざっくり）
6
最初に、Demoをお⾒せします！
Slide 7
Slide 7 text
今⽇のセッションの流れ（ざっくり）
7
⾼⽥が考えている「品質の本質」をベースに、
AIを活⽤したテスト設計について、お話します！
Slide 8
Slide 8 text
アジェンダ
● なめらかな"品質保証"と、その敵
● AIも理解できる「品質の構造」
● 「構造化」によるAIとの共創ワーク
フロー
● まとめ
8
Slide 9
Slide 9 text
9
なめらかな"品質保証"と、その敵
Slide 10
Slide 10 text
なめらかな"品質保証"と、その敵
10
技術スタック
● 「Cursor 」+ 「spec-kit」を使⽤
○ Claude codeや、Github Copilotなどに対応。
○ 対応の詳細は、
https://github.com/github/spec-kit?tab=readme-ov-file#-supported-ai-agentsを参照
願います。
○ spec-kit の“道具箱”（.specify/ 配下のファイル）を使⽤して、テスト設計をAIと共に作って
いきます。
Slide 11
Slide 11 text
なめらかな"品質保証"と、その敵
11
Demo
Slide 12
Slide 12 text
なめらかな"品質保証"と、その敵
12
Demoの内容
● 出⼒：以下のように出⼒（⼀部抜粋）
“spec.md”の⼀部を抜粋
Slide 13
Slide 13 text
なめらかな"品質保証"と、その敵
13
Demoの内容
● 出⼒：以下のように出⼒（⼀部抜粋）
“test-design.md”の⼀部を抜粋
Slide 14
Slide 14 text
なめらかな"品質保証"と、その敵
14
Demoの内容
● 出⼒：以下のように出⼒（⼀部抜粋）
「AIに丸投げしない」＝ 曖昧さを“管理”する
Slide 15
Slide 15 text
なめらかな"品質保証"と、その敵
15
なぜこれだけで、テスト観点が出るの？
↓
後半で、解説します！
Slide 16
Slide 16 text
なめらかな"品質保証"と、その敵
16
AI時代の開発スピードと「違和感」について
Slide 17
Slide 17 text
なめらかな"品質保証"と、その敵
17
AIの活⽤って、どれくらい普及してる？
Slide 18
Slide 18 text
なめらかな"品質保証"と、その敵
18
AI活⽤の実態（国内）
● Gartnerジャパン 2025年調査によると、国内企業の3分の1~約半数（31.8
〜49.0%）が既にAIコーディングツールを導⼊
○ 対象：⽇本国内でソフトウェア開発に従事する企業内個⼈ 「400⼈」（n = 400）
○ 「コード⽣成‧補完」では、49%
○ 「コード‧レビュー」では、40%
○ 「要件定義」では、39.8% etc…
○ 前回 (2024年6⽉) の調査時：各⼯程12.8〜21.2%
「Gartner、国内のソフトウェア開発における
AI活用の現状に関する最新の調査結果を発表」より抜粋
Slide 19
Slide 19 text
なめらかな"品質保証"と、その敵
19
AI活⽤の実態（国内）
● 更に、「AIツール利⽤者の過半数が⽣産性の向上を実感」
○ 対象：ソフトウェア開発においてAIツール∕サービスを使⽤していると答えた回答者「363
⼈」（n = 363）
○ ⼀位：「開発効率‧⽣産性の向上」（57.9%）
○ ⼆位：「コード品質の向上」(44.1%)
○ 三位：「ドキュメント品質の向上」(30.6%)
○ 「9割弱の開発者がAI活⽤をポジティブに捉えている」
「Gartner、国内のソフトウェア開発における
AI活用の現状に関する最新の調査結果を発表」より抜粋
Slide 20
Slide 20 text
なめらかな"品質保証"と、その敵
20
AI活⽤の実態（国内）
● 2025年度に⾏った、住友商事の「バイブコーディング体験研修」
○ 対象：プログラミング未経験者含む、住友商事に勤める社員の⽅々
■ 90分間で、様々な実⽤的なプロトタイプ作品を作成
○ 「研修後のアンケートでは90%以上が「何か⾃分でも作れそう」という変化を実感して頂き
ました」とのこと。
○ 技術習得だけでなく、「業務や⽣活における課題解決⼿段としてデジタル技術を捉える視
点」の変化
■ 「イメージを共有しあうモックアップ作成に利⽤したい」
■ 「新規サービスやプロダクトを作る際に、簡易的な検証⽤に使いたい」
「総合商社の文系社員が
AIプログラミングでアプリ開発。
90分で成果物実装まで行うバイブコーディング研修を住友商事にて実施。」より抜粋
Slide 21
Slide 21 text
なめらかな"品質保証"と、その敵
21
ほう。なら、海外は？
Slide 22
Slide 22 text
なめらかな"品質保証"と、その敵
22
AI活⽤の実態（海外）
● Cognizant、AIリテラシー向上のため世界最⼤規模の「Vibe Coding
Week」を開催
○ 対象：⼈事、営業、エンジニアリング、マーケティング部⾨など、25万⼈以上の従業員
○ 全社員25万⼈以上を対象に、AIエージェントを活⽤した開発イベントを実施
○ オンライン⽣成AIハッカソンの参加者数最多で、「ギネス世界記録™」のタイトル獲得を⽬指
しています。
「Cognizant Attempts World's Largest Vibe Coding Event to Accelerate AI Literacy Across Thousands of Employees」より抜粋
Slide 23
Slide 23 text
なめらかな"品質保証"と、その敵
23
結果：AI活⽤によってソフトウェア開発は、「爆速」になった。
Slide 24
Slide 24 text
なめらかな"品質保証"と、その敵
24
疑問：「テスト」と「品質保証」、置き去りになっていませんか？
Slide 25
Slide 25 text
なめらかな"品質保証"と、その敵
25
DORA (DevOps Research and Assessment) レポートを、⾒てみる
Slide 26
Slide 26 text
なめらかな"品質保証"と、その敵
26
"AI is an amplifier."（AIは増幅器である）
1. 「スループット」と「安定性」の不均衡（システム的な未成熟）
a. 開発者はAIを使ってかつてない速度で変更を⽣成‧コミットできるけど、下流⼯程にある
「テストやデプロイ」のパイプラインがその量と速度に対応できていない。
2. 「信頼」は、そんなに⾼くない（と、感じる）
a. ⽣成されたコードを「信頼している」と感じる回答者が70%いる⼀⽅で、残りの30%は、
「信頼がほとんどない」、もしくは「まったくない」と報告している。
3. 「検証の難化」と「認知摩擦」の移動
a. 「⼀⾒正しそうに⾒える」コード（⽣成AIが作ったコード）は、変更量の増加によって、検証
と調整のコストを増加させる可能性がある。
b. ⽣成されたコードを⼗分に理解‧検証せずに信頼してしまうと、微細なバグやシステムの不
整合が⾒過ごされる。
「Google Cloud DORA Report (2025): State of AI-assisted Software Development」より抜粋
Slide 27
Slide 27 text
なめらかな"品質保証"と、その敵
27
t-wadaさんは、なんて⾔ってる？（和⽥卓⼈さんの記事を⾒てみる）
Slide 28
Slide 28 text
なめらかな"品質保証"と、その敵
28
1. AIの登場は、問題の顕在化を圧倒的に早めた
a. そもそも、「昔からあった問題」ですよね？
i. 技術的負債の⾼速な積み上げによる開発のスループット低下も、コードレビューがボト
ルネックになることも。
2. 「ソフトウェアエンジニア以外の⼈々」に対する⾰命
a. これまで障壁となっていたコーディングという作業が、AIを⽤いることで簡単に突破できるよ
うになり、ソフトウェア開発の裾野がどんどん世界中に広がっていった。
3. 「労⼒は外注できるが、能⼒は外注できない」
a. ⼈間の設計判断能⼒を上げていくために必要なフィードバックは、⾃らの⼿でコードを書く
ことによって⼀番多く得られる。
b. ⼈間側の能⼒を上げていかないと、開発スピードや組織の能⼒は上がらない。
「t-wadaが説く、今あえて
“自分の手”でコードを書く理由「バイブコーディングは、エンジニアのためのものではない」より抜粋
Slide 29
Slide 29 text
なめらかな"品質保証"と、その敵
29
AI時代の開発スピードと「違和感」のイメージ
↓
「普通の乗⽤⾞に、F1のエンジンを搭載して動かす」ようなもの
Slide 30
Slide 30 text
なめらかな"品質保証"と、その敵
30
構造化能⼒がないままAIを使うと、「技術的負債が⾼速 / 爆速に」積み上がる
Slide 31
Slide 31 text
なめらかな"品質保証"と、その敵
31
設計などの基礎能⼒が不⾜していると、混乱を招く
Slide 32
Slide 32 text
なめらかな"品質保証"と、その敵
32
本当の（根本的、本質的な）「敵」は？
ここからは、高田の個人的な視点からみたものです。
Slide 33
Slide 33 text
なめらかな"品質保証"と、その敵
33
敵の本質：「◯◯◯◯」
Slide 34
Slide 34 text
なめらかな"品質保証"と、その敵
34
敵の本質：「バイアス」
Slide 35
Slide 35 text
なめらかな"品質保証"と、その敵
35
「バイアス：思い込み、勘違い」
Slide 36
Slide 36 text
なめらかな"品質保証"と、その敵
36
「バイアス：思い込み、勘違い」
↓
⼈間が潜在的に持っている、「不具合（バグ）」
↓
完全に失くすことは「不可能」だが、影響を最⼩限にすることは「可能」
Slide 37
Slide 37 text
なめらかな"品質保証"と、その敵
37
影響：「利⽤可能性ヒューリスティック」と「損失回避」による「偶像化」
Slide 38
Slide 38 text
なめらかな"品質保証"と、その敵
38
「利⽤可能性ヒューリスティック」
● 「頭に思い浮かびやすいもの」や「⽬⽴ちやすいもの」を選択してしまうこ
と
「損失回避」
● 「今の損失」を過⼤評価し、「将来の損失」を過⼩評価すること
「偶像化」
● 「こうするしかない！」と決めつけて、進むこと
「利用可能性ヒューリスティック」「
損失回避」は、「ファスト＆スロー 上・下
―あなたの意思はどのように決まるか？
―（ハヤカワ文庫
NF）」より抜粋
「偶像化」は、「戦略の要諦（日経
BP 日本経済新聞出版）」より抜粋
Slide 39
Slide 39 text
なめらかな"品質保証"と、その敵
39
影響：「利⽤可能性ヒューリスティック」と「損失回避」による「偶像化」
↓
「技術的負債が⾼速 / 爆速に」積み上がる、開発のスループットを低減させる
Slide 40
Slide 40 text
なめらかな"品質保証"と、その敵
40
「AIでのソフトウェア開発」は、どのように映る？
Slide 41
Slide 41 text
なめらかな"品質保証"と、その敵
41
System 1 (Fast：早い思考) vs System 2 (Slow：遅い思考)
↓
AIコーディング(System 1) vs Quality Assurance(System 2)
「ファスト＆スロー 上・下
―あなたの意思はどのように決まるか？
―（ハヤカワ文庫
NF）」より抜粋
Slide 42
Slide 42 text
なめらかな"品質保証"と、その敵
42
System 1 (Fast：早い思考)
● AIコーディング (System 1)： 早い思考で「作る」
○ 直感的に書けて、しかも⾼速 / 爆速で書ける。
○ かかる⼯数（コスト）や認知負荷を、省エネでき、「楽に」書ける
○ 「動いたからヨシ！」と判断しやすい
Slide 43
Slide 43 text
なめらかな"品質保証"と、その敵
43
System 2 (Slow：遅い思考)
● Quality Assurance(System 2)： 遅い思考で「検証する」
○ 体系的な⼿法や技法‧経験知を駆使して、ロジカルに考える
○ テストドキュメントのフォーマットでアウトプット
○ 「品質指標」を監視‧制御しながら、品質を判断
「品質指標」：定量的な「
Value（価値）を、ユーザーに届けられる状態にあるのか？」と、定性的な「
Value（価値）は、ユーザーにどれくらい届けられているのか？」を指す
Slide 44
Slide 44 text
なめらかな"品質保証"と、その敵
44
AIはコードを量産するが、テストコードや仕様書は後回し。
↓
「テスト設計に時間がかかる」「何を書けばいいかわからない」
↓
結果、「⾼速な技術的負債の積み上げ」につながりやすい
Slide 45
Slide 45 text
なめらかな"品質保証"と、その敵
45
「この機能のテスト書いて」と、AIエージェントに頼む
↓
AI「書きました（幻惑や情報過多）」→ ⼈間「ヨシ！（思考停⽌）」
↓
結果、形だけのテスト‧運⽤できないテストの⼭になり、AIへの丸投げに失敗
Slide 46
Slide 46 text
なめらかな"品質保証"と、その敵
46
敵の正体
↓
バイアスの影響により、テスト⾃⾝を楽しようとする
Slide 47
Slide 47 text
なめらかな"品質保証"と、その敵
47
問い
↓
AI時代の「品質」と、どう正対すべきか（向き合うべきか）？
Slide 48
Slide 48 text
なめらかな"品質保証"と、その敵
48
品質保証においても、「テストの構造化能⼒」「テスト設計⼒」が必要
Slide 49
Slide 49 text
なめらかな"品質保証"と、その敵
49
AI任せにするのではなく、AIも理解できる「品質の構造」を⼈間が設計する能⼒
↓
でも、どうやって？
Slide 50
Slide 50 text
なめらかな"品質保証"と、その敵
50
「品質保証の本質」を⾒てみる
Slide 51
Slide 51 text
AIも理解できる「品質の構造」
51
Slide 52
Slide 52 text
AIも理解できる「品質の構造」
52
Quality Assurance(System 2)： 遅い思考で「検証する」
↓
QAエンジニアの頭の中って、どうなってる？
Slide 53
Slide 53 text
AIも理解できる「品質の構造」
53
Where?
What?
How?
Slide 54
Slide 54 text
AIも理解できる「品質の構造」
54
1. Where? (テスト対象): どこをテストするのか？
a. どの機能か？、どのAPIか？、どのメソッドか？ etc…
b. CRUD（新規作成、読み込み、更新、削除）のどれ？
2. What? (テスト観点): 何をテストするのか？
a. 正常系？、異常系？
b. 「どういう状態のときに、何の操作をした時」の何の検証？
3. How? (テスト⽅法): どうやってテストするのか？
a. ⼿順など、具体的な操作⼿順は？
b. テストデータは？
c. テストパターンは、ある or ない？
Slide 55
Slide 55 text
AIも理解できる「品質の構造」
55
これらを、⾼⽥は「品質保証のゴールデントライアングル」と呼んでいます。
Slide 56
Slide 56 text
AIも理解できる「品質の構造」
56
同時に⾼⽥は、これらは「品質保証の本質」であると考えてます
Slide 57
Slide 57 text
AIも理解できる「品質の構造」
57
「テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02 p.20」より抜粋
Slide 58
Slide 58 text
AIも理解できる「品質の構造」
58
更に、QAエンジニアの「暗黙知」（AIエージェントが知らない）を⾒てみる
Slide 59
Slide 59 text
AIも理解できる「品質の構造」
59
Who?
Why?
Slide 60
Slide 60 text
AIも理解できる「品質の構造」
60
Who?（ユーザーのペルソナ、権限、コンテキスト）
↓
AIには「誰にとっての正解か」が⾒えていない
Slide 61
Slide 61 text
AIも理解できる「品質の構造」
61
Why?（システムの因果関係、⽬的、不変条件）
↓
「なぜその結果になるべきか」の意図が伝わっていない
Slide 62
Slide 62 text
AIも理解できる「品質の構造」
62
構造（Where/What/How）を整理する。
⽂脈（Who/Why）を明⽰する。
Slide 63
Slide 63 text
AIも理解できる「品質の構造」
63
「What You See Is What It Does（WYSIWID）」
Slide 64
Slide 64 text
「構造化」によるAIとの共創ワークフロー
64
Slide 65
Slide 65 text
「構造化」によるAIとの共創ワークフロー
65
“What You See Is What It Does: A Structural Pattern for Legible Software”
↓
Daniel Jackson教授とEagon Meng教授（どちらも、MITの教授）が提唱した
「ソフトウェアの可読性を⾼めるための構造パターン（Concepts/Syncs）と、
AIエージェントにおける「認知（See）」と「⾏動（Do）」の⼀致を⽬指すため
のモデル」
「What You See Is What It Does: A Structural Pattern for Legible Software」より抜粋
Slide 66
Slide 66 text
「構造化」によるAIとの共創ワークフロー
66
“What You See Is What It Does: A Structural Pattern for Legible Software”
↓
上記の論⽂をベースに、ソフトウェア（およびテスト）を3層で構造化する。
「What You See Is What It Does: A Structural Pattern for Legible Software」より抜粋
Slide 67
Slide 67 text
「構造化」によるAIとの共創ワークフロー
67
構造（Where/What/How）を整理する。
1. Concepts (概念)
a. 独⽴した状態とアクションを持つ機能単位。Page Object Modelにおけるページクラスのよ
うな、他と依存しない「個」としての存在。
2. Syncs（Synchronizations：同期）
a. Concepts同⼠の連携ルール。あるConceptの状態変化が、別のConceptにどう影響するか。
3. Actions (操作)
a. Conceptsに対する具体的なメソッド実⾏。クリックや⼊⼒などの具体的な操作⼿順。
「What You See Is What It Does: A Structural Pattern for Legible Software」より抜粋
Slide 68
Slide 68 text
「構造化」によるAIとの共創ワークフロー
68
構造（Where/What/How）を整理する。
1. Concepts (概念) ≒ Where? (テスト対象)
a. どの機能か？、どのAPIか？、どのメソッドか？ etc…
b. CRUD（新規作成、読み込み、更新、削除）のどれ？
2. Syncs (同期) ≒ What? (テスト観点)
a. 正常系？、異常系？
b. 「どういう状態のときに、何の操作をした時」の何の検証？
3. Actions (操作) ≒ How? (テスト⽅法)
a. ⼿順など、具体的な操作⼿順は？テストデータは？
b. テストパターンは、ある or ない？
「What You See Is What It Does: A Structural Pattern for Legible Software」より抜粋
Slide 69
Slide 69 text
「構造化」によるAIとの共創ワークフロー
69
⽂脈（Why/Who）を明⽰する。
1. Observer(視点) ≒ Who? (ペルソナ)
a. 「テストを誰の視点で評価するか」
i. 業務側ペルソナ
ii. 開発側ステークホルダー
2. Purpose/Causality(⽬的/因果関係)≒ Why? (条件や性質)
a. テストが判定（Oracle）できる形にした“チェック可能な不変条件‧性質”
i. 「なぜその結果になるべきか」（因果関係）
ii. 「なぜその順序で操作するのか」（時間的な順番）
iii. 「どのルールがどれに優先するのか」（優先順位）
Slide 70
Slide 70 text
「構造化」によるAIとの共創ワークフロー
70
手前味噌ですが、高田が書いた記事「進め！
“Vibe Testing”計画！ 〜AI開発推進部 QAの”初”挑戦〜」より抜粋
Slide 71
Slide 71 text
「構造化」によるAIとの共創ワークフロー
71
技術スタック（再掲）
● 「Cursor 」+ 「spec-kit」を使⽤
○ Claude codeや、Github Copilotなどに対応。
○ 対応の詳細は、
https://github.com/github/spec-kit?tab=readme-ov-file#-supported-ai-agentsを参照
願います。
○ spec-kit の“道具箱”（.specify/ 配下のファイル）を使⽤して、テスト設計をAIと共に作って
いきます。
Slide 72
Slide 72 text
「構造化」によるAIとの共創ワークフロー
72
spec-kit の“道具箱”（.specify/ 配下のファイル）
● .specify/memory/
○ constitution.md: プロジェクトの憲法（品質‧テスト‧設計の“交渉不可ルール”を固定し、以降の
判断基準にする）
● .specify/scripts/bash/
○ common.sh: 共通ライブラリ（repo root/feature dir の解決、spec.md/plan.md/tasks.md 等の
パス計算）
○ create-new-feature.sh: 新規featureの⼟台作成（NNN-... ブランチ/specs/NNN-.../spec.md をテ
ンプレから⽣成）
○ setup-plan.sh: plan.md の雛形作成（specs//plan.md をテンプレから⽣成）
○ check-prerequisites.sh: 前提チェック（feature dir と plan.md、必要なら tasks.md の存在確
認）
○ update-agent-context.sh: エージェント設定同期（plan.md から技術情報を抽出し、CLAUDE.md
や .cursor/rules/... 等を更新/⽣成）
Slide 73
Slide 73 text
「構造化」によるAIとの共創ワークフロー
73
● .specify/templates/
○ spec-template.md: spec.md の型（Concepts/Syncs中⼼。Who/Whyを落とす）
○ plan-template.md: plan.md の型（技術スタック‧構成を確定）
○ tasks-template.md: tasks.md の型（タスク分解フォーマット）
○ test-design-template.md: test-design.md の型（観点表/Viewpoint Matrix）
○ test-implementation-template.md: test-implementation.md の型（テスト実装⽅針）
○ test-execution-template.md: test-execution.md の型（実⾏記録）
○ test-report-template.md: test-report.md の型（結果/学び/次アクション）
○ checklist-template.md: チェックリストの型（漏れ/曖昧さ検出）
○ agent-file-template.md: Agent⽤コンテキストの型（各種Agentファイルの元）
Slide 74
Slide 74 text
「構造化」によるAIとの共創ワークフロー
74
.specify配下に、設定している内容
1. Plan & Spec (対話と構造化):
a. ユーザーストーリーをConcepts（機能単位の対象） と Syncs（観点） に分解する。
b. ここで必ず Who（権限/⽴場） と Why（意図/不変条件） を問い直し、spec.md を作る。
2. Design (批判的思考で設計):
a. spec.md を⼊⼒に、AIが Viewpoint Matrix（観点表） を出す。
b. ⼈間が Critical Thinking で⽳（例外‧競合‧前提崩れ）を指摘し、設計を完成させる。
3. Implement (コード⽣成):
a. Designに基づき、Concepts（機能単位の対象） と Syncs（Test Scenario） を⽣成する。
b. Actions（操作） はAIが補完する（⼈間は“構造”に集中）。
4. Review (実⾏と修正):
a. 実⾏して、壊れたら コードではなく構造（Spec/Design） をまず疑う。
Slide 75
Slide 75 text
なめらかな"品質保証"と、その敵
75
Demoの内容
● Promptの内容：以下の通り
○ 固定（基本コピペ）：指⽰の概要（テスト設計書の作成）、やること、出⼒形式の指定、制
約（ガードレール）を記述
○ 変動（⼈間側が書くところ）：スコープ内‧スコープ外の記述、ユーザーストーリー、Why
（構造的Why）とWho（ペルソナ）の記述
Slide 76
Slide 76 text
「構造化」によるAIとの共創ワークフロー
76
Demoの内容：「固定」(テンプレ＋ガードレール)
Slide 77
Slide 77 text
「構造化」によるAIとの共創ワークフロー
77
Demoの内容：「変動」（スコープ/ストーリー/Why/Who）
Slide 78
Slide 78 text
「構造化」によるAIとの共創ワークフロー
78
⼈間側のほうで考えること
1. Concepts（機能単位の対象）とSyncs（連携ルール）を定義すること
2. そして、「批判的思考（Critical Thinking）」で、その構造が正しいかを問
い続けること
Slide 79
Slide 79 text
「構造化」によるAIとの共創ワークフロー
79
1. 単なる「ノリ（Vibe）」ではない。
2. 「なめらかな品質保証（Smooth QA）」を実現するアプローチ。
a. 「QAエンジニアの経験知（Golden Triangle）」を「構造（Structure）」に変換し、AIと共
に品質をエンジニアリングする⼿法。
3. 敵（バイアス）に対抗するために、「品質の構造（Structure）」をAIも理
解できる形にし、System 2の思考をAIと共に⾼速化（System 1化）する⼿
法。
Slide 80
Slide 80 text
まとめ
80
Slide 81
Slide 81 text
まとめ
81
1. 「敵（バイアス）」を知る: ⾃分たちがSystem 1（直感）で楽をしようとし
ていることを⾃覚する。
2. 「Easy」に逃げない: AIに丸投げせず、「Who/Why」を⾔語化し「品質の構
造」からテストを作る。
3. 能⼒を磨く: 「批判的思考（Critical Thinking）」で品質をデザインする。
a. JSTQB (Version 2023V4.0.J02) でも、テストに不可⽋なスキルとして「分析的思考、批判的
思考、創造性」が定義されている。
b. AIが出してきた答えを鵜呑みにせず（System 2）、構造の正しさを問う⼒が求められる。
Slide 82
Slide 82 text
82
⾼⽥が考えているQAエンジニア像は、「品質という”誰かにとっての価値”を語る
ストーリーテラー」になること
↓
「品質のモデラー」へと進化しなければならない
Slide 83
Slide 83 text
83
「作業はシュリンクするが、品質をエンジニアリングすることは無くならない」
Slide 84
Slide 84 text
84
Appendix
Slide 85
Slide 85 text
Appendix
85
● 「Gartner、国内のソフトウェア開発におけるAI活⽤の現状に関する最新の調査結果を
発表」
● 「総合商社の⽂系社員がAIプログラミングでアプリ開発。90分で成果物実装まで⾏う
バイブコーディング研修を住友商事にて実施。」
● 「Cognizant Attempts World's Largest Vibe Coding Event to Accelerate AI
Literacy Across Thousands of Employees」
● 「t-wadaが説く、今あえて“⾃分の⼿”でコードを書く理由「バイブコーディングは、
エンジニアのためのものではない」
● 「進め！“Vibe Testing”計画！ 〜AI開発推進部 QAの”初”挑戦〜」
● 「Google Cloud DORA Report (2025): State of AI-assisted Software
Development」
Slide 86
Slide 86 text
Appendix
86
● 「ファスト＆スロー 上‧下 ―あなたの意思はどのように決まるか？―（ハヤカワ
⽂庫NF）」
● 「戦略の要諦（⽇経BP ⽇本経済新聞出版）」
● 「テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02 p.20」
● 「What You See Is What It Does: A Structural Pattern for Legible Software」
● 「spec-kit（コーディングエージェントを利⽤した仕様駆動開発（Spec-Driven
Development）のためのツールキット）」
● 「批判的思考」（Wikipedia）
Slide 87
Slide 87 text
87
ユニファ開発チーム、仲間を探しています
お知らせ
ユニファ株式会社 会社紹介資料（開発チーム版） / Unifa inc
information for dev team - Speaker Deck
Slide 88
Slide 88 text
88
ご清聴、ありがとうございました！