Claude Codeは「賢い部下」。指示の出し方と成果物のレビューの仕方を覚える回です。あなたの「現行仕様をコードから読み解く力」は、AIの出力の正否を判定する力そのもの。今日から「読む・書く」の大半をAIに任せ、「指示する・検証する」側に回ります。題材は付属のlegacy-orders(レガシー風の注文管理システム)です。
legacy-orders フォルダ(zipを展開した場所)で claude を起動して、以下を順に体験します。
| 操作 | やり方 | 覚えること |
|---|---|---|
| 質問する | そのまま日本語で入力 | 敬語不要。具体的に書くほど良い |
| 処理を止める | Esc キー | 暴走したら遠慮なく止める |
| 会話をリセット | /clear | 話題を変えるときは切る(混ざると精度が落ちる) |
| 終了する | /exit | |
| 変更の承認 | 実行前に確認が出る | 内容を読んでから y — レビューの第一歩 |
最初の一言(コピーして貼り付け):
このプロジェクトの全体構成と、主要なクラスの役割・依存関係を日本語で説明してください。 クラス間の関係図をテキストで描いてもらえると助かります。
→ 出力を読み、自分のコードリーディングと同じ結論かを確認。違和感があれば「〜は本当に合ってる?」と聞き返す(鵜呑みにしない練習)。
src/main/java/com/example/orders/OrderService.java の現行仕様を読み解き、 以下がわかるMarkdownの仕様書を docs/order-service-spec.md に作成してください: - 公開メソッドごとの入力・出力・例外 - バリデーションのルール(OrderValidator の内容も含めて) - 注文ステータスの遷移と、キャンセル時の在庫の扱い
レビュー観点(あなたの仕事): 仕様書とコードを突き合わせ、間違い・抜けを最低1つ探す → 見つけたら「◯◯が抜けている。追記して」と指示。
src/main/java/com/example/orders/PriceCalculator.java に JUnit 5 のユニットテストを 作成してください。 - 既存テスト(src/test/java 配下)の書き方・命名規約に合わせる - 送料無料になる5000円の境界、クーポン適用の3000円の境界、まとめ買い割引の 10個の境界、会員ランクごとの割引、書籍と一般商品の税率の違いを必ず含める - 作成後、run-tests.cmd を実行して全テストが通ることを確認してください
続けてもう1本。対象クラスは自分で選びます(候補: OrderValidator、OrderService.cancel)。
レビュー観点: ①各テストが仕様の「何を」保証しているか説明できるか ②境界値の選び方は妥当か ③グリーンになったからOKではなく、テストの意図を1本ずつ読む。
ReportGenerator の generateMonthlyReport メソッドを、挙動を変えずに読みやすく リファクタリングしてください(メソッド分割・変数名の改善など)。 変更後、run-tests.cmd で全テストが通ることを確認してください。
→ さきほど自分たちで増やしたテストが「安全網」として機能する体験。テストを先に作ってからリファクタするのがAI駆動開発の基本順序です。
数字はこの端末に自動保存されます。「従来の見積」は正直に(効果を語るときの説得力になります)。
| 演習 | タスク | 従来の見積(分) | 実際(分) | 短縮率 |
|---|---|---|---|---|
| A | 仕様書化 | — | ||
| B | テスト生成×2クラス | — | ||
| C | リファクタ1件 | — |
1. 具体的に — 「テスト書いて」ではなく「◯◯クラスに、既存規約に合わせて、境界値含むJUnit5テストを」
2. 検証まで指示 — 「作成後、テストを実行して通ることを確認して」を必ず付ける
3. 段階的に — 大きな依頼は「まず計画を見せて」と言ってから実行させる
4. 疑う — 違和感があれば「本当に?」と聞き返す。AIは自信満々に間違える