Goal Ownership

定義

Goal Ownership

Goal Ownership とは、ある Actor が、ある Process Frame において、
その frame が何を達成しようとしているのかを定義し、維持し、必要に応じて再解釈し、最終的に受理または未達と判断する責任 である。

それは単なる「要求を知っていること」ではなく、
goal、success criteria、scope boundary、priority among constraints、reframe authority、completion acceptance、goal-level escalation sink を含む。

より短く言えば、Goal Ownership とは
「この仕事は何を達成すべきで、何を達成したときに終わったとみなすのか」を引き受ける責任
である。

PCE 2.0 において process は Process Frame として立ち上がる。
しかし frame に goal フィールドがあるだけでは process は動かない。
その goal を

• 誰が持つのか
• 誰が曖昧さを解くのか
• 誰が優先順位を決めるのか
• 誰が「もう十分に達成した」と認めるのか

が必要になる。
それを引き受けるのが Goal Ownership である。

この意味で Goal Ownership は、
Responsibility-first を、process の起点側から具体化した責任である。

---

なぜ Goal Ownership が必要なのか

PCE 2.0 が Goal Ownership を独立の責任として置くのは、
goal が存在していることと、goal が保持されていることは別だからである。

少なくとも、次の問題がある。

1. goal は放置すると曖昧化する

長時間・多段・多主体の process では、

• 途中で local optimization が始まる
• actor ごとに違う解釈が生まれる
• いつの間にか別の仕事に変質する
• acceptance criteria が implicit なまま進む

ことが起こりやすい。

2. execution と goal definition は違う

作業している actor が、常に goal を定義してよいわけではない。
実装者が便利だからという理由で勝手に scope を広げると、process はすぐに壊れる。

3. approval と goal ownership は違う

approver は特定 subject を ratify できても、
その frame 全体の goal を定義・変更・閉じる権限までは持たないことがある。

4. incident が起きたとき、goal の優先順位を再判断する必要がある

失敗や曖昧性が起きたとき、

• scope を縮めるのか
• quality を優先するのか
• deadline を優先するのか
• frame を abandon するのか

を決める必要がある。
これは execution ではなく goal-level の責任である。

5. 「done」の意味を誰かが保持しなければならない

feature delivery で最も壊れやすいのは、
「とりあえず動くから done」
「CI が通ったから done」
「時間切れだから done」
が混ざることだ。

PCE 2.0 では、done は outcome の見た目だけでは決まらない。
goal owner が success criteria と照らして accept する必要がある。

だから Goal Ownership は、
process の最初に goal を書くためだけの責任ではなく、
process 全体を通じて goal の同一性を保持する責任
である。

---

Goal Ownership は何ではないか

輪郭をはっきりさせるために、まず何ではないかを書いておく。

1. 単なる「要求を知っていること」ではない

要求文書を読めるだけでは goal owner ではない。
goal をどう解釈し、どこで止め、どの trade-off を受け入れるかを引き受ける必要がある。

2. 単なる product role ではない

実務上、product owner や PM が goal owner になることは多い。
しかし PCE 2.0 において Goal Ownership は role 名ではなく、frame に対する責任である。

3. 単なる execution ではない

作業を進めることと、goal を保持することは別である。
coding agent が execution を担っていても、goal ownership を持たないことは普通にある。

4. 単なる approval ではない

approval authority は、特定 subject に対する ratification の権限である。
goal ownership は、それより広く、frame 全体の方向と終端条件を持つ。

5. 単なる incident ownership ではない

incident owner は failure や逸脱を引き受ける。
goal owner は goal の妥当性・優先順位・完了判定を引き受ける。
同じ actor であることは多いが、概念としては別である。

6. 単なる requirement authoring ではない

最初に requirement を書いたからといって、そのまま goal owner になるわけではない。
goal ownership は process を通じて継続する責任である。

---

Goal Ownership が含む責任

Goal Ownership は一枚岩ではない。
PCE 2.0 では、少なくとも次の責務を含むと考える。

1. Goal Definition

その frame が何を達成するためのものかを定める。
ここでいう goal は、単なる作業名ではなく、達成対象の意味である。

2. Success Criteria Binding

何をもって「達成した」とみなすかを定める。
goal owner は、goal と success criteria を結びつける責任を持つ。

3. Scope Guardianship

何が in-scope で何が out-of-scope かを守る。
scope drift が起きたときに、それを認めるのか戻すのかを決める。

4. Priority and Trade-off Resolution

複数の制約が衝突したときに優先順位を決める。

例:

• speed vs quality
• completeness vs scope containment
• local optimization vs architectural consistency
• short-term workaround vs long-term cleanliness

5. Reframe Authority

必要なら frame 自体の意味を修正する。
goal、scope、success criteria を変えることは強い操作であり、goal ownership の中核に属する。

6. Completion Acceptance

この frame を completed として閉じてよいかを判断する。
これは artifact が一つできたことではなく、frame 全体として十分かどうかの判断である。

7. Goal-level Escalation Sink

局所 actor が自力で goal ambiguity を解けないときの引受先になる。
つまり goal owner は、最終的な goal interpretation の受け皿でもある。

---

Goal と Goal Ownership の違い

これは単純だが重要である。

Goal

frame が達成しようとする対象そのもの

Goal Ownership

その goal を定義・維持・再解釈・受理する責任

つまり、

• goal は object
• goal ownership は relation / responsibility

である。

同様に、

• success_criteria は条件
• goal owner はそれを結びつけて保持する責任主体

である。

---

Goal Ownership と Goal Slice の関係

大きな frame では、goal はそのままでは大きすぎる。
そこで PCE 2.0 では、goal はしばしば goal slice に分かれる。

Goal Slice

親 frame の goal のうち、ある child frame や actor が局所的に担う断面

ここで重要なのは、goal slice を渡すことと、global goal ownership を全面移譲することは別だという点である。

典型パターン

1. 親が global goal ownership を保持し、子に local goal slice を渡す

最も一般的な形。
子はその slice に対して局所的な stewardship を持つが、親の goal を勝手に広げたり書き換えたりできない。

2. 子に local goal stewardship を与える

child frame や specialized actor が、自分の slice 内で goal clarification を行える。
ただし global success criteria や out-of-scope は親に従う。

3. 明示的な goal ownership transfer

フレームを事実上委譲し、goal owner 自体を別 actor に移す。
これはありうるが、PCE 2.0 では強い transition として扱うべきで、暗黙に起こしてはならない。

---

Goal Ownership と他の責任の違い

Goal Ownership vs Execution

• Goal Ownership: 何を達成すべきかを保持する
• Execution: 実際に作業を進める

execution actor は goal owner の解釈に従って work するが、
勝手に goal を変更してはならない。

Goal Ownership vs Approval

• Goal Ownership: frame 全体の目標と完了条件を持つ
• Approval: 特定 subject を ratify する

approver は code patch を approve できても、
「この frame は目的達成済みだ」と言う authority を持たないことがある。

Goal Ownership vs Evaluation

• Goal Ownership: 何を達成したいかを保持する
• Evaluation: 何が criteria を満たしたかを判断する

goal owner が evaluator であることはありえるが、概念上は別である。
goal owner は success criteria を定め、evaluator は適合性を測る。

Goal Ownership vs Memory Writing

• Goal Ownership: この仕事が何を達成すべきかを保持する
• Memory Writing: 何を durable state に残してよいかを決める

feature delivery の goal owner が、必ずしも memory writer である必要はない。

Goal Ownership vs Incident Ownership

• Goal Ownership: goal / scope / completion の責任
• Incident Ownership: failure / violation / ambiguity の最終引受責任

両者は重なることが多いが、片方だけ持つ設計も可能である。

---

Goal Ownership と actor symmetry / responsibility asymmetry

PCE 2.0 は actor の分析上の対称性を認める。
しかし Goal Ownership は、そのまま対称には配られない。

原理的にはどうか

理論上、goal ownership を非人間 actor に割り当てることを完全に禁じる必要はない。
PCE 2.0 は ontology 上、actor を human-only にはしない。

実務上どうか

ただし、full goal ownership には通常次が伴う。

• reframe authority
• trade-off legitimacy
• completion acceptance
• often incident adjacency
• organizational accountability

このため、実務上は

• 人間 actor
• governance-backed organizational actor
• 明示的 authority を持つ control actor

に保持されることが多い。

よくある形

AI actor が持つのは、しばしば full goal ownership ではなく

• local goal stewardship
• goal interpretation proposal
• plan proposal
• ambiguity surfacing

である。

つまり PCE 2.0 は、

• actorhood の対称性を維持しつつ
• goal ownership の配分は非対称に保つ

という立場を取る。

---

Goal Ownership のトポロジ

goal owner は常に一人とは限らない。
しかし複数にするなら topology を明示しないと危険である。

1. Single Goal Owner

もっとも単純で強い形。
最終的な goal interpretation と completion acceptance は一人に集約される。

2. Primary + Consulted

主 goal owner がいて、別 actor が consultation を受ける。
たとえば domain owner の意見を聞くが、最終決定は product owner が持つ。

3. Split by Goal Slice

親 frame の異なる slice を別 owner が持つ。
ただし overlap 部分の conflict resolution rule が必要である。

4. Quorum / Joint Ownership

複数 actor の合意でしか goal-level decisions ができない形。
高リスク変更ではありうるが、遅くなりやすいので明示的に使うべきである。

PCE 2.0 では、goal owner を複数にする場合、少なくとも

• primary owner
• conflict resolution path
• escalation sink

を決めるべきである。

---

Goal Ownership の主要操作

goal ownership は static ではない。
process の中で、少なくとも次の操作が起こりうる。

Assign

新しい frame に対して、ある actor に goal ownership を割り当てる。

Clarify

曖昧な goal を、scope と success criteria の両面で明確化する。

Slice

子 frame や actor 用に goal slice を切り出す。

Delegate (Stewardship)

local goal stewardship を別 actor に委ねる。
ただし global ownership は retain されることが多い。

Transfer

goal ownership 自体を別 actor に移す。
これは強い変化なので、明示的で traceable でなければならない。

Reframe

goal / scope / success criteria を再定義する。
replan と密接に結びつく。

Accept Completion

この frame を成功として閉じる。

Declare Abandonment / Non-completion

この frame を未達のまま close する、あるいは別 frame に吸収する。

このうち reframe と accept completion は、goal ownership の核であり、
execution actor が暗黙に行ってはならない。

---

Goal Ownership と parent / child process の関係

feature delivery のような大きい frame では、parent と child で goal ownership の扱いが重要になる。

Parent frame

通常、global goal ownership を保持する。

Child frame

多くの場合、局所的な goal slice に対する stewardship を持つ。

原則

1. 子は親の goal を silent に書き換えてはならない
2. 子は local ambiguity を処理できる範囲だけ持つ
3. parent-close の可否は親 goal owner が持つ
4. child return handoff では、goal-relevant unresolved issues を返すべきである

この構造があることで、長い仕事でも goal の同一性が保たれる。

---

Goal Ownership と close の関係

PCE 2.0 において close は単なる state update ではない。
それは「この frame は goal に照らして十分か」という判断を含む。

したがって通常は、少なくとも次のどちらかが必要である。

• goal owner による explicit acceptance
• frame 定義に埋め込まれた explicit close rule

後者の例としては、

• low-risk auto-close
• pre-authorized criteria completion

がありうる。
しかしその場合でも、goal ownership が最初にその auto-close rule を認めている必要がある。

つまり close は、goal ownership と切り離せない。

---

Goal Ownership の最小スキーマ

PCE 2.0 における最小スキーマは、次のように置ける。

goal_ownership:
  actor_ref:
  frame_id:
  ownership_level:
    # global | local_slice
  goal_scope:
  success_criteria_binding:
  authority:
    define_goal: true | false
    clarify_goal: true | false
    reprioritize_constraints: true | false
    authorize_reframe: true | false
    accept_completion: true | false
    declare_abandonment: true | false
  retained_by_parent: true | false
  escalation_target:
  transfer_policy:
  validity:
    active_when:
    expires_when:
  provenance:

より allocation 寄りに書くなら、frame 側には次のように持てる。

goal_ownership_allocation:
  frame_id:
  global_owner:
    actor_ref:
    authority_scope:
  local_stewards:
    - actor_ref:
      goal_slice:
      limits:
  conflict_resolution:
  escalation_sink:
  provenance:

このスキーマで重要なのは、次の点である。

1. global と local slice を区別する
2. authority の中身を明示する
3. retained / delegated / transferred を区別する
4. conflict resolution と escalation sink を持てる

---

小さな例

feature.checkout.coupon-combination frame での goal ownership は、たとえば次のように書ける。

goal_ownership:
  actor_ref: product_owner
  frame_id: feature.checkout.coupon-combination
  ownership_level: global
  goal_scope: >
    checkout にクーポン併用制約を導入し、
    既存の pricing / validation flow を損なわずに運用可能な形へ反映する
  success_criteria_binding:
    - spec_approved
    - code_change_merged
    - required_regression_suite_passed
    - rollback_path_recorded
  authority:
    define_goal: true
    clarify_goal: true
    reprioritize_constraints: true
    authorize_reframe: true
    accept_completion: true
    declare_abandonment: true
  retained_by_parent: false
  escalation_target: release_owner
  transfer_policy:
    full_transfer_requires: explicit_reframe_and_trace
  validity:
    active_when: frame_instantiated
    expires_when: frame_closed
  provenance:
    defined_by: release.checkout.spring-2026

一方で、spec-analysis child frame では analyst agent に次のような local stewardship を与えられる。

goal_ownership:
  actor_ref: analyst_agent
  frame_id: feature.checkout.coupon-combination.spec-analysis
  ownership_level: local_slice
  goal_scope: >
    仕様案を整理し、影響範囲と未解決論点を parent frame に返す
  success_criteria_binding:
    - spec_summary_returned
    - unresolved_issues_identified
    - scope_conflicts_marked
  authority:
    define_goal: false
    clarify_goal: true
    reprioritize_constraints: false
    authorize_reframe: false
    accept_completion: false
    declare_abandonment: false
  retained_by_parent: true
  escalation_target: product_owner
  transfer_policy:
    local_goal_redefinition_requires: escalation
  validity:
    active_when: child_frame_started
    expires_when: child_frame_returned
  provenance:
    delegated_by: product_owner

この例で重要なのは、analyst agent がただの executor ではなく、
局所 goal clarification を行える一方で、global goal を勝手に書き換えられないことだ。

---

Goal Ownership の不変条件

PCE 2.0 では、少なくとも次の不変条件を置く。

1. Every frame has at least one goal owner

goal owner のいない frame は不完全である。
goal が書いてあっても、それを保持する責任がなければ process は drift しやすい。

2. Goal ownership must bind goal to success criteria

goal と success criteria が切り離されていてはならない。
goal owner は両者の結びつきを保持する必要がある。

3. Execution does not imply goal ownership

execution actor が goal を silent に書き換えてはならない。

4. Approval does not imply goal ownership

approver が subject を ratify できても、frame 全体を close できるとは限らない。

5. Child stewardship does not imply parent redefinition

child frame や specialized actor が local goal を扱えても、親 goal を拡張・変更してはならない。

6. Goal ambiguity must have an escalation sink

goal interpretation で詰まったときに誰へ返すかが必要である。

7. Transfer of goal ownership must be explicit and traceable

goal owner の交代は、暗黙に起こしてはならない。

8. Completion acceptance must be attributable

「done」と判断したなら、どの goal owner またはどの明示ルールに基づくのか追跡できなければならない。

---

いつ Goal Ownership を分けるべきか

次の条件があるなら、単一 owner ではなく split や local stewardship を考える意味がある。

1. Parent と child で意味の異なる success criteria があるとき

child frame に局所達成条件があるが、親の global goal とは別の粒度で管理すべき場合。

2. Goal の domain が複数に跨るとき

たとえば product / security / compliance が独立の観点を持つ場合。
ただし split するなら conflict resolution が必須である。

3. Goal clarification を specialized actor に任せたいとき

analyst agent や domain specialist に local stewardship を与える場合。

4. 長い process で global owner の負荷が高すぎるとき

ただし load shedding のための split は、責任の空洞化になりやすいので注意が必要である。

短く言えば、
goal の断面が実際に複数の統治単位を必要とするときだけ分ける
のが基本である。

---

最低限の自己点検

ある process 設計が goal-ownership-aware かどうかは、次で点検できる。

1. その frame の goal owner を言えるか
2. その goal owner が success criteria を保持しているか
3. execution actor と goal owner を混同していないか
4. approval authority と goal ownership を混同していないか
5. goal ambiguity を誰が解くか決まっているか
6. child frame に local goal stewardship を渡しているなら、その限界が明示されているか
7. frame close を誰が accept できるか言えるか
8. goal ownership transfer が explicit か
9. trade-off の最終判断者がいるか
10. incident や reframe が起きたときに、goal の再定義権限が誰にあるか分かるか

このどれかが欠けるなら、その process はまだ goal ownership を十分に持っていない。

---

関連する概念

Goal Ownership は、PCE 2.0 の責任系の起点として、次の概念と強く結びつく。

• Responsibility-first
• 対称的アクター性、非対称的責任
• Process Frame
• Responsibility Bundle
• Actor
• Handoff
• Approval Points
• Transitions
• Outcome vs Process
• Execution
• Approval
• Incident Ownership
• Asymmetry
• Parent-Child Process
• Escalation

---

暫定的なまとめ

Goal Ownership が言っていることは、最終的には次の一文に集約できる。

process は、goal が書いてあるだけでは成立しない。
その goal が何であり、どこまでが範囲で、何をもって達成とみなし、途中の曖昧さや trade-off を誰が引き受けるのかが明示されてはじめて成立する。

PCE 2.0 において goal owner は、単なる依頼主ではない。
それは、frame の identity を保つ責任であり、completion の意味を最後まで保持する責任である。

だから Goal Ownership は、単なる project role ではない。
それは、PCE 2.0 において process が別の仕事へ drift しないように保つための起点責任 である。