Claude Codeをチームで使い始めるなら、最初に何ができるようになりたいかを決めておくと、教える内容を選びやすくなります。今回は、QA担当者と、問い合わせ対応などでプロダクトに詳しいメンバーが一緒に学ぶ案です。知っていることをテストで確かめられる観点にまとめたり、他部署に判断を依頼する資料を作ったりするところから始めます。
この記事のポイント
QA担当者は確認の方法を考え、プロダクトに詳しい人は実際の使われ方と照らし合わせます。一つずつ調べながら、根拠を添えて質問したり、調査結果をまとめたりする練習をします。
それぞれの担当と質問先を決めておく
教える人がClaude Codeのすべてを説明できなくても、この案は始められます。QA担当者は検証方法、AIの回答の確認、成果物のレビューを受け持ちます。一緒に学ぶ人には、ユーザーの行動や業務について知っていることを出してもらいます。
コードの読み方に確信が持てないときは、エンジニアに確認します。仕様や運用については誰が判断するかも、先に決めておきます。分からない内容を曖昧なまま共有してしまうのを防ぐためです。
| 役割 | 持ち寄るもの |
|---|---|
| QA担当者 | テスト観点、検証方法、成果物のレビュー |
| プロダクトに詳しいメンバー | ユーザー行動、問い合わせ、現在の運用 |
| Claude Code | 関連ファイルの調査、情報整理、下書き |
| エンジニア | 実装解釈や技術的な不明点の確認 |
| 仕様・業務の責任者 | 仕様と運用の最終判断 |
第1回：作業範囲と確認の仕方を知る
第1回は60分程度です。リポジトリ、ファイル、ターミナルが何を指すかを、実際の画面で確認します。Claude Codeはファイルの読み取りだけでなく、編集やコマンドの実行もできます。どのフォルダで何を任せるかを、使う前に確認しておきます。
まずはPlanモードで調査してみます。ソースを編集せずに調査と計画を進めるためのモードですが、使えるコマンドやアクセスできる範囲も確認しておきます。意味が分からない操作が出たら、説明してもらってから判断する練習も入れます。
- 変更前に、調査結果と作業案を確認する
- 説明には根拠となるファイルを付けてもらう
- 確認できた事実、推測、不明点を分ける
- 技術的な判断が必要な箇所を質問として残す
第2回：機能の説明・テスト観点・不具合報告を作る
第2回は90分程度です。共有してよい情報だけを含む練習用の機能を一つ選びます。機能の仕組みを調べて説明をまとめ、テスト観点、不具合報告の順に作ってみます。一つの機能に絞れば、調査結果と実際の使われ方をその場で比べやすくなります。
| 演習 | 残すもの |
|---|---|
| 機能を理解する | 操作、内部処理、入力と出力、関連ファイル、不明点 |
| テスト観点を作る | 目的、前提条件、操作、期待結果、仕様上の根拠 |
| 不具合を整理する | 環境、再現手順、期待と実際、頻度、影響、証跡 |
対象機能に関係するファイルを調査してください。
コードやCSVは変更しないでください。
次を分けて説明してください。
- ユーザーが行う操作
- 入力と出力、エラーになる条件
- 関係するファイルと該当箇所
- 確認できた事実
- 推測していること
- エンジニアに確認したいこと第3回：調べた内容を添えて他部署へ質問する
第3回は60分程度です。問い合わせやテスト中に起きたことをもとに、他部署への確認依頼を作ってみます。関連資料を調べて、確認できた事実と仮説を分けます。QA担当者は、再現する条件と影響に不足がないかを確認します。
たとえば、画面の動きとコードの調査結果が食い違っていたら、AIの回答だけではどちらが正しいかを決められません。利用環境、権限、参照した版、根拠のファイルを添えて担当者に聞きます。回答をもらった後、問い合わせへの対応やテストケースに反映するところまで練習します。
■起きていること
■ユーザーへの影響
■確認できた事実と根拠
■現時点の仮説
■再現条件
■確認したいこと
■判断をお願いする担当者
■回答が必要な時期開始前に用意する環境と共通ルール
利用を認められたアカウントと練習用リポジトリを用意し、質問を受けてくれるエンジニアにも依頼しておきます。最初の環境確認は一緒に進めます。使い方を学ぶ前に、導入作業だけで疲れてしまわないようにしたいです。
プロジェクトの目的、調査の範囲、根拠の示し方、変更してよい対象などはCLAUDE.mdに簡潔にまとめられます。ただし、これはAIへ渡す指示です。機密ファイルや操作への制限は、権限設定や実行環境でも管理します。
CRUD表を題材にする場合の実務手順
CRUD表では、最初に対象を画面・API・DBのどこに置くかを合意します。一覧取得と詳細取得、一般ユーザーと管理者、論理削除と物理削除、公開済みと開発中の機能をどう区別するかも決めます。参照ブランチと対象CSVを固定してから調査します。
CSVは今の形式を維持します。記録する場所が足りない場合は、列を追加するか、別の調査票を使うかを検討します。根拠のファイル、該当する関数、調査したコミット、利用条件、確認状態、確認者、確認日があると、後からレビューしやすくなります。分からない内容は無理に○か×にせず、要確認とした理由を残します。
進め方は、調査、レビュー、質問、反映、差分確認の順です。まずコードとCSVを変更せずに比較し、プロダクトに詳しい人が実際の画面や運用と照合します。食い違いは根拠を添えてエンジニアへ質問し、確認できた変更だけをCSVへ反映します。
- 調査：既存CSV、確認できた実装、差分候補、根拠、不明点を並べる
- レビュー：利用者の権限、公開状態、実際の業務フローと照合する
- 質問：対象操作と根拠ファイルを示し、判断できない点を絞る
- 反映：確認済みの内容だけを対象CSVへ反映し、変更理由を残す
- 差分確認：対象外ファイル、列順、文字コード、重複、行削除の理由を確認する
研修後の2週間で2〜3件を試してみる
研修が終わったら、実務に近い小さな課題を2〜3件試してみます。渡した情報、できた成果物、人が直した箇所、誤った説明、かかった時間、他部署との会話で役立った点を記録しておきます。
最後に30分ほど振り返り、次も使いたい依頼文を残します。CRUD表を更新するなら、画面・API・DBのどこが対象か、論理削除や未公開機能をどう扱うかを先に決めておきます。使った回数に加えて、調べた根拠や変更した理由を自分の言葉で説明できるかも、導入の結果として確認したいです。