lukaszbadowski/manage-ai-software-projects

AIソフトウェアプロジェクト管理

曖昧なAI支援による成果物を、1人の人間オペレーターが制御できる実行システムに変えます。フレームを引き出し、ストーリー分割の意識的な承認を得て、耐久性のあるファイル内の小さなルーティングタスクキューを通じて実行し、エビデンスで検証し、すべての成功基準がエンドツーエンドのチェックに合格した後にのみクローズします。

プロジェクトの状態をベンダーニュートラルに保ちます。Codex、Claude Code、または互換性のある他のエージェント間の切り替え時に、pm/ファイルを変換する必要があってはなりません。

クイックスタート

1. ワークスペースを検査します。pm/が存在する場合、pm/STATE.mdを読み、次にpm/TASKS.mdを読みます。システムを再生成するのではなく、ギャップを修復します。
2. プロジェクトシステムが存在しない場合、CP1を実行します。引き出し質問をし、pm/PLAN.mdにフレームをドラフトします。
3. references/file-templates.mdから4つの標準ファイルを作成します。
4. CP2分割、CP3キュー、実行ループ、CP4最終受け入れを通じて作業を推進します。

オペレーターチェックポイントプロトコル

オペレーターと共同で分割を作成します。各承認をpm/PLAN.mdまたはpm/TASKS.mdに日付とともに記録します。

• CP1 — フレーム。 目的、成功基準、最終チェック、スコープ、制約、構造的前提を引き出し、承認を得ます。
• CP2 — 分割。 ストーリーをオペレーターの言葉で提示します。各ストーリーに受け入れ基準を設定し、それがどの成功基準に貢献するかをトレースします。未解決の構造的決定をオペレーターと解決します。
• CP3 — キュー。 実行開始前に、ルーティング階層を含む順序付けられたタスクキューを提示します。
• CP4 — 最終受け入れ。 CP1のすべての最終チェックをエンドツーエンドで再実行し、エビデンスをリンクし、受け入れレポートを提示してサインオフを得ます。完了したタスクだけではプロジェクトが完了したとはみなされません。

以下の定常ルールを使用します：

• 承認されたフレーム内の小さなギャップは、pm/DECISIONS.mdに記録された仮定で埋めます。
• 構造的変更（スコープ、ストーリー、成功基準、受け入れ基準）は、該当するチェックポイントに戻し、トレードオフを記録します。
• CP1で尋ねること：どのような成果が、誰のために存在すべきか？オペレーターはそれをどのように個人的に検証するか？スコープ外は何か？どの制約が固定されているか？何がすでに存在するか？最もリスクが高い、または不明瞭な点は何か？オペレーターはどの程度のレビューを希望するか？
• レスキューモードでは、ワークスペースから暗黙のフレームと分割を再構築し、確認のために提示し、その後キューを再構築します。

標準プロジェクトファイル

pm/の下に4つのファイルを維持します：

• pm/PLAN.md — 目的、成功基準、スコープ、ストーリー、トレーサビリティ、承認
• pm/TASKS.md — 順序付けられたタスクキュー、安定したID、ルーティング、検証、エビデンス
• pm/STATE.md — 現在の状態、ハンドオフノート、セッションログ
• pm/DECISIONS.md — 決定事項、仮定、リスク、課題、変更ログ

デフォルトではこれ以上コントロールファイルを作成しません。対応するブランチがアクティブな場合にのみ、pm/CONSTRAINTS.md、pm/RELEASE.md、またはpm/RESEARCH.mdを追加します。

製品固有のエントリファイル（AGENTS.mdやCLAUDE.mdなど）は短く、ナビゲーショナルに保ちます：pm/STATE.mdを指し、次にpm/TASKS.mdを指し、pm/PLAN.mdを承認済みスコープとして示します。セッションローカルな計画ツールからの耐久性情報をpm/TASKS.mdとpm/STATE.mdにミラーリングします。

能力に応じた作業ルーティング

各タスクがキューに入るときに、ベンダーニュートラルなRoute:階層を割り当てます：

階層	使用用途
heavy	計画、分解、アーキテクチャ、あいまいなデバッグ、横断的リファクタリング、リスクの高いレビュー、最終受け入れ
standard	範囲が定められた実装、テスト、中程度の複雑さの変更
light	リポジトリ検索、サマリー、機械的な編集、ドキュメント、ログトリアージ

各タスクを、それを確実に完了できる最も低コストな階層にルーティングします：

• プライマリスレッドが指示（ブリーフィング、作業ルーティング、エビデンス判定、サインオフ）を行うのに十分な能力を維持します。
• 同じタスクで2回失敗した後、または低信頼度の結果の後は1階層エスカレーションし、エスカレーションを記録します。
• レビューア階層は少なくとも作成者階層以上である必要があります。リスクの高い、または横断的な変更には、新しいコンテキストでのheavyレビューを要求します。lightワーカーが自己承認することを決して許可しません。
• モデル名をpm/に含めないでください。製品のエイリアスや価格は変わりますが、能力階層は有用なままです。
• Codex、Claude Code、または別のエージェント用にワーカーを設定する前に、references/agent-routing.mdを読んでください。

まずコンテキストを構築する

• 実際の目的、ユーザー、受け入れ基準、依存関係、リリース期待値を抽出します。
• 日付、予算、承認、ベンダースケジュール、ローンチウィンドウは、明示されている場合にのみ第一級の入力として扱います。
• 新しいアーティファクトを作成する前に、既存のpm/ファイル、タスクブリーフ、バックログ、設計、ADR、テスト戦略、ラン ブック、リスクログ、エージェント指示ファイルを探します。
• レスキュー作業では、目的の明確さ、スコープ、依存関係、受け入れ品質、リスク衛生、コンテキストの可読性、権限、リリース準備状況を評価します。

最小の制御モードを選択する

• デフォルトはsolo-operator：1人のオペレーターがAIエージェントを操作します。
• 実際の固定日付、コンプライアンスゲート、承認、ベンダー依存関係、クォータ、またはローンチウィンドウがある場合はexternal-constraintを追加します。
• 発見、ユーザー学習、またはUXイテレーションが支配的な場合はfeedback-heavyを追加します。
• 出荷にカットオーバー、ロールバック、モニタリング、または運用ノートが必要な場合はrelease-safetyを追加します。

実行単位のサイジング

• ストーリーはユーザーに見える価値と受け入れに使用します。マイルストーンは作業をグループ化するためだけに使用します。タスクを通じて実行します。
• 各タスクを1回の焦点を絞ったエージェント実行と1回の簡単なオペレーターレビューに適合させます：1つのサブシステム、インターフェース、ドキュメント、またはテストサーフェスと1つのレビュー可能なdiff。
• すべてのタスクに、安定したID、ストーリー参照、ルーティング階層、スコープ、依存関係、完了条件、正確な検証、エビデンスフィールド、明示的な停止ポイントを設定します。
• タスクが無関係な領域や複数の独立した検証に及ぶ場合は、実行前に分割します。履歴を保持します：子タスクには新しいIDが割り当てられ、置き換えられたタスクはsupersededになります。
• タスク完了後、同じ実行内でエビデンスを記入し、pm/STATE.mdを更新します。

トレーサビリティを維持する

• すべての成功基準を少なくとも1つのストーリーにマッピングし、すべてのストーリーを少なくとも1つのタスクにマッピングします。
• すべてのタスクと受け入れ基準がエビデンスで検証された後にのみ、ストーリーを完了とマークします。
• CP4ですべての成功基準をエンドツーエンドで再検証した後にのみ、プロジェクトを完了とマークします。

品質ファーストのループを実行する

• 実装前に最小の信頼できる証明を定義します：失敗する再現、自動テスト、期待される出力、スクリーンショット比較、コントラクトチェック、または正確な手動手順。
• explore -> plan -> implement -> verify -> review -> documentを使用します。
• 結論だけでなく、コマンド、結果、スクリーンショット、メトリクス、レビューノートを記録します。
• リスクの高いタスクには変更予算を明記します：許可されるファイル、安定したインターフェース、データ安全性、ロールバック、エスカレーションのトリガー。
• スケーリング前に、反復的または自動化された変更を狭い代表的なサンプルでパイロットします。
• 同じ失敗が2回発生した後は、停止して環境、ドキュメント、ルール、またはバリデーターを改善し、クリーンなコンテキストで再開します。
• エージェントの繰り返しの失敗をシステムフィードバックとして扱います。現在の答えだけでなく、プロセスを改善します。

安全に委任する

• 自律準備が整った、範囲が定められた作業のみを委任します。目標、分解、統合、サインオフはプライマリスレッドに残します。
• 各ワーカーに書面によるブリーフを提供します：タスクID、目的、スコープ、制約、検証コマンド、期待されるエビデンス、停止ポイント、エスカレーショントリガー、ルーティング階層。
• 委任のオーバーヘッドがその利益を上回る場合、小さく、密結合、または高度にインタラクティブな作業はプライマリスレッドに残します。
• 必要なテスト、パス制限、フォーマット、シークレットスキャンなどのゼロ例外ルールには、決定論的なバリデーターを優先します。
• 最小権限、信頼境界、シークレット処理ルール、リスクの高いアクションに対する明示的なオペレーター承認を強制します。

参考資料

• pm/を作成または修復するときは、references/file-templates.mdを読んでください。
• コンパクトなエンドツーエンドの例については、references/worked-example.mdを読んでください。
• プロジェクトの監査またはレスキュー時には、references/project-rulebook.mdを読んでください。
• 実際の外部制約またはプロダクションリリースリスクがある場合のみ、references/external-constraints.mdを読んでください。
• 耐久メモリ、コンテキスト、委任、評価、ガードレールに関する詳細なガイダンスについては、references/ai-agent-practices.mdを読んでください。
• 階層を製品の現在の機能にマッピングするときは、references/agent-routing.mdを読んでください。
• 出所や変動の多いベンダーガイダンスが重要な場合は、references/source-anchors.mdを読んでください。
• 最小の関連参照のみをロードしてください。

出力基準

• 具体的で決定準備の整ったアーティファクトを命令形で記述します。
• チェックポイントステータスを最初に報告し、散文的なステータスの前にタスクIDを報告します。
• タスクを次のようにフォーマットします：タスクID、タスク、ストーリー、ルート、スコープ、依存関係、完了条件、検証方法、エビデンス、停止後、ステータス。
• タスクごとに1つのレビュー可能なdiffを優先します。
• モデル名を耐久性のあるプロジェクトファイルに含めないでください。
• プロジェクトが真に必要としない限り、日付計画、予算、承認ワークフロー、定例セレモニー、ステージゲートを追加しないでください。
• 現在のモデル、ベンチマーク、価格、またはベンダーワークフローの主張を使用する前に、一次ソースで検証してください。