こんにちは。タイミーでデータサイエンティストをしている吉川です。
最近、生成AIを使ったプロジェクト管理の仕組みを試しているのですが、想像以上に働き方が変わったので、その体験を共有したいと思います。
TL;DR
- 「進捗を更新して」の一言で、5つの管理ファイルが自動更新される仕組みを作った
- 成果物作成時間が約50%削減（6.5時間→3.25時間）※体感ベース・タスクにより削減率は異なる
- LLMが「外部ツール」から「チームメンバー」に変わる感覚
- 秘訣は、Git管理されたMarkdownファイルにドキュメントを集約し、自動化ルールを作成すること
はじめに：もっと本質的な仕事に時間を使いたかった
プロジェクト管理をしていて、こんなふうに感じたことはありませんか？
デイリースクラム準備 - タスク管理ツールを開く - 「昨日のタスク、進捗率どうなった？」 - 完了タスクを目視でカウント（1, 2, 3...） - 電卓で進捗計算「40/45...88.9%か」 - 手動で更新 今日のタスクを決める - 「タスクAとB、どっちを先にやるべき？」 - 依存関係を確認しようとする - 複数のツールを参照して判断（15分） タスク決定、作業開始 - 「前提となる仕様、どこだっけ？」 - 「前に決めた内容、何だっけ？」 - 複数のツールやドキュメントを探索（30分） 文書を書き始める - 構造を考え、内容を練り上げる（4時間） 週次報告の準備（金曜日） - 完了タスクを手作業でカウント - Sprint切り替え準備：未完了タスクを整理 - 次週の準備（30分）
日常的な進捗管理や情報収集に時間を使うより、もっと創造的で本質的な仕事に時間を使いたい。そう考えるようになりました。
やったこと：Git + Markdown + LLM自動化ルールで進捗管理を自動化
そこで、以下のような仕組みを作りました。
1. すべてのドキュメントをGit管理されたMarkdownファイルに集約
プロジェクトに関するドキュメントをすべてMarkdown形式でGitリポジトリに格納しました。
requirements/
├── A_現状分析/（5ファイル）
│ ├── p01_a_01_high_level_kpi_analysis.md
│ └── ...
├── B_詳細分析/（5ファイル）
├── C_ビジネス要件/（5ファイル）
├── D_データ要件/（5ファイル）
├── F_機能要件/（4ファイル）
├── S_詳細設計/（7ファイル）
└── execution_management/
├── sprint_plans/sprint6.md
├── phase1_issues.md
├── project_epics.md
├── project_dashboard.md
└── project_roadmap.md
なぜMarkdownなのか？
- ファイルベースなので、LLMがコンテキストを取得しやすい
- 相対リンクで、ファイル間の関連性をLLMが自動理解できる
- Git管理により、変更履歴を追跡できる
grepによる高速全文検索が可能
2. 「進捗を更新して」というトリガーワードで自動処理
次に、Cursor（AIエディタ）のルール機能を使って、自動化フローを定義しました。
なぜLLMなのか？
- Git管理のMarkdownに集約された全体の文脈を横断的に理解できる
- 関連ドキュメントを自動収集し、依存関係を把握して不足情報だけ質問できる
- 叩き台の生成と整合性検証を自動化し、人はLLMと壁打ちしながら仕上げに集中できる
「進捗を更新して」と入力すると、以下の処理が自動実行されます：
実際の動作例
※以下は実際の出力を読みやすく簡略化したものです。
私: 進捗を更新して Claude: ╔══════════════════════════════════════════════════════╗ ║ 📊 進捗更新の自動処理を開始 ╚══════════════════════════════════════════════════════╝ ┌──────────────────────────────────────────────────┐ │ 🗂️ ステップ1: エビデンス確認結果 ├──────────────────────────────────────────────────┤ │ A.現状分析（5個全完了） │ ├─ p01_a_01_high_level_kpi_analysis.md ✅ │ ├─ p01_a_02_stakeholder_hearing_summary.md ✅ │ ... │ │ D.データ要件（1個） │ └─ p01_d_01_data_sources_list.md ✅ └──────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────┐ │ 📈 ステップ2: 進捗率算出 ├──────────────────────────────────────────────────┤ │ 完了Sub-issue数: 17 → 18（+1） │ 全Sub-issue数: 54 │ │ 進捗率 = (18 / 54) × 100 = 33.3% │ 進捗バー: ███░░░░░░░ 33.3% └──────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────┐ │ 📝 ステップ3: 5ファイル同時更新 ├──────────────────────────────────────────────────┤ │ 1️⃣ sprint6.md ✅ 更新完了 │ 2️⃣ phase1_issues.md ✅ 更新完了 │ 3️⃣ project_epics.md ✅ 更新完了 │ 4️⃣ project_dashboard.md ✅ 更新完了 │ 5️⃣ project_roadmap.md ✅ 更新完了 └──────────────────────────────────────────────────┘ ✅ 進捗更新処理が完了しました
3. エビデンスベース管理
進捗の判定は「実ファイルが真実」という哲学に基づいています。
そのため、あらかじめ生成される成果物のファイル名や置き場所などを決めておく必要があります。
タスク一覧： - A-1: API設計書 → ファイルあり、ただし [WIP] タグ付き - A-2: DB設計書 → ファイルあり ✓ - A-3: 画面設計書 → ファイルあり ✓ - A-4: テスト計画書 → ファイルあり ✓ - A-5: 運用手順書 → ファイルなし（未着手） LLMの判定：「WIPは除外、未着手1個、実際は60%完了」 → 進捗率 = 完了数（3） ÷ 全体数（5） × 100 = 60% → 成果物ベースの進捗把握で進捗率を明確化
推測や自己申告を排除し、実成果物ファイルの存在で作業完了を判定します。
効果：体感で成果物作成時間が50%削減、そして仕事の質が変わった
Before（従来の方法）
10:45 要件定義を開始 - 「前提となる仕様、どこだっけ？」 - 「前に決めた内容、何だっけ？」 - 複数のツールやドキュメントを確認（30分） 11:15 材料が揃って、ゼロから文書を書き始める - 構造を考えながら、内容を練り上げる（4時間） 15:15 レビュー依頼 - レビュー指摘を受けて、修正対応 17:15 初稿完成（合計6.5時間）
After（LLMとの協働）
11:00 「タスクCに取り組んで」と指示 11:05 LLMがタスクの本質を理解・必要情報を一覧化（5分） - 「このタスクの目的は〇〇ですね」 - 「必要な情報：A, B, C。不足：Dを教えてください」 11:10 不足情報を提供（20分） 11:30 LLMが叩き台作成（5分） - 関連ドキュメント自動収集済み - 7割完成の初稿を生成 11:35 LLMと壁打ちしながらじっくり詰めていく（2時間30分） - 私：「UIの表示項目これで全部？」 - LLM：「〇〇の観点が抜けています。追加しましょうか？」 - 私：「エラーハンドリングのパターンは？」 - LLM：「A, B, Cの3パターン。それぞれメリット・デメリットは...」 14:05 最終調整（10分） 14:15 高品質な成果物が完成！
Before: 6.5時間 After: 3.25時間 - 50%削減、しかも品質向上 ！
体感的に変わったこと
| 指標 | Before | After | 変化 |
|---|---|---|---|
| 進捗更新作業 | 手動で5分～30分 | LLM作業10分～30分＋人の確認1分～5分 | 50%削減 |
| 成果物作成 | 人10割 | LLM叩き台5～7割＋人仕上げ3～5割 | 50%削減 |
| 視点の網羅性 | 人の経験に依存 | 多角的な視点で抜け漏れ減 | 抜け漏れ減 |
※ 上記の50%削減は体感ベースであり、タスクの性質によって削減率は変動します。
削減率が高かったタスク（60-80%削減）：
- 一般的な知識で構成されるタスク
- テンプレート化・パターン化しやすい
- LLMの事前学習データに豊富な事例がある
- 例：技術調査、API設計書作成、一般的なテスト計画書
削減率が低かったタスク（20-40%削減）：
- 組織固有の知識が必要なタスク
- LLMに与えるコンテキストが膨大
- 人間の判断・確認が必要
- 例：既存システムの設計意図の理解、複雑なビジネスロジックの要件定義
その他の副次効果
Markdown集約による「組織の記憶」は、進捗管理と成果物作成以外にも、様々な場面で価値を発揮します。
1. コンテキストを渡さずに、即座に壁打ちができる
※以下は実際の出力を読みやすく簡略化したものです。
私: 機能Xのユーザー認証、どう実装すればいい？ Claude: S-1で決定した認証方式を使用してください 【認証方式】 - JWT + OAuth 2.0（Google認証） - トークン有効期限：24時間 【実装制約】 - 共通ライブラリ：@/lib/auth.ts を使用 - エラーハンドリング：共通形式（S-7：ログ・エラー設計） 【依存関係】 - ログイン機能：完了済み - API仕様：S-3（API設計）に記載
LLMが過去の意思決定（S-1で決定した認証方式）を記憶しているので、すぐに実装方針がわかります。
2. 属人化の排除
「組織の記憶」があることで、特定メンバーへの依存が最小になります。
※以下は実際の出力を読みやすく簡略化したものです。
私: 担当メンバーが突然退職することになった。
引き継ぐため機能Xの実装状況を把握したい。
Claude:
機能X（ユーザー認証）の進捗状況
【完了したIssue】
✅ N-1: セキュリティ基盤設計（100%完了）
- Cloud IAP + NextAuth.js設計
- 決定日: 2025-09-15（CTO承認済み）
【次のIssue】
🟡 N-2: ユーザー認証機能実装（進捗 60%）
✅ 完了: LoginForm基本実装
⏳ 残タスク: エラーハンドリング実装
従来では、担当者のアサイン変更時に情報の引き継ぎに時間がかかっていました。
LLMによる組織の記憶があれば、即座に状況を把握し、スムーズに作業を引き継げます。
3. 思考の深まり（LLMとの壁打ち）
- 下準備（情報収集・構造化）をLLMに任せることで、本質的な思考に集中できます
- LLMと壁打ちすることで多角的な視点を獲得できます（要件の漏れ、エラーハンドリング、セキュリティ等）
- 一人では気づかなかった観点をLLMが補完してくれます
- 結果：最大の価値は時間削減ではなく品質向上にあります
運用してわかったこと
- 始めるのは簡単だが、期待通りに動かすにはそれなりの試行錯誤が必要でした
- プロンプトの調整、ルールの修正を何度も繰り返す必要がある
- しかし、一度作れば継続的に価値を生み出し続ける
- 長期的な投資対効果が初期の手間を上回る
まとめ
この記事では、「進捗を更新して」で進捗管理が自動化され、LLMとの壁打ちで成果物作成が効率化される仕組みを紹介しました。
実現の基盤となる3つのポイント
1. Git管理のMarkdownに集約
- LLMが「組織の記憶」として機能
- 関連ドキュメントを自動収集・整理
- 進捗管理と成果物作成の両方を支える基盤
2. 自動化ルール（トリガーワード）
- 「進捗を更新して」で5ファイル同時更新
- Sprint期限超過の自動検出
3. エビデンスベース管理
- 実成果物ファイルの存在で進捗を判定
- 推測や自己申告を排除
得られた効果
- 事務作業の負荷が半減し、品質は安定化
- 創造的な仕事に時間を使え、アウトプットの質が向上
- LLMは「外部のツール」から「内部のチームメンバー」に変化
最後までお読みいただき、ありがとうございました！
