お疲れ様です！IT業界で働くアライグマです！
Claude Codeで開発速度がかなり上がった一方で、品質担保のやり方を変えないと事故るなと感じる場面が増えてきました。今回は、自分が実際にやっている品質担保のTipsを共有します。
PR作成前は別CWでコードレビュースキルを使う
自分がやっているのは、PRを作成する前に必ずコードレビュースキルを実行することです。ただし、実装したのと同じCW（Claude Codeのセッション）でレビューまでやらせると、正直あまり機能しません。実装した文脈をそのまま引きずっているぶん、判定が甘くなる感覚があります。同じCWだとバカになる、という言い方が近いです。
そのため、レビューは必ず別のCWを立ち上げて行うようにしています。実装の経緯を知らない状態から見てもらうことで、実装側のCWでは気づけなかった視点からの指摘が返ってくることが多いです。AIコーディング時代の開発フロー再設計でも触れられている「レビューと実装を分離する」という考え方に近い運用だと思っています。
IT女子 アラ美
ITアライグマレビュー待ちの時間はgit worktreeで並行修正に使う
コードレビュースキルは、実行するとそれなりに時間がかかります。ただ待っているだけだと手が空いてもったいないので、その間は別のCWでコードレビューそのものを進めたり、git worktreeを使ったマルチセッション運用を組み合わせて、修正範囲が被らない箇所を並行して直すようにしています。
worktreeで作業ツリーを分けておけば、レビュー中のブランチに触れずに、別の箇所の修正を同時並行で進められます。レビューが返ってくるのを手を止めて待つ時間がほぼなくなるので、体感の開発速度はここでかなり変わってくると感じています。
IT女子 アラ美ITアライグマ人の目のダブルチェックが必須な理由（1万行CSVの例）
別CWでのコードレビューを挟んでいても、最後は必ず自分の目でも見るようにしています。実際にあった例ですが、仕様通りに動いていてバグもない、とレビュースキル側の判定は問題なしでした。ところが中身を見てみると、1万行あるCSVアップロード処理を、チャンク分割も何もせずにそのまま1つの変数に読み込もうとしていました。
「仕様を満たしていてバグがない」という判定と、「実運用でメモリやパフォーマンス的に大丈夫か」という観点は、実は別物なんだと痛感した出来事でした。AIコードレビュー指摘の信頼性を見極める判断軸にもある通り、AIのレビューは「指摘がない＝安全」とは限らないので、最後の一手は人の目に残しています。
IT女子 アラ美ITアライグマまとめ
Claude Codeで開発速度を上げつつ品質を落とさないために、自分がやっているのは大きく3つです。PR前のレビューは実装と同じCWでやらせない、レビュー待ちの時間はworktreeで別の修正に充てる、そして最後は必ず自分の目でも確認する。どれも特別な工夫ではありませんが、この3つを外さないようにするだけで、事故る確率はだいぶ下がっている感覚があります。
IT女子 アラ美ITアライグマ
