AI開発の生産性を上げる「小さく作る」アプローチ

はじめに

カウシェでは、AIツールを導入したものの、期待したほど生産性が上がらないという課題に直面しました。

この記事では、その原因を分析し、「実装計画」という仕組みを通じて解決した経験を共有します。

AI導入で見えた課題

AIを開発に取り入れた当初、生成AIが大量のコードを出力するため開発効率が上がったと感じていました。
しかし、デプロイ頻度などの定量的な生産性指標を見ると、以前とほとんど変わっていませんでした。

原因を分析したところ、以下の2つの問題が見えてきました：

1. PRが大きすぎてレビューがボトルネックになる

   • AIが大量のコードを生成した結果、1つのPRが巨大化
   • レビュアーの負担が増大し、レビューに時間がかかる

2. 新規ロジックの品質が低く、何度もやり直しになる

   • 参考実装がない新しいロジックをAIに任せても、アウトプットの質が低い
   • 結局、人間が修正と再生成を繰り返すことに

このことから「大きく曖昧な指示ではAIを活かしきれない」という結論に至り、「小さく作る」 という方針をとることにしました

解決策：実装計画による「小さく作る」アプローチ

カウシェでは「小さく作る」手段として、「実装計画」と呼んでいるものを作るプロセスを開発フローに導入しています。

実装計画とは

実装計画は、開発タスクを実装レベルの具体的な手段まで細かく分割し、タスク化する方法です。

以下のようなルールで実装計画を作成しています。

• 1タスク = 1PR とする
• 各タスクは個別に実装・テスト可能にする
• AIにも人にもわかる粒度で書く
• コーディングを始める前に実装計画をレビューする

これは、Spec-Driven Developmentの「タスク化」プロセスと似ています。

実装計画の例

例えば、新しいAPI機能を実装する場合：

## 実装計画: ユーザー検索API

### やりたいこと
ユーザー名で検索できるAPIエンドポイントを追加

### 実装タスク（PR単位）

**PR 1: proto定義の実装**
- [ ] search_users.proto にRPC定義追加
- [ ] 基本的なリクエスト・レスポンス型定義
- [ ] バリデーションルール追加
- [ ] protoファイルのコンパイル確認

**PR 2: ハンドラー層の実装 + E2Eテスト**
- [ ] ハンドラー関数追加（認証だけ行う）
- [ ] Unauthenticatedのテストケースを実装

**PR 3: リクエストのバリデーション + E2Eテスト**
- [ ] バリデーションロジック実装
- [ ] 対応したハンドラーでrequestを呼び出す
- [ ] InvalidArgumentのテストケースを実装

**PR 4: データベーススキーマ実装**
- [ ] マイグレーションファイル作成

**PR 5: ドメインモデル実装**
- [ ] ドメインモデル定義
- [ ] ドメインロジック実装
- [ ] ユニットテスト実装

このように、機能を小さな単位に分割することで、各PRが独立してレビュー・テスト可能になります。

小さく作ることのメリット

1. AIが暴走しにくい

タスクを細かく分割することで、AIに与える指示が明確になります。

• 「ユーザー検索API全部作って」→ AIが何を作るか予測困難
• 「proto定義だけ作って」→ 範囲が明確で、出力を制御しやすい

明確な指示は高品質な出力につながります。AIは曖昧な指示よりも、具体的で範囲が限定された指示の方が得意です。

2. レビューコストの削減

PRが小さくなることで、レビューの負担が大幅に軽減されます。

大きいPRの問題点：

• 変更が多すぎて全体像を把握しづらい
• レビューに時間がかかり、フィードバックサイクルが遅くなる
• 見落としが発生しやすい

小さいPRのメリット：

• 変更箇所が少なく、理解しやすい
• 短時間でレビューできる
• 問題を早期に発見できる

実際、カウシェでは実装計画導入後、レビューの負荷が軽減されました。
レビューからapproveまで以前は10時間を超えることもあったのですが、今では平均3時間程度になっています。

3. リリースの安全性が高まる

小さな変更を段階的にリリースすることで、リスクが分散されます。

段階的リリースの利点：

• 問題が発生しても影響範囲が限定的
• ロールバックが容易
• デバッグがしやすい
• 本番環境での動作確認を細かく行える

例えば、先ほどの例では：

1. PR1でproto定義のみをマージ（影響なし）
2. PR2でハンドラーの空実装をマージ（Unimplementedエラーを返すだけ）
3. PR3〜5で段階的に機能を追加

このように、各ステップで動作を確認しながら進められます。

チーム開発での効果

小さく作ることは、チーム全体のパフォーマンスにも良い影響を与えます。

認識合わせが容易になる

実装計画を事前にレビューすることで：

• 実装内容をチームで合意形成できる
• 後々の手戻りを防ぐ
• アーキテクチャの方向性をすり合わせられる

「コーディングしてからレビュー」ではなく、「計画段階でレビュー」することで、大きな手戻りを防げます。

進捗が可視化される

タスクが細かく分割されているため：

• どこまで実装が進んでいるか一目瞭然
• 新メンバーのオンボーディングに有用
• プロジェクト管理がしやすい

PRが5つに分かれていれば、「5つのうち2つが完了」と明確に進捗を把握できます。

DORAレポートとの関連性

実は、「小さく作る」というアプローチは、DORAの研究でも推奨されています。

2025 DORA State of AI-assisted Software Development Reportでは、Working in small batches というプラクティスが紹介されています。
https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report

Working in small batches の効果

DORAのレポートによると、Working in small batches には以下の効果があります：

Working in small batches amplifies the positive effects of AI code generation on product performance and dampens friction in teams due to reviews and coordination costs.
（小さなバッチで作業することで、AIコード生成がプロダクトパフォーマンスに与えるプラスの効果が増幅され、レビューや調整コストによるチーム内の摩擦が軽減される）

— 2025 DORA State of AI-assisted Software Development Report

また、レポートでは「AIのコード生成量を制限する手法なので、個人の生産性は下がったように感じるが、チームのパフォーマンスは向上する」ということも紹介されており、これは私たちの課題感とも一致しています。
AIに大量のコードを生成させると、一見生産的に見えますが、実際にはレビューや修正で時間がかかり、チーム全体では遅くなります。

成果

カウシェで実装計画を導入した結果、PR数やDeploy頻度などのメトリクスが10〜50%向上しました。

PRが増えたのは、1つの機能を複数のPRに分割したためです。
Deploy頻度の増加は、小さなPRを素早くマージできるようになった証拠です。

まとめ

カウシェでは「実装計画」という手段で、小さく作ることを実践しています。

• 開発タスクを実装レベルまで細かく分割
• 1タスク = 1PR
• コーディング前に計画をレビュー

結果として、PR数とDeploy頻度が10〜50%向上し、レビュー負荷も大幅に軽減されました。

---

AI開発ツールを導入しても生産性が上がらないと感じている方は、ぜひ「小さく作る」アプローチを試してみてください。

カウシェでは、少人数×AIで生産性を高めながら、新しい生活圏のカタチを作るエンジニアを募集しています！