Status: Stable Review cadence: Monthly Owner: Product / Maintainer
このドキュメントは、PlanGate を PM / PO に説明するための elevator pitch、メッセージング、見直し観点をまとめる。
PlanGate は AI コーディングエージェントを「速くコードを書く道具」としてだけ扱うのではなく、PBI、計画、受入条件、承認、検証、handoff を通じて、プロダクト価値に接続された開発プロセスへ組み込むためのゲート型ハーネスである。
PlanGate は、AI が速くコードを書く時代に、PM / PO が守るべき 「何を作るか」「なぜ作るか」「Done とは何か」 を失わないためのゲート型ハーネスである。
AI は実装前に計画と受入条件を出し、人間が承認してからコードを書く。実装後は検証と handoff を残す。
PlanGate は、AI が勝手にコードを書く前に、PBI・計画・受入条件・承認を必ず通すための AI 開発ゲートである。
PM / PO にとっては、AI 開発を速くするだけでなく、何を作るか、なぜ作るか、Done とは何かを守るための仕組みである。
AI コーディングエージェントは速い一方で、スコープ逸脱、受入条件の曖昧化、レビュー不能な実装が起きやすい。
PlanGate は、AI が実装に入る前に PBI、計画、TODO、テストケースを作らせ、人間が C-3 で承認するまで本番コードを書かせない。
つまり、PM / PO が持つ「価値・優先順位・受入条件への責任」を、AI 開発の中でも崩さないためのガードレールである。
PM / PO にとって一番怖い AI 開発は、「速く作ったけれど、そもそも求めていた価値と違うものができる」ことである。
AI エージェントは実装速度を上げる。しかし、そのまま使うと、PBI の意図、受入条件、スコープ、レビュー観点が曖昧なままコードが進む。
PlanGate はそこにゲートを置く。
AI はまず PBI を読み、計画、TODO、テストケースを作る。人間が C-3 で承認するまでコードを書けない。実装後は検証、レビュー、handoff まで残す。
これにより、AI 開発を「速いけど危ないもの」から、「計画・承認・検証・監査があるプロダクトデリバリー」に変える。
PM / PO にとっての PlanGate は、AI 時代の Backlog Governance である。
PM に対しては、プロダクトリスクと成果管理で説明する。
PlanGate は、AI 開発の成果を PM が管理可能な形に戻す仕組みである。
AI がいきなり実装するのではなく、まず「何を作るか」「なぜ作るか」「どう検証するか」を成果物として残す。
これにより、AI 開発でもロードマップ、スコープ、リリース判断、リスク管理が崩れない。
| 観点 | 説明 |
|---|---|
| スコープ逸脱を防ぐ | AI が PBI 外の実装へ広げることを抑える |
| リリース判断の証跡が残る | plan、test-cases、verification、handoff が残る |
| AI 作業がブラックボックス化しない | 何を根拠に進めたかを追跡できる |
| PR 前に説明可能になる | 実装内容と受入条件の対応を確認できる |
| チーム横断で標準化できる | 同じ Gate / Artifact / Review flow を使える |
PO に対しては、価値、PBI、受入条件、Done の定義で説明する。
PlanGate は、PO が定義した PBI と受入条件を、AI 開発の最後まで守らせる仕組みである。
AI は便利だが、受入条件が曖昧なまま実装すると、Done の意味が崩れる。
PlanGate では、AI が実装する前に plan と test-cases を作り、人間が承認してから進めるため、PO は「この PBI は何を満たせば完了か」をコントロールできる。
| 観点 | 説明 |
|---|---|
| PBI の意図を守る | 実装前に PBI の理解を plan として外化する |
| 受入条件を固定する | test-cases を実装前に作り、Done の条件を曖昧にしない |
| Done の定義を崩さない | 検証証拠なしに完了扱いしない |
| 変更理由が残る | plan、review、handoff に判断過程が残る |
| Backlog の透明性を保つ | AI の作業が PBI 単位で追跡できる |
| 方向性 | タグライン |
|---|---|
| 一番わかりやすい | AI がコードを書く前に、計画と受入条件を通す |
| PO 向け | AI 時代の Backlog Governance |
| PM 向け | AI 開発を、管理可能なプロダクトデリバリーにする |
| エンジニア組織向け | No approved plan, no code |
| 経営向け | AI 開発の速度に、承認・検証・監査を組み込む |
| OSS 向け | Governance-first workflow harness for AI coding agents |
このピッチは、PlanGate の実装状況、利用者の反応、ロードマップ進捗に応じて定期的に見直す。
月 1 回、ロードマップ進捗とあわせて見直す。
| 観点 | 確認すること |
|---|---|
| PM に伝わるか | 管理可能性、リスク、リリース判断への価値が明確か |
| PO に伝わるか | PBI、受入条件、Done、Backlog Governance への価値が明確か |
| 実装状況とズレていないか | 現在の PlanGate の機能を誇張していないか |
| ロードマップと整合しているか | Harness Improvement Roadmap の進捗を反映しているか |
| OSS 向けに使えるか | GitHub / README / pages で初見ユーザーに伝わるか |
| タグラインが強いか | 1文で価値が伝わるか |
| 言葉が重すぎないか | PM / PO が日常会話で使える表現になっているか |
PlanGate は、AI が速くコードを書く時代に、PM / PO が守るべき「何を作るか」「なぜ作るか」「Done とは何か」を失わないためのゲート型ハーネスである。