Clineとスクラム開発をやってみたら開発速度が2倍になった

はじめに

Clineを業務に導入して２週間、実務のチケットをやらせてみました。その時のノウハウをこの記事にまとめます。
メイン使用したモデルはGPT-4.1です。（Claude 3.7/Gemini 2.5/o4-miniも試しました）

任せたタスク

今回はClineにSpringBootのウェブアプリの管理画面の作成を依頼しました。
ウェブアプリは5万行程の規模で、バックエンドがSpringBoot, フロントエンドがVue3で書かれています。

タスクの概要: フロントエンドにハードコードしていた設定ファイルをDB上で管理できるようにする。

- テーブルの作成
- 管理画面の実装（Thymeleafベース)
  - 作成画面
  - 更新画面
  - 一覧画面
- フロント画面の実装（Vue3ベース）
  - ハードコードしていた設定ファイルから管理画面で作成した設定ファイルを読み込むように変更する

このタスクは人間がやると２週間ほどかかる見積もりのタスクです。

Clineとのインターフェース

ClineのUIからの指示のみでは限界を感じたため、テキストベースでClineとやりとりするための以下のようなフォーマットを作成しました。

• ISSUE.md
• PLAN.md
• DAILY_SCRUM.md
• PROGRESS.md
• RETROSPECTIVE.md

チケット

ISSUE.mdでは今回依頼したチケットの概要と受け入れ条件を記載しています。
このファイルは人間が作成します。

ISSUE.md

# 概要
<!-- このチケットで解決したい課題 -->

## 関連リンク

# 受け入れ条件
<!-- チケットをクローズできる条件を状態として表現する -->

# 心配事
<!-- チケットを進めるうえでハードルとなりそうな懸念点を列挙します -->

# タスク
<!-- チケットの見積もりを行うために、必要なタスクを列挙します -->

# 成果物
<!-- PR以外の成果物のリンクを記載 -->

# 振り返り
<!-- チケットを進める過程で発生したトラブル等 -->

実装計画

PLAN.mdではチケットをサブタスクに分解してClineに依頼する最小単位を決めます。
以下のようなフォーマットでユーザストーリーのフォーマットで作成します。
この中の一つのユーザーストーリーを一回のClineタスクとして実行させます。
このファイルはClineが作成し、随時更新していきます。

PLAN.md

# Issueの計画

<!-- Issueの計画を立てます。ユーザーストーリーに分解し、一つ一つにタスクを洗い出します。-->


## Story-1: {ペルソナ}として{機能}により{価値}を得る

{ストーリーの内容を記載します。}

### タスク

- [ ] タスク1
- [ ] タスク2
- [ ] タスク3

デイリースクラム

DAILY_SCRUM.mdはClineタスクの作業計画です。

DAILY_SCRUM.md

# DAILY SCRUM

## 日付

YYYY/MM/DD (X回目)

## 今日の作業予定
<!-- PLAN.mdの計画の中でどのユーザーストーリーに取り組むか記載してください。 -->

## 修正予定のファイル
<!-- 修正予定のファイルを記載してください。 -->

## 相談事項
<!-- 相談したいこと、質問したいこと、レビューしてほしいこと -->

## 一言コメント
<!-- 感情ベースで一言コメントをお願いします。 -->

## チェックリスト

以下の作業を実施したらチェックをつけてください。全てにチェックがついたらタスクを完了できます。

- [ ] 作業を始める前に、ユーザとデイリースクラムを実施した
- [ ] 作業完了後、PROGRESS.mdに進捗を記載し、レビューを依頼した
- [ ] レビュー通過後、振り返りを実施し、RETROSPECTIVE.md, PLAN.md を更新した

進捗

PROGRESS.mdはClineの記憶を保持するためのファイルです。Clineは新しいタスクを開始するとそれまでの作業の記録を忘れてしまうので、１タスクの最後にこれまでどの程度作業が進んだのかを記録します。
また人間はコードレビューで指摘した内容などをこのファイルに追記します。

PROGRESS.md

# 進捗

このファイルは作業の記録を残すためのものです。追記のみ行い、内容の修正や削除は行わないでください。

## YYYY/MM/DD (X回目) の進捗

<!-- ここに進捗を記載 -->

### YYYY/MM/DD (X回目) のレビューコメント

<!-- ここはユーザが書くので空欄にしておいてください。 -->

振り返り

RETROSPECTIVE.mdはClineが自身の行動を振り返って改善するためのファイルです。
こちらも１タスクの最後にClineが追記します。

RETROSPECTIVE.md

# 振り返り

このファイルで毎日の振り返りを行います。追記専用です。過去の内容を修正しないでください。

## YYYY/MM/DD (X回目) の振り返り
<!-- KPT法で振り返りを行なってください -->

### Keep
<!-- うまく行ったこと、続けていきたいこと -->

### Problem
<!-- 問題点、苦労したこと、レビューで指摘を受けたこと -->

### Try
<!-- 次回やってみたいこと -->
<!-- タスクベースではなく、行動ルールとして記載してください。 -->

その他

Clineにプロジェクト全体の知識を教えるために以下のようなファイルを作成しました。

• .clinerules: Clineの行動指針を書きます。プロジェクトの構成図、技術スタックなど
• {project}/CODING_STYLE.md: バックエンド/フロントエンドそれぞれのコーディングガイドラインを記述します。

作業の流れ

Clineを使ったスクラム開発の流れは以下の図のように進めます。

1. スプリントの開始

最初に、PLANモードでISSUE.mdを参照して実装計画を立てPLAN.mdを作成してというプロンプトでClineに計画を立てさせます。
Clineは既存コードを読んで大まかな修正方針を立ててくれます。
人間はそれをレビューし、レビューが完了したらPLAN.mdとして保存させます。

2. 作業の実施

2-1. デイリースクラムの実施

Clineのタスクを開始する際にはISSUE.md/PLAN.md/PROGRESS.md/RETROSPECTIVE.mdをコンテキストとして渡して、PLANモードで今日（YYYY/MM/DD） X回目の作業を計画を立てデイリースクラムを実施してくださいというプロンプトを渡して作業させます。

そうするとClineは既存のコードを読んで作業計画を立ててくれます。

ある日の例

## 今日取り組むユーザーストーリー

PLAN.md Story-2:
「開発者として***のタグ入力UIをcontrolレベル設計にリファクタリングし、保守性・再利用性を高めたい」

## 修正予定のファイル
- app-front/src/components/***TagControl.vue（新規作成またはリファクタ）
- app-front/src/composables/use***TagControl.ts（新規作成）
- app-front/src/composables/tests/use***TagControl.spec.ts（新規作成）
- app-front/src/stories/***TagControl.stories.ts（新規作成）
- 必要に応じて型定義ファイルや既存の***TagInput.vue

## 相談事項
- タグデータ（***）のhidden input生成仕様（name属性の付け方、Thymeleaf両対応）
- 自動補完やバリデーションの仕様（既存実装との互換性）
- Storybookでのフォーム送信例・バリエーション設計
- テストでの入力パターン網羅方法

## 一言コメント
「タグ入力UIの再設計で、型安全性・UI/UX・再利用性を徹底します！」

## チェックリスト
[ ] 作業を始める前に、ユーザとデイリースクラムを実施した
[ ] 作業完了後、PROGRESS.mdに進捗を記載し、レビューを依頼した
[ ] レビュー通過後、振り返りを実施し、RETROSPECTIVE.md, PLAN.md を更新した

このファイルを以下のような観点でレビューし、フィードバックします。

• 変なところを修正しようとしていないか？
• 参考実装として渡すべきファイルがないか？
• 相談事項のところで、定まっていない仕様はないか？

2-2. 実装とコードレビュー

デイリースクラムが完了したら、ACTモードに切り替えて作業を開始してください。実装が完了したらPROGRESS.mdを追記してコードレビューを依頼してくださいというプロンプトで作業を開始させます。

概ね3-5分ほどで作業が完了します。この間、人間はお茶を飲んだりしていましょう。

進捗報告の例

## 進捗追記（2025/4/23 3回目）

- PLAN.md Story-2「***のタグ入力UIをcontrolレベル設計にリファクタ」に着手し、以下を実施
  - ***TagControl.vueを新規作成（controlレベル・props/model分離・hiddenフィールド生成・Thymeleaf両対応・inputNamePrefix対応）
  - ロジックをcomposables（use***TagControl.ts）に抽出し、テスト容易性・再利用性を向上
  - 単体テスト（use***TagControl.spec.ts）でadd/remove/重複排除/空文字排除/型安全性を網羅
  - Storybook（***TagControl.stories.ts）で使い方・hidden input生成・inputNamePrefix・フォーム送信例を明示
- hidden input生成仕様は update_***.html に厳密に準拠（***形式）
- 型定義・アクセシビリティ・既存画面との互換性も考慮した設計
- 本Story-2のリファクタリングは完了。レビューをお願いします。

### レビュー観点

- controlレベル設計・props/model分離・hiddenフィールド生成・Thymeleaf両対応の実装方針
- composables抽出によるテスト容易性・再利用性
- Storybookによる使い方・バリエーション・hidden input仕様の明示
- 型安全性・アクセシビリティ・UI/UX

### レビューコメント

- 単体テストは `src/composables/__tests__`以下に配置してください。
- Storybookではwith***ではフォーム送信ボタンを用意し、どのようなフォームが送信されるかを確認できるようにしてください。

Clineは時々レビューコメントを捏造してきたりしますが、そういうのは無視して、淡々とコードレビューを行いましょう。

### レビューコメント

- ***.tsにタグ操作のユーティリティがあるので使ってください。
- タグ補完の機能を***.vue を参照して作ってください。
- タグ取得APIはテスト時にはモックできるようにすること。
- Storybookではwith***ではフォーム送信ボタンを用意し、どのようなフォームが送信されるかを確認できるようにしてください。

修正お願いします。

レビューの内容は手動でPROGRESS.mdに記載した上で、ClineのUI上で同じコメントを追記します。
PROGRESS.mdを再確認させてもいいですが、この方がトークンを節約できます。

2-3. 振り返り

コードレビューを1-2回行ったらその作業は終了です。あまり指摘を長く続けるとコンテキストウィンドウが溢れてしまうので、無理に修正しきるのではなく、次のタスクのTODOに追記します。

Clineに今回の作業は終了にします。振り返りを行い、PROGRESS.md/PLAN.md/RETROSPECTIVE.mdを更新してくださいというプロンプトで振り返りと計画の見直しをさせます。
この際AutoApproveはオフにしておいて、一つのファイルごとに人間が確認して指示を出します。

PROGRESS.md/RETROSPECTIVE.mdがある程度溜まってきたら、それをベースに、別タスクでCODING_STYLE.mdの更新を依頼すると良いです。
過去のレビューで受けた指摘を踏まえてコーディングガイドラインを見直してくれます。

作業が全て完了したら、人間が今回の修正をリポジトリにコミットします。

3. プルリクエストの作成

PLAN.mdのTODOが全て完了したらプルリクエストを作成させます。
PROGRESS.mdとgitのdiff, チームのPULL REQUESTのフォーマットを渡して、プルリクエストの本文を作成し、PULL_REQUEST.mdに保存してと指示します。
出てきた内容を確認して、問題なければ実際にプルリクエストを作成させます。GitHubのMCPサーバを使うとここもClineに依頼できます。

効果

ROI

今回、２週間の開発期間でClineにコードを書かせてみたところ、通常の半分の期間（3日）でプルリクエストの作成まで行うことができました。書いた行数は2700行で、かかったコストは4085円でした。

残りの１週間で、追加のリファクタリングを行い、普段は行えていなかった、

• コンポーネントのStorybook化
• コンポーネント単位での単体テストの作成

などを達成することができました。これには3400円ほどかかりました。

まとめると、エンジニア一人当たり週4000円ほどの追加コストで、通常の2倍のコード量を開発できる、という結果になりました。
（この結果はまだN=1なので、再現性を確認する必要はあります。）

定性的な効果

テスト容易性を意識した設計

Clineに修正を指示させるためには、テスト駆動など修正の完了が機械的に判定できるようにすることが重要になります。
これまではUIのテストはあまり自動テストを作っていませんでしたが、
Clineに仕事をさせることを意識すると、自然とテスト容易性を考慮した設計になりました。

作業記録の見える化

また、PROGRESS.md/RETROSPECTIVE.mdで記録をつけ、それを蓄積して分析することで、コードベースのどこに問題があるかを特定できるのではないかと期待できます。
実際の修正のログからコーディングガイドラインをつくることで精度の高いガイドラインができますし、
修正を人間が行う場合でもClineに記録係を担当してもらうことで、進捗やトラブルの発生
をチームメンバーに共有しやすくなる効果がありそうです。

課題

アプリ独自のルール

全体の80%ほどはClineに依頼するだけで良かったのですが、20%ほどは手動（Copilot利用）でコードを修正する必要がありました。特に難しかったのはフロントエンドとバックエンドの受け渡しで、そこがアプリ独自のやり方だったため、うまく指示ができませんでした。また、UIの細かい調整やバグ修正などは苦手なので人間が微調整する必要がありました。
フロントエンドとバックエンド連携はAPI経由にして、APIの仕様をOpenAPIなどで管理した方がいいかもしれません。

タスク失敗率

また、作業ベースで言うと、10回中1回程度は1サイクル（デイリーの実施から振り返りまで）がまるまる無駄になることもありました。そのような場合はPROGRESSとRETROSPECTIVE以外の修正内容をgitでリセットして、再開させました。

長いファイルの修正

チケットの後半は、PROGRESSとRETROSPECTIVEが長くなってきて、Clineによる修正が末尾への追記ではなく、既存の記述の変更になることがよくありました。DAILY_SCRUM.mdに追記したあとで、転記を人間が担当する方が効率は良いと思います。
(DAILY_SCRUM.mdはサイクルごとにリセットしています。）

モデルの比較

今回使用したモデルはGPT-4.1でした。途中Claude 3.7やGemini 2.5、o4-miniも試しました。

• GPT-4.1 (Tier 1)

  • 良かった点：応答が早い。コードも意図通りのものが多かった
  • 悪かった点：直前の指示を優先して、最初の方にした指示（.clinerulesでのルール）を忘れることが多かった

• Gemini-2.5 (Tier 1)

  • 良かった点：.clinerulesの指示を守る率が高かった。コードも意図通りだった
  • 悪かった点：冗長なコメントが多い

• Claude 3.7 (Tier 2)

  • 良かった点: UIのデザインが良い
  • 悪かった点: 意図と異なるコードを生成することがあった

• o4-mini (Tier 3)

  • 良かった点: コードは意図通りでルールも守ってくれる
  • 悪かった点: 応答が遅い。途中経過がわからないので不安になる。ClineがResponses APIに対応してない。

Clineで使う場合はGPT-4.1あるいはGemini 2.5をメインで使うのが良さそうと言う結論になりました。
o4-miniも期待していますが、現状はその真価を発揮するにはCodex CLIを使う必要がありそうです。

まとめ

• 費用対効果◎
  追加コスト週 4,000 円で、従来の 2 倍の開発速度 を達成

• 成功の鍵は“枠組み”
  Clineとのインターフェースを整備することで、安定した開発が可能に

• 人 20 %：Cline 80 %
  実装は Cline に任せ、人間はレビューと微調整に集中するのが最も効率的

• 推奨モデル
  GPT-4.1（速度） or Gemini 2.5（ルール遵守）が現状ベスト

きちんとルールとタスク粒度を整えれば、Cline をチームメイトに加えることで開発速度を２倍になることがわかりました。ただし、再現性はまだ検証する必要があります。