未経験QAでも入社初月からテスト設計に参加できる Claude Code を活用した仕組みづくり
はじめに
EMとしてQAチームの立ち上げを担当している池田と申します。私たちのチームは立ち上げから半年ほどで、現在はブラックボックステストを中心に品質保証業務を行っています。メンバー構成は以下の通りです：
- 実務未経験のQAエンジニア 2名
- 第三者検証機関からの外部メンバー 2名
今回は、実務未経験のQAエンジニアが入社初月からテスト設計業務に参加できるようにした仕組みについて紹介します。
解決したかった2つの課題
1. 新メンバーの即戦力化が必要だった
チーム立ち上げ初期で人員も限られているため、早期に一定水準以上のテスト設計業務をしてもらう必要がありました。ドメイン知識に依存する部分はありますが、画面要素によって見るべき観点はある程度共通化できるはずだと考えていました。
例えば、ボタンであれば「クリック可否」「状態変化」「表示テキスト」など、要素の種類ごとに確認すべき観点はパターン化できます。しかし、これらの知識を未経験者に伝えるには時間がかかりますし、人によって観点の抜け漏れが発生しやすい状況でした。
2. テスト設計業務における入力作業が辛い
元々はテストケースの作成と、テストの実行結果の入力をNotionのデータベースにて行なっていました。しかし、コーディング時にAIの補助に慣れてしまっている今のご時世からすると、1ケースずつ手動で入力していく作業はかなり辛く感じます。
特にテスト設計業務では、似たような文章を大量に書く必要があるため、入力ミスも発生しやすいです。例えば、境界値テストでは「255文字まで入力できること」「256文字は入力できないこと」といった、パターンは同じだが値だけが異なるケースを何度も記述します。
Claude Code 導入の狙い
1. 画面要素ごとのテスト観点生成をルール化
以下の2点から実務未経験メンバーも早期に業務に当たることができるようになりました：
CLAUDE.mdによるルール定義
プロジェクトのルートにCLAUDE.mdを配置し、必ず画面要素ごとにテスト観点・テストケースを生成するようなルールを定義しました。以下は実際に使用しているCLAUDE.mdの一部です（サンプル用に一部修正）：
## テスト分析生成ルール
### 重要な制約
- **必ず画面の要素単位で観点を生成すること**
- **一度に複数の要素に対して観点を生成しない**
- **1つの要素の観点生成が完了したら、都度レビューを求める**
### テスト分析フォーマット
Markdownのテーブル形式で以下の項目を含めること：
| カラム名 | 説明 |
|---------|------|
| 要素ID | テスト対象となる画面要素の識別子 |
| 要素名 | 画面要素の名称 |
| 要素タイプ | 要素の種類（テキストフィールド、ボタン等） |
| 観点名 | テストで確認する観点 |
| 確認項目 | 具体的な確認内容 |
| 観点ID | テスト観点の識別子（プロジェクト内でユニーク） |
標準観点のデータ化
画面要素ごとに標準のテスト観点をデータ化しました。例えばボタン要素の場合：
| カテゴリ | 観点名 | 確認内容 | 適用条件・備考 |
|---|---|---|---|
| 状態制御 | 活性制御（条件満たさない） | 入力条件を満たさない場合に非活性になること | 入力フォームの送信ボタン等 |
| 状態制御 | 活性制御（条件満たす） | 入力条件を満たした場合に活性になること | 入力フォームの送信ボタン等 |
| 状態制御 | 権限による非活性 | 権限がない場合に非活性になること | 権限制御があるボタン |
| ... |
これにより、Claude Codeが一貫性のある観点を自動的に生成できるようになりました。
2. AIによる入力補助で工数削減
テスト設計業務においては、少しだけ異なる似たような文章を書くことが多いですが、AIの入力補助によって工数の削減ができました。また、人間が手入力する際に発生しがちな入力ミスも大幅に減らせました。
旧業務フローと新業務フローの比較
主な変更点
| 項目 | 旧フロー（Before） | 新フロー（After） | 改善効果 |
|---|---|---|---|
| テスト観点作成 | Notionで全て手動入力 | ・仕様書が構造化されている場合：Claude Codeが自動生成 ・画面要素が明確でない場合：手動で作成後、Claude Codeが標準観点を提案 |
可能な部分は自動化、手動作成時もAIがアシスト |
| テストケース作成 | Notionで手動入力 | CSVでClaude Codeが自動生成（要素ごとに観点が決まれば自動化可能） | 入力ミス削減、類似ケースの効率的な生成 |
| レビュー管理 | Slack + Notionコメント | GitHub PR/レビュー機能 | レビュー履歴の一元管理、開発フローと統一 |
| Notionへのデータ投入 | 手動で1件ずつ入力 | GitHub Actionsで自動エクスポート | 転記作業の完全自動化 |
| 作業環境 | ブラウザ（Notion）のみ | VSCode + Claude Code | AIアシストによる高速化 |
効率化の具体例
Before：テキストフィールドの境界値テストケース作成
1. Notionを開く
2. 「254文字は入力できること」を手入力
3. 新規行を追加
4. 「255文字は入力できること」を手入力（ほぼ同じ内容）
5. 新規行を追加
6. 「256文字は入力できないこと」を手入力（ほぼ同じ内容）
→ 似た文章を何度も手入力、コピペしても値の変更が必要
After：同じテストケースの作成
1. テスト観点が決まっていれば、Claude Codeに「境界値テストを生成して」と指示
2. 254, 255, 256文字のケースが自動生成される
3. 内容を確認してコミット
→ 観点さえ決まれば、テストケース作成は確実に自動化可能
削減された作業
-
❌ 廃止された作業
- テストケースのNotionへの手動入力作業
- Slackでのレビュー依頼メッセージ作成
- レビュー指摘箇所の手動修正
-
⚠️ 部分的に自動化された作業
- テスト観点の作成（仕様書の品質に依存）
- 標準観点の適用（Claude Codeが提案）
-
✅ 残った作業（品質担保のため）
- 生成された内容の確認・レビュー
- 仕様書から読み取れない要素の手動特定
- テスト実行と結果入力
実際の生成例
例えばログイン機能のテスト分析の場合、以下のようなテスト観点とテストケースを生成しています。
テスト観点
| 要素ID | 要素名 | 要素タイプ | 観点名 | 確認項目 | 観点ID |
|---|---|---|---|---|---|
| email_field | メールアドレス | テキストフィールド | 必須チェック | 未入力の場合エラーメッセージが表示されること | P_LOGIN_001 |
| フォーマットチェック | 不正なメールアドレス形式の場合エラーメッセージが表示されること | P_LOGIN_002 | |||
| 最大文字数チェック | 255文字まで入力できること | P_LOGIN_003 | |||
| ... |
テストケース
| 観点ID | テストケースID | 確認項目 | 画面名 | 画面エリア | テスト対象要素 | テスト観点 | 前提条件 | 確認手順 | 期待値 |
|---|---|---|---|---|---|---|---|---|---|
| P_LOGIN_001 | P_LOGIN_001_01 | 未入力の場合エラーメッセージが表示されること | ログイン画面 | ログインフォーム | メールアドレス入力フィールド | 必須チェック | ログイン画面が表示されていること | 1. メールアドレス欄を空欄のままにする 2. パスワード欄に任意の値を入力する 3. ログインボタンをクリックする |
メールアドレス欄の下に「メールアドレスを入力してください」というエラーメッセージが表示されること |
| P_LOGIN_002 | P_LOGIN_002_01 | 不正なメールアドレス形式の場合エラーメッセージが表示されること | ログイン画面 | ログインフォーム | メールアドレス入力フィールド | フォーマットチェック | ログイン画面が表示されていること | 1. メールアドレス欄に「test」と入力する 2. パスワード欄に任意の値を入力する 3. ログインボタンをクリックする |
メールアドレス欄の下に「正しいメールアドレス形式で入力してください」というエラーメッセージが表示されること |
| P_LOGIN_002 | P_LOGIN_002_02 | 不正なメールアドレス形式の場合エラーメッセージが表示されること | ログイン画面 | ログインフォーム | メールアドレス入力フィールド | フォーマットチェック | ログイン画面が表示されていること | 1. メールアドレス欄に「test@」と入力する 2. パスワード欄に任意の値を入力する 3. ログインボタンをクリックする |
メールアドレス欄の下に「正しいメールアドレス形式で入力してください」というエラーメッセージが表示されること |
| P_LOGIN_002 | P_LOGIN_002_03 | 不正なメールアドレス形式の場合エラーメッセージが表示されること | ログイン画面 | ログインフォーム | メールアドレス入力フィールド | フォーマットチェック | ログイン画面が表示されていること | 1. メールアドレス欄に「@example.com」と入力する 2. パスワード欄に任意の値を入力する 3. ログインボタンをクリックする |
メールアドレス欄の下に「正しいメールアドレス形式で入力してください」というエラーメッセージが表示されること |
| ... |
2セッション並行稼働による待機時間の削減
当初はClaude Codeを1セッションで作業しており、「楽だけどスピードはそんなに早くならない」という印象でした。そこで、2セッション並行稼働させることでレスポンスまでの待機時間の削減を図りました。
以下の具体例のように、同じ画面の観点IDごとにセッションを分けて、それぞれが同じ画面についての作業を進めることでコンテキストスイッチの切り替えコストを減らすようには気をつけています。
具体例：
- セッションA：観点ID 001〜050 のテストケース生成
- セッションB：観点ID 051〜100 のテストケース生成
成果と効果
定量的な成果
1テストケースあたりの作成スピードの改善
- Before：11.04分/ケース
- After：9.19分/ケース
→ 所要時間が16.76%減
Beforeは私や外部の検証機関のメンバー（経験者）が実施していたので、現時点では未経験QAエンジニアがそれ以上の速度を出せるようになったことになります。
学びと今後の課題
現在の課題
-
仕様書のフォーマット統一
仕様書はまだフォーマットが統一できておらず、人の目でテスト観点のテーブルを作るケースがあります。仕様書の標準化を進めることで、更なる自動化が可能になると考えています。 -
テストデータの自動生成
アプリケーション側のデータ構造などの情報を渡して、必要なテストデータを用意するためのクエリなども生成できるようになるといいなと思っています。 -
リリース後の効果測定
今回の仕組みで設計したプロジェクトはまだリリースしていないので、リリース後の経過観察が必要です。
今後の展望
実装側のAI活用が進んでいるので、テストする側ももっとAIの活用をしないと、テスト業務がボトルネックとなりリリーススピードが遅くなってしまいます。
今はリリース前のテストを行なっていますが、開発プロセス中から実施できる品質保証の方法がないか模索していく必要がありそうです。例えば：
- プルリクエスト時点でのテスト観点の自動生成
- コード変更に基づくテストケースの自動更新
- AIによるテスト実行の自動化
- など...
まとめ
Claude Codeを活用することで、以下の成果を達成できました：
- 未経験者の早期戦力化：入社初月からテスト設計業務に参加可能
- 作業効率の向上：テストケース作成時間を16.76%削減
- 品質の向上：標準観点の活用により、観点の抜け漏れを防止
- チーム全体の生産性向上：GitHubでの統一的な管理により、レビュープロセスが効率化
QAチームの立ち上げ期や、未経験者の採用を検討されている方の参考になれば幸いです。AIツールを適切に活用することで、経験の浅いメンバーのテスト設計のレベルの底上げが可能になることを実証できたと考えています。
ご質問やフィードバックがありましたら、ぜひコメントでお聞かせください！
Discussion