はじめに
うちの会社は業務系のソフトウェアを作っているんですけど、正直エンジニアの数が全然足りてないんですよね。少人数チームで社内ツールから製品コードまで全部見てるので、雑務的なタスクはとにかく後回しになりがちでした。
そんな時にClaude Codeが話題になって、「じゃあ試しに実務のタスク丸投げしてみるか」と思ったのがきっかけです。最初はコード書かせるだけかと思ってたんですが、想像以上にいろんな作業を任せられることに気づいたんですよね。
最初の間違ったアプローチ
正直、最初は完全に舐めてました。
「AIなんだから雑にお願いすれば良い感じにやってくれるでしょ」と思って、こんな感じで投げてたんです。
この機能のテストデータ作って
これだけ。結果、案の定微妙なデータが返ってきました。境界値もろくに考慮されてないし、ファイル形式も想定と違うし、結局自分で全部直す羽目になって「AIに頼んだ意味あった?」って感じの結果に。
あと一番やっちゃいけないミスだったのが、生成されたコードやドキュメントをレビューせずにそのままコミットしたことです。ある日社内向けのスクリプトを丸投げして出てきたコードをほぼノーチェックでマージしたら、後日別のメンバーから「このエラーハンドリング、想定してるケースと違う」と指摘されました。結局自分の理解不足のまま人に渡してしまって、地味に信頼を落とすことになったんです。
雑な指示 → 雑な結果 → 手直しで余計時間かかる、という悪循環にハマってました。
正しい理解・実践方法
ここから試行錯誤して、自分なりに掴んだコツをまとめます。
1. 丸投げする前に「境界」を明示する
タスクを渡す時、何を判断してよくて何を判断してはいけないかを最初に伝えるようにしました。
このテストデータ生成では、正常系のパターンは自由に増やしてOK。
ただし境界値・異常系のケースは必ず一覧化してから実装に着手して。
実装後は生成したデータの妥当性を自分で検証してから提出して。
これだけで手戻りがかなり減りました。AIに「どこまで裁量があるか」を伝えるのは、人に仕事を依頼する時と全く同じだなと実感しました。
2. レビューのプロセスを必ず挟む
これが一番効果があったポイントです。丸投げ=検証しないという意味では絶対にないんですよね。
# 生成されたコードに対して必ずレビューを走らせる
# コードレビュー観点で不整合・バグ・簡略化余地をチェックしてもらう
実際に自分のチームで運用している中では、コード生成のあとに必ず別視点でのレビューを1回挟むフローにしています。人間のレビューと同じで、生成させた本人（同じセッション）だけに判断させず、一度距離を置いて検証させることで、明らかなミスの大半は事前に潰せるようになりました。
3. 既存資産の活用を先に指示する
これも痛い目にあって学んだことです。何も言わないと、既存のクラスやデータ構造を無視して新規にコードを書き始めることがあるんですよね。社内の既存データ管理クラスがあるのに、それを使わず新しいロジックを一から生成されて、後から「これ既存のクラスで足りるじゃん」となったことが何度かありました。
なので今は最初に一言、
新規実装の前に、既存の関連クラス・データ構造を確認して、
流用できる部分は流用する方針で進めて
と伝えるのを徹底しています。この一手間で無駄なコード量がかなり減りました。
4. 段階的にタスクの粒度を上げていく
最初から複雑な仕様書作成や大規模なリファクタリングを丸投げするのではなく、
- まずは小さい単発タスク（テストデータ生成、簡単なスクリプト）
- 次にレビュー・検証込みのタスク
- 最後に仕様書作成のような、構造化された成果物を求めるタスク
という順で任せる範囲を広げていきました。人間の新人メンバーに仕事を教える時のステップとほぼ同じ感覚です。急に大きい裁量を渡さず、小さい成功体験を積んでから範囲を広げるのがコツでした。
おわりに
結局のところ、「丸投げ」という言葉のイメージと実態はかなり違ってました。放り込んで放置するのではなく、指示の出し方・検証プロセス・既存資産の扱い方をちゃんと設計しないと、むしろ余計な手間がかかることもあるんですよね。
一方で、境界を明示してレビューを挟む運用に切り替えてからは、地味な雑務系のタスク(テストデータ作成、簡単なドキュメント整備、コードレビューの一次チェック)がかなり巻き取れるようになって、チームの実働時間が確実に空いてきています。5人しかいないチームにとって、この差は結構大きいです。
丸投げは万能の魔法じゃなくて、「渡し方」を工夫することでようやく力を発揮する道具なんだな、というのが今回の一番の学びでした。