├── .gitignore ├── README.md ├── setup_config.sh └── setup_workspace_simple.sh /.gitignore: -------------------------------------------------------------------------------- 1 | # SpecStory explanation file 2 | .specstory 3 | # SpecStory explanation file 4 | .specstory/.what-is-this.md 5 | 6 | # macOS用の.gitignore 7 | 8 | # macOSシステムファイル 9 | .DS_Store 10 | .DS_Store? 11 | ._* 12 | .Spotlight-V100 13 | .Trashes 14 | Icon? 15 | ehthumbs.db 16 | Thumbs.db 17 | 18 | # 個別フォルダ内のDSストアも明示的に除外 19 | **/.DS_Store 20 | 21 | # Cursor関連ファイル 22 | .cursorindexingignore 23 | 24 | # エディタ関連ファイル 25 | .vscode/ 26 | 27 | # その他の一般的な除外ファイル 28 | *.log 29 | *.tmp 30 | 31 | .cursor/rules/basic 32 | Stock/programs/夕食作り 33 | scripts -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 俺の考えた最強のAIPMシステム with Cursor Agent 2 | ## PMBOK × Lean UX × Agile ― 総合PMフレームワーク支援Rulesセット 利用ガイド 3 | 4 | このドキュメントは、PMBOK標準、Lean UX、およびアジャイル手法を融合したプロジェクト管理システムの使い方を説明するものです。 5 | 6 | **対象読者**: プロジェクト責任者 / PO / スクラムマスター / UX デザイナー / PMO ― 「ドキュメントも実装もユーザー価値も、すべて1本のレールで回したい」人たち 7 | 8 | ## 1. システム概要 9 | 10 | このシステムは、プロジェクト管理における文書作成から確定・アーカイブまでの流れを自動化し、LLM（大規模言語モデル）の支援を受けながらプロジェクトを効率的に進めるためのものです。 11 | 12 | ### 主な特徴 13 | 14 | - **PMBOK × Lean UX × Agileハイブリッド**: 上流工程はPMBOK準拠の文書管理、中流にLean UXの発見と検証、実装フェーズはアジャイル手法を採用 15 | - **フォルダ構造の分離**: `Flow`（ドラフト）→ `Stock`（確定版）→ `Archived`（完了プロジェクト） 16 | - **自動文書生成**: 質問応答による文書ドラフト作成 17 | - **自動同期**: 「確定反映」コマンドによるFlowからStockへの文書移動 18 | - **LLM活用**: 各フェーズで適切な質問と文書テンプレートを提供 19 | 20 | ### 成し遂げたいこと 21 | 22 | 1. **"正しい課題"にフォーカス**: Lean UX & デザイン思考のDiscovery → 仮説検証をPMBOKの立ち上げに取り込み、作る前に迷子にならない 23 | 2. **学習しながら作る**: Dual-Track/Continuous DiscoveryをアジャイルDevelopmentと並走させ、ユーザーの声が常にバックログへ直結 24 | 3. **ドキュメントを無駄にしない**: "Flow → Stock → Archived"の3層によって、必要最小限の文書だけが公式資産として残る 25 | 4. **拡張し続けられる**: ルール自体を対話で増やせる（90_rule_maintenance.mdc）。プロセス改善がコード管理できる 26 | 27 | ## 2. システム全体像 28 | 29 | ``` 30 | ┌──────────────────────────────┐ trigger（チャットコマンド） 31 | │ 00_master_rules.mdc │◀───────────────────────┐ 32 | └─────────┬────────────────────┘ │ 33 | call │ 34 | ┌─────────▼────────────┐ 発散/収束も Draft 化 │ 35 | │ 01‑06_pmbok_*.mdc │──────────────────┐ │ 36 | │ 08_flow_assist.mdc │ create_draft │ │ 37 | └─────────┬────────────┘ │ │ 38 | ▼ Draft (.md) │ │ 39 | Flow/YYYYMM/YYYY‑MM‑DD/─────────────────────────────┘ │ 40 | │ human review + "確定反映して" │ 41 | ▼ │ 42 | Stock/programs/PROGRAM/projects/PROJECT/.. ← flow_to_stock_rules.mdc ────┘ 43 | ``` 44 | 45 | ### 主要コンセプト 46 | 47 | #### 三つ巴モデル 48 | 49 | | 方法論 | 役割 | 50 | |--------|------| 51 | | **PMBOK** | フェーズ & 知識エリアで **What** を管理 | 52 | | **Lean UX/Design Thinking** | ユーザー中心の **Why** を確認 | 53 | | **Agile / Scrum** | イテレーションで **How** を適応 | 54 | 55 | このシステムはPMBOKの骨格にLean UXのDiscoveryとアジャイルDeliveryをレイヤー合成しているため、上流で迷わず・開発中に学び・下流で残せるワークフローが1つにまとまります。 56 | 57 | #### Flow / Stock / Archived 58 | 59 | | 階層 | 役割 | 60 | |------|------| 61 | | **Flow** | 下書き・ラフアイデア・日次アウトプット | 62 | | **Stock** | 承認済みドキュメント・正式成果物 | 63 | | **Archived** | 完了プロジェクトの凍結コピー | 64 | 65 | #### 4ステップ・サイクル 66 | 67 | 1. **Ask** - LLMが質問で情報収集 68 | 2. **Draft** - テンプレへ自動整形（Flow） 69 | 3. **Review** - 人が編集 → 「確定反映して」 70 | 4. **Sync** - Shell / ルールでStockへ自動移動 71 | 72 | ## 3. 基本的なフォルダ構造 73 | 74 | ``` 75 | プロジェクトルート/ 76 | ├── .cursor/ 77 | │ └── rules/ # LLMルールファイル群 78 | │ ├── basic/ # 基本ルールフォルダ 79 | │ │ ├── pmbok_paths.mdc 80 | │ │ ├── 00_master_rules.mdc 81 | │ │ ├── 01_pmbok_initiating.mdc 82 | │ │ └── ... 83 | │ └── (additional_rules)/ # プロジェクト別特化ルール 84 | ├── Flow/ # 日付ごとのドラフト文書 85 | │ ├── YYYYMM/ # 年月フォルダ 86 | │ │ ├── YYYY-MM-DD/ # 作業日ごとのフォルダ 87 | │ │ │ ├── draft_project_charter.md 88 | │ │ │ └── ... 89 | │ │ └── ... 90 | │ └── templates/ # テンプレート 91 | ├── Stock/ # 確定済み文書 92 | │ ├── programs/ # プログラム（プロジェクトのまとまり）単位でのフォルダ 93 | │ │ └── PROGRAM_NAME/ # プログラムフォルダ 94 | │ │ └── projects/ 95 | │ │ └── PROJECT_ID/ # プロジェクトごとのフォルダ 96 | │ │ └── documents/ 97 | │ │ ├── 1_initiating/ 98 | │ │ ├── 2_discovery/ 99 | │ │ ├── 2_research/ 100 | │ │ ├── 3_planning/ 101 | │ │ ├── 4_executing/ 102 | │ │ ├── 5_monitoring/ 103 | │ │ └── 6_closing/ 104 | │ └── shared/ # 共有テンプレート 105 | │ └── templates/ 106 | └── Archived/ # 完了プロジェクト 107 | └── programs/ # アーカイブ済みプログラム 108 | ``` 109 | 110 | ## 4. システムのセットアップ 111 | 112 | ### クイックスタート 113 | 114 | Cursorの新規ウィンドウから簡単にセットアップできます： 115 | 116 | 1. Cursorを起動し、「New Window」を選択 117 | 2. 「Clone repo」を選び、このリポジトリのURLを入力 118 | 3. フォルダ指定のUIが表示されたら、右下の「Select as repository destination」ボタンをタップ 119 | 4. リポジトリがクローンされたら、README.mdファイルを開く 120 | 5. Chatパネルを開き「初期設定お願いします」と入力 121 | 122 | これだけで、READMEの内容を読み取り、必要な初期設定が自動的に実行されます。フォルダ構造の作成、ルールファイルの設定、必要なリポジトリのクローンなどが自動で行われます。 123 | 124 | ### 手動セットアップ 125 | 126 | 127 | ### 初期設定 128 | 129 | #### ユーザー設定（タスク管理用） 130 | 131 | タスク管理システムでは、バックログファイルからユーザーに割り当てられたタスクを抽出するために、ユーザー名の設定が必要です。以下の手順で設定してください： 132 | 133 | 1. 設定ファイルを開く： 134 | ```bash 135 | open /Users/daisukemiyata/aipm_v3/scripts_public/config/user_config.yaml 136 | ``` 137 | または任意のエディタで `scripts_public/config/user_config.yaml` を開く 138 | 139 | 2. ユーザー名を設定： 140 | ```yaml 141 | # ユーザー設定ファイル 142 | # 自分のユーザー名を設定します（複数指定可能） 143 | 144 | # assigneeフィルタリングに使用するユーザー名 145 | user_names: 146 | - 宮田 # バックログでの表記に合わせて設定 147 | - miyatti # 複数の表記がある場合は追加 148 | - Daisuke Miyata 149 | ``` 150 | 151 | 3. バックログファイル内で使用されている自分のユーザー名（assignee）をすべて登録してください 152 | 4. これにより 色々なタスク関連のタスクで、自分に割り当てられたタスクのみが抽出されるなど活用されます 153 | 154 | ### プレゼンテーションの背景画像 155 | 156 | 「プレゼン資料生成」コマンドを実行すると、タイトルスライド（lead）用の背景画像が自動的にassetsディレクトリにコピーされます。背景画像は次の方法で利用できます： 157 | 158 | 1. **自動適用**: テーマCSS内で設定された背景画像が lead クラスのスライドに自動的に適用されます 159 | 160 | 2. **Markdown内で指定**: 特定のスライドに異なる背景画像を適用したい場合 161 | ```markdown 162 | ![bg](assets/bg_explaza.png) 163 | ``` 164 | 165 | 3. **カスタム背景画像**: 独自の背景画像をアップロードし、`assets/` ディレクトリに配置すれば、同様の方法で使用できます 166 | 167 | 現在利用可能な背景画像: 168 | - `bg_explaza.png`: explazaテーマ用の青系背景 169 | - `bg_brown.png`: modern-brownテーマ用の茶系背景 170 | 171 | ### セットアップスクリプトの主な機能 172 | 173 | `setup_workspace_simple.sh` スクリプトを使用すると、以下の作業が自動的に行われます： 174 | 175 | 1. **基本ディレクトリ構造の作成** 176 | - Flow, Stock, Archived などの基本フォルダ 177 | - ルールファイル用の .cursor/rules フォルダ 178 | - プログラム用フォルダ Stock/programs 179 | 180 | 2. **Flow内の年月日フォルダ作成** 181 | - 現在の日付で Flow/YYYYMM/YYYY-MM-DD 形式のフォルダ作成 182 | 183 | 3. **各種リポジトリのクローン** 184 | - ルールリポジトリ（.cursor/rules/basic など） 185 | - スクリプトリポジトリ（scripts ディレクトリ） 186 | - プログラムリポジトリ（Stock/programs 配下） 187 | 188 | ### User Rules 189 | 190 | Cursorの設定からユーザールールを設定してください（推奨） 191 | 192 | 1. Cursorの右上にある歯車アイコン（⚙️）をクリック 193 | 2. 「Settings」から「Rules」を選択 194 | 3. 以下の内容をコピーして貼り付け 195 | 196 | ```markdown 197 | 198 | #======================================================== 199 | # 0. ベースポリシー 200 | #======================================================== 201 | ! Always respond in 日本語 202 | - 添付されてるRulesがないか確認。あったら必ず読み込むこと。読み込んだら✅などをつける。 203 | - 成果物はできるだけファイルとしてedit_fileして生成してください（細かく分割） 204 | - MCP やファイル閲覧など可能な作業は自律実行 205 | - タスク依頼時は不足情報を確認し、自ら計画→ゴールまで進行 206 | #======================================================== 207 | # 0. シェル処理の安全な実行 208 | #======================================================== 209 | ! 重要: コマンド実行時の禁止事項と推奨方法 210 | - サブシェル関数($(コマンド)形式)は絶対に使用禁止 211 | - バッククォート(`コマンド`)も使用禁止 212 | - パイプ(|)やリダイレクト(>)を使う複雑なコマンドは個別のシンプルなコマンドに分解する 213 | - 日付情報が必要な場合: 214 | 1. まず単独のdate関数を実行してターミナル出力を取得 215 | 2. 出力された日付文字列を次のコマンドで明示的に使用 216 | 3. 例: 「date +%Y-%m-%d」を実行→出力「2024-05-12」→この文字列を直接使用 217 | 218 | ! コマンド実行の具体例 219 | - NG: mkdir -p Flow/$(date +%Y%m)/$(date +%Y-%m-%d) 220 | - OK: [以下の2ステップに分ける] 221 | 1. date +%Y%m 222 | 2. date +%Y-%m-%d 223 | 3. mkdir -p Flow/{出力1}/{出力2} 224 | 225 | #======================================================== 226 | # 1. 必須ルールファイル参照（pre‑load） 227 | #======================================================== 228 | # ※ pmbok_paths_*.mdc を最優先で読み込み、以降すべて 229 | # {{dirs.*}} / {{patterns.*}} 変数でパスを参照する 230 | required_rule_files: 231 | - /Users//{{PROJECT_ROOT}}/.cursor/rules/basic/pmbok_paths.mdc 232 | - /Users//{{PROJECT_ROOT}}/.cursor/rules/basic/00_master_rules.mdc 233 | ``` 234 | 235 | 236 | ### 必要なルールファイル 237 | 238 | `.cursor/rules/`ディレクトリに以下のファイルを配置されます： 239 | 240 | - `basic/pmbok_paths.mdc` - パス変数定義 241 | - `basic/00_master_rules.mdc` - マスタールール 242 | - `basic/01_pmbok_initiating.mdc` - 立ち上げフェーズのテンプレート 243 | - `basic/02_pmbok_discovery.mdc` - 発見フェーズのテンプレート 244 | - `basic/02_pmbok_research.mdc` - 調査フェーズのテンプレート 245 | - `basic/03_pmbok_planning.mdc` - 計画フェーズのテンプレート 246 | - `basic/04_pmbok_executing.mdc` - 実行フェーズのテンプレート 247 | - `basic/05_pmbok_monitoring.mdc` - 監視・コントロールフェーズのテンプレート 248 | - `basic/06_pmbok_closing.mdc` - 終結フェーズのテンプレート 249 | - `basic/08_pmbok_flow_assist.mdc` - フロー支援機能 250 | - `basic/09_pmbok_development.mdc` - 開発フェーズ支援 251 | - `basic/90_rule_maintenance.mdc` - ルール自体のメンテナンス用 252 | - `basic/flow_to_stock_rules.mdc` - 自動同期ルール 253 | 254 | 255 | 256 | ## 5. フェーズ別の使い方 257 | 258 | ### 0️⃣ 事前準備 259 | 260 | ```bash 261 | 262 | 263 | # プロジェクト作成ガイド 264 | 「カレー作りたい　プロジェクト開始して」 # → プログラム名を尋ねられます 265 | 「夕食作り」 # プログラム名を入力 266 | 「はい」 # 確認に応答 267 | ``` 268 | 269 | 上記の対話により、以下の処理が行われます： 270 | - プログラムディレクトリ作成（Stock/programs/夕食作り） 271 | - プロジェクトディレクトリ作成（Stock/programs/夕食作り/projects/カレー） 272 | - ドキュメントフォルダ作成（documents/1_initiating など） 273 | - Flowフォルダ作成（Flow/YYYYMM/YYYY-MM-DD/夕食作り_カレー） 274 | 275 | ### 1️⃣ 立ち上げ（Initiating） 276 | 277 | ``` 278 | # プロジェクト憲章作成 279 | 「プロジェクト憲章を作成したい」 # LLMが質問に導きます 280 | # 質問に回答すると、Flow/YYYYMM/YYYY-MM-DD/draft_project_charter.md が生成されます 281 | 282 | # 内容確認後、確定反映 283 | 「確定反映して」 # draft_project_charter.mdがStockフォルダに移動 284 | 285 | # プロダクト（プログラム）定義 286 | 「プロダクト定義」 # プログラムレベルの定義書作成 287 | 「確定反映して」 # 確定処理 288 | 289 | # ステークホルダー分析 290 | 「ステークホルダー分析やりたい」 # 同様に質問と回答で文書作成 291 | 「確定反映して」 # 確定処理 292 | ``` 293 | 294 | ### 2️⃣ 発見（Discovery） 295 | 296 | ``` 297 | # Discoveryフェーズのメニュー表示 298 | 「Discovery」 # 利用可能なテンプレートリスト表示 299 | 300 | # 前提条件マップ作成 301 | 「仮説マップ」 # 仮説検証に必要な前提条件をマッピング 302 | 「確定反映して」 # Flow/YYYYMM/YYYY-MM-DD/draft_assumption_map.md を確定 303 | 304 | # ペルソナ作成 305 | 「ペルソナ作成」 # ユーザーペルソナ定義 306 | 「確定反映して」 307 | 308 | # 問題定義 309 | 「課題定義」 # 解決すべき問題の定義 310 | 「確定反映して」 311 | 312 | # その他のDiscoveryドキュメント 313 | 「ジャーニーマップ」 # ユーザージャーニーマップ作成 314 | 「ソリューション定義」 # ソリューション定義書作成 315 | 「検証計画」 # 仮説検証計画 316 | 「UXリサーチ」 # UXリサーチ調査概要 317 | ``` 318 | 319 | ### 2️⃣-B リサーチ（Research） 320 | 321 | ``` 322 | # Researchフェーズのメニュー表示 323 | 「Research」 # 利用可能な調査テンプレート表示 324 | 325 | # 顧客調査レポート 326 | 「顧客調査」 # 顧客調査レポート作成 327 | 「確定反映して」 328 | 329 | # 競合調査レポート 330 | 「競合調査」 # 競合分析 331 | 「確定反映して」 332 | 333 | # デスクリサーチ 334 | 「デスクリサーチ」 # 市場・業界など総合的な調査 335 | 「確定反映して」 336 | 337 | # 市場規模推定 338 | 「市場規模推定」 # TAM/SAM/SOM分析 339 | 「確定反映して」 340 | ``` 341 | 342 | ### 2️⃣-C プレゼンテーション（Presentation） 343 | 344 | ``` 345 | # プレゼン資料生成 346 | 「プレゼン資料生成」 # Marpを使用したプレゼンテーション作成 347 | 348 | # プレゼン用の図表作成 349 | 「図表生成」 # draw.ioテンプレートからの図表作成 350 | 「確定反映して」 # 編集したプレゼン資料を確定 351 | ``` 352 | 353 | ### 3️⃣ 計画（Planning） 354 | 355 | ``` 356 | # WBS作成 357 | 「WBS作成」 # 質問に回答してWBSドラフトを作成 358 | 「確定反映して」 # 確定処理 359 | 360 | # プロダクトバックログ初期化 361 | 「プロダクトバックログ初期化して」 # バックログの初期構造作成 362 | 363 | # リスク計画 364 | 「リスク計画」 # リスク分析と対策計画作成 365 | 366 | # プロジェクトスコープ記述書 367 | 「プロジェクトスコープ記述書」 # スコープ定義 368 | 369 | # プロダクト要求仕様書 370 | 「プロダクト要求仕様書」 # PRD作成 371 | 372 | # リリースロードマップ 373 | 「ロードマップ作成」 # リリース計画作成 374 | ``` 375 | 376 | ### 4️⃣ 実行（Executing）とDevelopment 377 | 378 | ``` 379 | # 開発フェーズの開始 380 | 「Development」 # 利用可能な開発テンプレート表示 381 | 382 | # 開発環境セットアップ 383 | 「開発環境初期化」 # 環境セットアップドキュメント作成 384 | 385 | # 開発計画 386 | 「開発計画作成」 # 実装計画書作成 387 | 388 | # 実装順序計画 389 | 「実装順序計画」 # 依存関係を考慮した実装順序の定義 390 | 391 | # ストーリー実装 392 | 「ストーリー実装」 # 個別ストーリー実装計画 393 | 394 | # スプリントゴール 395 | 「スプリントゴール」 # Sprint Goal Sheet作成 396 | 397 | # 日次タスク 398 | 「今日のタスク」 # 日次タスクリスト生成 399 | ``` 400 | 401 | ### 5️⃣ 監視・コントロール（Monitoring） 402 | 403 | ``` 404 | # 変更要求管理 405 | 「変更要求」 # 変更要求テンプレート作成 406 | 407 | # スプリントレビュー 408 | 「スプリントレビュー作成」 # レビュー自動生成 409 | ``` 410 | 411 | ### 6️⃣ 終結（Closing） 412 | 413 | ``` 414 | # 教訓記録 415 | 「教訓記録」 # Lessons Learned作成 416 | 「確定反映して」 417 | 418 | # 移管ドキュメント 419 | 「移管ドキュメント作成」 # 引き継ぎ資料作成 420 | ``` 421 | 422 | 423 | ## 5.5 全トリガーワード対応表 424 | 425 | 以下に、システムで使用できるすべてのトリガーワードをフェーズ別にまとめています。各コマンドがどのルールファイル内で定義されているか、必要とする情報も示しています。 426 | 427 | ### フェーズ1：立ち上げ（Initiating） 428 | 429 | | トリガーワード | 対応するルールファイル | 必要情報 | 出力ファイル | 430 | |--------------|-------------------|--------|---------| 431 | | プロジェクト初期化
プロジェクト開始
プロジェクト立ち上げ | basic/01_pmbok_initiating.mdc | プログラムID、プロジェクトID、目的、開始日、終了日、ステークホルダー | (ディレクトリ構造) | 432 | | "XXX始めたい"
"XXX作りたい"
(プロジェクト名+開始したい) | basic/01_pmbok_initiating.mdc | プログラム名（プロダクトのカテゴリー） | (ディレクトリ構造) | 433 | | プロダクト定義
プロダクト目標定義
Product定義
プログラム定義 | pmbok/01_pmbok_initiating.mdc | プロダクト名、目標・ビジョン、関連するOKR、背景と目的 | draft_program_definition.md | 434 | | プロジェクト憲章
プロジェクトチャーター | basic/01_pmbok_initiating.mdc | プロジェクト名、目的、背景、成果物、予算、マイルストーン | draft_project_charter.md | 435 | | ステークホルダー分析
ステークホルダーマップ | basic/pmbok_initiating.mdc | 主要ステークホルダー、役割、期待、影響力、関与度 | draft_stakeholder_analysis.md | 436 | | リスク分析
リスク計画 | basic/pmbok_planning.mdc | リスク項目、影響度、発生確率、対応策、責任者 | draft_risk_plan.md | 437 | | 作業開始
work start
今日の作業開始 | basic/00_master_rules.mdc | なし | daily_tasks.md | 438 | 439 | ### フェーズ2：リサーチ（Research） 440 | 441 | | トリガーワード | 対応するルールファイル | 必要情報 | 出力ファイル | 442 | |--------------|-------------------|--------|---------| 443 | | リサーチ
Research | basic/00_master_rules.mdc
(メニュー表示) | なし | なし | 444 | | 顧客調査
Customer Research | basic/02_pmbok_research.mdc | プロジェクト名、ターゲットオーディエンス、調査トピック、業界背景 | draft_customer_research.md | 445 | | 競合調査
Competitor Research | basic/02_pmbok_research.mdc | プロジェクト名、自社製品/サービス概要、主な競合、調査フォーカス | draft_competitor_research.md | 446 | | デスクリサーチ
Desk Research | basic/02_pmbok_research.mdc | プロジェクト名、調査範囲、調査トピック、業界背景 | draft_desk_research.md | 447 | | 市場規模推定
TAM SAM SOM
フェルミ推定 | basic/02_pmbok_research.mdc | プロジェクト名、ビジネスモデル、ターゲット顧客、地域、推定アプローチ | draft_market_size_estimation.md | 448 | 449 | ### フェーズ2：発見（Discovery） 450 | 451 | | トリガーワード | 対応するルールファイル | 必要情報 | 出力ファイル | 452 | |--------------|-------------------|--------|---------| 453 | | ディスカバリー
Discovery | basic/00_master_rules.mdc
(メニュー表示) | なし | なし | 454 | | 仮説マップ
Assumption Map | basic/02_pmbok_discovery.mdc | 主な仮説、検証方法、前提条件 | draft_assumption_map.md | 455 | | ペルソナ作成
Persona | basic/02_pmbok_discovery.mdc | ユーザー像、年齢・職業、目標、課題、行動パターン | draft_persona.md | 456 | | 課題定義
Problem Statement | basic/02_pmbok_discovery.mdc | 問題概要、影響、原因、解決の価値 | draft_problem_statement.md | 457 | | ユーザージャーニーマップ
User Journey Map
ジャーニーマップ | basic/02_pmbok_discovery.mdc | ユーザー、フェーズ、行動、感情、課題、機会 | draft_user_journey_map.md | 458 | | ソリューション定義
Solution Definition | basic/02_pmbok_discovery.mdc | 提案するソリューション、機能要件、成功基準 | draft_solution_definition.md | 459 | | 検証計画
Validation Plan | basic/02_pmbok_discovery.mdc | 検証仮説、方法、成功基準、スケジュール | draft_validation_plan.md | 460 | | UXリサーチ
ユーザー調査
UX調査 | basic/02_pmbok_discovery.mdc | 調査目的、質問、方法、参加者要件 | draft_ux_research_overview.md | 461 | | インタビュー設計
インタビュー質問
質問表作成 | basic/02_pmbok_discovery.mdc | 調査目的、質問リスト、進行手順 | draft_interview_guide.md | 462 | | リクルーティング
ユーザー募集
被験者募集 | basic/02_pmbok_discovery.mdc | 対象者プロフィール、募集方法、参加条件 | draft_recruiting_plan.md | 463 | | インタビュー分析
インタビュー結果
インタビュー記録 | basic/02_pmbok_discovery.mdc | 参加者ID、主な発見、引用、洞察 | draft_interview_analysis_{{participant_id}}.md | 464 | | リサーチサマリー
調査サマリー
全体分析 | basic/02_pmbok_discovery.mdc | 調査目的、方法、主要な発見、次のステップ | draft_research_summary.md | 465 | | 仮説バックログ
Hypothesis | basic/02_pmbok_discovery.mdc | 仮説一覧、優先度、検証方法、成功基準 | draft_hypothesis_backlog.md | 466 | | アイディア発散 | basic/08_pmbok_flow_assist.mdc | テーマ、アイデア、評価基準 | draft_flow_assist.md | 467 | | プレゼン資料生成 | basic/02_pmbok_presentation.mdc | タイトル、発表者、対象者、主要ポイント | draft_presentation.md | 468 | 469 | ### フェーズ3：計画（Planning） 470 | 471 | | トリガーワード | 対応するルールファイル | 必要情報 | 出力ファイル | 472 | |--------------|-------------------|--------|---------| 473 | | プロジェクトスコープ記述書
Project Scope Statement | basic/03_pmbok_planning.mdc | プロジェクト範囲、成果物、除外事項、制約、前提条件 | draft_project_scope_statement.md | 474 | | プロダクト要求仕様書
PRD
Product Requirements Document | basic/03_pmbok_planning.mdc | 製品概要、ユーザー、要件、優先度、制約 | draft_product_requirements.md | 475 | | Design Doc
デザインドック
設計文書 | basic/03_pmbok_planning.mdc | システム概要、アーキテクチャ、コンポーネント、インターフェース | draft_design_doc.md | 476 | | WBS作成
作業分解構造 | basic/pmbok_planning.mdc | 主要フェーズ、サブタスク、所要時間、担当者 | draft_wbs.md | 477 | | プロダクトバックログ初期化
backlog初期化
バックログ初期化 | basic/pmbok_planning.mdc | プロダクト名、ストーリー一覧、優先度、見積もり | backlog.yaml, epics.yaml | 478 | | ルーチンタスク定義
routines作成
ルーティン定義 | basic/07_task_management.mdc | 日次/週次/月次タスク、スケジュール、所要時間 | routines.yaml | 479 | | バックログが正しく出力されたか確認
バックログ検証
バックログ確認
バックログチェック | basic/00_master_rules.mdc | 検証したいバックログYAMLのパス | 検証結果（ターミナル出力） | 480 | | ルーチンタスクが正しく出力されたか確認
ルーチンタスク検証
ルーチン検証
ルーチンチェック | basic/00_master_rules.mdc | 検証したいroutines.yamlのパス | 検証結果（ターミナル出力） 481 | | ロードマップ作成
プロダクトロードマップ
リリース計画 | basic/pmbok_planning.mdc | リリース計画、マイルストーン、機能、日程 | draft_product_roadmap.md | 482 | 483 | ### フェーズ4：実行（Executing） 484 | 485 | | トリガーワード | 対応するルールファイル | 必要情報 | 出力ファイル | 486 | |--------------|-------------------|--------|---------| 487 | | 今日のタスク
日次タスク作成
Daily tasks | basic/07_task_management.mdc | 当日の作業予定、完了タスク、メモ | daily_tasks.md | 488 | | 週次レビュー
Weekly review | basic/07_task_management.mdc | 週番号、主な成果、課題、次週の計画 | weekly_review.md | 489 | | Sync
WBSと同期
リスクログと同期 | basic/07_task_management.mdc | 対象アーティファクト、更新内容 | (既存のWBSやリスクログを更新) | 490 | | 開発フェーズ
Development
実装フェーズ | basic/00_master_rules.mdc
(メニュー表示) | なし | なし | 491 | | 開発環境初期化
Development初期化
実装環境セットアップ | basic/09_pmbok_development.mdc | プロジェクト名、技術スタック、開発環境要件 | draft_dev_setup.md | 492 | | 開発計画作成
Development計画
実装計画 | basic/09_pmbok_development.mdc | 機能一覧、技術スタック、スケジュール、担当者 | draft_dev_plan.md | 493 | | 実装順序計画
開発順序
ストーリー依存関係 | basic/09_pmbok_development.mdc | ストーリーリスト、依存関係、優先度 | draft_implementation_order.md | 494 | | ストーリー実装
実装開始
ユーザーストーリー実装 | basic/09_pmbok_development.mdc | ストーリーID、実装詳細、タスク分割 | draft_dev_story.md | 495 | | 記事執筆
ドキュメント作成
記事作成 | basic/09_pmbok_development.mdc | タイトル、概要、対象読者、構成 | draft_dev_article.md | 496 | | 成果物確認
実装確認
確定レビュー | basic/09_pmbok_development.mdc | レビュー対象、確認項目、フィードバック | draft_development_review.md | 497 | | スプリントゴール
Sprint Goal | basic/pmbok_executing.mdc | スプリント番号、期間、目標、成功基準、デモ項目 | draft_sprint_goal_{{sprint_number}}.md | 498 | | 議事録
ミーティングノート | basic/pmbok_executing.mdc | 会議名、日時、参加者、議題、決定事項、アクション | draft_meeting_minutes.md | 499 | 500 | 501 | ### フェーズ5：監視・コントロール（Monitoring） 502 | 503 | | トリガーワード | 対応するルールファイル | 必要情報 | 出力ファイル | 504 | |--------------|-------------------|--------|---------| 505 | | 変更要求
チェンジリクエスト | basic/pmbok_monitoring.mdc | 変更内容、理由、影響範囲、優先度 | draft_change_request.md | 506 | | スプリントレビュー作成
Sprint Review | basic/pmbok_executing.mdc | スプリント番号、達成事項、デモ項目、課題、次のステップ | draft_sprint_review_{{sprint_id}}.md | 507 | 508 | 509 | ### フェーズ6：終結（Closing） 510 | 511 | | トリガーワード | 対応するルールファイル | 必要情報 | 出力ファイル | 512 | |--------------|-------------------|--------|---------| 513 | | 教訓記録
レッスンラーニド
レッスンずらーんど | basic/pmbok_closing.mdc | 成功事例、改善点、学び、提案 | draft_lessons_learned.md | 514 | 515 | ### ユーティリティ 516 | 517 | | トリガーワード | 対応するルールファイル | 必要情報 | 出力ファイル | 518 | |--------------|-------------------|--------|---------| 519 | | 確定反映して | flow_to_stock_rules.mdc | 対象ドラフトファイル | (Stock内の対応ファイル) | 520 | | フェーズ追加
Phase追加
新フェーズ作成 | basic/90_rule_maintenance.mdc | フェーズ名、トリガーワード、ルールの詳細 | 新規ルールファイル | 521 | 522 | ### 各ドキュメント間の参照関係 523 | 524 | 開発やドキュメント作成時に参考にできる主な参照関係は以下の通りです： 525 | 526 | * **ペルソナ作成**：市場調査レポート、ユーザーインタビュー結果、競合調査結果を参照すると効果的 527 | * **プロジェクト憲章**：プロダクト定義、ステークホルダー分析、リスク分析を基にすると整合性が高まる 528 | * **バックログ初期化**：プロダクト要求仕様書、WBS、ユーザージャーニーマップの内容を反映させると良い 529 | * **スプリントゴール**：プロダクトバックログ、ロードマップを参照して設定すると計画との整合性が確保できる 530 | * **週次レポート**：日次タスク、スプリントゴール、課題記録の情報を集約して作成すると効率的 531 | * **実装計画**：バックログ、デザインドック、技術仕様書を基に作成すると実装の指針が明確になる 532 | 533 | 534 | ## 6. ユースケース：カレープロジェクト 535 | 536 | 以下は、実際のプロジェクト例として「カレー作り」プロジェクトの流れを示します。 537 | 538 | ### 1. プロジェクト初期化 539 | ``` 540 | User: カレー作りたい　プロジェクト開始して 541 | AI: 「カレー」のプログラム名（カテゴリ）を教えてください。 542 | User: 夕食作り 543 | AI: 以下の内容でプロジェクトを初期化します： 544 | プログラム: 夕食作り 545 | プロジェクト: カレー 546 | よろしいですか？ 547 | User: はい 548 | ``` 549 | 550 | この対話により、以下のフォルダ構造が作成されます： 551 | ``` 552 | Stock/programs/夕食作り/projects/カレー/ 553 | └── documents/ 554 | ├── 1_initiating/ 555 | ├── 2_discovery/ 556 | ├── 2_research/ 557 | ├── 3_planning/ 558 | ├── 4_executing/ 559 | ├── 5_monitoring/ 560 | └── 6_closing/ 561 | 562 | Flow/202505/2025-05-05/夕食作り_カレー/ 563 | └── daily_tasks.md 564 | ``` 565 | 566 | ### 2. プロジェクト憲章の作成 567 | ``` 568 | User: プロジェクト憲章つくって 569 | AI: 【プロジェクト憲章】の作成に必要な情報を収集します。以下の質問に回答してください。 570 | 1. プロジェクト名: カレー 571 | 2. プロジェクトの目的: 572 | 3. プロジェクトの背景: 573 | [...] 574 | User: おまかせ 575 | AI: 収集した情報で「プロジェクト憲章」のドラフトを作成してよろしいですか？ 576 | User: はい 577 | ``` 578 | 579 | AIは以下の内容を含む詳細なプロジェクト憲章を作成します： 580 | - プロジェクト概要（名前、期間、オーナー） 581 | - 目的と背景 582 | - スコープ（含まれるもの/含まれないもの） 583 | - 成果物 584 | - ステークホルダー一覧 585 | - マイルストーン 586 | - 予算（食材費3,000円、消耗品500円） 587 | - リスク管理計画 588 | - 制約条件と前提条件 589 | 590 | ### 3. ペルソナの作成 591 | ``` 592 | User: ペルソナ作成して 593 | AI: 【ペルソナ作成】に必要な情報を収集します。以下の質問に回答してください。 594 | 1. ペルソナの名前: 595 | 2. 年齢・世代: 596 | [...] 597 | User: おまかせ 598 | ``` 599 | 600 | AIは以下の詳細情報を含むペルソナを作成します： 601 | - 基本情報：田中健太（42歳、IT企業PM、4人家族） 602 | - ライフスタイル：平日は仕事、週末は料理担当 603 | - 目標と課題：家族の好みにばらつきがある、調理時間の見積もりが苦手 604 | - 行動特性：レシピサイトやSNSで情報収集、家族の意見を聞いて決定 605 | - 好みと傾向：程よい辛さのカレーが好き 606 | - 使用ツール：スマートフォン、料理アプリ 607 | - 代表的な発言：「家族が笑顔になる料理を作りたいな」 608 | 609 | この例はプロジェクト管理手法を日常的なタスクに適用する方法を示しており、以下のフェーズに進むことで、カレープロジェクトは成功へと導かれます： 610 | - Discovery：材料や調理方法の調査 611 | - Planning：レシピ決定、買い物リスト作成 612 | - Executing：材料購入、調理 613 | - Monitoring：味の調整 614 | - Closing：完成・振り返り 615 | 616 | ## 7. 主要コマンドリファレンス 617 | 618 | ### 文書作成コマンド（トリガーワード） 619 | 620 | #### 立ち上げフェーズ 621 | | コマンド | 説明 | 出力先 | 622 | |--------|------|-------| 623 | | 「プロジェクト初期化」 | プログラム・プロジェクト構造作成 | Stock/programs//projects// | 624 | | 「プロダクト定義」 | プロダクト（プログラム）定義書作成 | Flow/YYYYMM/YYYY-MM-DD/draft_program_definition.md | 625 | | 「プロジェクト憲章」 | プロジェクト憲章作成 | Flow/YYYYMM/YYYY-MM-DD/draft_project_charter.md | 626 | | 「ステークホルダー分析」 | ステークホルダー分析 | Flow/YYYYMM/YYYY-MM-DD/draft_stakeholder_analysis.md | 627 | 628 | #### Discoveryフェーズ 629 | | コマンド | 説明 | 出力先 | 630 | |--------|------|-------| 631 | | 「仮説マップ」 | 前提条件マップ作成 | Flow/YYYYMM/YYYY-MM-DD/draft_assumption_map.md | 632 | | 「ペルソナ作成」 | ユーザーペルソナ作成 | Flow/YYYYMM/YYYY-MM-DD/draft_persona.md | 633 | | 「課題定義」 | 問題定義書作成 | Flow/YYYYMM/YYYY-MM-DD/draft_problem_statement.md | 634 | | 「仮説バックログ」 | 仮説リスト作成 | Flow/YYYYMM/YYYY-MM-DD/draft_hypothesis_backlog.md | 635 | | 「ジャーニーマップ」 | ユーザージャーニーマップ | Flow/YYYYMM/YYYY-MM-DD/draft_user_journey_map.md | 636 | 637 | #### Researchフェーズ 638 | | コマンド | 説明 | 出力先 | 639 | |--------|------|-------| 640 | | 「顧客調査」 | 顧客調査レポート | Flow/YYYYMM/YYYY-MM-DD/draft_customer_research.md | 641 | | 「競合調査」 | 競合分析レポート | Flow/YYYYMM/YYYY-MM-DD/draft_competitor_research.md | 642 | | 「デスクリサーチ」 | 総合調査レポート | Flow/YYYYMM/YYYY-MM-DD/draft_desk_research.md | 643 | | 「市場規模推定」 | TAM/SAM/SOM分析 | Flow/YYYYMM/YYYY-MM-DD/draft_market_size_estimation.md | 644 | 645 | #### プレゼンテーションフェーズ 646 | | コマンド | 説明 | 出力先 | 647 | |--------|------|-------| 648 | | 「プレゼン資料生成」 | Marpによるスライド作成 | Flow/YYYYMM/YYYY-MM-DD/draft_presentation.md | 649 | | 「図表生成」 | Draw.io図表テンプレート作成 | Flow/YYYYMM/YYYY-MM-DD/assets/diagram.drawio | 650 | 651 | #### Planningフェーズ 652 | | コマンド | 説明 | 出力先 | 653 | |--------|------|-------| 654 | | 「WBS作成」 | WBSドラフト作成 | Flow/YYYYMM/YYYY-MM-DD/draft_wbs.md | 655 | | 「リスク計画」 | リスク分析と計画 | Flow/YYYYMM/YYYY-MM-DD/draft_risk_plan.md | 656 | | 「プロジェクトスコープ記述書」 | スコープ定義書 | Flow/YYYYMM/YYYY-MM-DD/draft_project_scope_statement.md | 657 | | 「プロダクト要求仕様書」 | PRD作成 | Flow/YYYYMM/YYYY-MM-DD/draft_product_requirements.md | 658 | | 「ロードマップ作成」 | リリース計画 | Flow/YYYYMM/YYYY-MM-DD/draft_product_roadmap.md | 659 | 660 | #### Developmentフェーズ 661 | | コマンド | 説明 | 出力先 | 662 | |--------|------|-------| 663 | | 「開発環境初期化」 | 環境セットアップ | Flow/YYYYMM/YYYY-MM-DD/development/draft_setup.md | 664 | | 「開発計画作成」 | 実装計画書 | Flow/YYYYMM/YYYY-MM-DD/development/draft_development_plan.md | 665 | | 「実装順序計画」 | 実装順序定義 | Flow/YYYYMM/YYYY-MM-DD/development/draft_implementation_order.md | 666 | | 「ストーリー実装」 | ストーリー実装計画 | Flow/YYYYMM/YYYY-MM-DD/development/draft_story_implementation.md | 667 | 668 | #### Executingフェーズ 669 | | コマンド | 説明 | 出力先 | 670 | |--------|------|-------| 671 | | 「スプリントゴール」 | スプリント目標設定 | Flow/YYYYMM/YYYY-MM-DD/draft_sprint_goal_Sn.md | 672 | | 「今日のタスク」 | 日次タスク | Flow/YYYYMM/YYYY-MM-DD/daily_tasks.md | 673 | | 「議事録」 | 会議議事録 | Flow/YYYYMM/YYYY-MM-DD/draft_meeting_minutes.md | 674 | 675 | #### Closingフェーズ 676 | | コマンド | 説明 | 出力先 | 677 | |--------|------|-------| 678 | | 「教訓記録」 | 教訓記録 | Flow/YYYYMM/YYYY-MM-DD/draft_lessons_learned.md | 679 | | 「移管ドキュメント作成」 | 引き継ぎ資料 | Flow/YYYYMM/YYYY-MM-DD/draft_transition_document.md | 680 | 681 | ### システムコマンド 682 | 683 | | コマンド | 説明 | 684 | |--------|------| 685 | | 「確定反映して」 | Flow→Stock同期を実行 | 686 | | 「作業開始」 | 今日の日付フォルダとタスクファイルを作成 | 687 | | 「フェーズ追加」 | 新しいフェーズルールの雛形を生成 | 688 | 689 | ## 8. バックログ管理 690 | 691 | 本システムでは、プロダクトバックログをYAML形式で管理する方法を採用しています。この方法には大きなメリットがありますが、YAMLの可読性については工夫が必要です。 692 | 693 | ### YAMLでバックログを管理する利点 694 | 695 | - **AIエージェントとの親和性**: YAML形式はCursorエージェントが正確に解析・操作できるため、口語的な指示でもバックログを効率的に更新できます 696 | - **構造化された情報管理**: 階層構造を持つバックログを自然に表現でき、ストーリー間の関係性を明確に記述できます 697 | - **変更操作の簡便さ**: 「ストーリーAのステータスを完了に変更して」「担当者をBさんに変更して」といった指示をAIに伝えるだけで正確に更新されます 698 | - **他システムとの連携**: YAMLはプログラムで扱いやすく、JIRAやGitHubなど他のツールとの連携も容易です 699 | 700 | ### バックログの初期化と管理 701 | 702 | プロダクトバックログは「プロダクトバックログ初期化」「backlog初期化」「バックログ初期化」などのトリガーワードを使用することで自動生成できます。初期化プロセスではプロジェクト名、ストーリー一覧、優先度、見積もりなどの情報を入力することで、構造化された`backlog.yaml`と`epics.yaml`ファイルが生成されます。 703 | 704 | 生成されたバックログは日次タスク作成やスプリント計画などの下流プロセスで活用されるため、正しく機能することが重要です。特にYAML形式のファイルはインデントや構文に敏感なため、「バックログ検証」「バックログ確認」などのトリガーワードを使用して定期的に検証することをお勧めします。これにより、バックログの構造的な問題を早期に発見し、タスク管理プロセス全体がスムーズに動作することを確保できます。 705 | 706 | 707 | 708 | ### バックログ操作テクニック 709 | 710 | YAMLファイルをAIエージェントで効率的に操作するテクニック： 711 | 712 | ``` 713 | User: バックログのストーリーUS-123のステータスを「完了」に変更して、担当者を田中さんにしてほしい 714 | 715 | AI: backlog.yamlを更新します: 716 | - ストーリーUS-123のステータスを「完了」に変更 717 | - 担当者を「田中」に変更 718 | 変更を行いますか？ 719 | 720 | User: はい 721 | 722 | AI: backlog.yamlを更新しました。以下が変更内容です: 723 | - US-123のstatus: "in-progress" → "done" 724 | - US-123のassignee: "佐藤" → "田中" 725 | ``` 726 | 727 | このようにUI操作よりも自然言語での指示の方が、場合によってはスピーディーで正確なバックログ管理が可能になります。 728 | 729 | ### ルーチンタスク定義機能 730 | 731 | Backlogとは別に、ルーチンタスクというものも別に定義できます。違いは、バックログは一度きりのタスクですが、ルーチンは繰り返し実行するタスクです。プロジェクトのルーチンタスクを定義するには、以下のトリガーワードを使用できます： 732 | 733 | ``` 734 | User: ルーチンタスク定義して 735 | ``` 736 | 737 | または、以下のトリガーワードも同様の機能を呼び出します： 738 | - 「routines作成」 739 | - 「ルーティン定義」 740 | 741 | このコマンドを実行すると、AIがルーチンタスクに関する情報を収集するための質問を行います。質問に回答すると、プロジェクトのルートディレクトリに`routines.yml`ファイルが自動生成されます。 742 | 743 | ルーチンタスク定義の主な機能： 744 | - 日次、週次、月次のルーチンタスクを簡単に定義 745 | - 曜日や日付指定でのタスクスケジュール設定 746 | - 所要時間や依存関係の設定 747 | - プロジェクト固有のルーチンワークフローの定義 748 | 749 | 作成したルーチンタスク定義は、「確定反映して」コマンドでStockフォルダに移動でき、「日次タスクまとめて」コマンドで自動的に参照されるようになります。 750 | 751 | ### ルーチンタスク定義ファイルの例 752 | 753 | 各プロジェクトのルートディレクトリに`routines.yml`を作成することで、プロジェクト固有のルーチンタスクを定義できます： 754 | 755 | # 朝の作業ルーティンタスクの例 756 | ```yaml 757 | morning_routines: 758 | name: "朝の作業ルーティン" 759 | description: "出社時に行うべき作業の標準セット" 760 | total_estimate: 34 # 分単位の合計見積もり 761 | items: 762 | - id: "RT-001" 763 | reference: "US-001" 764 | title: "Slackのフォローアップ確認" 765 | estimate: 5 766 | priority: 1 767 | 768 | - id: "RT-002" 769 | reference: "US-002" 770 | title: "PCデスクトップの整理" 771 | estimate: 1 772 | priority: 2 773 | 774 | - id: "RT-003" 775 | reference: "US-003" 776 | title: "出勤登録" 777 | estimate: 3 778 | priority: 1 779 | ``` 780 | 781 | ルーチンタスクもバックログタスク同様、作成後に「ルーチンタスクの検証をして」ということで、正しいフォーマットで出力されたか確認できます。 782 | 783 | ### YAML可読性向上のためのツール 784 | 785 | バックログやルーチンタスクのYAMLをより見やすく表示するために、以下のツールを推奨します： 786 | 787 | 1. **VSCode拡張機能「Yaml2Table Preview」** 788 | - [Marketplace リンク](https://marketplace.visualstudio.com/items?itemName=adautomendes.yaml2table-preview) 789 | - インストール方法: VSCodeのQuick Open (Ctrl+P)で`ext install adautomendes.yaml2table-preview`を実行 790 | - 使用方法: YAMLファイルを開いた状態で`Ctrl+Shift+P`から「Yaml2Table: Open preview」を選択 791 | 792 | ![yaml2table preview example](https://github.com/adautomendes/vscode-yaml-preview/raw/HEAD/resources/preview.png) 793 | 794 | 2. **VSCodeの標準YAML拡張機能** 795 | - YAMLの構文ハイライト、入れ子構造の折りたたみ、スキーマ検証などの基本機能を提供 796 | - これだけでもかなり見やすくなります 797 | 798 | ## 8. 日次タスク管理 799 | 800 | 日次タスク機能は、複数プロジェクトにまたがる作業を一元管理し、日々の業務を効率化するための機能です。複数のソースから情報を自動的に集約し、その日に集中すべきタスクの全体像を把握できます。 801 | 802 | ### 日次タスクの主な機能 803 | 804 | ``` 805 | User: 日次タスクまとめて 806 | ``` 807 | 808 | このコマンドを実行すると、以下の情報が自動的に集約されます： 809 | 810 | 1. **Googleカレンダーからの予定取得（※追加設定が必要）** 811 | - その日のミーティングやイベントを時系列で一覧表示 812 | - 会議の準備や事前作業が必要なものを強調表示 813 | 814 | 2. **プロジェクトバックログからのタスク抽出** 815 | - 各プロジェクトの`backlog.yml`から、現在のスプリントに割り当てられたタスクを抽出 816 | - 担当者フィルタリングや優先度ソートにも対応 817 | 818 | 3. **ルーチンタスクの確認** 819 | - 各プロジェクトの`routines.yml`に定義された定期的な作業を抽出 820 | - 曜日やプロジェクトフェーズに応じた適切なルーチンを表示 821 | 822 | ### 日次タスクの活用方法 823 | 824 | 日次タスク機能は単なるタスク表示だけでなく、以下のようなワークフローを支援します： 825 | 826 | 1. **朝の作業開始時** 827 | - 「日次タスクまとめて」でその日の全体像を把握 828 | - 優先度の高いタスクを特定して計画を立てる 829 | 830 | 2. **日中の進捗管理** 831 | - タスクの完了状況をチェックリスト形式で記録 832 | - タスク実行中に発生した課題やメモを記録 833 | 834 | 3. **終業時の振り返りと更新** 835 | - 進捗状況を「バックログ更新して」コマンドで各プロジェクトの`backlog.yml`に反映 836 | - 翌日に持ち越すタスクを確認 837 | - 学びや気づきを記録 838 | 839 | ### Googleカレンダー連携機能（オプション） 840 | 841 | Googleカレンダーから予定を直接取得するには、以下のリポジトリで公開されているアプリケーションのセットアップが必要です： 842 | 843 | - [calendar_app](https://github.com/miyatti777/calendar_app) - Google Apps Script & Claspを使用したカレンダー連携ツール 844 | 845 | このアプリケーションを導入すると、エージェントが直接Googleカレンダーから予定を取得できるようになり、MCPの不安定さを回避した安定した運用が可能になります。セットアップ方法は上記リポジトリのREADMEを参照してください。 846 | 847 | セットアップ後は「予定確認」と入力するだけで、Googleカレンダーからの予定取得が可能になります。 848 | 849 | 850 | 851 | 852 | ### タスク管理のベストプラクティス 853 | 854 | 1. **一貫したステータス管理**: バックログとの整合性を保つため、タスクのステータス更新は日次タスク→バックログの流れを保つ 855 | 2. **複数プロジェクトの並行管理**: 関連タスクをプロジェクト横断で確認することで、リソース配分を最適化 856 | 3. **記録の習慣化**: 実施したこと、気づき、課題は日次タスクに都度記録し、知見を蓄積 857 | 4. **日々のバックログ更新**: 一日の終わりに「バックログ更新して」コマンドで正式な進捗状況を反映 858 | 859 | ## 9. ルール追加と拡張プロセス 860 | 861 | システム自体を成長させるため、新しいルールの追加や既存ルールの拡張機能が組み込まれています。ルール追加自体もルール化することで、システムの継続的進化を促進します。 862 | 863 | ### ルール拡張の基本的な流れ 864 | 865 | 1. **「フェーズ追加」トリガー**: チャットで「フェーズ追加」や「新フェーズ作成」と入力すると、ルール拡張モードが起動します 866 | 2. **情報収集**: システムが新規フェーズやルールに関する情報を質問します 867 | 3. **自動ルール生成**: 情報を基に必要なルールファイル更新を行います 868 | 869 | ### 自動更新される要素 870 | 871 | ルール追加機能は主に以下の3つの要素を自動的に更新します： 872 | 873 | 1. **マスタールールへのトリガー追加**: `00_master_rules_kc.mdc` にトリガーキーワードと処理フローを追加 874 | 2. **専用ルールファイルの作成/更新**: 新しいフェーズ専用のルール（例: `0X_pmbok_xxxxx.mdc`）を作成するか、既存のカテゴリに質問やテンプレートを追加 875 | 3. **パス変数の追加**: `pmbok_paths.mdc` に必要なパス変数を追加（これにより実際のパスを変数で参照可能になる） 876 | 877 | ### 使用例 878 | 879 | ``` 880 | User: フェーズ追加 881 | AI: 新しいフェーズやルールを追加します。以下の情報を教えてください： 882 | 1. 追加したいフェーズ/ルール名: 883 | 2. 主な機能や目的: 884 | 3. 必要なトリガーワード: 885 | ... 886 | 887 | User: マーケティングフェーズを追加したい。 888 | トリガーワードは「マーケティング計画」「広告戦略」など。 889 | 成果物としてはマーケティング計画書、広告戦略、分析レポートなど。 890 | 891 | AI: 以下の内容でルールを追加します： 892 | 1. マスタールールにトリガーワード追加 893 | 2. 12_pmbok_marketing.mdc ファイル作成 894 | 3. パス変数追加 895 | 896 | よろしいですか？ 897 | 898 | User: はい 899 | 900 | AI: ルール追加が完了しました。 901 | 以下のファイルが作成/更新されました： 902 | - .cursor/rules/pmbok/00_master_rules_kc.mdc 903 | - .cursor/rules/pmbok/12_pmbok_marketing.mdc 904 | - .cursor/rules/pmbok/pmbok_paths_kc.mdc 905 | 906 | 「マーケティング計画」と入力して新機能をテストできます。 907 | ``` 908 | 909 | ### カスタムルールのメリット 910 | 911 | - **再利用性**: 一度定義したルールはプロジェクト間で再利用可能 912 | - **一貫性**: テンプレートやワークフローの標準化により、チーム全体での一貫性を確保 913 | - **効率化**: 繰り返し作業が自動化され、本質的な思考に集中できる 914 | - **知識の形式化**: チームの知見やベストプラクティスをルールとして形式化し共有 915 | 916 | ルール追加自体もルール化することで、プロジェクト完了時や作業が一段落した時点で「次回からはこうしたい」という改善をすぐにシステムに反映できます。たとえ面倒に感じる場合でも、このプロセスが習慣化されることで、システムは継続的に進化していきます。 917 | 918 | 919 | ## 10. よくある質問 (FAQ)とベストプラクティス 920 | 921 | 922 | ### システムとツールの利用 923 | 924 | **Q1. トリガーワードが反応しない場合はどうすればいいですか？** 925 | 926 | A1. Rulesの限界により、トリガーワードが期待通り動作しない場合があります。その場合でも、LLMはRuleを読まなくてもPMBOKの知識をベースに基本的な対応はしてくれますが、カスタムテンプレートは無視される可能性があります。対処法： 927 | 928 | 1. **明示的なルール指定**: トリガーワードが属するルールを明示的にメンションする（例: @01_pmbok_initiating.mdc） 929 | 2. **情報源の指定**: 特定のプロジェクト文書を参照させたい場合は、明示的にドキュメントを指定する 930 | 3. **基本に戻る**: うまく動かない場合は、通常のプロンプトとして質問を具体的に記述する 931 | 932 | **Q2. Cursorの特徴と限界について教えてください** 933 | 934 | A2. Cursorの主な特徴と実用上のポイント： 935 | 936 | 1. **ルールファイル参照**: MDファイルに書いたプロンプトをメンションするだけで呼び出せるため、毎回同じ指示を書く必要がない 937 | 2. **生成物の再利用**: 前のプロンプトで生成された成果物を次のプロンプトの入力に簡単に使える 938 | 3. **限界**: ルールファイルの読み込みが常に完璧ではなく、Thinkingペインでの表示や動作に不安定な部分がある 939 | 4. **β版としての位置づけ**: 本システムは継続的に改善されており、不具合や改善点のフィードバックを歓迎 940 | 941 | 942 | 943 | ### チーム活用のベストプラクティス 944 | 945 | **Q3. チームでの成果物共有はどのように行うのが最適ですか？** 946 | 947 | A3. **Stockフォルダの共有**: GitHubやObsidian（Sync機能）などのファイル共有サービスを活用して、Stockフォルダをチーム全体で共有しましょう。これにより、確定した成果物に全員がアクセスできるようになります。 948 | 949 | **Q4. プロジェクト固有のニーズに対応するにはどうすればよいですか？** 950 | 951 | A4. **プロジェクト固有のルール**: 独自のフォルダ（例: `.cursor/rules/project_specific/xxxxx.mdc`）を作成し、プロジェクト固有のルールを定義・共有することをお勧めします。これにより、プロジェクトの特性に合わせたカスタマイズが可能になります。 952 | 953 | **Q5. 新メンバーの導入をスムーズにする方法はありますか？** 954 | 955 | A5. **セットアップの簡易化**: `setup_config.sh` をカスタマイズして、プロジェクト固有のルールやプロジェクトのレポジトリを設定しておくと、新しいメンバーの初期設定が簡単になり、チームの生産性向上に役立ちます。 956 | 957 | **Q6. チーム全体で効率的に連携するためのワークフローは？** 958 | 959 | A6. 以下のようなチーム連携のワークフローをお勧めします： 960 | 961 | 1. 各メンバーは自分のローカル環境で `Flow` で作業 962 | 2. 確定した成果物は `Stock` に反映 963 | 3. 共有リポジトリに定期的にプッシュ/コミット 964 | 4. チームミーティングで成果物をレビュー 965 | 5. フィードバックを `Flow` で反映させて改善サイクルを継続 966 | 967 | このアプローチにより、個人の作業とチーム全体の成果を効率的に統合できます。 968 | 969 | **Q7. モデル選択とルール読み込みのコツはありますか？** 970 | 971 | A7. 最適な結果を得るためのヒント： 972 | 973 | - **推奨モデル**: ThinkingモードでClaude3.7を使用。高品質アウトプットが必要な場合はMAXモデルが推奨 974 | - **ルール参照確認**: Thinkingペインで「Rulesを読み取ってます」などの表示があればOK 975 | - **明示的指定**: うまく動作しない場合は、チャット入力時に@から必要なRuleを明示的に指定 976 | - **マスタールール重視**: 特に「Master Rules」が最重要。これが読み込まれていれば基本機能は動作 977 | 978 | 979 | 980 | 981 | ## 11. 開発Tips 982 | 983 | このワークスペースは単なるドキュメント管理だけでなく、開発活動自体もサポートする機能を備えています（※ベータ版/試験運用中）。 984 | 985 | ### 開発フェーズの活用方法 986 | 987 | `.cursor/rules/basic/09_pmbok_development.mdc` に定義されたルールを活用することで、以下のような開発ワークフローを実現できます： 988 | 989 | 1. **開発環境初期化**（「開発環境初期化」と入力） 990 | - プロジェクト専用の開発フォルダ構造を自動生成 991 | - 必要な初期ファイルのセットアップ 992 | - 開発環境構成の定義 993 | 994 | 2. **開発計画作成**（「開発計画作成」と入力） 995 | - 対象ストーリーの特定 996 | - 実装アプローチの定義 997 | - 技術スタックの選定 998 | 999 | 3. **実装順序計画**（「実装順序計画」と入力） 1000 | - ストーリー間の依存関係分析 1001 | - 優先度付けと最適な実装順序の決定 1002 | - フェーズ分けと実装スケジュール案の作成 1003 | 1004 | 4. **ストーリー実装**（「ストーリー実装」と入力） 1005 | - 個別ストーリーの詳細な実装計画 1006 | - 実装ステップの定義 1007 | - 主要コード構造の設計 1008 | 1009 | 5. **記事執筆**（「記事執筆」と入力） 1010 | - 技術記事やドキュメントの構成立案 1011 | - 執筆プラン作成 1012 | - 添付資料の管理 1013 | 1014 | 6. **成果物確認**（「成果物確認」と入力） 1015 | - 開発成果物の品質チェック 1016 | - レビュープロセスの実施 1017 | - Flow→Stockへの確定プロセス 1018 | 1019 | ### 開発ディレクトリ構造 1020 | 1021 | 開発作業は以下のディレクトリ構造で管理されます： 1022 | 1023 | ``` 1024 | プロジェクト/ 1025 | ├── development/ # 開発成果物のルートディレクトリ 1026 | │ ├── code/ # コードベース（ソフトウェア開発の場合） 1027 | │ ├── articles/ # 記事/ドキュメント（コンテンツ作成の場合） 1028 | │ └── assets/ # 共有リソース（画像、データなど） 1029 | └── documents/ # プロジェクトドキュメント（既存） 1030 | ``` 1031 | 1032 | ### 開発Tipsの活用例 1033 | 1034 | 1. ユーザーストーリーを「実装順序計画」で最適な順序に整理 1035 | 2. 最重要ストーリーを「ストーリー実装」で詳細設計 1036 | 3. 同時並行で「記事執筆」機能を使って技術ドキュメントを作成 1037 | 4. 開発完了後「成果物確認」でレビューし、Stockに確定 1038 | 1039 | このワークフローにより、プロジェクト管理と開発作業を一貫したプロセスで進めることができます。 1040 | 1041 | 1042 | 1043 | ## 13. 作った人 1044 | 1045 | ### プロフィール 1046 | 1047 | 1048 | 株式会社エクスプラザで生成AIエバンジェリスト・リードAIプロデューサーを務める宮田大督。生成AI技術の社会実装と普及に注力し、企業のAI導入支援やコミュニティ活動を推進。 1049 | 1050 | 前職のGaudiyや令和トラベルでは、SNSでのエージェント実装やDifyなどノーコードツール活用での大量コンテンツ生成など、様々な企画から実際の実装まで手がける。楽天やメルカリでのPdMの経験を活かし、PdMに関する登壇・執筆活動も行い、最近はAIxPM領域に特に関心をもち活動している。 1051 | 1052 | 生成AI技術の可能性と実践的な活用方法について情報発信を行い、企業のDX推進やイノベーション創出をサポート。AIと人間が共生する未来の実現を目指し、技術と社会の架け橋となることを使命としている。 1053 | 1054 | 1055 | ### SNSアカウント 1056 | - Twitter: [@miyatti](https://twitter.com/miyatti) 1057 | 1058 | ### 企業情報 1059 | - 会社名：株式会社エクスプラザ 1060 | - ミッション：「プロダクトの力で、豊かな暮らしをつくる」 1061 | - 事業内容：生成AIの活用支援/プロダクトマネジメントコンサルティング事業 1062 | - 設立：2020年7月 1063 | - 代表者：高橋一生 1064 | - 本社：東京都港区六本木4-8-5 和幸ビル503 1065 | - コーポレートサイト：[https://explaza.jp/](https://explaza.jp/) 1066 | - 採用ページ：[https://lifeat.explaza.jp/](https://lifeat.explaza.jp/) 1067 | 1068 | ## 14. 参考ブログ記事 1069 | 1070 | 1071 | ### 実際の活用事例 1072 | - [実際のCursorエージェントとのやり取り例（Twitter）](https://x.com/miyatti/status/1918922486739292432) 1073 | - ブログ作成プロジェクトでの実際の対話例を公開しています 1074 | - システムがどのように質問し、ユーザーの意図を理解していくかがわかります 1075 | 1076 | ### 活用シナリオ 1077 | - ブログ記事作成プロジェクト管理 1078 | - 技術ドキュメント整備 1079 | - 研究プロジェクト管理 1080 | - 小規模チームでの業務効率化 1081 | 1082 | 1083 | 1084 | 1085 | ### 基本コンセプトとCursorエージェント活用法 1086 | 1087 | このシステムの背景にある考え方や活用方法について、以下の記事も参考にしてください： 1088 | 1089 | - [あなたの仕事に"AI秘書"を。ノンエンジニアでもOKなCursorエージェント超入門](https://note.com/miyatad/n/nae304a0024af) 1090 | - [プロジェクト管理もストレスもAIがサポート！ ノンエンジニアでもOKなCursorエージェント講座 実践編](https://note.com/miyatad/n/ne9fb1575cddb) 1091 | 1092 | ### 解説資料 1093 | - [Cursorエージェント講座 超応用編](https://www.docswell.com/s/miyatti/KN182G-2025-03-21-202746) 1094 | - [ノンエンジニアでもOKなCursorエージェント講座](https://www.docswell.com/s/miyatti/Z6VDGV-2025-03-30-192815) 1095 | 1096 | これらの記事では、Cursorを使ったAIエージェントによるタスク管理、プロジェクト管理、文書作成の自動化などについて詳しく解説しています。本システムを最大限に活用するためのヒントやテクニックを学ぶことができます。 1097 | 1098 | ## 15. 著作権・ライセンス・免責事項 1099 | 1100 | ### 著作権 1101 | 1102 | © 2025 宮田大督 (Daisuke Miyata) 1103 | 1104 | 本「俺の考えた最強のAIPMシステム with Cursor Agent」のコンテンツ（テキスト、ルールファイル、スクリプト、ドキュメント構造など）は、作者の許可なく無断で複製、配布することはできません。 1105 | 1106 | ### ライセンス 1107 | 1108 | 本システムは以下のライセンス条件の下で提供されます： 1109 | 1110 | 1. **個人利用**: 個人的な学習、プロジェクト管理、非商用目的での利用は無償で許可されます。 1111 | 2. **社内利用**: 一つの法人・団体内でのプロジェクト管理ツールとしての利用は無償です。 1112 | 3. **商用利用**: 本システムをベースにした有料サービスの提供、コンサルティングなど営利目的で利用する場合は、作者への連絡が必要です。 1113 | 4. **配布・改変**: 改変版の作成・配布を行う場合は、オリジナルの著作権表示とこのライセンス条件を維持し、作者のクレジットを明記してください。 1114 | 1115 | ### 免責事項 1116 | 1117 | 本システムは「現状有姿」で提供され、明示または黙示を問わず、いかなる種類の保証もありません。システムの利用によって生じた直接的または間接的な損害について、作者は責任を負いません。 1118 | 1119 | ### 連絡先 1120 | 1121 | 著作権、ライセンス、商用利用に関するお問い合わせ： 1122 | - Twitter: @miyatti 1123 | - 会社: 株式会社エクスプラザ 1124 | 1125 | ### 謝辞 1126 | 1127 | 本システムの開発にあたり、多くの方々からのフィードバックとサポートをいただきました。特に、初期テスト段階でご協力いただいたコミュニティメンバーの皆様に感謝いたします。 1128 | -------------------------------------------------------------------------------- /setup_config.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | #============================================================ 3 | # setup_config.sh.example 4 | # ─ ワークスペース構築スクリプト用のコンフィグファイル例 5 | # 6 | # 使い方: cp setup_config.sh.example setup_config.sh 7 | # 編集後、./setup_workspace_simple.sh [path] setup_config.sh を実行 8 | #============================================================ 9 | 10 | # 自動確認をスキップする（trueに設定すると確認なしで進行） 11 | AUTO_APPROVE=false 12 | 13 | # リポジトリを自動クローンする（trueに設定すると確認なしでクローン） 14 | AUTO_CLONE=false 15 | 16 | # ルート 17 | # 形式: "GitリポジトリURL|ターゲットパス" 18 | RULE_REPOS=( 19 | "https://github.com/miyatti777/rules_basic_public.git|.cursor/rules/basic" 20 | # 必要に応じて追加 （追加するときはカンマなどで区切らず、改行のみでOK） 21 | # "https://github.com/username/custom_rules.git|.cursor/rules/custom" 22 | ) 23 | 24 | # スクリプトリポジトリ 25 | SCRIPT_REPOS=( 26 | "https://github.com/miyatti777/scripts_public.git|scripts" 27 | # 必要に応じて追加 （追加するときはカンマなどで区切らず、改行のみでOK） 28 | # "https://github.com/username/custom_scripts.git|scripts/custom" 29 | ) 30 | 31 | # プログラムリポジトリ 32 | PROGRAM_REPOS=( 33 | "https://github.com/miyatti777/sample_pj_curry.git|Stock/programs/夕食作り" 34 | # 必要に応じて追加 （追加するときはカンマなどで区切らず、改行のみでOK） 35 | # "https://github.com/username/custom_program.git|Stock/programs/CUSTOM" 36 | ) 37 | 38 | 39 | # 基本ディレクトリ構造 40 | BASE_DIRS=( 41 | "Flow" 42 | "Stock" 43 | "Archived" 44 | "Archived/projects" 45 | "scripts" 46 | ".cursor/rules" 47 | ".cursor/rules/basic" 48 | "Stock/programs" 49 | # 必要に応じて追加 50 | ) -------------------------------------------------------------------------------- /setup_workspace_simple.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | #============================================================ 3 | # setup_workspace_simple.sh 4 | # ─ AIプロジェクト管理ワークスペースの簡易構築スクリプト 5 | # 6 | # 使い方: ./setup_workspace_simple.sh [root_directory] [config_file] 7 | # ./setup_workspace_simple.sh [config_file] 8 | # 例: ./setup_workspace_simple.sh /Users/username/new_workspace ./my_config.sh 9 | # ./setup_workspace_simple.sh setup_config.sh # カレントディレクトリに作成 10 | # 11 | # 基本的なフォルダ構造を作成し、Flowに日付フォルダを作成します 12 | # コンフィグファイルを指定すると、クローンするリポジトリをカスタマイズできます 13 | #============================================================ 14 | 15 | set -e 16 | 17 | # 色の定義 18 | RED='\033[0;31m' 19 | GREEN='\033[0;32m' 20 | YELLOW='\033[0;33m' 21 | BLUE='\033[0;34m' 22 | NC='\033[0m' # No Color 23 | 24 | # ログ関数 25 | log_info() { 26 | echo -e "${BLUE}[INFO]${NC} $1" 27 | } 28 | 29 | log_success() { 30 | echo -e "${GREEN}[SUCCESS]${NC} $1" 31 | } 32 | 33 | log_warning() { 34 | echo -e "${YELLOW}[WARNING]${NC} $1" 35 | } 36 | 37 | log_error() { 38 | echo -e "${RED}[ERROR]${NC} $1" 39 | } 40 | 41 | # デフォルト設定 42 | # これらの設定はコンフィグファイルでオーバーライドできます 43 | setup_default_config() { 44 | # ルールリポジトリ 45 | RULE_REPOS=( 46 | "https://github.com/miyatti777/rules_basic_public.git|.cursor/rules/basic" 47 | ) 48 | 49 | # スクリプトリポジトリ 50 | SCRIPT_REPOS=( 51 | "https://github.com/miyatti777/scripts_public.git|scripts" 52 | ) 53 | 54 | # プログラムリポジトリ 55 | PROGRAM_REPOS=( 56 | "https://github.com/miyatti777/sample_pj_curry.git|Stock/programs/夕食作り" 57 | ) 58 | 59 | # サンプルプログラムフォルダ（フォールバック用） 60 | SAMPLE_PROGRAMS=( 61 | "夕食作り" 62 | ) 63 | 64 | # 基本ディレクトリ 65 | BASE_DIRS=( 66 | "Flow" 67 | "Stock" 68 | "Archived" 69 | "Archived/projects" 70 | "scripts" 71 | ".cursor/rules" 72 | ".cursor/rules/basic" 73 | "Stock/programs" 74 | ) 75 | 76 | # AUTO_APPROVE：trueに設定すると確認メッセージをスキップ 77 | AUTO_APPROVE=false 78 | 79 | # AUTO_CLONE：trueに設定するとリポジトリを自動クローン 80 | AUTO_CLONE=false 81 | } 82 | 83 | # コンフィグファイルの読み込み 84 | load_config() { 85 | local config_file="$1" 86 | 87 | if [ -f "$config_file" ]; then 88 | log_info "コンフィグファイルを読み込んでいます: $config_file" 89 | # shellcheck source=/dev/null 90 | source "$config_file" 91 | log_success "コンフィグファイルを読み込みました" 92 | else 93 | log_warning "指定されたコンフィグファイルが見つかりません: $config_file" 94 | log_info "デフォルト設定を使用します" 95 | fi 96 | } 97 | 98 | # リポジトリのクローン処理 99 | clone_repository() { 100 | local url=$1 101 | local target=$2 102 | local full_path="$ROOT_DIR/$target" 103 | 104 | # ターゲットディレクトリが既に存在し、かつgitリポジトリである場合はpullのみ 105 | if [ -d "$full_path/.git" ]; then 106 | log_info "リポジトリは既に存在します: $target - 更新を試みます" 107 | (cd "$full_path" && git pull) 108 | if [ $? -eq 0 ]; then 109 | log_success "リポジトリを更新しました: $target" 110 | else 111 | log_warning "リポジトリの更新中にエラーが発生しました: $target" 112 | log_info "更新をスキップして継続します" 113 | fi 114 | else 115 | # ディレクトリが存在する場合は中身を確認 116 | if [ -d "$full_path" ]; then 117 | # 空のディレクトリでなければ、バックアップして再クローン 118 | if [ "$(ls -A "$full_path")" ]; then 119 | log_warning "ターゲットディレクトリ '$full_path' は空ではありません" 120 | 121 | # ユーザーにディレクトリの扱いを確認 122 | local dir_action="" 123 | if [ "$AUTO_APPROVE" != "true" ]; then 124 | read -p "既存のディレクトリを [b]バックアップして続行、[s]スキップ、[f]強制的に削除して続行? (b/s/f): " dir_action 125 | else 126 | dir_action="b" # 自動承認の場合はバックアップを選択 127 | fi 128 | 129 | case "$dir_action" in 130 | [Bb]*) 131 | # バックアップして続行 132 | local backup_dir="${full_path}_backup_$(date +%Y%m%d%H%M%S)" 133 | log_info "ディレクトリをバックアップしています: $full_path -> $backup_dir" 134 | mv "$full_path" "$backup_dir" 135 | log_success "バックアップ完了: $backup_dir" 136 | ;; 137 | [Ss]*) 138 | # スキップ 139 | log_info "ディレクトリ $target のクローンをスキップします" 140 | return 0 141 | ;; 142 | [Ff]*) 143 | # 強制削除 144 | log_warning "ディレクトリを強制的に削除します: $full_path" 145 | rm -rf "$full_path" 146 | ;; 147 | *) 148 | # デフォルトはスキップ 149 | log_info "ディレクトリ $target のクローンをスキップします" 150 | return 0 151 | ;; 152 | esac 153 | else 154 | # 空のディレクトリなら削除してクローン 155 | rmdir "$full_path" 156 | fi 157 | fi 158 | 159 | # 親ディレクトリを作成 160 | mkdir -p "$(dirname "$full_path")" 161 | 162 | # リポジトリをクローン 163 | log_info "リポジトリをクローンしています: $url -> $target" 164 | git clone "$url" "$full_path" 165 | if [ $? -eq 0 ]; then 166 | log_success "リポジトリをクローンしました: $target" 167 | 168 | # サブモジュールの初期化（必要な場合） 169 | if [ -f "$full_path/.gitmodules" ]; then 170 | log_info "サブモジュールを初期化しています: $target" 171 | (cd "$full_path" && git submodule update --init --recursive) 172 | if [ $? -eq 0 ]; then 173 | log_success "サブモジュールを初期化しました: $target" 174 | else 175 | log_warning "サブモジュールの初期化中にエラーが発生しました: $target" 176 | fi 177 | fi 178 | 179 | # Gitリポジトリの状態確認 180 | log_info "リポジトリの状態を確認しています: $target" 181 | if [ -d "$full_path/.git" ]; then 182 | log_success "Gitリポジトリが正常に作成されました: $target" 183 | else 184 | log_warning "警告: $target に.gitディレクトリが見つかりません" 185 | fi 186 | else 187 | log_error "リポジトリのクローンに失敗しました: $url" 188 | return 1 189 | fi 190 | fi 191 | } 192 | 193 | # リポジトリのクローン 194 | clone_repositories() { 195 | log_info "リポジトリをクローンしています..." 196 | 197 | # git が必要 198 | if ! command -v git &> /dev/null; then 199 | log_warning "git がインストールされていません。リポジトリクローンをスキップします。" 200 | return 1 201 | fi 202 | 203 | # AUTO_CLONEがfalseの場合は確認 204 | local clone_confirm="y" 205 | if [ "$AUTO_CLONE" != "true" ]; then 206 | read -p "リポジトリをクローンしますか？ (y/n): " clone_confirm 207 | if [[ "$clone_confirm" != [yY] ]]; then 208 | log_info "リポジトリのクローンはスキップされました" 209 | return 0 210 | fi 211 | else 212 | log_info "AUTO_CLONE=true が設定されているため、すべてのリポジトリを自動クローンします" 213 | fi 214 | 215 | # 結果集計用変数 216 | local success_count=0 217 | local fail_count=0 218 | local skip_count=0 219 | 220 | # ルールリポジトリ 221 | if [ ${#RULE_REPOS[@]} -gt 0 ]; then 222 | log_info "ルールリポジトリをクローンしています..." 223 | for repo_entry in "${RULE_REPOS[@]}"; do 224 | url=$(echo "$repo_entry" | cut -d'|' -f1) 225 | target=$(echo "$repo_entry" | cut -d'|' -f2) 226 | clone_repository "$url" "$target" 227 | if [ $? -eq 0 ]; then 228 | ((success_count++)) 229 | else 230 | ((fail_count++)) 231 | fi 232 | done 233 | else 234 | log_info "ルールリポジトリの指定がないためスキップします" 235 | ((skip_count++)) 236 | fi 237 | 238 | # スクリプトリポジトリ 239 | if [ ${#SCRIPT_REPOS[@]} -gt 0 ]; then 240 | log_info "スクリプトリポジトリをクローンしています..." 241 | for repo_entry in "${SCRIPT_REPOS[@]}"; do 242 | url=$(echo "$repo_entry" | cut -d'|' -f1) 243 | target=$(echo "$repo_entry" | cut -d'|' -f2) 244 | clone_repository "$url" "$target" 245 | if [ $? -eq 0 ]; then 246 | ((success_count++)) 247 | else 248 | ((fail_count++)) 249 | fi 250 | done 251 | else 252 | log_info "スクリプトリポジトリの指定がないためスキップします" 253 | ((skip_count++)) 254 | fi 255 | 256 | # プログラムリポジトリ 257 | if [ ${#PROGRAM_REPOS[@]} -gt 0 ]; then 258 | log_info "プログラムリポジトリをクローンしています..." 259 | for repo_entry in "${PROGRAM_REPOS[@]}"; do 260 | url=$(echo "$repo_entry" | cut -d'|' -f1) 261 | target=$(echo "$repo_entry" | cut -d'|' -f2) 262 | 263 | # AUTO_CLONEがtrueでない場合は各リポジトリごとに確認 264 | local repo_confirm="y" 265 | if [ "$AUTO_CLONE" != "true" ]; then 266 | read -p "$url をクローンしますか？ (y/n): " repo_confirm 267 | fi 268 | 269 | if [[ "$repo_confirm" == [yY] || "$AUTO_CLONE" == "true" ]]; then 270 | clone_repository "$url" "$target" 271 | if [ $? -eq 0 ]; then 272 | ((success_count++)) 273 | else 274 | ((fail_count++)) 275 | log_warning "リポジトリ $url のクローンに問題が発生しましたが、処理は継続します" 276 | fi 277 | else 278 | log_info "リポジトリはスキップされました: $url" 279 | ((skip_count++)) 280 | fi 281 | done 282 | else 283 | log_info "プログラムリポジトリの指定がないためスキップします" 284 | ((skip_count++)) 285 | fi 286 | 287 | # 結果のサマリー表示 288 | log_info "リポジトリクローン結果: 成功=${success_count}, 失敗=${fail_count}, スキップ=${skip_count}" 289 | 290 | if [ $fail_count -gt 0 ]; then 291 | log_warning "一部のリポジトリクローンに失敗しましたが、セットアップは継続します" 292 | return 1 293 | else 294 | log_success "リポジトリのクローンが完了しました" 295 | return 0 296 | fi 297 | } 298 | 299 | # フォールバックのディレクトリ作成 300 | create_fallback_directories() { 301 | log_info "追加のディレクトリを作成しています..." 302 | 303 | # 共通ナレッジ領域作成 304 | if [ ! -d "$ROOT_DIR/Stock/programs/Common/Public" ]; then 305 | mkdir -p "$ROOT_DIR/Stock/programs/Common/Public" 306 | log_info "共通ナレッジディレクトリ作成: Stock/programs/Common/Public" 307 | fi 308 | 309 | # サンプルプログラムフォルダの作成（クローンが失敗または選択されなかった場合のフォールバック） 310 | for prog in "${SAMPLE_PROGRAMS[@]}"; do 311 | if [ ! -d "$ROOT_DIR/Stock/programs/$prog" ]; then 312 | mkdir -p "$ROOT_DIR/Stock/programs/$prog" 313 | log_info "プログラムディレクトリ作成: Stock/programs/$prog" 314 | fi 315 | done 316 | } 317 | 318 | # VSCodeの設定を更新 319 | setup_vscode_settings() { 320 | log_info "VSCode設定を更新しています..." 321 | 322 | # .vscode ディレクトリ作成 323 | mkdir -p "$ROOT_DIR/.vscode" 324 | 325 | # settings.json のパス 326 | SETTINGS_JSON="$ROOT_DIR/.vscode/settings.json" 327 | 328 | # 設定データ 329 | MARP_THEMES_SETTING='{ 330 | "markdown.marp.themes": [ 331 | ".cursor/rules/basic/templates/marp-themes/explaza.css", 332 | ".cursor/rules/basic/templates/marp-themes/modern-brown.css" 333 | ] 334 | }' 335 | 336 | # settings.json が存在するか確認 337 | if [ -f "$SETTINGS_JSON" ]; then 338 | log_info "既存のsettings.jsonを更新します" 339 | 340 | # すでに markdown.marp.themes 設定が含まれているか確認 341 | if grep -q "markdown.marp.themes" "$SETTINGS_JSON"; then 342 | log_info "markdown.marp.themes の設定はすでに存在します。スキップします。" 343 | else 344 | # JSON 形式を保持しながら設定を追加 345 | # 最後の閉じ括弧を一時的に削除し、設定を追加してから閉じ括弧を戻す 346 | sed -i.bak '$ s/}$/,/' "$SETTINGS_JSON" 347 | sed -i.bak '$ s/,$//' "$SETTINGS_JSON" # 末尾のカンマを削除 348 | echo "$MARP_THEMES_SETTING" | sed 's/^{//' | sed 's/}$//' >> "$SETTINGS_JSON" 349 | echo "}" >> "$SETTINGS_JSON" 350 | rm -f "$SETTINGS_JSON.bak" 351 | log_success "settings.jsonにマープテーマ設定を追加しました" 352 | fi 353 | else 354 | # 新規作成 355 | echo "$MARP_THEMES_SETTING" > "$SETTINGS_JSON" 356 | log_success "settings.jsonを新規作成しました" 357 | fi 358 | } 359 | 360 | # マープテーマCSSの背景画像パスを更新 361 | update_marp_theme_paths() { 362 | log_info "マープテーマのパスを更新しています..." 363 | 364 | # テーマディレクトリ 365 | THEME_DIR="$ROOT_DIR/.cursor/rules/basic/templates/marp-themes" 366 | 367 | # テーマディレクトリが存在するか確認 368 | if [ ! -d "$THEME_DIR" ]; then 369 | log_warning "テーマディレクトリが見つかりません: $THEME_DIR" 370 | return 1 371 | fi 372 | 373 | # 新しい絶対パス 374 | NEW_PATH="$ROOT_DIR/.cursor/rules/basic/templates/marp-themes/assets" 375 | 376 | # CSSファイルのパスを更新 377 | log_info "CSSファイル内の背景画像パスを更新中..." 378 | for css_file in "$THEME_DIR"/*.css; do 379 | if [ -f "$css_file" ]; then 380 | # 背景画像の絶対パスを検索して置換 381 | sed -i.bak "s|background-image: url(\"[^\"]*assets/|background-image: url(\"$NEW_PATH/|g" "$css_file" 382 | rm -f "${css_file}.bak" 383 | log_info "更新: $css_file" 384 | fi 385 | done 386 | 387 | log_success "マープテーマの背景画像パスを更新しました" 388 | } 389 | 390 | # リポジトリの状態を確認 391 | verify_repositories() { 392 | log_info "リポジトリの状態を確認しています..." 393 | 394 | # 結果集計用変数 395 | local valid_count=0 396 | local invalid_count=0 397 | 398 | # ルールリポジトリ 399 | if [ ${#RULE_REPOS[@]} -gt 0 ]; then 400 | log_info "ルールリポジトリの状態を確認しています..." 401 | for repo_entry in "${RULE_REPOS[@]}"; do 402 | target=$(echo "$repo_entry" | cut -d'|' -f2) 403 | local full_path="$ROOT_DIR/$target" 404 | 405 | if [ -d "$full_path/.git" ]; then 406 | log_success "ルールリポジトリが有効です: $target" 407 | ((valid_count++)) 408 | else 409 | log_warning "ルールリポジトリの.gitディレクトリがありません: $target" 410 | ((invalid_count++)) 411 | fi 412 | done 413 | fi 414 | 415 | # スクリプトリポジトリ 416 | if [ ${#SCRIPT_REPOS[@]} -gt 0 ]; then 417 | log_info "スクリプトリポジトリの状態を確認しています..." 418 | for repo_entry in "${SCRIPT_REPOS[@]}"; do 419 | target=$(echo "$repo_entry" | cut -d'|' -f2) 420 | local full_path="$ROOT_DIR/$target" 421 | 422 | if [ -d "$full_path/.git" ]; then 423 | log_success "スクリプトリポジトリが有効です: $target" 424 | ((valid_count++)) 425 | else 426 | log_warning "スクリプトリポジトリの.gitディレクトリがありません: $target" 427 | ((invalid_count++)) 428 | fi 429 | done 430 | fi 431 | 432 | # 結果のサマリー表示 433 | log_info "リポジトリ状態の確認結果: 有効=${valid_count}, 問題あり=${invalid_count}" 434 | 435 | if [ $invalid_count -gt 0 ]; then 436 | log_warning "一部のリポジトリに問題があります。git pullが正しく動作しない可能性があります。" 437 | log_info "修正するには、問題のあるディレクトリを削除して再度セットアップを実行してください。" 438 | return 1 439 | else 440 | log_success "すべてのリポジトリが正常です" 441 | return 0 442 | fi 443 | } 444 | 445 | # 問題発生時のトラブルシューティングガイドを表示 446 | display_troubleshooting_guide() { 447 | echo 448 | echo "============================================================" 449 | echo " トラブルシューティングガイド" 450 | echo "============================================================" 451 | echo "問題: リポジトリを git pull しても更新されない" 452 | echo "原因: ディレクトリ内に .git フォルダがない可能性があります" 453 | echo 454 | echo "解決方法:" 455 | echo "1. 問題のあるディレクトリを削除: " 456 | echo " rm -rf \"$ROOT_DIR/.cursor/rules/basic\"" 457 | echo " rm -rf \"$ROOT_DIR/scripts\"" 458 | echo 459 | echo "2. セットアップを再実行:" 460 | echo " ./setup_workspace_simple.sh \"$ROOT_DIR\" \"$CONFIG_FILE\"" 461 | echo 462 | echo "3. または、個別のリポジトリを手動でクローン:" 463 | echo " git clone <リポジトリURL> <ターゲットディレクトリ>" 464 | echo "============================================================" 465 | } 466 | 467 | # メイン処理 468 | main() { 469 | echo "============================================================" 470 | echo " AIプロジェクト管理ワークスペース簡易構築スクリプト" 471 | echo "============================================================" 472 | 473 | # 引数の処理を柔軟にする 474 | # 引数が1つだけの場合、それがconfig_fileかどうかを判断 475 | if [ $# -eq 1 ] && [[ "$1" == *".sh" ]]; then 476 | ROOT_DIR="./" 477 | CONFIG_FILE="$1" 478 | else 479 | # 通常の引数処理（以前と同じ） 480 | ROOT_DIR="${1:-./}" 481 | CONFIG_FILE="${2:-./setup_config.sh}" 482 | fi 483 | 484 | # デフォルト設定をロード 485 | setup_default_config 486 | 487 | # コンフィグファイルをロード（指定されていれば） 488 | if [ -n "$CONFIG_FILE" ]; then 489 | load_config "$CONFIG_FILE" 490 | fi 491 | 492 | # 絶対パスに変換（ディレクトリが存在しなくてもパスを解決できるように） 493 | if [[ "$ROOT_DIR" = /* ]]; then 494 | # 既に絶対パスの場合はそのまま 495 | : 496 | else 497 | # 相対パスの場合は現在のディレクトリからの絶対パスに変換 498 | ROOT_DIR="$(pwd)/$ROOT_DIR" 499 | fi 500 | 501 | log_info "ワークスペースのルートディレクトリ: $ROOT_DIR" 502 | log_info "使用するコンフィグファイル: $CONFIG_FILE" 503 | 504 | # 確認メッセージ（AUTO_APPROVEがtrueの場合はスキップ） 505 | if [ "$AUTO_APPROVE" != "true" ]; then 506 | read -p "この場所にワークスペースを作成してよろしいですか？ (y/n): " confirm 507 | if [[ "$confirm" != [yY] ]]; then 508 | log_info "キャンセルされました" 509 | exit 0 510 | fi 511 | else 512 | log_info "AUTO_APPROVE=true が設定されているため、確認をスキップします" 513 | fi 514 | 515 | # ルートディレクトリ作成 516 | mkdir -p "$ROOT_DIR" 517 | 518 | log_info "基本ディレクトリ構造を作成しています..." 519 | 520 | # ディレクトリ作成 521 | for dir in "${BASE_DIRS[@]}"; do 522 | mkdir -p "$ROOT_DIR/$dir" 523 | log_info "ディレクトリ作成: $dir" 524 | done 525 | 526 | # 日付フォルダ作成 527 | log_info "Flow 内に日付フォルダを作成しています..." 528 | TODAY=$(date +"%Y-%m-%d") 529 | YEAR_MONTH=$(date +"%Y%m") 530 | FLOW_DATE_DIR="$ROOT_DIR/Flow/$YEAR_MONTH/$TODAY" 531 | mkdir -p "$FLOW_DATE_DIR" 532 | log_info "日付フォルダ作成: Flow/$YEAR_MONTH/$TODAY" 533 | 534 | # クローンされなかったディレクトリをフォールバックとして作成（先に行う） 535 | create_fallback_directories 536 | 537 | # リポジトリのクローン 538 | clone_repositories 539 | 540 | # VSCode設定を更新 541 | setup_vscode_settings 542 | 543 | # マープテーマのパスを更新 544 | update_marp_theme_paths 545 | 546 | # リポジトリの状態を確認 547 | verify_repositories 548 | 549 | # 完了メッセージ 550 | log_success "ワークスペースの構築が完了しました: $ROOT_DIR" 551 | echo "============================================================" 552 | echo "完了しました！新しいワークスペースが構築されました。" 553 | echo "ディレクトリ: $ROOT_DIR" 554 | echo "============================================================" 555 | 556 | # 問題が検出された場合はトラブルシューティングガイドを表示 557 | local issues_detected=false 558 | 559 | # ルールディレクトリのgit確認 560 | if [ -d "$ROOT_DIR/.cursor/rules/basic" ] && [ ! -d "$ROOT_DIR/.cursor/rules/basic/.git" ]; then 561 | issues_detected=true 562 | fi 563 | 564 | # スクリプトディレクトリのgit確認 565 | if [ -d "$ROOT_DIR/scripts" ] && [ ! -d "$ROOT_DIR/scripts/.git" ]; then 566 | issues_detected=true 567 | fi 568 | 569 | # 問題が検出された場合はガイドを表示 570 | if [ "$issues_detected" = true ]; then 571 | log_warning "一部のリポジトリに問題が検出されました。git pull による更新が機能しない可能性があります。" 572 | display_troubleshooting_guide 573 | fi 574 | } 575 | 576 | # スクリプト実行 577 | main "$@" 578 | --------------------------------------------------------------------------------