はじめに
こんにちは。QAエンジニアの松永です。
QAが行う作業の一つに、テスト観点表のレビューがあります。
今回、Claudeとのチャットでレビューを手伝ってもらいました。この記事では、そのレビューが終わった後に、一連のやりとりをもとにClaudeのカスタムスキルを作った、という話を紹介します。
スキルを作ろうと思ってレビューを始めたわけではありません。レビューが終わってから、チャットに残ったやりとりを見て、これは型にできると気づいた、という順序です。まずは、そのレビューを実際どう進めたかから書いていきます。
まずやったこと
きっかけは単純で、レビュー対象の観点表の量が多く、一つ一つ読むのが面倒になってきたことでした。加えて、量が多いと見落としが怖いです。そこで試しに、まずは雑にスプレッドシートをClaudeに読ませてみることにしました。
やってみると、それらしい指摘はいろいろ返ってきます。ただ、返ってきた内容を精査していくと、これはこれで大量で、結局終わる気がしません。しかも、仕様がわからないまま指摘してくるので、的外れなものも混ざっていていつまでも終わりません。
そこで、仕様をわかった上で見てもらおうと考え、Figmaのデザインを読ませることにしました。ところが今度は、中身が読みきれないと言ってきます。仕方なく、読める段階までレビューの対象範囲を小さく区切り、Figmaを前提に置いてチャットしながらレビューを進めました。
ここまでの感想
ここまでやって、正直な感想はこうでした。
- 自分で読んだ方が早かったのでは？
- 仕様に関係ない部分を目視で見つけてコメントを返すのが負担が大きい。内容によっては、これは自分の主観なのでは、と迷う
- Figmaを読ませるのが地味に負担が大きい。毎回、どこからなら読めるのかを探るところから始まる
終わった後で気づきました。このチャットでの苦労は毎回起きるのでは？ だとすれば、レビュー観点を精査・整理すればスキルにできるのでは？ と。
スキル化するにあたって
まず、この試行錯誤をしていたチャットそのものをもとに、Claudeにスキルの土台を作ってもらいました。実際にやったやりとりが全部残っているので、それをもとに手順を起こす形です。
その上で、スキルで見るレビュー観点を絞り込みました。ポイントは、仕様を知らなくても指摘できる部分だけに限定したことです。仕様の理解が必要な指摘は人間の側に残し、機械的・形式的に判定できるところをスキルに任せる、という切り分けです。
現在のチェック項目は以下の通りです。
| # | チェック観点 | 内容 |
|---|---|---|
| 1 | テスト観点の検証可能性 | テスト実施者が「どの画面のどこを見て合否を判断するか」を一意に決められる書き方かを最初に確認する。内部処理（採番・登録など）は画面から観測できないため、その結果として現れる表示・状態の確認に書き換える。 |
| 2 | 誤字脱字 | 明らかな誤字・脱字・変換ミスがないかを確認する。 |
| 3 | 日本語の表現 | 「十分に長い」「適切な」など主観的・曖昧な表現がないか、箇条書きや括弧の表記揺れ、シート全体をまたぐ用語の揺れがないかを確認する。 |
| 4 | 辻褄（整合性） | 各項目の記載内容が互いに整合しているかを確認する。条件の前提が観点に反映されているか、対象と観点が対応しているかなど双方向で見る。 |
| 5 | 観点分類（表示・遷移など）の適切さ | 分類がテスト観点の内容と意味として合っているかを確認する。キーワードの一致ではなく意味で判定し、同一の観点に複数の分類が使われている場合は機械的に指摘する。 |
| 6 | カバレッジの非対称 | 同種の機能をもつ対象の間で、条件の組み合わせの網羅範囲が揃っているかを確認する。片方にしかない組み合わせは、意図的な絞り込みか漏れか判別できないため要確認とする。 |
| 7 | 重複チェック | 実質的に同じ内容を確認している行がないかを確認する。完全一致でなくても、重複の可能性があるものは拾う。 |
| 8 | No.の連番チェック | No.列が連番になっているかを確認する。非表示行で番号が飛ぶことがあるため、その可能性も明記する。 |
| 9 | 観点表の必須項目の空欄 | 必須項目が空欄でないかを確認する。 |
あわせて、次の調整も加えました。
- レビュー結果を、項目番号・チェック観点・内容からなるテーブル形式で出力できるようにする
- 設計者に返すレビューバックコメントを生成できるように指示を追加する
一方で、Figmaを使うスキルは今回見送りました。URLを共有しても読めないことが多々あり、安定して動く前提を作れなかったためです。仕様の理解を要する観点を人間側に残したのは、この事情とも重なっています。
スキルを作った後の話
設計者にも共有してみた
エンジニアから「設計者側でも使えるのではないか」と提案をもらいました。そこで、レビューバックコメントを生成する部分を削り、設計者が自分の観点表を提出前にチェックできる形に整えました。共有方法はシンプルに、スキルのファイルをそのまま渡す形です。
狙いは、設計者が提出前にスキルを回すことで、レビュアーが誤字脱字や日本語表現といった形式的な指摘をする必要を前段で減らすことでした。ただ、実際にはあまり使われていないようです。ここも改善点だと思っています。
GASでやっていた仕様書チェックもスキルに
テスト仕様書のチェックについては、もともとGASで行っていました。ただ、GASでできるのは機械的な判定に限られ、連番のチェックや必須項目の空欄チェック程度にとどまっていました。日本語表現や辻褄といった、読んで判断が必要な部分は人が見るしかありません。
これをスキルに移したことで、人が目で追う範囲そのものが減りました。同じ要領で作れたのは、観点表のスキルで手順が固まっていたからです。
まとめ
結果として、レビューはとても楽になりました。チェックしてもらっている最中に、別の作業や観点漏れの確認を進められるのが大きいです。
もちろん、まだまだ改善の余地はあります。
- スキルが返してきた項目を確認している最中に、ごく稀に「これ、なんで指摘されてないの？」と思う観点を見かける
- 生成されるレビューバックコメントが、長すぎて頭に入ってこなかったり、逆に端的すぎて冷たい印象になったりする
- 設計者向けに共有したスキルが、あまり使われていない
- Figmaを安定して読めるようにしたい
とはいえ、意図してツールを設計したわけではなく、目の前の作業を進めた過程からスキルが立ち上がってきた、というのは自分にとって新鮮な体験でした。同じように、これから繰り返しそうな作業に気づいたときは、その部分をそのまま型にしてみると、意外と道具になるかもしれません。
