positioning
文書の位置づけ
本文書の位置づけ: Issue #143 組織アーキテクチャ要件定義書の移行計画別紙。Issue #153 PJ推進大全とは姉妹文書の関係にあり、#153がPJ推進の運用ガイドを扱うのに対し、本文書は現行システムから目標アーキテクチャへの移行手順を定義する。本文書単体で自己完結しており、他文書を参照せずとも移行計画の全体像を把握できる。
関連文書
| 文書 | Issue | 内容 | 関係 |
|---|
| 組織アーキテクチャ要件定義書 | #143 | 組織構造・Division定義・UC定義 | 本体（本文書はその別紙） |
| PJ推進大全 | #153 | PJM運用ガイド・品質ゲート・推進ナレッジ | 姉妹文書 |
| 移行計画書（本文書） | #154 | Phase 0〜3の段階的移行方針 | — |
basic policy
移行の基本方針
段階的移行
Phase 0（基盤整備）→ Phase 1（Division体制導入）→ Phase 2（DAG並行実行）→ Phase 3（高度化）の4段階で移行する。各Phaseは前Phaseの安定稼働を確認してから開始する。
巻き戻し許容
Phase間の退行（ロールバック）を許容する。失敗時は前Phaseに退行し、原因を解決してから再挑戦する。無理な前進よりも安定性を優先する。
CEO承認ゲート
各Phase移行時にCEO承認を必須とする。判断基準を明確に定義し、数値的な完了条件で移行可否を判定する。
現行システム非破壊
移行中も現行システム（bot.py + 直列パイプライン）は稼働し続ける。新機能を追加しつつ既存機能を壊さないことを保証する。
phase summary
Phase一覧サマリ
| Phase | 名称 | 期間目安 | 目的 | 主要成果物 |
|---|
| P0 |
基盤整備 |
2〜3週間 |
現行システムの安定化と移行基盤要素の整備 |
IF層内蔵化、worktree対応、CLAUDE.md整備、自律ループ安定化 |
| P1 |
Division体制導入 |
3〜4週間 |
M層のDivision分割とPMO/PJM体制導入 |
Division CLAUDE.md、PJMテンプレート、パイロットPJ 3件完走 |
| P2 |
DAG並行実行 |
4〜6週間 |
依存関係を尊重した最大並行実行の実現 |
DAGモデル、Scheduler、worktree並行制御、ダッシュボード可視化 |
| P3 |
高度化・最適化 |
継続的 |
運用実績に基づく最適化と自律度の引き上げ |
承認ゲート最適化、ナレッジ自動適用、リソース予測、OA監査自動化 |
移行フロー概観
Phase 0：基盤整備
IF層内蔵化、worktree対応、CLAUDE.md整備、M層自律ループ安定化
移行判断：自律ループ5件正常完了 + SA異常なし3日 + CEO承認
Phase 1：Division体制導入
Division CLAUDE.md作成、PJMテンプレート、パイロットPJ 3件実行
移行判断：パイロット3件完走 + OA監査NG処理成功 + CEO承認
Phase 2：DAG並行実行
DAGモデル定義、Scheduler実装、worktree並行制御、ダッシュボード可視化
移行判断：並行PJ 2件同時完了 + リソース監視正常 + CEO承認
Phase 3：高度化・最適化
承認ゲート最適化、ナレッジ自動適用、リソース予測、OA監査自動化
完了条件なし（継続的改善）
current architecture
現行システムと目標アーキテクチャ
現行システム（Phase 0開始前）
- bot.py常駐 + IF層CLIルーティング
- M層: m-dev / m-bo / m-legal の3マネージャー
- W層: 直列実行（1タスク1ワーカー）
- worktreeなし（メインブランチ直接操作）
目標アーキテクチャ（Phase 3完了後）
- IF層bot.py内蔵（CLI起動不要）
- M層: Division体制（VDU/PMO/OA/SA/BA/H&A）
- W層: DAG並行実行（依存関係解決済みノードを同時起動）
- worktreeによるファイル競合回避
- PJM有期ロール + ナレッジ自動適用
| 項目 | 内容 |
|---|
| 目的 | 現行システムを壊さずに、Division体制導入に必要な基盤要素を整備する |
| 期間目安 | 2〜3週間 |
| 前提条件 | なし（現時点から開始可能） |
| リスク | IF層内蔵化によるルーティング精度の変化、worktree導入時のgit操作の複雑化 |
milestones
マイルストーン詳細
| # | マイルストーン | 完了条件 | 担当 |
|---|
| P0-1 | IF層のbot.py内蔵化 | Slackメッセージ→ルーティング判断がCLI起動なしで完了する | VDU |
| P0-2 | coderのworktree対応 | coder起動時にgit worktreeが自動作成・マージ・削除される | VDU |
| P0-3 | CLAUDE.md整備 | 全エージェントのCLAUDE.mdが新組織構造と整合する | VDU OA |
| P0-4 | M層自律ループの安定化 | STATUSタグ制御（CONTINUE/DONE/APPROVAL_NEEDED/CONSULT）が安定動作 | VDU |
P0-1：IF層のbot.py内蔵化
目的: IF層の判断をbot.py内のルーターとして内蔵化し、CLI起動コスト（トークン消費・起動時間）を削減する。
完了条件の詳細
- Slackメッセージ受信からM層委譲までCLI起動が発生しない
- ルーティング精度が現行IF層と同等以上（既存テストケースで検証）
- 未知のパターンに対するフォールバック（CEO相談）が正常動作する
- 既存のSlack UIフロー（ボタン操作、スレッド応答）に変更がない
P0-2：coderのworktree対応
目的: Phase 2のDAG並行実行に備え、複数coderが同時にファイルを編集してもメインブランチを汚染しない仕組みを先行導入する。
完了条件の詳細
- coder起動時にgit worktreeが自動作成される
- coder完了時にworktreeがメインブランチにマージされる
- マージ衝突発生時にM層に報告され、手動解決フローに移行する
- coder異常終了時にworktreeが残存しない（クリーンアップ処理）
P0-3：CLAUDE.md整備
目的: 全エージェントのCLAUDE.mdを新組織構造（四層 + Division体制）と整合させ、Phase 1でのDivision CLAUDE.md作成の土台を作る。
完了条件の詳細
- 全CLAUDE.mdが四層構造（CEO/IF/M/W）の用語を統一的に使用している
- Division名（VDU/PMO/OA/SA等）が正しく参照されている
- OA監査により整合性チェックが実施され、不整合がゼロ
P0-4：M層自律ループの安定化
目的: M層がW層に作業を委譲し、結果を確認し、次のアクションを自律的に判断するループを安定させる。Division体制移行後もこのループが基盤となる。
完了条件の詳細
- STATUSタグ（CONTINUE/DONE/APPROVAL_NEEDED/CONSULT）の全パターンが正常動作
- W層からのエラー伝播が正しくハンドリングされる
- APPROVAL_NEEDED時にCEO承認フローが正常に起動する
- CONSULT時にIF層経由でCEOへの相談が正常に行われる
transition gate
Phase 0 → Phase 1 移行判断基準
全て満たすこと:
・P0-1〜P0-4が全て完了
・M層自律ループで5件以上のタスクが正常完了（NG差し戻し含む）
・SA監視が異常を検知していない期間が3日以上継続
・CEOが移行を承認
判断プロセス: VDUが上記基準の充足状況をIF層経由でCEOに報告し、CEO承認を取得する。定量基準（5件完了、3日無異常）はSA監視ログから検証する。
| 項目 | 内容 |
|---|
| 目的 | 現行のm-dev/m-bo/m-legal体制から、VDU/PMO/OA/SA/BA/H&A のDivision体制に移行する |
| 期間目安 | 3〜4週間 |
| 前提条件 | Phase 0の全マイルストーン完了 |
| リスク | Division間の責務境界の曖昧さ、PJMライフサイクル管理の複雑さ |
milestones
マイルストーン詳細
| # | マイルストーン | 完了条件 | 担当 |
|---|
| P1-1 | VDU CLAUDE.md作成 | 12工程体系・品質ゲート・エスカレーション基準を含む | VDU |
| P1-2 | PMO CLAUDE.md作成 | PJM生成・管理・重複チェック・ナレッジ蓄積を含む | VDU |
| P1-3 | OA/SA CLAUDE.md作成 | 三線防御の独立監査体制が定義されている | VDU |
| P1-4 | PJMテンプレート作成 | PJM用CLAUDE.mdテンプレートが作成され、PMOが動的生成できる | PMO |
| P1-5 | IF層ルーティング更新 | IF層が新Division体制に基づきルーティングできる | VDU |
| P1-6 | パイロットPJ実行（3件） | 新体制で3件のPJが工程1〜12を完走する | 全Division |
P1-1〜P1-3：Division CLAUDE.md作成
目的: 各Divisionの責務・権限・エスカレーション基準を明文化し、自律的な判断の根拠を提供する。
各CLAUDE.mdには以下を含めること:
- Divisionの責務範囲と権限の境界
- 他Divisionとの連携インターフェース
- CEO承認ゲートの判断基準
- エスカレーション基準（いつCEOに相談するか）
- 品質基準と監査チェックリスト（OA/SA）
P1-4：PJMテンプレート
目的: PJMはPJ単位で動的に生成される有期ロール。PMOがテンプレートからCLAUDE.mdを生成し、PJ固有のパラメータ（スコープ、期限、担当W層）を注入する。
テンプレートに含む要素
- PJ基本情報（Issue番号、スコープ、期限）の注入ポイント
- 工程管理の標準フロー（12工程のうち該当工程）
- W層への委譲・レビュー・差し戻しのルール
- 完了条件とPJ解散の手順
P1-5：IF層ルーティング更新
Phase 0でbot.py内蔵化したIF層のルーティングロジックを、新Division体制に対応させる。
- 旧マネージャー名（m-dev, m-bo, m-legal）から新Division名へのマッピング
- 新Division（PMO, OA, SA, H&A）へのルーティングパス追加
- 既存のSlackスレッドフローへの影響がないことの検証
P1-6：パイロットPJ選定基準
パイロットPJの選定基準: 以下の条件を満たすPJを3件選定する。パイロットの目的は新体制の検証であり、高リスクPJは避ける。
| 条件 | 理由 |
|---|
| 小〜中規模（実装1〜3日程度） | 短期間で全工程を回し、フロー検証に集中する |
| 技術リスクが低い | 新体制の問題と技術的問題を分離するため |
| 全12工程を経由する案件 | フェーズスキップではなく全工程のフロー検証が必要 |
| 異なるDivisionが関与する | Division間連携の検証を含める |
transition gate
Phase 1 → Phase 2 移行判断基準
全て満たすこと:
・パイロットPJ 3件が正常完了（工程1〜12の全ステップ経由）
・OA監査が機能し、少なくとも1件のNG差し戻しが正常に処理された
・CEO承認ゲートが全て正常動作（工程3, 4, 9, 10）
・PJMの生成・消滅ライフサイクルが正常に動作
・CEOが移行を承認
判断プロセス: PMOがパイロットPJの実行結果を集計し、OAが独立監査レポートを作成。両者をIF層経由でCEOに報告し、承認を取得する。
| 項目 | 内容 |
|---|
| 目的 | 直列パイプラインの制約を解消し、依存関係のないタスクを同時実行する |
| 期間目安 | 4〜6週間 |
| 前提条件 | Phase 1のパイロットPJが3件以上成功 |
| リスク | DAG不正並行によるデータ破損、worktreeマージ衝突の頻発、リソース逼迫 |
milestones
マイルストーン詳細
| # | マイルストーン | 完了条件 | 担当 |
|---|
| P2-1 | DAGモデル定義 | M層がPJ計画をDAG（ノード=工程、エッジ=依存関係）として出力できる | VDU |
| P2-2 | DAG Scheduler実装 | bot.pyがDAGを受け取り、依存解決済みノードを並行起動できる | VDU |
| P2-3 | worktree並行制御 | 複数coderが同時にworktreeで作業し、マージ衝突を自動検知・報告する | VDU |
| P2-4 | ダッシュボードDAG可視化 | DAGの進行状況がリアルタイムでダッシュボードに表示される | VDU |
| P2-5 | 並行PJ実行テスト | 2件以上のPJが同時進行し、リソース競合なく完了する | 全Division |
P2-1：DAGモデル定義
設計方針: M層（Planner化）がPJ計画をDAGとして出力する。各ノードはW層タスク（工程）、各エッジは依存関係を表す。合流ノード（複数タスクの比較・判断）は生成しない — タスク間の比較はCEOが行う。
DAGモデルの仕様
- ノード: タスクID、ワーカー種別（coder/researcher/architect等）、入力パラメータ、完了条件
- エッジ: 依存元ノードID → 依存先ノードID（依存元の完了が依存先の開始条件）
- 制約: 合流ノード不要。タスク間の比較・判断はCEOが行う
- 出力形式: JSON（bot.pyが解析可能な構造化データ）
P2-2：DAG Scheduler実装
設計方針: bot.pyがDAGを受け取り、依存関係が解決済みのノードを自動的に並行起動する。各ノードの完了をトリガーに、次に実行可能なノードを判定する。
Schedulerの要件
- 依存関係の解決: ノードの全依存元が完了状態の場合のみ起動する
- 並行度制御: 同時実行ノード数の上限設定（リソース逼迫防止）
- エラーハンドリング: ノード失敗時に依存先ノードをブロック状態にする
- CEO承認ゲート: DAGノードにゲートタイプを設定可能（自動/承認必要）
- リトライ: 既存のリトライ機構（MAX_RETRY_COUNT=3）との整合
P2-3：worktree並行制御
Phase 0で導入したworktreeを、複数coderの同時実行に対応させる。
- 各coderが独立したworktreeで作業する（ブランチ名の衝突回避）
- マージ順序の制御（DAGの完了順序に従う）
- マージ衝突の自動検知と、M層への報告フロー
- 衝突解決後の再マージ手順
P2-4：ダッシュボードDAG可視化
既存ダッシュボード（worker_status.json + SSE）を拡張し、DAGの進行状況をリアルタイム表示する。
- DAGノードの状態（待機/実行中/完了/エラー/ブロック）を色分け表示
- 依存関係の矢印表示
- 並行実行中のノードのリアルタイム更新
- 完了済みノードの実行時間表示
transition gate
Phase 2 → Phase 3 移行判断基準
全て満たすこと:
・並行PJ 2件以上が同時進行で正常完了
・DAG Schedulerが依存関係を正しく解決し、不正な並行起動がゼロ
・worktreeマージ衝突の検知・報告が正常動作
・SA監視でリソース逼迫アラートが適切に発火
・CEOが移行を承認
| 項目 | 内容 |
|---|
| 目的 | Phase 2で確立した並行実行基盤の上で、運用効率と自律度を継続的に改善する |
| 期間目安 | 継続的（Phase 2安定後に随時実施） |
| 前提条件 | Phase 2の並行実行が安定稼働 |
Phase 3は完了条件を持たない: 各マイルストーンは独立しており、順不同で着手可能。運用実績とCEO判断に基づき、優先度を決定する。
milestones
マイルストーン詳細
| # | マイルストーン | 完了条件 | 担当 |
|---|
| P3-1 | CEO承認ゲートの最適化 | 実績に基づき、低リスクPJの承認ゲートを簡略化（VDU判断に委任） | CEO VDU |
| P3-2 | ナレッジ自動適用 | 過去PJのナレッジが新PJの計画策定時に自動参照される | PMO |
| P3-3 | リソース予測 | SAがPJ計画からCLI使用量を予測し、rate limit回避を事前提案する | SA |
| P3-4 | OA監査の自動化 | 定型チェック項目がOAによって自動実行され、結果がレポート化される | OA |
P3-1：CEO承認ゲートの最適化
方針: 全PJでCEO承認を求めることはボトルネックになりうる。運用実績に基づき、低リスクPJのうち特定の承認ゲートをVDU判断に委任する。ただし、以下は常にCEO承認を必須とする。
- 常時CEO承認: 破壊的変更（DB変更・main直接push）、外部サービス連携の新規追加、セキュリティに関わる変更
- 委任候補: 既存機能のバグ修正、ドキュメント更新、テスト追加、UI微調整
- 委任判断: 過去の類似PJでの問題発生率に基づきCEOが判断する
P3-2：ナレッジ自動適用
PMOが蓄積した過去PJのナレッジ（成功パターン、失敗事例、推定工数）を、新PJの計画策定時に自動的に参照・提案する仕組み。
- 過去PJのナレッジをベクトル化し、類似案件を検索可能にする
- PJM生成時に関連ナレッジを自動注入する
- 推定工数の精度を過去実績と比較し、フィードバックループを構築する
P3-3：リソース予測
SAがPJ計画（DAG）からCLI使用量を予測し、rate limit到達前に事前アラートを出す。
- DAGノード数 × 推定トークン消費量からPJ全体のリソース使用量を推定
- 並行PJのリソース競合を検出し、実行スケジュールの調整を提案
- rate limit到達予測時刻を算出し、実行タイミングの分散を推奨
P3-4：OA監査の自動化
OAの定型チェック項目（セキュリティ・品質・プロセス遵守）を自動実行し、結果をレポート化する。
- コードレビューの定型チェック（OWASP Top 10、入力バリデーション等）の自動化
- CLAUDE.md整合性チェックの定期自動実行
- 監査結果のレポート自動生成とCEOへの定期報告
rollback policy
退行（ロールバック）方針
基本原則: 移行は「前進のみ」ではない。各Phaseで重大な問題が発生した場合、前Phaseに退行して安定状態に戻すことを許容する。退行は失敗ではなく、安定性を担保するための設計上の選択肢である。
rollback triggers
退行トリガーと退行先
| Phase | 退行トリガー | 退行先 | 判断者 |
|---|
| Phase 1 |
パイロットPJで致命的な工程フロー不備が3件以上発生 |
Phase 0（旧m-dev直接委譲に一時退行） |
CEO |
| Phase 2 |
DAG Schedulerの不正並行起動、またはデータ破損 |
Phase 1（直列実行に退行） |
VDU + CEO |
| Phase 3 |
承認ゲート簡略化で品質低下が検出 |
Phase 2（元のゲート基準に復帰） |
OA + CEO |
rollback details
退行手順の詳細
Phase 1 → Phase 0 退行
トリガー: パイロットPJで致命的な工程フロー不備（工程の欠落、CEO承認ゲートのバイパス、PJMの暴走等）が3件以上発生した場合。
- 判断者: CEO（IF層経由で報告を受け、退行を決定）
- 退行手順:
- 進行中のパイロットPJを全て停止
- Division CLAUDE.mdを無効化（ディレクトリを退避）
- IF層ルーティングを旧マネージャー体制（m-dev/m-bo/m-legal）に復帰
- 不備の原因分析と対策立案
- 対策完了後、Phase 1を再開
Phase 2 → Phase 1 退行
トリガー: DAG Schedulerが依存関係を無視した並行起動を行った場合、またはworkteeマージでデータ破損（コード消失・不正マージ）が発生した場合。
- 判断者: VDU + CEO
- 退行手順:
- DAG Schedulerを停止し、直列実行モードに切り替え
- 進行中のworktreeを全てマージまたは破棄（CEOの指示に基づく）
- データ破損がある場合、gitログから復元
- 原因分析と対策立案（SAがログを分析）
- 対策完了後、Phase 2を再開
Phase 3 → Phase 2 退行
トリガー: CEO承認ゲートの簡略化（VDU委任）後に、品質低下（本番障害、セキュリティ問題等）が検出された場合。
- 判断者: OA + CEO
- 退行手順:
- VDU委任された承認ゲートを全てCEO承認に復帰
- 品質低下の原因となったPJを特定し、影響範囲を調査
- OAが再発防止策を提案
- 委任基準の見直し後、段階的に再委任
timeline overview
移行タイムライン（概観）
Phase 0：基盤整備（2〜3週間）
IF層内蔵化、worktree対応、CLAUDE.md整備、M層自律ループ安定化。現行システムを壊さずに基盤を整える。
判断ポイント：Phase 0 → 1
自律ループで5件正常完了、SA異常なし3日以上、CEO承認。不合格時は基盤整備を継続。
Phase 1：Division体制導入（3〜4週間）
VDU/PMO/OA/SAのCLAUDE.md作成、PJMテンプレート、パイロットPJ 3件実行。
判断ポイント：Phase 1 → 2
パイロット3件完走、OA監査NG処理成功、CEO承認ゲート正常動作、CEO承認。退行時はPhase 0へ。
Phase 2：DAG並行実行（4〜6週間）
DAGモデル定義、Scheduler実装、worktree並行制御、ダッシュボード可視化。
判断ポイント：Phase 2 → 3
並行PJ 2件同時完了、リソース監視正常、CEO承認。退行時はPhase 1へ。
Phase 3：高度化・最適化（継続的）
承認ゲート最適化、ナレッジ自動適用、リソース予測、OA監査自動化。完了条件なし、継続的改善。退行時はPhase 2へ。
合計期間目安: Phase 0〜2の完了まで約9〜13週間。ただし各Phase間の判断期間は含まない。Phase 3は継続的改善のため終了時点を定めない。