JaSST Niigata LT大会6本まとめ ― AIが作業する時代、人は何をする？

はじめに

この記事を読む前に：
LT大会では質疑応答の時間がなく、登壇者の方に確認できていない部分があります。
各LTの「内容」は動画視聴時のメモをもとにした要約で、「考察」「補足」には私の推測や解釈が含まれます。
推測の部分はそう明記していますが、聞き取りの誤りなどがあればご指摘ください。
正確な内容は、末尾の参考にある各登壇資料をご覧くださいm(_ _)m

JaSST Niigataで開催されたLT大会6本の内容を、「AIが作業する時代、人は何をするのか」という視点で3つの軸に整理してまとめました！

JaSST（Japan Symposium on Software Testing）は、2003年から開催されているソフトウェアテストのシンポジウムです。今回のJaSST Niigataのテーマは「思考の純度を高め、品質の壁を突破する」で、LT大会のどの話もこのテーマにつながっていました。
私は今回オンラインで参加しました！

6本を3つの軸で整理してみた

AIに任せっぱなしにすると大きなしっぺ返しがある、ということは多くのエンジニアがわかっていると思います。
でも「じゃあ人は具体的に何をすればいいの？」と聞かれると、意外と言葉にしにくいものです。
そこで6本のLTを、私なりに次の3つの軸で整理しました。

軸	ひとことで	LT
考える	AIに任せきりにせず、自分の頭で考える	Explore It!／APIテストをAIスキルでやろう／ニイガタやむをえん。
確かめる	AIの出力を、仕組みと数値で検証する	AI駆動開発におけるテストのトレーサビリティ／プロンプトの良し悪しを数値で判断してみた
広げる	AI活用を組織に根付かせる	エンジニアのAI利用実態と障壁を調べてみた

個人の思考から、それを支える仕組み、そして組織へと視点が広がっていく順番でご紹介します。
なお、この3つの軸は私なりの整理でありLT大会でこう分類されていたわけではありません！

テーマ1：考える ― AIに任せきりにせず、自分の頭で考える

3本に共通していたのはAIが作業を担う時代だからこそ、何を見るか・何を大事にするかを人が考える必要がある、というお話でした。

Explore It! AI時代に効く「探索」という技術を５分でご紹介します。

登壇者：じゅんぺー氏（資料）

内容（要約）

• 探索的テストの書籍『Explore It!』を紹介するLT
• バスケットボールのパス回しを数えていると、画面を横切るゴリラの着ぐるみに約半数の人が気付かない🦍
  人は集中していると大事なものを見落としやすく、これはバグの見逃しに似ている
• 作業はAIの仕事になりつつあり、人には「まだ誰も気づいていない価値やリスクを見つける探索」がこれまで以上に求められる
• 探索的テストは気になったことを追いかけて深掘りしていく活動であり、自分が納得するまでやめずオーナーシップを持って踏み込むことで本当の価値に触れられる
• AIのアウトプットに満足せず、本当に正しいのか、意味があるのかを批判的に問い直すことで、精度の高い意思決定にたどり着ける

私の感想

バグというものは、1つの機能に意識を集中しすぎると別のバグを見逃すし、集中していなくても見逃すし、ちょうど良い状態にするのは中々難しいなと思います。
そういう意味では、AIにある程度バグ探しを手伝ってもらいつつ、人は自分が気になるところを納得いくまで探索的にテストするといった役割分担ができるのは、良い時代になったなと改めて感じました！

APIテストをAIスキルでやろう

登壇者：鈴木 昭吾氏（資料）

内容（要約）

• 企業向け会計システムAPI開発チームのQAの方のLT
• APIテストは、ユースケースの整理、境界値・異常値の検討、事前データの準備など時間がかかるため従来はAPIツールで1件ずつ実行していた
• 別チームが作ったSkillを借りて、テスト設計と実行をAIで行ったところ特に実行が大きく速くなった
• ところが、最大1000件のデータを取得できるAPIでリリース後にお客様が「500件ずつ2ページ」と指定したところ、同じ500件が2回返ってきたという問い合わせがありバグを見逃していたことがわかった
• インフラ側に最大500件の制限があったことが原因であったが、AIは指示されていないことは考えない
• AIに思考を任せずQAは「AIに考えさせる人」になり、指示する・何を見るかを決める・結果を審査するということをやっていく必要がある

私の感想

AIではなく、テスト経験のある人間が自分の手でテストしていれば気づけたかもしれない問題だなと思ったのと同時に、AIにテストを任せるということは便利になる一方で暗黙知を言語化しなければならないなと感じました。
実際の失敗を踏まえての対応策についてのLTだったので、とても説得力がありました！

ニイガタやむをえん。

登壇者：Mark Ward氏（資料公開なし）

内容（要約）

• Mark Ward氏の自己紹介LT
• AI時代に大事なのは、AIをプロセスに組み込むことの前にある「ピープル品質」であり、人の感覚・経験・思考・意思ではないか
• Mark氏は翻訳の仕事でAIを使っていて、AIに複数パターンの翻訳を出させて自分でも訳し、それをAIに評価させて議論をする
• 翻訳で一番大事なのは日本語能力と、どんな翻訳者でありたいかという「意思」であり、それを軸にしてAIはアシスタントとして使っている
• AIは主にならず主役はあくまで人間であり、その場を楽しんで機会を活かすことが大事
• 地方JaSSTの魅力もそこにある！つまり人間として地方を楽しむことはやむを得ない＝ニイガタやむをえん

私の感想

Mark氏はご自身の近況を『論理無職でありロンリー無職』と表現されていて、うまいこと言うなと思いました🤗
スライド一枚でLTに挑むなど、ギャグも織り交ぜたトークで非常に聞きやすかったです！
AIと協業する中でもピープル品質は意識していきたいところです。

テーマ2：確かめる ― AIの出力を、仕組みと数値で検証する

AIは大量の成果物を短時間で作ってくれますが、それと同時に人が全部をチェックするのは難しくなります。
そこでAIの出力を仕組みや数値で確かめる、というLTが2本ありました。

AI駆動開発におけるテストのトレーサビリティ

登壇者：江尻 好治氏（資料）

内容（要約）

結論は「AI駆動開発で、テストのトレーサビリティの重要性が増した」です。
トレーサビリティとは、要件・テスト・テストの実行結果の関係をたどれる状態のことで、これがあるとテストのない要件や仕様変更で影響するテストがわかるとのこと。

• AI駆動開発で5か月の間に受け入れ基準が約2,000件、自動テストが約14,000件まで増え、どの要件がどのテストで検証済みかを把握するのが難しくなった
• AIに把握させることもできるが、量が多いと結果がブレてそのたびにコストがかかる
• そこで仕様書からテスト条件・テストケース・テストコードをSkillで生成し、生成時に各成果物へIDを埋め込み、実行ログにもIDが出るのでそれらをつなぎ合わせてトレーサビリティを実現した
• 結果をHTMLで出力してCIに組み込み、どの機能にどんなテストが足りないかをすぐ把握できるようにした
• ログとIDでつないでいるため、ユニットテスト・API・E2Eなど言語を問わず使える
• ただしテストは要件からだけ作るものではなく、過去の障害やリスクから作るテストも重要で今後はそちらにも適用する予定

IDがつながる流れは次のとおりです。

1. 仕様書（つながりの起点。仕様書側のIDの付け方はLTでは語られていませんでした）
2. テスト条件（生成時にIDを埋め込む）
3. テストケース（生成時にIDを埋め込む）
4. テストコード（生成時にIDを埋め込む）
5. 実行ログ（IDが出力される）

補足：私なりの理解

トレーサビリティは、スーパーの野菜の産地表示にたとえるとわかりやすいと感じました！
産地のシールがあれば、ある畑で問題が見つかったときに、その畑の野菜をすぐ探し出せます。
このLTの仕組みは、AIがテストを作るときに最初から産地シール（ID）を貼らせているイメージです🍆

野菜の産地表示	このLTの仕組み
畑	仕様書（要件）
野菜	仕様書から作られたテスト
産地シール	ID
検査の記録	テストの実行結果（ログ）
問題が見つかった畑の野菜をすぐ探せる	仕様が変わったとき、直すべきテストがすぐわかる
野菜が1つも出荷されていない畑が見つかる	テストのない要件が見つかる

また、足りないテストを見つけているのはHTMLやCIそのものではなくIDの突き合わせだと理解しました。
HTMLは結果の見せ方、CIは実行するタイミングを担っていて、テストが追加・変更されるたびにレポートが自動で最新になります。
探すのは自動、どのテストを足すか判断するのは人、という分担だと推測します！

プロンプトの良し悪しを数値で判断してみた

登壇者：Komatsuna氏（資料）

内容（要約）

1つのツールを多くのメンバーが使うようになり、成果物の品質やUI/UXへのフィードバックが増えたとのこと。
そのたびにプロンプトを修正し、成果物を作って読み比べて違ったらまた検討する、というループが非効率だったため、指標を決めてAIで検証して数値で比べることにしたそうです。

指標は、実際に受け取ったフィードバックをそのまま数値にしたものです。

もらったフィードバック	数値にした指標	測り方
用語が言い換えられていてわかりにくい	仕様との用語一致率	生成結果が仕様書と同じ用語を使えているかを、文字列マッチで計算
仕様書に対してテスト観点が多く、対応しづらい	トレース可能セクション数	仕様書のどのセクションに機械的にたどれるかの件数
テストケースの内容が薄くなった／増えた	生成されたテストケースの総数	テストケースの水増しや欠落がないかを確認する件数

同じ仕様書・同じモデルで、4つのプロンプト候補を比較した結果は次のとおりです。

プロンプト	観点数	用語一致率	トレース可能セクション数	テストケースの総数
旧プロンプト	7	44%	0/20	76
新プロンプト＋粒度ガード	15	55%	10/20	83
新プロンプト＋案A（観点数アンカー）	7	45%	6/20	57
新プロンプト＋案B（セクション束ね）	7	59%	6/20	61

案A・案Bは、「観点数を旧プロンプトと同じ7個にそろえてほしい」という要望に応えて追加で作ったパターンだそうです！

• フィードバックをくれた人に何も伝えずに4パターンの成果物を渡して選んでもらったところ、数値で総合的に一番良かった「粒度ガード」が選ばれ、数値の判断と人の判断が一致した
• 用語一致率が最も高かった案Bはトレース可能セクション数が低く、原因を確認すると以下の観点が丸ごと消えていた
  • 表示内容の細部（アイコン・ラベルなど）
  • 補助的な導線（ヘルプ・ガイドリンクなど）
  • 呼び出し元による表示の分岐
• 4件を読み比べなくても数値から異変に気付くことができ、比較や退行の検出も数値で見るほうが早かった

私の感想

一つの指標だけでは判断を誤ってしまうということが具体的に分かるLTでした！
特に面白かったのは数値と人の判断が一致したところで、人の判断に数値による根拠がついたことでテスト設計の改善に自信を持てる仕組みになっていて非常に良いですね🙆
各案（粒度ガード、観点数アンカー、セクション束ね）についての具体的な中身についてのお話はなかったので（おそらく時間の都合上）その点についても聞いてみたいなと思いました！

テーマ3：広げる ― AI活用を組織に根付かせる

ここまでは個人やチームの話でしたが、最後はAIを組織にどう根付かせるか、というお話です。

エンジニアのAI利用実態と障壁を調べてみた

登壇者：山田 涼太氏（資料公開なし）

内容（要約）

• AIエージェントを配ったあとに誰がどこで使っているのか・どこで利用が止まっているのかを知り、次の支援につなげるため社内アンケートを実施した
• アンケートでわかるのは利用実態と阻害要因までであり、生産性や品質など成果への効果はこのアンケートだけでは測れない
• 同じチームの中でも人によって利用の温度差が大きいことがわかり、使い込んでいる人が数値を押し上げてチーム全体が使いこなしているように見えることもある
• 高度な使い方に進みにくい背景として以下の声があった
  • 普段使いで足りている
  • Skillなどの知見を共有する場がない
  • 出力が正しいか検証できるか不安
• 次の壁は「使えない」ではなく「困っていない」である
• 価値は困りごとと結びついて伝わるので、他チームの実践から自分たちの困りごとに効くユースケースを見つけて共有することが次の一手

私の感想

次の壁が「困っていない」というのは目からうろこでした！
「使い方がわからない」であれば対策のしようがありますが、「AIが無くても問題ない・現状で困っていない」ということに対してはアプローチの仕方が難しくなりますよね。
不便なことを不便であると捉えていないケースもあると思うので、困りごとに効くユースケースの共有というのはアプローチとして理にかなっているなと思いました🐟

一番刺さった話：人間がわかりやすい目印を残して、AIと協業する

今回のLT6本の中で、私に一番刺さったのはテストのトレーサビリティのLTでした！

正直、最初はトレーサビリティという言葉の意味もよくわかっていない状態で聞いていました…
それでも、AIにテストを作ってもらいながら人間にわかりやすい目印（ID）をしっかりと残して、人間がボトルネックになりにくい仕組みを作っている点がとても良いと感じました🙆

私たちのチームはこれからテスト文化を作っていく段階です。
だからこそ、最初からこういう目印を残す考え方を取り入れたいと考えています。
まずは地道に、テストケースに対応する要件の番号をつけるところから始めるつもりです(｀・ω・´)ゞ

まとめ

LTを通して、AIが作業してくれる時代に人がやることは次の3つだと私は理解しました。

• 考える：AIに任せきりにせず、自分の頭で考える
• 確かめる：AIの出力を、仕組みと数値で検証する
• 広げる：ユースケースを見つけて、組織に共有する

どれも「AIに作業を任せたうえで人が何を担うか」というお話でした。

AIの登場で、QAの仕事の重心は「考えること」に大きくシフトしたと感じています（QAだけではないですが）
このLT大会だけではなく、JaSST Niigataでは「どういうことを考えて実行すべきか」のヒントをたくさんもらうことができました！

参考：ご紹介したLT

タイトル	登壇者	資料
Explore It! AI時代に効く「探索」という技術を５分でご紹介します。	じゅんぺー氏	Speaker Deck
APIテストをAIスキルでやろう	鈴木 昭吾氏	Docswell
ニイガタやむをえん。	Mark Ward氏	資料公開なし
AI駆動開発におけるテストのトレーサビリティ	江尻 好治氏	Speaker Deck
プロンプトの良し悪しを数値で判断してみた	Komatsuna氏	Speaker Deck
エンジニアのAI利用実態と障壁を調べてみた	山田 涼太氏	資料公開なし