トップ > 新人PM Devinくん奮闘記

新人PM Devinくん奮闘記

こんにちは、Reproでデザイナー兼ユニットリーダーをしている竹内です。

ここ最近、チームの定例会議の準備やファシリテーションをAIエージェントであるDevinに任せてみているので、その手法やぶちあたってきた問題についてお話しします。

プロジェクト管理に改善の余地あり

私の所属するFeature 3 Unitでは、スクラムで1〜2週間のスプリントを回しています。 スプリントの始めにプランニングをして実施する項目を決定し、日々のデイリーで進捗を確認し、スプリント終わりに振り返り（レトロスペクティブ）をするという、よくある流れです。

ClickUpというタスク管理ツールを利用してタスクを可視化しています。

しかし完璧に運用できているわけではなく、ClickUp上のタスクと実態が乖離してしまうことがしばしば発生しました。Doneにならずに期日を過ぎたタスクが残っており、状況がわからないのです。

また、できるだけタスクを細かくサブタスクとして分割していたのですが、ネストが深くなりすぎてタスクが把握しづらかったり、スプリントリスト（スプリントのタスクを集めているClickUpのリスト機能）にサブタスク単体を表示できずに管理できないなどの問題がありました。

このような問題を解決するためにタスク管理方法やMTGアジェンダの改善を検討していましたが、せっかくなのでAIエージェントを導入して改善することにしました。

AIエージェント導入と管理の見直し

導入するAIエージェントにはDevinを選びました。Slackからで誰でも利用できるし、ClickUpと既にMCPで連携していたので導入のハードルが低かったからです。

さて、Devinに働いてもらう前に、まずタスク管理の設計そのものを見直しました。

まずサブタスクのネストをやめました。長期で取り組んでいる開発テーマと、日々の作業タスクを別々に作ってリンクする構造にしたのです。これでスプリントに積むタスクをフラットに管理できるようになりました。

その上で、コメントで進捗を管理しようとするのもやめました。タスクが適切な粒度で切られていれば、「完了 / 未完了」だけで状態が把握出来ます。コメントは 「ブロッカーが発生したとき」「重要な判断をしたとき」 だけ書く、 と割り切ったルールにしました。

定例MTGのアジェンダとプロンプト設計

3つの定例MTGに共通する基本的な流れは以下です。

  1. Slack WorkflowがチームにClickUpの更新と状況共有を呼びかける
  2. メンバーがClickUpを更新しながらスレッドに返信する
  3. 情報が集まったところでDevinを呼び出す
  4. Devinがサマリ生成やタスク登録をやってくれる

SlackでWorkflowがメンバーに更新を促しているキャプチャ
Workflowに従ってみんなコメントしてデイリーを始めている様子

Devinへの指示にはPlaybookという機能を使っています。定例MTGごとに1つPlaybookを作って運用しています。

ちなみにDevinには日時を指定してプロンプトを実行できるScheduleという機能がありますが、本フローではSlack Workflowを起点としています。 なぜなら、最初からDevinを起動すると、待機時間などの影響で1セッションに非常にお金がかかってしまったからです。

デイリーの設計

Slack WorkflowでメンバーにClickUp更新を依頼します。メンバーは各自ClickUpを更新し、今日注力するタスクをスレッドに書いてチェックインします。準備ができたら誰かが「次に進む」ボタンを押してDevinを呼び出す流れです。

  1. Slack Workflowがチェックイン依頼を投稿
  2. メンバーがClickUpを更新してスレッドに返信
  3. 誰かが「次に進む」ボタンを押す
  4. Devinが起動 → 状況を確認し、各メンバーに必要に応じて個別質問 → 現状のサマリを生成
  5. 10:00 AM：同期ミーティングでサマリを確認・ブロッカーについて協議

Devinのプロンプト（抜粋）はこんな形です：

## Procedure

1. ClickUp MCPを使って、現在アクティブなスプリントリストをMarkdown形式で取得する
   - この1回の取得結果を以降のStep全体で再利用する（追加取得は不要）

2. 取得したスプリントリストとチェックイン返信を照合し、
   問いかけが必要なメンバーを特定する

3. このスレッドに問いを投稿する
   - 1人あたり1〜2問に絞り、断定・評価はせず気づきを促す問いの形にする
   - 末尾に「次に進んで」または「proceed」で進む旨を添える

4. 「次に進んで」が投稿されるまで待機する

5. 以下の構成でサマリをこのスレッドに投稿する（1500文字以内）
   - 完了したこと（担当者ごと）
   - 今日やること（担当者ごと。チェックインの内容も添える）
   - 要確認・ブロッカー（未回答・ブロッカー報告・レビュー待ちが長いPR）
   - 全体進捗（Sprint Goalごとに、現在の進捗・このままのペースでゴールに届くかどうかを必ず言及する）

最終的に、要確認事項に関する質問や、スプリントゴールに対する進捗などファシリテータが話すべき内容を全てDevinが出力してくれるので、メンバーはこれらを確認するだけでデイリーの目的が果たされるようになりました。

ちなみに 「ClickUpのAPI呼び出しはStep 1の1回のみで完結させる」 という制約を入れています。当初はDevinがスレッドをポーリングして、誰かの報告があるたびにClickUpの情報を取得しに行っていたので、デイリー1回のセッションでまあまあ良いランチ食べられるくらいの金額が溶けました🫠

振り返り（レトロスペクティブ）の設計

振り返りは全てをDevinに任せている訳ではなく、スプリントゴールの達成状況やタスク完了状況を把握するところに利用しています。

前スプリントのリストを参照して、出力形式を細かく指定してスプリントのまとめを出してもらっています。 Devinのプロンプト（抜粋）：

## Procedure

1. 直前のスプリントリストからSprint Goal・スプリント期間・全タスクを取得する
2. 以下の形式でサマリを出力する

## 出力形式

- サマリ：完了 X件 / 未完了 Y件（完了率 Z%）
- Sprint Goal：達成 / 未達成 + 理由を1〜2行
- 完了したタスク — Sprint Goal関連（担当者ごと）
- 完了したタスク — Sprint Goal外（存在しない場合は省略）
- 未完了のタスク（持ち越し予定かどうか・理由のカテゴリを添える）

## Advice

- 未完了タスクの理由は以下のカテゴリのいずれかに分類して添える：
  - **見積もりミス**：着手してみたら想定より工数がかかった
  - **スコープ追加**：スプリント中に追加・変更が入った
  - **ブロッカー**：依存関係・外部要因・レビュー待ちなどで止まった
  - **その他**：上記に当てはまらないもの

未完了タスクの理由は「見積もりミス / スコープ追加 / ブロッカー / その他」でカテゴリ分けさせています。
簡潔にスプリントの結果を把握でき、その後のKPT振り返りの出発点として使いやすくなりました。

プランニングの設計

プランニングでは、まずはスプリントで達成したいスプリントゴールを人間が考えます。 それをもとにDevinがタスクに落とし込み、ClickUpへの登録までを行います。

Devinのプロンプト（抜粋）：

## Procedure

### フェーズ①：タスク案作成（ClickUpへの書き込みは行わない）

1. Sprint Goal・スプリント期間・イシューURLをスプリントリストから読み取る
2. 各イシューについて、技術領域ごとに必要な作業を列挙する
   バックエンド実装 / フロントエンド実装 / テスト / レビュー / ドキュメント / インフラ・デプロイ
3. 各タスク候補に「1人が1日以内に完了できるか？」を確認する。If No → 分割する
4. タスク案をテキスト投稿し、末尾に「問題なければ『登録して』と投稿してください」を添える
5. 「登録して」が投稿されるまで待機する

### フェーズ②：ClickUpへの登録

6. タスク案をClickUpに登録する（対応イシューへの "relates to" リンク・スプリントリストへの追加）

## Forbidden Actions

- フェーズ①（「登録して」を受け取る前）にClickUpへ書き込まない

タスクをできるだけ細かく分割しておく ことで、完了できないときの遅延に気付きやすくなります。今まで苦労していた点でもあったのですが、プロンプトに組み込むことで自然に意識できるようになりました。

もちろんいきなり完璧なタスク切り出しができるわけではないので、フェーズ①でDevinと会話しながらタスクを調整し、フェーズ②でClickUpにタスク登録するというように、フェーズを明示的に分けています。

ぶち当たった問題たち

当然いきなりうまくいったわけではなく、試行錯誤を繰り返して今に至っています。 これまでの説明でもいくつか問題があったことを紹介していますが、そのほかにも今までにぶち当たった問題をいくつかご紹介します。

  • タスクのDueはまだ来ていないはずなのに「Dueが過ぎているタスク」などと言って詰められる
    • 日本のタイムゾーンで考えていなかった。 ClickUpの日付を見るときは必ず日本のタイムゾーンで考えるよう追記した
  • あまり重要でないタスクを「一番重要なこと」などと言ってデイリーの場を混乱させる
    • 優先度の判断基準を情報として渡せていなかった。 ClickUpにPriorityフィールドがあるので、全てのタスクでこれを埋めて運用するようにした
  • 情報が集まってからDevinが思考する時間が意外と長く、待ち時間が発生する
    • 非同期で済ませられるフェーズは非同期で完了 させてからMTGを開始する。MTG中に待ち時間が発生する場合は雑談タイムにする。など

まとめ

まだまだ発展途上の開発プロセスではありますが、回し始めてみてかなり有用だと感じています。

スプリントゴールの進捗確認やブロッカーの把握など、今まではファシリテーターの技量に依るところが大きかったことが、AIにより一定のクオリティで簡単に再現できるようになりました。

また、AIに正確に理解させようという意識により、開発の進行状況が分かりやすく可視化され始めました。MTG時間の短縮にもつながっています。

このような取り組みは、専任PMがいないチームでも効果を発揮すると思います。同じような課題を抱えているチームの参考になれば嬉しいです。

WE ARE HIRING

Reproでは、プロダクトを共に開発していく仲間を募集しています。この記事を読んで少しでも気になった方がいれば、是非お話しましょう！

Repro株式会社 の全ての求人一覧

© About Repro Tech Blog