設計から実践へ：QAスキル群を育てた話とチームへの広め方

こんにちは！hacomonoのQAチームに所属している「ゆう」です。最近は子どもの寝かしつけのあとに記事を書くのがルーティンになってきました。夜の静かな時間が、まとまった思考には一番向いているかもしれません。

さて、今回は前回の記事の「続き」です。

前回（2026年3月）は、チーム統合を機に感じた課題と、それを解決するための「プレイブック」（チームで共通して使う手順やルールをまとめたもの）の設計について書きました。記事の最後に「チームに展開した結果については、また別の記事で」と書いたのですが、あれから数ヶ月が経ち、ようやくその話ができる状態になってきたので、今回まとめてご紹介します。

おさらい：前回設計したこと

前回の記事では、QAメンバー間のAI活用の質がばらついている問題に対して、以下の仕組みを設計しました。

4-Step Flow：仕様→実装の順で分析を進めるフロー（「実装ありき」の分析を防ぐ）
Quality Gates：AIの出力に確信度ラベル（【確定】【推察・高/中/低】）を付与し、どこまで信頼できるかを可視化
ナレッジ蓄積：ドメイン知識をAIに読み込ませ、担当が変わっても同じ前提で分析できる仕組み

当時は「設計が完了した」段階で、チームへの展開はこれからでした。
その後、この仕組みをClaude Codeのスキル（AIエージェントへの指示セット）として実装していきました。今回はその「実装と普及」の話です。

スキル群の現在地

現在、QA業務を支援するスキルは11個あります。設計のときにイメージしていた「フロー」が、具体的なツールとして形になった状態です。

11個というと多く聞こえますが、整理すると3つの層に分かれています。

層	役割	スキル
1. 作る系（6スキル）	テスト分析〜コード生成の一気通貫フロー	qa-flow（司令塔）、qa-epic-registration、qa-test-analysis、qa-test-case、qa-automation-selection、qa-code-generation
2. 補助系（4スキル）	必要なときに横から支える	qa-review、qa-test-execution、qa-bug-report、qa-domain-knowledge
3. 共有基盤（1スキル）	全スキルが参照する土台	qa-common（品質方針・確信度ルール・テンプレ）

普段使いしているのは「作る系」です。「受け入れ条件（機能が完成したと判断するための基準）をインプットすると、テスト分析→テストケース作成→自動化選定→Playwright（ブラウザを自動操作するE2Eテストフレームワーク）のコード生成まで、AIが司令塔（qa-flow）を通じて順番に進めてくれる」というのが基本的な使い方になっています。

「補助系」は、不具合が出たときの起票サポートや、深掘りレビューが欲しいときに呼び出す形です。「共有基盤」は、他のスキルが内部的に参照するもので、ユーザーが直接呼び出すことはありません。

設計で大切にしたこと：AIはreportであってjudgeではない

スキルを実装していく中で、一つの原則を明示的に言語化するようになりました。

「AIはreportであって、judgeではない」

どういうことかというと、AIは分析・チェック・生成の「材料」を出す役割であって、「合否を判定する」役割は人間が担う、という意味です。

これを意識するようになったのは、実際に使っていくうちに「AIの出力をそのまま採用してしまいやすい」と気づいたからです。AIが自信満々に書いた分析結果でも、間違っていることはあります。特に、仕様が曖昧な部分や、ドメイン固有のルールが絡む部分は要注意です。

そこで、スキルの動作を設計するときにはこの原則を徹底しました。

テスト分析の結果には、確信度ラベルを必ずつける（【確定】【推察・高/中/低】区分）
フローの要所に「人が確認するゲート」を設ける（AIが確認なしに次の工程へ進まない）
確認できなかった情報は「要確認」として明示させる

AIに「答えを出してもらう」のではなく、「判断に必要な材料を整理してもらう」。この発想の切り替えが、スキルの信頼性を高める上で一番大切だったと感じています。

チームへの広め方：1対1・1時間のモブプログラミング

スキルができても、使ってもらえなければ意味がありません。「どうやって広めるか」は、設計と同じくらい悩んだテーマでした。

試行錯誤の末、「1対1・1時間・画面共有のモブプログラミング」という形に落ち着きました。モブプログラミングとは、複数人で同じ画面を共有しながら一緒に作業を進めるやり方です。

最初は「ドキュメントを整備して共有すればいいか」と思っていたのですが、それだと「なんとなく読んだ、でも使い方がよくわからない」で終わってしまいます。実際に手を動かして一緒に使ってみる体験が、定着への近道だと判断しました。

進め方はシンプルです。相手が実際に担当しているPBI（プロダクトバックログアイテム）を題材にして、1時間で「テスト分析→テストケース作成」までを一緒に走ります。ちょうどよいPBIがなければサンプルのPBIを用意するので、「今ちょうど担当案件がない」という状況でも始められます。説明するのではなく、隣で見ながら実際の成果物を作る。これが思いのほかうまくいきました。

現時点（2026年6月）で2名の方と実施を完了し、さらに2名と実施を予定しています。

また、予想外の広がり方もありました。チームの振り返り（レトロスペクティブ）でスキル群を紹介したところ、同じチームのエンジニアから「面白そう」「使ってみたい」という声をもらいました。

さらに、AI推進担当の方が「誰でも自作スキルを登録・共有できるリポジトリ」を用意してくれたことで、QAスキル群もそこに登録することができました。それ以来、他部署の方がQAエンジニアに相談する際、テスト分析の結果や実施内容をすでに添付してくれているケースを見かけるようになりました。

「QAのためのツール」として始めたものが、少しずつ自分たちの手を離れていく感覚は、なかなか嬉しいものです。

自分自身に起きた変化

チームへの広がりと並行して、自分自身の働き方も変わりました。

◼︎作業のリズムが変わった
以前は「テスト分析→レビュー依頼→テストケース作成→実施」という工程を、ある程度手作業と勘で進めていました。今は受け入れ条件を起点に、スキルがドラフトを出して、自分がゲートで確認・修正するというリズムができています。また、「ここの観点が漏れていると思う」「このケースを追加して」と対話しながら成果物を育てていけるので、プロンプトを一から書き直す手間もありません。
頭の使い所が「作業」から「判断」に変わった感覚があります。

◼︎複数のPBIを並行して進められるようになった
Gitのworktree機能（同じリポジトリを複数のディレクトリに展開し、それぞれで独立した環境を同時に立ち上げる仕組み）を組み合わせることで、複数PBIのテスト分析・設計を並行して進められるようになりました。あるPBIの分析をAIに走らせている待ち時間に、別のworktreeでE2Eテストのメンテナンスや新しいスキルの開発を進める、といった使い方です。「AIが処理している間に人間が別の作業をする」という分業が、自然にできるようになりました。

見えてきた課題

良いことばかりではなく、取り組みを続ける中で課題も見えてきました。

◼︎入口のハードルが高い
スキルを使い始めるには、受け入れ条件やPRD（プロダクト要求仕様書）の情報をClaude Codeに渡す必要があります。現状、NotionのPBIはコピペで入力、FigmaはスクリーンショットをコピペでAIに読み込ませる形になっています。MCP（AIと外部サービスをつなぐ連携の仕組み）を使えばこうした入力を自動化できる場合もありますが、セキュリティ上の制約などで導入できないものもあり、そういったときは別の工夫で乗り越えています。「便利だとわかっているけど、最初の一歩が手間」という状況は、普及のネックになっています。

◼︎改善サイクルが追いつかない
スキルを実際に使うと、自動的にフィードバックが蓄積される仕組みになっています。「この観点が抜けていた」「このフローが使いにくい」といった気づきが集まってくるのですが、それを精査してスキルに反映するサイクルが、蓄積のスピードに追いつけていません。道具を整備しながら使い続けるのは思った以上に難しく、継続的な取り組みが必要だと感じています。