ソフトウェアテスト
イベント
マガジン
技術ブログ
こんにちは。株式会社タップルでiOSアプリエンジニアをしている五味と、同じく株式会社タップルでiOS ...
はじめに 介護/障害福祉事業者向け経営支援サービス「カイポケ」のQAを担当している星です。 今年の夏頃、所属チームで立ち上がった「4スプリント限定のAI実験チーム」にQAとして参加しました。本記事では、QAの作業をどこまでAIに任せ、どこから人間が見るべきかという線引きを、チームの判断基準として言語化してみた試みを紹介します。 まだまだ試行錯誤中の内容も含まれていますが、同じように悩んでいる方の参考になれば嬉しいです！ AI実験チームってどんなもの？ AIでコードを書く速さが上がる一方で、レビューやQAがボトルネックになる可能性も見えてきた、という課題感から、既存プロセスに縛られずに試せる場として実験チームが立ち上がりました。 期間 ：2週間スプリント × 4本のタイムボックス 体制 ：開発2名＋QA1名の最小構成 テーマ ：既存チームのベロシティに影響しにくいよう、ロードマップに寄与しつつもクリティカルパス上にはないもの（扱った機能の具体例としては請求画面の改善など） 「失敗してもいい範囲」が最初から決まっているので、本番品質に直結するQAプロセスの実験にも思い切って踏み込めたのがありがたかったです。 どんな仮説を立てた？ 実験を始めるにあたって、チームでは次のような仮説を立てました。 全てのPBIを既存プロセスでQAせず、可能な限りAIに任せることで、低リスクで価値が高まる部分があるのではないか？ どこを「省略していい」かを決めることは、裏を返せばどこで「慎重であるべき」かを決めることでもあります。ただ、その判断はこれまで個人の感覚に頼りがちでした。リスクの濃淡はストーリーポイントとも一致せず、小さなPBI（プロダクトバックログアイテム）でも品質を落とせない領域に触れることがあります。 そこでPBIごとに最初に「Tier判定」をおこない、通るテストプロセスの重さを「軽量プロセス」と「重量プロセス」に分岐させてみることにしました。Tierはテストの厳格さを表す3段階の区分で、Tier1が最も厳格、数字が大きくなるほど軽いテストになります。 プロセス 対象 人間（QA）がやること 軽量プロセス Tier1以外 AIが作ったテスト計画・テストコードのレビュー、探索的テスト 重量プロセス Tier1 上記に加えて、詳細なテスト設計・テスト実装・スクリプトテスト実行 判断基準をどう言語化した？ きっかけになった2つの実例 実験チームでAIと一緒にテスト計画やテスト設計を進める中で、判断基準が必要だと強く感じた出来事が2つありました。AIに任せてうまくいったケースと、うまくいかなかったケースです。 うまくいったケース ：小粒なPBIで、AIが出したテスト観点をレビューして品質リスクは低いと判断し、網羅的なテストなしでGo判断。問題なくリリースできました。 うまくいかなかったケース ：AIが「内部処理ではグルーピングされるはず」という期待値を出してきましたが、外部仕様ではグルーピングされないのが正しい挙動でした。AIはコードから振る舞いを推測するのは得意でも、「今のビジネスルールとして何が正か」までの判断は難しく、業務知識を持つ人間だからこそ気づけたズレでした。 この2つから、「AIを信じてよい場面」と「立ち止まるべき場面」を基準で分けたいと考え、判定基準をClaude Codeのスキルにしてチームで試しています。 スキルには後述するTier判定の質問や再判定の観点をそのまま書き込んであり、チケットを渡すと次のような決まったフォーマットで判定結果を返してくれます。 ## <チケットキー>: <タイトル> **判定: Tier<N>（<厳格/標準/軽量>）** - 根拠: <どの質問でどう判定したか> - テストボリューム: <網羅/正常系＋探索/なし> - 実施者: <誰がテストするか> - 確認してほしい点: <要確認の場合のみ> - AIテスト適性: <AI向き/ハイブリッド/人間向き>（3観点それぞれの判定つき） 「テスト設計して」と頼んだ場合は、この判定結果に続けて観点別のテストケース表と、仕様が曖昧な点の確認リストまでまとめて出力します。 軸1：Tier判定（どれくらい厳格にテストするか） 3つの質問に上から答え、最初に「はい」になったところでTierが決まります。 上の図のQ2で「はい」になった「Tier1候補」は、副作用はあるものの、本当に厳格なテストが必要かはまだ分からない状態です。そこで、次の4つの観点でもう一段階チェックします。 外部に出る成果物に影響するか ：帳票のPDFや請求書、介護報酬を請求するための提出データなど、お客様や外部機関に渡るものの中身が変わるか 不可逆か ：重複登録や実績確定のように、一度実行すると後から取り消したり直したりしにくい操作か 必須業務が止まるか ：エラーによって、実績確定や請求といった毎月必ずおこなう業務が完了できなくなるか 値そのものが違うか ：見た目の崩れではなく、金額や件数などの値自体が正しくなくなるか 1つでも当てはまればTier1として重量プロセスへ、どれにも当てはまらなければTier2として軽量プロセスに進みます。判断しきれない場合は無理に決めず「要確認」とします。 「要確認」の場合は、「プレビュー表示だけの問題か、PDFに出力される値自体も違うのか」のように確認すべき観点もあわせて出力し、チームでも確認したうえでプロセスを確定させています。誤ってTier2に倒してしまうより、確認を挟む方が安全だと考えているためです。 実験期間中に「要確認」になったケースは、そこまで多くありません。ほとんどの場合は3つの質問でそのままTierが決まり、迷うのは4観点の詳細確認が必要なTier1候補が中心です。 Tier テストボリューム 実施者 Tier1（厳格） 網羅 QAがケース設計、チームで受け入れレビュー Tier2（標準） 正常系＋探索 エンジニアがユニット・E2E、QAが探索的テスト Tier3（軽量） 既存の自動回帰のみ エンジニアのみ 軸2：AIテスト適性（AIに任せやすいか） Tierとは別に、「依存関係が薄いか」「一般的な技術知識で判断できるか」「仕様が変わりにくいか」の3観点で、AI向き／ハイブリッド／人間向きを判定します。Tier1でも計算ロジックが明文化されていればAI寄りになるなど、重さとAIへの任せやすさは別物、というのがポイントです。 どちらの判定も出力はあくまで一次案で、最終判断はチーム（QA・エンジニア・PO）でおこなっています。 実験を終えてどうだった？ 使う人と使い方が広がった 4スプリントの実験期間を終えた現在もスキルは使われ続けています。 Tier判定とテスト設計のたたき台を蓄積するesaのカテゴリを用意したところ、実験チーム以外のメンバーも使い始めてくれて、判定結果がどんどん増えてきました。 使い方も少しずつ広がっています。当初はTier判定とテスト設計のたたき台が中心でしたが、最近では探索的テストの計画づくりや、既存のE2Eテストでどこまで画面遷移をカバーできているかの棚卸しにも応用されています。 「判定の型」が決まっていることで、人が変わっても同じフォーマットで議論できるようになったのは、思っていた以上に大きかったです。 難しかったこと 一方で、実際に運用してみて見えてきた難しさもありました。 判定がキーワードに引っ張られる 表示崩れを直すだけの修正でも、対象画面に金額に関わる言葉が含まれているとTier1と判定されることがありました。逆に、金額に関わる機能でも、トーストの文言修正だけであれば正しくTier2と判定できたケースもあります。 「何に触れるか」と「何を変えるか」を分けて見る必要があり、ここは判定ロジックの改善ポイントとして残っています。 判定の前提になる事実が足りない 「ボタン押下後に選択を変えても、実際に出力される内容は変わらない」といった事実が確認できて初めて、Tier2と自信を持って言えるケースがありました。判定の精度は、チケットにどれだけ事実が書かれているかに大きく左右されます。 結局のところ、「要確認」をどれだけ素早く解消できるかが、軽量パスに乗せられるかどうかの分かれ目になっていると感じています。 設計が固まるタイミング自体はあまり早くならない 表示方針がPOとのすり合わせで確定するまで、テスト設計を暫定版として置いておき、決定後に作り直すこともありました。AIのおかげでたたき台を作るコストは下がりましたが、「何が正か」が決まっていないものは、どれだけ速く作っても手戻りは発生します。 ただ、これはテスト計画を早い段階で出せるようになったぶん、仕様の曖昧さに早く気づけるようになった、と前向きに捉えています。 QAの役割はどう変わりそう？ QAの役割は「自分の手でテストを実行する人」から、「AIの出力のどこを信じ、どこを疑うかを判断し、その基準をチームに広める人」へ変わりつつあると感じています。 とはいえ、仕事が減るわけではないと考えています。今回の実験を通して改めて意識したのは、軽量パスで生まれた余力の使い道です。その余力は、重量パスに残る「人間にしかできない仕事」に再配分されていくと感じています。たとえば、ビジネスやドメイン理解に基づくテスト設計や、まだ言語化されていない違和感を探しにいく探索的テストです。 これからQAが主導すべきアクションとして、次の4つを考えています。 判断基準をつくり、広める ：AIに任せる／任せないの判断を、チーム全体が使える基準にする 危険信号の勘所を伝える ：AIでは現状カバーが難しいポイントを共有し、同じ勘所を持てる人を増やす 失敗を学びに変える ：間違いを個人の反省で終わらせず、判断ロジックの改善につなげる 「なぜ」を残す ：仕様判断や運用リスクの背景を、人間もAIも参照できる形で残す どれも「リスクを言語化する」仕事で、QA組織の行動指針に掲げている「チームで品質保証」にもつながる取り組みだと感じています。 tech.bm-sms.co.jp まとめ AIに任せる範囲を決めることは、QAの仕事を手放すことではなく、リスクの言語化という本来の仕事そのものでした。 判定基準の精度向上は今も続けていて、実験チーム以外の現場でも検証や利用を進めています。判定がずれたケースこそ基準を磨くヒントになるので、引き続きみんなで育てていきたいと考えています。 一緒に取り組んでくれたメンバーをはじめ、いつもサポートしてくださるみなさん、ありがとうございます！ エス・エム・エスのプロダクト組織やQA組織に少しでも興味を持ってくださった方は、ぜひカジュアル面談でお話しさせてください！
