fukabori.fm出張版：AI駆動開発でテストエンジニアは不要になるのか / 20260723 Yoshimasa Iwase & Tomoo Morikawa

Embed

Start on current slide

Slide 1

Slide 1 text

AI DevEx Conference 2026 2026 7 / 23 11:35-12:15 fukabori.fm ホスト fukabori.fm出張版: AI駆動開発でテストエンジニアは不要になるのか株式会社SHIFT プロダクトマネージャー／エンジニアリングマネージャー岩瀬義昌森川知雄 Yoshimasa Iwase Tomoo Morikawa Copyright SHIFT Inc., All Rights Reserved. 1

Slide 2

Slide 2 text

Slide 3

Slide 3 text

自己紹介株式会社SHIFT デリバリ改革部サービスプラットフォームG グループ長森川知雄｜Tomoo Morikawa ⚫ エンジニアリング・マネージャーとして社内外向けプロダクトの開発チームを担当。 ⚫ SI出身の知見を活かしてDX、DevOps、チームビルドに日々奔走してます。 ⚫ 関西出身。あまりお金にならない音楽と書籍が趣味。 ⚫ 好きなものはfukabori.fm（DevRelも大好物）。 Copyright SHIFT Inc., All Rights Reserved. 3

Slide 4

Slide 4 text

Slide 5

Slide 5 text

SHIFTのテスト事業とは ⚫ 第三者の立場でソフトウェアの品質を上流から下流まで支える品質保証事業 SHIFTのテスト事業 ⚫ ソフトウェアテストを中心に、テスト計画、設計、実行、自動化支援までを提供 ⚫ CAT検定でスクリーニングした未経験人材を採用。「判断」と「作業」を分離したタスクに従事することで最適化 Copyright SHIFT Inc., All Rights Reserved. 5

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

「テストエンジニア」を3つのレイヤーで考えます 3 2 1 ドメインエキスパートさん事業・業務を知り尽くし、“何を守るべきか”を定義するテスト設計屋さんリスクを見極め、テスト設計・観点を組み立てる打鍵屋さん決められた手順どおりに操作し、結果を確認する（テスト実行） ※ 本セッションでは「品質を担う人（テストエンジニア）」を広義に捉えます。 Copyright SHIFT Inc., All Rights Reserved. 11

Slide 12

Slide 12 text

Slide 13

Slide 13 text

打鍵テストがAI打鍵に置き換わる ➢ 打鍵テストの作業性質は AIの得意領域と一致する ➢ 手動打鍵が大量に残っているのはWF/SIer領域 ➢ AI打鍵は従来の自動テストが超えられない壁を突破する ➢ コスト（トークン量）が課題 E2E テスト AI 打鍵テスト手動打鍵テスト現状 before 2~3年後 after ※ DX白書(IPA)のアジャイル開発の割合（22.8%)をもとに試算 ※ AI打鍵テストは高コスト、トークン費用は今後のAIベンダーの動向次第 Copyright SHIFT Inc., All Rights Reserved. 13

Slide 14

Slide 14 text

Slide 15

Slide 15 text

テスト設計者は「トリアージャー」に AIが大量にテストを生成する時代、必要なのは「判断・選別」 ➢ 試験観点を洗い出しテストケースを網羅的に設計・記述 ➢ 「どう作るか」が価値 ➢ 工数＝アウトプット量従来：「テスト設計者」 Copyright SHIFT Inc., All Rights Reserved. ➢ AIが出す大量のケースから取捨選択・優先順位づけ ➢ 「どれが重要か・どれを直すか」を判断する ➢ 工数＝意思決定の質これから：「トリアージャー」 15

Slide 16

Slide 16 text

人間 1秒 vs AI 1時間テストエンジニアなら1秒で気づくビジネスリスク、 AIには判断できない人間（テストエンジニア） 1秒 AI（Computer Use） VS 1時間〜差分を見た瞬間に即決。同じ判断に、コンテキスト総動員。「このボタン配置、半年前のABテストで離脱率が +20%跳ねた時と同じ感じだ」 AB全履歴＋行動ログ＋KPI定義を投入。さらに誤報チューニングが要る。 ── 事業の“痛み”を知っているから。 Copyright SHIFT Inc., All Rights Reserved. 16

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

明らかに増えている「AIDDの駆け足導入・実践」 AIDDに関する品質のご相談増えています非エンジニアチームで開発をすることになった。ハーネスのベストプラクティスがわからない。若手がハルシネーションを見抜けず障害。対応に追われて、結局”コスト削減”になっていない。 AI起因の本番障害が発生。「リリース前の人間チェック」が、結局マストに戻った。 Copyright SHIFT Inc., All Rights Reserved. 19

Slide 20

Slide 20 text

既視感 —— 発注先が“ベンダー”から“AI”に変わっただけその煙、見たことある ── “丸投げ”は色が違うだけ、燃えてるものは同じかつて｜ベンダー丸投げいま｜AI 丸投げ ➢ ブラックボックスのコードが ➢ 同じくブラックボックスのコードが降ってくる「あとよろしく」で降ってくる ➢ 設計書なし・口頭仕様・「動くから正しい」 ➢ テストエンジニアは仕様を逆算 —— テストというより“考古学” ➢ プロンプト履歴はある、でも“設計意図”ではない ➢ 「AI が作った＝正しい」がさらに強化される ➢ 「何がしたい？」と訊くと「AI に聞いて」決定的な違いは、2 つ ① 負債が“数ヶ月”ではなく“数分”で同時多発する ② 発注者に罪悪感がない（AIは何度でもやり直せると思っている） Copyright SHIFT Inc., All Rights Reserved. 20

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

ハーネスが効いていても起こる課題があるビジネス上クリティカルなバグ例）ECサイトの在庫引き当て処理を「読みやすく」リファクタリング。ロック取得→在庫確認→引き当てを、きれいなasync/awaitに書き直した結果、悲観的ロックが消えた。通常は問題ない。タイムセールで同時アクセスが集中した瞬間、在庫1個の商品が50人に販売された。意味論的なカスケードバグ例）ポイント付与ロジックを修正。ポイント自体は正しく付与されるものの、失効判定の起算日がズレてしまった。結果、1ヶ月後に大量のポイントが誤って失効した。ユーザー体験の低下例）「アカウント削除」機能を実装。確認ダイアログ（“Are you sure?”）も表示される。しかし、文言が軽すぎて、ユーザーが「設定リセット」の感覚で押してしまう。 10年分のデータを削除する操作にもかかわらず、ボタンの色やサイズが他のボタンと変わらない。「怖さ」のデザインが抜けている。 Copyright SHIFT Inc., All Rights Reserved. 23

Slide 24

Slide 24 text

なぜ防げないのか「このコード、ビジネス的にヤバくないか？」 —— 今のAIにはこの問いが立てられない。 AIはコードの正しさを判断できる。でもコードの重大さを判断できない。排他制御が消えた → コードとしては動く。「タイムセールで死ぬ」を知っているのは人間だけ。ポイントの起算日がズレた → テストは通る。「3ヶ月後に法的リスクになる」を想像できるのは人間だけ。確認ダイアログが軽い → 機能としては正しい。「ユーザーが10年分のデータを軽い気持ちで消す」を怖がれるのは人間だけ。ドメインエキスパートの得意領域 Copyright SHIFT Inc., All Rights Reserved. 24

Slide 25

Slide 25 text

【構想】AIエージェントが全情報を束ねて、ヒトを支援設計情報・ビジネス要件・CI/CD・o11yの情報 ——すべてをAIエージェントに接続。判断・通知し、最終判断のヒトを支える CI / CD （コードマージ） O11y （Log・メトリクス）設計情報（アーキテクチャ） AIエージェント判断・通知で支援全情報を集約し判断・通知するヒトテストエンジニアビジネス要件ルール点在する情報をAIエージェントが束ねて判断・通知。だからヒトは“裁く”ことに集中できる。 Copyright SHIFT Inc., All Rights Reserved. 25