※Claude Codeを使用して記事を作成しています。
シリーズ：Claude Codeを使ったAndroidアプリ開発 失敗談
- #15（最終回）：コードレビューをサボると、チームのコード品質が下がりがちな話 ← 今回
※この記事の事例は、Claude Codeを使った開発で起こりがちなケースをもとにした想定例です。
Claude Codeの出力やエラーの内容は、環境や指示の内容によって異なります。
はじめに
シリーズ最終回は、チーム開発に関わる失敗です。
個人の失敗ではなく、チーム全体に影響するケースです。
起こりがちなケース
チームにClaude Codeを導入してしばらくすると、コードレビューの質が落ちてくることがあります。
「Claude Codeが書いたコードだから大丈夫だろう」という空気がチームに広がり、プルリクエストの承認が、形だけになってしまう。
その状態が続くと、数ヶ月後には、コードベースに次のような問題が現れるかもしれません。
- 命名規則が、バラバラ（各自のClaude Codeへの指示の差が出る）
- 同じ処理が、複数の場所に重複して書かれている
- ある画面だけ、アーキテクチャが全然違う
- コメントが、英語・日本語・なしで混在している
Claude Codeの品質が高くても、各自が別々に使うと、統一性がなくなるのです。
問題の本質
Claude Codeを個人で使う分には、問題になりにくいことでも、チームで使う場合は、次のような状況が起こりえます。
- 各自のCLAUDE.mdが違う
- 指示の粒度・方針が、人によって違う
- 「Claude Codeが書いたから正しいはず」という過信
これらが重なると、レビューの目が甘くなり、品質が下がりやすくなります。
改善の方法
チーム共通のCLAUDE.mdを作成する
プロジェクトのルートに、全員が参照するCLAUDE.mdを置き、コーディングルールを統一します。
# チーム共通ルール
## コメント
すべて日本語で書く
## 命名規則
・変数・関数：camelCase（英語）
・クラス：PascalCase（英語）
・コメント・エラーメッセージ：日本語
## アーキテクチャ
Clean Architecture（3層構造）を必ず守る
ViewModelにリポジトリの直接参照を書かない
## レビュー観点
Claude Codeが書いたコードであっても以下を必ず確認する
・アーキテクチャのルールに沿っているか
・非推奨APIが使われていないか
・メインスレッドで重い処理をしていないかコードレビューの観点を明文化する
「Claude Codeが書いたから大丈夫」という空気を変えるため、Claude Codeが生成したコードにも、通常のレビュー基準を適用することを、チームで合意しておきます。
Claude Codeはチームの「最初の実装者」
Claude Codeを、ゼロからコードを書く役割として位置づけ、チームメンバーが、レビューと改善を行う役割を担う分業が、機能しやすくなります。
Claude Codeの役割：初稿を書く
チームの役割：レビューして品質を保証するシリーズを振り返って
全15回で取り上げた失敗例を通じて、伝えたかったことは一つです。
Claude Codeは心強い相棒ですが、最終的な責任は自分にあります。
指示の出し方・生成コードの確認・セキュリティ・チームでの使い方、どれも「Claude Codeに任せたから大丈夫」では済みません。
Claude Codeをうまく使う人ほど、その限界と向き合い方を知っています。
このシリーズで取り上げた失敗例が、みなさんの開発をより良くするヒントになれば幸いです。
| # | 失敗のテーマ | 教訓のひと言 |
|---|---|---|
| 1 | 曖昧すぎる指示 | 頭の中を全部言葉にする |
| 2 | 大きすぎる指示 | 1回1機能に分割する |
| 3 | 「いい感じにして」 | デザインは具体的な言葉で伝える |
| 4 | 会話の文脈消滅 | CLAUDE.mdで記憶を補う |
| 5 | バージョンが古い | バージョンは公式で確認する |
| 6 | 非推奨APIの見落とし | Android Studioの警告を確認する |
| 7 | メインスレッドの重い処理 | 生成コードのスレッド処理を確認する |
| 8 | テストなし開発 | テストは実装とセットで依頼する |
| 9 | 設計の丸投げ | 設計方針はClaude Codeと決めてCLAUDE.mdに書く |
| 10 | Composeの不要な再描画 | 「パフォーマンス観点でも確認して」と指示に添える |
| 11 | コードが理解できない | 生成コードは説明を求めて理解する |
| 12 | APIキーの漏洩 | キーはコードに直書きしない |
| 13 | Firebaseのテストモード | リリース前にセキュリティルールを確認する |
| 14 | Crashlytics未導入 | 開発初期から入れる |
| 15 | チームのレビュー低下 | Claude Codeのコードも人間がレビューする |
このシリーズを最後まで読んでいただきありがとうございました！
