Skip to content

VDD.md

Latest commit

 

History

History
178 lines (121 loc) · 7.11 KB

VDD.md

File metadata and controls

178 lines (121 loc) · 7.11 KB

VDD（Vision-Driven Development）

概要

VDD は、日々の意思決定からビジョンを継続的に更新し、そのビジョンを入力として自律開発を回す方法論である。「何を目指すか」を常に明確にし、AI の自律実装がビジョンから逸脱しないようにする。

基本方針

  1. 自然言語中心で運用する: 過度なスキーマ化は避け、人間が読み書きしやすい形式を使う
  2. 「置き場所」を固定する: 解釈ブレを減らすために、各アーティファクトの保管場所を明確にする
  3. 過度なスキーマ化は避ける: 必要最小限の構造のみ定義する

主要アーティファクト

VDD は3つのアーティファクトで構成される。各アーティファクトは固定の場所に配置する。

Vision 正本

プロジェクトの方向性を示すドキュメント。以下を含む:

  • 現在の方向性
  • 重視する価値
  • 今はやらないこと
  • 品質バー

配置例: vdd/VISION.md または .claude/vdd/VISION.md

意思決定台帳

会議での意思決定を履歴として記録する。

  • 1行1意思決定
  • 理由（context）・影響・優先度・根拠を必須で記録
  • decision_id を付与（例: D-20260207-01、日次リセット連番）

配置例: vdd/DECISIONS.md

日次主観スコア

当日の主観スコア（1-5）を記録する。

  • 「良いものを早くリリースできた実感」をコメントで補足
  • Vision 正本や意思決定台帳とは分離して管理（肥大化防止）

配置例: vdd/DAILY_SCORE.md

運用ループ

1. 前回の学びを確認する
   ↓
2. 意思決定の場（フィードバック会 / レビュー会）
   ↓
3. 決定を台帳へ反映
   ↓
4. Vision 正本を更新（変更がある場合）
   ↓
5. 日次主観スコアを記録
   ↓
6. リリース仕様へ反映
   ↓
7. RDD で実装・レビュー・QA
   ↓
8. VDD 運用の振り返り（学びの蓄積）

学びの循環

  • フィードバック会の冒頭で、前回の学びと意思決定を確認する
  • 前回の指摘が今回のリリースにどう反映されたかを検証する
  • これにより、学びが実際の行動変化に繋がっているかを可視化する

学びの蓄積（VDD-learnings）

VDD プロセス自体の改善のために、運用の中で得た学びを process/VDD-learnings.md に蓄積する。これは主要アーティファクト（Vision / Decisions / Daily Score）とは異なり、運用ループの補助ドキュメントとして位置づける。

  • 役割: VDD.md を更新する前のバッファ。学びを蓄積し、VDD.md への反映が必要か判断する材料にする
  • 記録タイミング: 運用ループのステップ 8（VDD 運用の振り返り）で記録する
  • 確認タイミング: 運用ループのステップ 1（前回の学びを確認する）で確認する
  • 推奨フォーマット: 「文脈 / 何が起きたか / なぜそうなったか / 次にどうすべきか」の4項目（強制ではない）
  • VDD.md への反映: フィードバック会で蓄積された学びを確認し、反映が必要か判断する

運用ルール

会議運用

  • 定期的な固定会議（頻度はプロジェクトに応じて設定）
  • 会議内の時間配分は固定しない（都度最適化）

役割分担

  • AI: 会議アジェンダと意思決定候補を提案する
  • 人間: 候補ごとに承認判定を行う（最終決定者）

承認フォーマット

承認 意味
approve 承認。実装着手可能
reject 却下。実装不可
conditional 条件付き承認。条件が満たされるまで実装着手不可
  • conditional の条件は自由文で記述する
  • 条件達成は運用で判断する

アーティファクト更新ルール

  • Vision 正本: 毎日更新は必須ではない。方向性・価値・品質バーに変更があった場合に更新する
  • 意思決定台帳: 会議で扱った意思決定を記録する。根拠と文脈を必須とする
  • 日次主観スコア: 日次で主観スコアを記録する（1-5）

意思決定の矛盾処理

  • 新しい意思決定が過去の決定と矛盾する場合は、supersedes で置換元の decision_id を明示する
  • 置換された決定は status: superseded とする

ステータス管理

ステータス 意味
active 有効な決定
dropped 撤回された決定
superseded 新しい決定で置き換えられた決定

リリース仕様書連携

  • リリース仕様書の作成タイミングは厳密な閾値で固定しない
  • AI が提案し、人間が承認したタイミングで作成する
  • リリースブランチのマージ前に、以下8項目を必須チェックとして通す:
チェック項目 確認内容
Vision 整合 ビジョンの方向性と矛盾しないか
Decision 整合 既存の意思決定と整合するか
conditional 解消 条件付き承認の条件が満たされたか
主要導線非破壊 アプリの主要なユーザーフローが壊れていないか
リスク明示 リスク要因が明記されているか
ロールバック可能 問題時に巻き戻せるか
レビュー通過 AI レビューを通過しているか
スコープ逸脱なし 仕様書の範囲外の変更がないか

ディベートパートナー

リリース仕様書の作成後、外部の AI とディベート的な対話を行い、ビジョン整合を検証する。詳細は debate-partner.md を参照。

意思決定権限マトリクス

「誰が何を決めていいか」を明示する。詳細は decision-authority-matrix.md を参照。

ガードレール

以下の状況では、AI は自律実装を停止して人間に確認する:

  • Vision と矛盾する実装方針
  • 根拠が追跡できない決定
  • 複数解釈が成立する場合
  • 本番不具合リスクが高い場合
  • ユーザー影響が極めて大きい変更
  • ロールバック困難な変更
  • Vision 整合に疑義がある場合

成功判定

  • 日次で主観スコアを記録する（1-5）
  • 評価軸は「良いものを早くリリースできた実感」
  • 数値化困難な主観を、記録の蓄積によって傾向として可視化する

ブランチ戦略

VDD の自律開発サイクルを安全に運用するためのブランチ戦略については branch-strategy.md を参照。

QA の3層モデル

品質保証の仕組みについては qa-layers.md を参照。

RDD との関係

VDD は「何を目指すか」を更新する層、RDD は「どう届けるか」を実行する層。両者を分離することで、戦略の更新と実装の安定性を両立する。詳細は RDD.md を参照。