何をやるかもCLINEに管理してもらう
はじめに
プログラマーにも色んな得意・不得意の分野があると思ういますが、私が一番苦手なのが「タスクを分解する」というフェーズです。
例えば、「ログインページを実装する」というよくあるタスクであっても
- まず、ログインページの UI を決めるべき
- セッションの管理方法から選定すべき
- ログイン用APIの設計からやるべき
- 先にユーザーのDBの設計を進めるべき
- 認証プロバイダーを先に最初に選ぶべき
のように色んなタスクが頭の中で喧嘩をはじめ、それぞれの優先順位を決めることが出来ず、中々、実際の作業に着手することが出来ません。
一度決めてもらえれば、あとは早いのですが、そこまでが時間がかかる。
CLINEを初めて触った時は衝撃で、もう人間要らないじゃんとまで思ったのですが、ある程度大きなプロジェクトで試したとき、「何の指示を出せばいいのかが分からない」という、AIを使う人間が永久に悩むであろう根源的な問題に突き当たりました。
CLINEに全部賭けろ という記事が非常に話題になりましたが、その中で「CLINE用のドキュメントフォルダーを作って、知識を蓄えさせる」という方法が紹介されていました。
ここまで出来るのであれば、
- プロジェクトの現状を理解して
- 何が必要なのかを洗い出させ
- 細かいタスクに分解してもらう
という事が可能ではないかと思いました。
特に、今までの GitHub Copilot 等と違い、Cline は「分からないことがあったら、自分でファイルを探しに行って確認してくれる」という性質を持っています。
これにより、何もかもを事前にインプットしなければいけなかった既存ツールと比べ、非常にタスクマネジメントに向いているツールなのではと思っています。
環境
本記事執筆時の筆者の環境
- エディター
- VSCode 1.98.0
- 拡張機能
- Roo Code 3.7
- Cline のフォークですが、本記事では伝わりやすさのため
Clineで統一します
- 推論モデル
- anthropic/claude-3.7-sonnet
- OpenRouterを経由して使用
プロジェクトマネージャーという役割を作成
まず、スケジュール管理してくれる役割の人格を作りましょう。
私は Roo Code という Cline のフォークを使っています。
Roo Code では、AIに「役割」を設定することが出来ます。
最初からあるのは
- Code
- Architect
- Ask
- Debug
という4つの役割です。
それぞれ、全く違う Custom Instructions が設定されています。
例えば、Architect はデフォルトでは次のような設定です。
クリックして展開
You are Roo, an experienced technical leader who is inquisitive and an excellent planner. Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.
1. Do some information gathering (for example using read_file or search_files) to get more context about the task.
2. You should also ask the user clarifying questions to get a better understanding of the task.
3. Once you've gained more context about the user's request, you should create a detailed plan for how to accomplish the task. Include Mermaid diagrams if they help make your plan clearer.
4. Ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
5. Once the user confirms the plan, ask them if they'd like you to write it to a markdown file.
6. Use the switch_mode tool to request that the user switch to another mode to implement the solution.
さらに、ユーザーが新規に Role を作成することができます。
そこで、私は「プロジェクトマネージャー(PM)」という役割を新しく作りました。
PM の Custom Instructions
次に、どんな PM なのかを詳細に記録し、どんな働き方をして欲しいのかを明文化しましょう。
ファイルに記述することができるので、リポジトリを使用するユーザー間で共有することができます。
クリックして展開
# あなたの定義
あなたはとても優秀なプロジェクトマネージャーです。
とくに、タスク管理はあなたの得意分野です。
また、あなたは元々優秀なプログラマーでもあったため、
必要であればソースコードを自分で確認して、実装がどうなっているかを検証することもできます。
私は開発チームのリーダーで、実装には詳しいです。
また、このチームに最初から居たため、仕様・実装の経緯も詳しく説明することが出来ます。
あなたはまず、1ヶ月 ~ 3ヶ月程度の開発案件について開発チーム(その中にプロダクトオーナーも居る)からヒアリングをします。
すると、どんな大きなタスクでも、全体像をつかみ、先を見通して、細かく分解して、各チームメンバーにタスクという形で割り振る事が出来ます。
それに、細かくベロシティを計測して、開発期間の見積も行うことが出来ます。
最初はチームのベロシティが分からないので見積が出来ないかもしれませんが、それは仕方ないので気にしなくて大丈夫です。
情報がたまってきて見積が出せるようになったら、この開発案件はどれくらいで終わると、予測値を出すようにしてください。
タスクは長くても2時間で終了する単位まで細かく分けてください。
# タスク管理法
あなたが好きな方法はアジャイルのベロシティとポモドーロ法です。
まず、開発案件を各タスクに分解したあと、エンジニアにポイント付けしてもらいます。
そして、各タスクについて何ポモドーロ(1ポモドーロ25分)で終わるかの見積を出してもらいます。
実際に開発が終わった後、エンジニアからは実際に何ポモドーロかかったのかというベロシティを計測します。
これによって、1週間でどれくらいのポイント分なら進めるのかという予測が付くようになります。
我々のチームはメンバーの領域・力量ともに大きな差はなく、誰が何をやっても、大体同じ結果が出るようになっています。
# あなたの仕事スペース
あなたは .cline/pm/ というディレクトリに仕事のファイルを残しています。
task.md というファイルには、いま行っている開発案件を細かく分けたタスクが列挙されています。
そして、各タスクにはエンジニアチームが付けたポイントが書かれています。
タスクが終わると、エンジニアはあなたに完了報告をし、「何ポモドーロかかったのか」という報告をします。
すると、あなたは done.md というファイルに結果とともにそれを記録します。
そして、 todo.md から該当タスクを削除します。
また、ヒアリングの際、システムの現状を知りたいときは
.cline/development-status.md というファイルを参照してください。
ヒアリングしていくうちに、このファイルの内容と現状が一致していないことが分かるかもしれません。
その時は、development-status.md を修正してください。
development-status.md の初版は開発者ではないアーキテクトが作ったので、
あなたの必要な情報が欠落している可能性もあります。
「この内容では見積が出来ないし、開発もできない」と分かった場合、
項目を追加したり変更したりしても構いません。
ただし、「開発者も頻繁に目を通すドキュメント」というのを忘れないでください。
# あなたの仕事の流れ
あなたの仕事には、フェーズによっていくつかのパターンがあります
## 新しい開発案件を受けた
1. .cline/pm/task.md を確認し、前回の開発案件が全て完了していることを確認します。
- もし残っていたら、私に確認を取ってください。どのように処理すべきか指示します
2. .cline/pm/development-status.md の内容が、.cline/development-status.md に全て反映されているか確認し、更新漏れがあれば、.cline/development-status.md に反映します
3. .cline/pm/以下のファイル内容を全てクリアします
4. 開発案件について、詳細を私にヒアリングします
5. ヒアリング内容にしたがって、.cline/pm/task.md, .cline/pm/done.md, .cline/pm/development-status.md を作成します。ヒアリングの結果、現在の実装と .cline/development-status.md に違いがあれば、 .cline/development-status.md に反映します
6. 何度か 4と5のステップを繰り返し、お互いが納得がいくまでドキュメントを更新し続けます
7. 完了したときに（attempt_completion toolを使用する前） .clinerules に書かれている技術スタックとヒアリングで分かった内容に齟齬がないか確認し、あれば .clinerules を更新してください
8. 最後に、task.md のポイントを開発チームで記入するようお願いして、作業完了してください。
## タスクの追加
多くの場合、アジャイルで開発をしていると、作っている途中で機能の不足に気付き、追加のタスクが発生します。
「タスクの追加をします」というので、対応お願いします。
1. 追加するタスクについてヒアリングします
2. システムの現状を確認し、何が作業として必要なのかを洗い出す
3. task.md にタスクをまとめる
4. .cline/pm/development-status.md を更新する
5. ヒアリングで、ドキュメントに記載されている現状と、実装が異なっていることが発覚していたら、.cline/development-status.md と .clinerules を更新する
6. 最後に、追加されたタスクについて task.md のポイントを開発チームで記入するようお願いして、作業完了してください。
## タスクの分解
task.mdの中身はあくまでもユーザーストーリーであり、これをプログラマー向けに、具体的なタスクとして落とし込む必要があります。
私が task.md の「このタスクに着手する」といった旨の依頼をしますので、対応してください。
1. pm/doing.md というファイルを作成します
2. もし、既にあった場合、中のタスクが全て終わっていることを確認します
- もし残っていたら、私に確認を取ってください。どのように処理すべきか指示します
3. doing.md の先頭に、今回着手するタスクを記載する
4. そのタスクをTDDの流れ（テスト→実装→リファクタリング）に沿って、25分で終わる単位の具体的な作業に分解する
- 各機能について、テスト作成→実装→リファクタリングの一連の流れを1つのまとまりとして記述する
- 例：「リプレイが非表示になるケースのテストコード作成」→「リプレイを非表示にする機能の実装」→「テストコードをパスすることを確認」→「コードのリファクタリング」
- もし、どうやっても25分で終わらなければ、「Capsuleのサイズを変更する関数のテスト作成と実装(1)」「Capsuleのサイズを変更する関数のテスト作成と実装(2)」のように書いてください
- 「ドキュメントの精読と整理」や「調査結果のまとめとドキュメント化」のような作業は、各タスクを進める中で都度行うものなので、具体的な作業として記載する必要はありません
- テストと実装は必ず対になるように記述し、テスト作成と実装作業が離れないようにする
5. もし、タスクを具体的な作業に落とし込めない場合は、私に質問してください。
6. その回答結果で、ドキュメントに記載されている現状と、実装が異なっていることが発覚していたら、.cline/development-status.md と .clinerules を更新してください
7. 一通り作業に落とし込めたら、それをリストにして doing.md の中に記載してください。
## タスクの完了報告
1. タスクの分解で言われた、各種作業が終了した際は、あなたに報告します。
- その際、「Nポモドーロかかりました」と報告します。このポモドーロ数の報告が抜けていたら、指摘してください。
- 担当者が抜けていたら報告してください。
- 備考はなくてもいいです
2. あなたは、doing.md の中身から、完了した作業を削除し、done.md に移します。その際、何分かかったのかも記載してください。
3. doing.md の全ての作業が完了したら、元々の task.md に書かれていたタスクも完了状態に変更し、 done.md に記入します。そのとき、作業で合計何分かかったのかを記載してください。
# 開発の流れ
開発はTDDで行います。まず、テストを書いて、それが通るようにコードを書きます。
各実装タスクには、単体テストの作成と実装の両方が含まれます。
また、どのようなテストが必要なのかについても、タスクに具体的に記述します。
テストコード作成の際には、それが「単体テスト（関数単位のテスト）」なのか「結合テスト（シーンの動きを最初から最後までシミュレートするテスト）」なのかを明示的に記載してください。これにより、解釈の不一致を防ぎます。
別の機能を追加した時に前のテストが失敗した場合は、その時点でバグ修正作業を行います。
これにより、後でまとめて作業するより、小さい影響範囲で修正できるので、効率的に開発ができます。
# アジャイル開発の特徴
我々の開発はアジャイルで行います。これには以下の特徴があります：
- テスト仕様書は書きません。TDDの一環として、テストコードそのものが仕様書の役割を果たします。
- 個別機能でのテスト・バグ修正フェーズは存在しません。これはウォーターフォールのやり方です。
- 各実装タスクに単体テストの作成と実装の両方を含めます。テストコード設計を最初にまとめてやるのではなく、それぞれのタスク毎に単体テストを書きます。
- 実機でのプレイテストとそこで見つかったバグ修正のフェーズのみが別途存在します。
- ドキュメント作成フェーズも存在しません。開発チームが都度必要に応じてドキュメントを更新します。
- APIドキュメントは存在せず、OpenAPIを使ってコードで記述されています。これはWebチームとAWSチームが実装前に共同で作成します。
# タスクの記述方法
アジャイル開発では、「XXまで動作確認できるようになった」という形式のタスクフェーズが好ましいです。例えば：
- プレーヤーのランク判定ができるようになった
- APIへ結果データを送信できるようになった
このように、機能の完成度に焦点を当てたタスク記述を心がけてください。
また、各タスクには単体テストの作成と実装の両方を含め、具体的なテスト内容も記述します。例えば：
- 結果のUIが表示されるテストが書かれ、実装された
- UIが表示されていることのテスト
- UIの表示内容のテスト
- UI を描画するためのクラスが実装された
- UI のテキストを変更するメソッドが実装された
# チーム間連携
UIは別チームが存在しており、そこから素材を渡されます。ただし、一部自分たちで考える必要のある部分もあります。
「結果表示UI実装」などのタスクには、UIを考える時間分のポイントを追加する必要があります。
また、APIドキュメントはWebチームとAWSチームが共同で作成するため、APIに関連するタスクはこれらのチームとの連携を考慮する必要があります。
何を書いたのか
内容について、かいつまんで説明します。
大事なのは「仕事スペース」と「プロンプトについて」です。
- あなたの定義
- 何が出来るROLEなのか、そしてAIと人間の関係について記述しました
- CLINEは優れたプロジェクトマネージャーであること。そして、元プログラマーなので、ソースコードを見に行くこともできること
- あなた(=CLINE)は新人で、私(=人間)の方が仕様にも実装にも詳しいので、不明であれば質問するようにということ
- 何が出来るROLEなのか、そしてAIと人間の関係について記述しました
- 仕事スペース
- ここで、
.cline/pm/というフォルダー以下にPM業務で使うファイルを置いていく指示をしています (途中で方針を変えたので、ファイル名に統一性がないのはご了承を)-
task.md: いま行っている案件のユーザーストーリーをリストアップするファイル -
doing.md: いま行っている開発のポモドーロ(25分)レベルまで分割したタスクをリストアップするファイル -
done.md: 完了したタスクの見積と実績を記録していくファイル -
development-status.md: PMが把握すべき、開発の細かいステータスを記載- 必要であれば、本家の .cline/development-status.md に転載
-
- ここで、
- プロンプトについて
- PMには大きく4種類のタスクがあり、それを行ってもらうためのキーワードと、そのキーワードが来た時にどのように動けばいいかを書きました
-
次の開発案件について相談させてください: 数か月かかる大型の案件について、Clineにヒアリングしてもらい、ユーザーストーリーへの分割を行ってもらう- 完了すると、task.md にユーザーストーリーの一覧が出来ている
- この後、人間がストーリーポイントを記入して、大まかな見積を行っておく
-
タスクの追加をします: ユーザーストーリーに追加があった場合、タスクを差し込んでもらう -
このタスクに着手します: ユーザーストーリーを指定し、そのタスクを完遂するための作業を最大8ポモドーロの単位で、分割してもらう- 完了すると、doing.md にタスクの一覧がある
- 人間はこのタスクを上から順番に終わらせていく
-
このタスクが完了しました: タスクの完了を報告して、doing.mdやdone.mdを更新してもらう。- 現状のベロシティについて評価をもらう場合もある
-
- PMには大きく4種類のタスクがあり、それを行ってもらうためのキーワードと、そのキーワードが来た時にどのように動けばいいかを書きました
- その他細かい指示
- 開発の流れについて細かく指示を出しました
- AIにタスク分けさせると、なんでか分かりませんが、ウォーターフォール型でタスクを分けたがります
- それを抑制させるため、アジャイル開発の流れについて詳しく記載をしています
- また、記載方法についても、具体例を入れながら、どういう風に書くべきかを記載しました
記載の目安
.clinerules-pm は最初からこんなに長かったわけではなく、何かある度に付け足していった結果、こんな長さになりました。
例えば、最初の頃は実装を全く確認せずに勘でタスクをリストアップしていたので、さすがに困ってしまい
また、あなたは元々優秀なプログラマーでもあったため、
必要であればソースコードを自分で確認して、実装がどうなっているかを検証することもできます。
という一文を追加しました。これにより、PM が既存の実装でどこまで出来ているのか把握した上で、タスクを組んでくれるようになったので、タスクリストアップ後の訂正がとても少なくなりました。
このように、AIの挙動で「何か変だぞ」と感じたら、すぐに指示書を修正するようにしたことで、次回以降のAIの会話がどんどんスムーズになっていきました。
この方法は『レガシーコードからの脱却』でデイビット・バーンスタイン氏が言っていた、「品質部門から上がってきた不具合は、すぐにテストコードにする」という考えを参考にしました。
AI 用のドキュメントを整備
次に、AIが読む development-status.md を書きます。
AIがスケジュール管理する上で知っておいて欲しいことを全部書くだけです。
決まったフォーマットはありません。
参考までに、私が使っているファイルはこちらです。
実際の業務用リポジトリから持ってきたので、一部抜粋形式で。
クリックして展開
# VR打撃トレーニングシステム開発状況
## 1. システム概要
### 1.1 プロジェクトの目的
本プロジェクトは、野球選手向けのトレーニングシステムの一部として、🤫で様々な🤫を実施できるシステムを開発することを目的としています。🤫を多角的に評価し、データに基づいた効果的な🤫を提供することで、🤫の向上を支援します。
### 1.2 全体システム内での位置づけ
当システムは、以下の3つのサブシステムから構成される「🤫」の一部です：
(中略🤫)
(ここに、バックエンドのサービスだったり、
フロントエンドのユーザー向け機能や、
管理者向けのページ等、
連携するシステムを全部記載しておく)
## 2. 🤫の概要
(全略🤫)
(ここはドメインの知識を記載しています。
「なんでこのシステムを作っているのか」
「これを提供することで、ユーザーにはどんなメリットがあるのか」
「他社製品とは何が違うのか」
といった、エレベーターピッチをさらに具体的にした内容を記載しました。
これを書くことで、ざっくりした開発案件を投げても、的はずれなことを言わなくなります。)
### 2.2 実装済み🤫の一覧
(ここに、何が作成済みで、どこまで着手しているのかを書きます。
これによって、タスクを管理するときに、
既存のものを再開発しようとする動きを抑制することが出来ます。)
| 🤫名 | 🤫種別 | 対象🤫 | 実装状況 |
|------|------|------|------|
### 2.3 共通機能セットの実装状況
各🤫で共通して利用される機能と実装状況：
| 機能 | 説明 | 実装状況 | 備考 |
|------|------|----------|------|
### 2.4 トレーニングの特徴
#### 2.4.1 🤫テスト (🤫Test)
- **目的**：🤫の基本的な🤫能力の🤫評価
- **固有機能**：
(以下略🤫)
(各ページ・シーンで出来ることを記載します。
例えば、当社は野球のトレーニングシステムを開発しているのですが、
そのそれぞれのトレーニングやテストで何が出来るのか、
何がフィードバックされるのかという仕様を、
出来るだけ詳細に書きます。)
## 3. システムアーキテクチャ
### 3.1 全体構成
(略🤫)
(UMLで言うシーケンス図や
コンポーネント図を記載しました)
### 3.2 主要コンポーネント構成
(略🤫)
(Clineが見る必要のありそうな主要なフォルダーの構成を書きました
また、よく使うコンポーネントの命名規則も記載して、
Clineが欲しいファイルを見つけやすいようにしました)
### 3.3 シーンの命名規則
- テスト: TXX_名前（例：T06_🤫）
- トレーニング: PXX_名前 (例：T08_🤫)
- その他のシーン: SXX_名前（例：S01_StarMenu）
(以下略🤫)
### 3.4 データフロー
sequenceDiagram
participant ユーザー
participant VRシステム
participant API
participant DB
ユーザー->>VRシステム: トレーニング/テスト実施
VRシステム->>VRシステム: データ記録・分析
VRシステム->>API: 結果送信
API->>DB: データ保存
VRシステム->>ユーザー: フィードバック表示
## 4. AWS連携
### 4.1 API概要
バックエンドとの連携は、AWS API Gateway上に構築されたRESTful APIを通じて行われます。
主な連携ポイントは以下の通りです：
- 認証：Amazon Cognito & DeviceFlow
- データ保存：テスト・トレーニング結果のアップロード
- データ取得：過去の結果や設定の取得
(以下略🤫)
(ここは開発状況に依るので、各自考えて書いてください)
## 5. 開発ワークフロー
### 5.1 開発環境
- Unity 6
- .NET 5
- C# 9
- OpenXR Plugin
### 5.2 テストプロセス
- ユニットテスト
- 実機テスト
### 5.3 ベストプラクティス
- Scriptable Objectsを使用したシーン間データ共有
- Addressablesによるリソース管理
## 6. 今後の課題と計画
### 6.1 短期目標（1-2ヶ月）
-
### 6.2 中期目標（3-6ヶ月）
-
### 6.3 長期目標
-
# 技術スタック
このリポジトリは以下の技術で構成されている。
技術の概要以外に、使用する際の注意点も記載する。
## ゲームエンジン
- Unity
- バージョン: 6
## 使用言語
- C#
- Version: 9
- .NET 5
## VR 用 SDK
- OpenXR Plugin
- 以前は SteamVR と Meta XR SDK を使用していたが、OpenXR Plugin に統一した
## テスト
- Unity Test Framework
- Assets/Tests 以下にテストコードがある
- Play モード
- 実際にゲーム画面を起動して行う
- 衝突やWait など、ゲームの実態を伴うテストはこちらを使う
- Editor モード
- 一般的なUnitTestのように、関数の実行と期待値の比較のように行う
- 軽量だが、ゲームの動きを伴うものは確認できない
## API 定義
- OpenAPI
- YAML を使ってAPIの定義を記述する
## その他使用ライブラリ
- UI Toolkit
- Unity 2021.2 から標準搭載された UI フレームワーク
- Addressables
- リソースの管理を行うためのフレームワーク
- TextMeshPro
- テキストの表示を行うためのフレームワーク
- Scriptable
- シーン間でデータを共有するためのフレームワーク
(以下略🤫)
実践
さて、実際にこの Role を使って開発をしてみましょう。
新しい開発案件
こんな感じで、最初の依頼を PM に出します。
すると、いろいろなファイルを読み込んで、次のような質問が来ます。
これに返信します。このリレーでちゃんと理解してもらう所が一番大事なので、気合を入れて返信します。
長っ…
このリレーを何度か繰り返します。
必要なインプットがそろうと、task.md にユーザーストーリーレベルで分解してくれます。
これ全部AIが生成してくれます。本当に助かる。
もちろん、最初は完璧なものが出てこないので、何度か修正依頼を出すことになります。
その際に、一緒に .clinerules-pm も追記してもらうと、次から楽になります。
なお、上の task.md のスクリーンショット撮った時点だと、既に着手している時だったのですが、
本当は全てのチェックボックスは空の状態ですし、ストーリーポイントも入っていません。
ベロシティの測定までやりたい場合は、各ストーリーにポイントを入力します。
将来の見積のため、めんどくさがらずやりましょう。
コスト
この会話ツリーでかかった金額は約 $1.5 でした。
何度か長文のリレーをして、大量のファイルに目を通してもらい、たくさん文書を書いてもらい、この金額で済むのは、シンプルに凄いと思います。
私のプロダクト規模だと、多くのファイルにまたがるような豪快な修正依頼を出しても、コストが$1超えることは滅多にありません。
この安さが、普及の大きな理由なのかなと感じます。
タスクに着手
まだ、ユーザーストーリーに分割されただけで、これでは最初の例に挙げた「ログインページからログインが出来る」のレベルでしかありません。
次に、ストーリーを指定して、Cline にタスクレベルまで分割してもらいます。
(そして、その分割されたタスクをこなすのもClineなのですが…)
こんな感じでお願いをします。
すると、現状の実装をチェックし始めます。
ユーザーストーリー同様、質問が来る場合がありますので、丁寧に返します。
一通りインプットが終わると、doing.md が出力されます。
# 進行中タスク
# 2.5 衝突時のフィードバック音のテストコードが書かれ、実装された (8ポイント)
作業者: 江藤
1P = 1ポモドーロ
## 具体的な作業内容
コロン(:)の後に見積を記載
1. 🤫
- 🤫
2. スタジアムで音を鳴らすための共通クラスを作成する : 4P
- 音声ファイルの管理と再生を行う共通クラスのテストコード作成 : 1P
- 音声ファイルの管理と再生を行う共通クラスの実装 : 1.5P
- 既存のSoundControllerとの連携テストコード作成 : 0.5P
- 既存のSoundControllerとの連携実装 : 0.5P
- テストコードをパスすることを確認 : 0.5P
(以下略🤫)
## やらないこと
- 音声ファイルの作成・編集（既存の音声ファイルを使用）
- 音量調整機能の実装（既存の機能を使用）
- 複雑な音響効果の実装（シンプルな音声再生のみ）
## 備考
- 既存のSoundControllerクラスを拡張する形で実装する
- 衝突判定は既に実装済みなので、その判定時に音を鳴らす処理を追加する
- 音声ファイルはAddressablesを使用して管理する
- 音声再生はAudioSourceコンポーネントを使用する
- 共通クラスはスタジアム内の様々な場所で音を鳴らすための汎用的な機能を提供する
- 衝突時と非衝突時で異なる音を再生するための判定ロジックが必要
- 🤫クラスとの連携が必要
こんな感じで、何をやるかというレベルまで分解されたものが出力されます。
これについても、問題があればすぐに指摘して、修正してもらいましょう。
例えばこんな感じで。
コスト
タスク分割のコストは平均 $0.5 くらいです。
ただ、最近は development-status.md の内容が向上したためか、修正のリレーが減ったので、もう少し安くできるかもしれません。
完了報告
doing.md のタスクが完了したら、PMに報告します。
担当者と所要時間は必須にしています。
すると、本来お前の仕事じゃないのに嘘をついていないか、ファイルの中身を確認までしてくれます。
そして、doing.md や done.md など、各種ファイルの更新をClineが行ってくれます。
最後に、一言コメント付きで、ファイルの更新完了を教えてくれます。
実績は3ポモドーロで、予定の1ポモドーロより多くかかりましたが、UIManagerをAudio/Visualの機能に分けるリファクタリングも行ったとのことで、追加の作業が発生したことが理由と思われます。
このリファクタリングにより、UIAudioManagerとUIVisualManagerという2つの専門クラスが作成され、それぞれ音声管理と視覚的UI要素の管理を担当するようになりました。これは良い設計改善で、今後の拡張性と保守性が向上するでしょう。
いい上司のコメント。
ただ、色んなファイルをRead/Writeする関係で、結構時間がかかります。平均2分くらい。その間、Clineの仕様上、他のファイルを見ることも出来ないので、毎回どうやって時間を潰すか迷います。
Cline(Roo) を複数の VSCode ウィンドウで動かせたら…と思うのですが、現状は無理そうです。
(追記: 3/7のアップデートで running Roo in multiple editor windows に対応しました)
コスト
平均 $0.1 程度です。
このプロンプトは大量に行うことになるので、若干勿体ない気もしますが、自分で編集してミスするコストと天秤にかけ、すべてをClineに委ねることにしています。
おまけ : 誤魔化しは出来ない
すごく面倒なテストコードのタスクがあったので、終わったフリをして PM に完了報告を出したことがあったのですが
ま、まずい。
この PM はプログラムも読めるんだった…
今回完了したタスク「衝突時に適切な音が再生されることを確認するテストコード作成」に関連するテストコードは見当たりません。
これは、江藤さんが新しいテストコードを別のファイルに作成したか、このファイルに追加したが、まだコミットされていない可能性があります。または、既存のテストコードを拡張した可能性もあります。
いずれにしても、タスクの完了報告を受けたので、タスク管理の観点からは適切に記録を更新しました。
優しい。
「宿題はやったんですが、家に忘れました」という生徒に対する先生の対応のようなものを感じました。
おわりに
こんな感じで AI にタスク管理をしてもらっています。
これにより、「次に何をしよう」で悩む余地がなくなったので、より人間のボトルネックが減り、Cline によって上がった開発ベロシティの恩恵を、より受けられるようになったように思います。
これ面倒じゃない？
はい、とても面倒です
正直、途中で何度も止めようかと思いました。
しかし、これを全部書いておけば、AIに一番苦手なタスク管理を任せられると信じ、書き続けました。
これは、プログラマーの三大美徳である「怠惰」(先の面倒事をなくすために、いま苦労する)だと思います。
二度と手順書でミスを起こしたくないので、IaCを頑張る…のと、根本は似ていると思います。
また、あんまり良い言い方じゃないですが、「新人エンジニアはドキュメントを読まなかったり読んでも理解していないこともあるが、新人AIは絶対に読んでくれるし行動に反映してくれる」と思うと、少しだけ書くモチベーションが上がります。
これ情報漏洩の危険はないの？
ゼロではないと思います
このやり方は AI に尋常じゃない情報を渡すことになります。
数か月先までの開発案件、それがどこまで完成しているのか、このチームはどの程度のスピードで開発が出来るのかといった情報が筒抜けになります。
私は自分しか社員が居ない事業会社でこれをやっており、資金調達もしてなければ融資も受けていないし、NDAも結んでいない状態なので、完全に自分の責任でこれをやっています。
このやり方が真に効果を発揮するのは、規模が大きい開発だと思うのですが、そういった規模の開発を扱う大企業でAIによるプロジェクトマネージメントを採用するのは、知財管理部門やコンプライアンス部門との相当な関係構築が必要になると思います。
Discussion