どうして開発チームはClaude Codeをうまく活用できないのか
経営者から「AIを使った開発をうちの開発チームにもやってほしいんだけどうまく活用できていないようなので、うまく活用できるようにしたい」と相談を受けます。
僕も下記のような記事を書いているのですが、そもそも使い倒すためには前提条件があるので説明するためにこのnoteを書いています。
(ついでにエンジニアがこの記事を使って経営層に説明しやすくなると良いなと思ってます)
前提
エンジニアとしても生産性の向上するような施策はぜひやりたいと思っていて、Claude Codeなどのコーディングエージェントも活用してうまくやれるなら活用したいと思っている(はず。今回は現場のエンジニアも活用したいと思っている前提で進めます)
エンジニアとしては活用したいが活用できないというジレンマが存在しています。
今回、掲載する画像は下記のような簡易的なツールから生成しているので
経営層に説明する際にエンジニアの皆様はこちらのツールとこのnoteを使って説明してほしい
なぜ活用できないのか
チームの成熟度 x コードベース品質によって、どのようにAIが活用できるかが定まるためである。
① チーム成熟度が低く、コードベース品質がレガシー(技術的負債が溜まっている)パターン
チームが成熟しておらず、技術的負債が溜まっている状態だとコーディングエージェントはドキュメント作成やコードレビューなどの低リスクの作業の成果しか期待ができない(かつ成果も微妙になりやすい)

② チーム成熟度もしくは、コードベース品質が標準的なパターン
チームが成熟するか、コードベース品質が標準的(技術的負債がそこまで溜まってない)パターンだと自動テストの作成やリファクタリングの作業を担うことができるようになる。
この段階でやっとコーディングエージェントを使って、コーディングエージェントを動かす土台を整えることができるようになる。


③ チーム成熟度が高く、コードベース品質が標準的なパターン
コーディングエージェントを使って、品質向上のためのプロセスが回せるようになる。
この段階ではまだ事業に直結するような機能開発における生産性の向上にはほとんど寄与できていない。

④ チーム成熟度が一定以上、コードベース品質がモダン(技術的負債小)なパターン
この段階で初めて、新機能開発や機能修正をコーディングエージェントを活用して行えるようになります。
ここまで行うことによって、新機能開発や機能修正などの作業をコーディングエージェントに任せることができ、事業として生産性向上が実感できるようになると考えています。

どうすればよいか?
①→②→③→④もしくは①→②→④にするしか方法はない。
① チーム成熟度が低く、コードベース品質がレガシー(技術的負債が溜まっている)パターン
② チーム成熟度もしくは、コードベース品質が標準的なパターン
③ チーム成熟度が高く、コードベース品質が標準的なパターン
④ チーム成熟度が一定以上、コードベース品質がモダン(技術的負債小)なパターン
①→②にする方法
チームの改善プロセスを回して成熟度を上げる取り組みを行うことや
まずは愚直にテストを書いて、CIを回すようなプロセスが有効。
②を④にする方法
②になっている段階であれば、テストやCIの作成、リファクタリング(の一部)はコーディングエージェントに任せることができるようなっているのでコーディングエージェントを使い、技術的負債を解消し、モダン化するのが良いと思います。
アンチパターンについて
仮に②もしくは③の段階で機能追加をした場合はどうなるか?
レガシーなコードベースに対して、Claude Codeで新機能を追加しようとした結果、
意図とは違ったコードが生成されたり、
既存のパターンと異なるコードが生成されたりして技術的負債がさらに積み重なります。
また、エンジニアのレビューの負担が増大し、エンジニアのモチベーションも下がります。
超短期的にいいことはあっても、1週間や1ヶ月単位で見たらいいことはないです。(中長期で見ても同様に悪い結果しか生まない)
確認チェックリスト
チームが成熟しているか、コードベースがモダンかレガシーかどうかわからないという質問ももらうので参考程度にチェックリストを作っているので
参考にしてください。
コードベース品質チェックリスト
参考までにレガシー(技術的負債が多い)の特徴を列挙しておきます。
自動テストが書かれていない
CIが存在しない、または頻繁に失敗している
デプロイ作業が煩雑でデプロイするのに時間がかかる、よくデプロイに失敗している
Linter/Formatterが導入されていない
言語、フレームワークが2年以上アップデートされていない
依存関係の更新が1年以上放置されている
データベースマイグレーションが手動
同じような処理が複数箇所にコピペされている
エラーハンドリングが不統一
巨大な関数やクラスが多い(500行以上)
APIドキュメントが自動生成され、型情報が付与されていない(OpenAPI、GraphQLなど)
コードスタイルが各機能において統一感がない
※項目に合致している項目が多いとレガシーな可能性があるとして参考程度にしてください。
チーム成熟度チェックリスト
参考までに成熟度が低いチームの特徴を列挙しておきます。
コードレビューが形式的または存在しない
ドキュメントが更新されていない
チーム内の知識共有が行われていない
定期的な振り返りが実施されていない
開発プロセスが属人化している
テストを書く文化がない
技術的な意思決定の記録が残っていない
オンボーディングプロセスが確立されていない
技術的負債の可視化ができていない
リリース頻度が月1回未満
技術選定の基準が曖昧
※項目に合致している項目が多いと成熟度が低い可能性があるとして参考程度にしてください。
最後に
僕自身、コーディングエージェントには期待していて
実際、しっかり準備ができているプロジェクトでClaude Codeを使った時の開発生産性は明らかに向上している。
Claude Codeの導入を急ぐ気持ちはよくわかるのですが、ちょっと立ち止まって、自分たちの状況を見直してみてほしいです。
準備に時間をかけることは、遠回りに見えて実は近道です。
まずは現状を把握して地道な改善活動をしつつ、Claude Codeの導入を進めるのはどうでしょうか。
最後にもう一つ
僕がこの記事を書いた理由は、「AIを使えば魔法のように生産性が上がる」という幻想を解きたかったからです。
でも同時に、「適切な準備をした上でAIを使えば生産性は上がる」ということも伝えたいなと思います。
LLMの導入は開発チームがドカンとデカくなるのと同じことで、それでレビューやリリースが破滅するか滑らかであるかはスケールに耐えうる開発環境・チームを作ることにいかに真面目に取り組んできたかによって決まる、というのは鋭利だけど絶対言おうと思ってた #claude_code_deep_dive
— hiragram/ひらり (@hiragram) June 30, 2025
そうなんですよね。開発規模が大きくなると発生する諸問題がごく短期間で発生するようになったので、開発を破綻せずにスケールさせる仕組みへの投資が行われているかどうかが直撃するようになりました。 #claude_code_deep_dive https://t.co/YsPsNlitEY
— Takuto Wada (@t_wada) June 30, 2025
エンジニアの方は下記の記事を読んでください。
これからのポジショニングについて考えていきましょう。
補足説明
今回説明させていただいた内容は継続的に変更する必要のあるソフトウェアのケースを想定しています。
例えば、プロトタイプで作ってみる等については積極的にClaude Codeを活用していけると考えています。
コーディングエージェントの活用にて、お困りごとありましたら、問い合わせいただけると幸いです。
いいなと思ったら応援しよう!
よろしければ応援お願いします! いただいたチップはおいしいご飯を食べるのに使わせていただきます。