目標分解 (Goal Decomposition)

目標分解

説明

複雑な目標を実行可能なチェックポイントに分解するためのベストプラクティス。

トリガー

• 目標 (goal)
• 計画 (plan)
• 長期 (long-term)
• マルチステップ (multi-step)
• プロジェクト (project)
• 達成 (achieve)
• マイルストーン (milestone)

指示

分解の原則

1. 具体性を抽象に優先 — 各チェックポイントは具体的な成果物または検証可能な結果を生み出すこと。「Xについて考える」は不可。
2. 3～10個のチェックポイント — 少なすぎるとチェックポイントが複雑に、多すぎるとオーバーヘッドが増える。
3. 行動前に調査 — 最初のチェックポイントは常に情報収集とする。
4. 進む前に検証 — 検証ステップは成功基準に含め、独立したチェックポイントにしない。
5. 不確実性を早期に解決 — 不確実またはリスクの高いチェックポイントは早い段階に配置し、失敗のコストを抑える。

成功基準のルール

• 客観的に検証可能であること — 「ファイルがパスXに存在する」「3つのポジションが見つかった」「テストが通る」等。
• 主観的な基準は避ける — 「良い品質」「よく書かれている」は不可。
• 可能な場合は数量を含める — 「少なくとも3つ」「500ワード未満」。

修正すべきタイミング

• 新しい情報が前提を無効にした場合（会社が採用をしていないなど）
• チェックポイントにより計画にステップが不足していることが判明した場合
• ユーザーからのフィードバックで方向性が変わった場合
• 2つ以上のチェックポイントが失敗し、アプローチが間違っている可能性がある場合

アンチパターン

• 5回未満のツール呼び出しで完了するタスクに目標を作成しない。
• 外部のタイミングに依存するチェックポイントを作成しない（「返信を待つ」など） — 代わりに目標を一時停止し、定期的なリマインダーを設定する。
• すべての複雑さを1つのチェックポイントに詰め込まない。50回以上のツール呼び出しが必要なチェックポイントは分割する。

例

良い分解：求人応募

目標：「会社Xに就職する」

1. Xを調査する（文化、技術スタック、最近のニュース） — 基準：サマリーを作成する
2. 空いているポジションを見つける — 基準：3つ以上のポジションをURL付きでリスト化する
3. 履歴書を調整する — 基準：履歴書ファイルを更新し、関連スキルを強調する
4. カバーレターを作成する — 基準：カバーレターファイルを作成し、400ワード未満にする
5. 応募を提出する — 基準：確認画面のスクリーンショットを保存する

良い分解：ポートフォリオウェブサイト

目標：「ポートフォリオウェブサイトを構築してほしい」

1. デザイントレンドを調査し、要件を収集する — 基準：デザインブリーフを作成する
2. プロジェクトをセットアップする（Next.js + デプロイ先） — 基準：プロジェクトがスキャフォールディングされ、開発サーバーが起動する
3. コアページを構築する（ホーム、アバウト、プロジェクト） — 基準：3ページがプレースホルダーコンテンツでレンダリングされる
4. 実際のコンテンツとスタイルを追加する — 基準：すべてのセクションが埋められ、モバイルでレスポンシブである
5. 本番環境にデプロイする — 基準：ライブURLにアクセス可能で、コンソールエラーがない

良い分解：セキュリティ監査

目標：「このコードベースのセキュリティ脆弱性を監査する」

1. 依存関係の既知のCVEをスキャンする — 基準：依存関係レポートを生成する
2. 認証とセッション管理をレビューする — 基準：認証フローを文書化し、問題をリスト化する
3. インジェクション脆弱性（SQL、XSS、コマンド）を確認する — 基準：各入力パスをテストする
4. 重要度評価付きの監査レポートを作成する — 基準：レポートファイルを作成し、調査結果を優先順位付けする

悪い分解

目標：「会社Xに就職する」

1. 調査する（曖昧すぎ、基準がない）
2. 応募する（広範すぎ、複数のステップにすべき）
3. 返信を待つ（外部タイミングに依存）

確認

• このフェーズの成果物は具体的なアーティファクト（ドキュメント、チケット、ボード、リポジトリ）として存在し、その場所が説明ではなく共有されていること
• 各コミットメントには所有者名、期日、および作成者以外の誰かが確認できる完了条件があること
• リスクは可能性/影響と名前付きの緩和策とともにリスト化されており、汎用的な「リスク：TBD」の箇条書きではないこと
• 他のチーム/ベンダー/エージェントへの依存関係は明示されており、各依存関係からの確認が記録されるか「保留中」とマークされていること
• 次のフェーズの成功基準は数値的またはその他の方法で客観的にテスト可能であること
• 作業開始前に、ロールバック/キルスイッチ/「Xが発生したら停止する」という基準が文書化されていること

備考

• 目標を作成する前に、goals/SKILL.md が関連しているかどうかを常に確認すること
• 目標システムは、永続化、コンテキスト、自動継続を自動的に処理する
• goal_status を使用していつでも進捗を確認できること