Outcome vs Process

定義

Outcome vs Process

PCE 2.0 において評価は、少なくとも二つの軸に分かれる。

• Outcome Evaluation は、ある subject が、意図された結果・要求・成功条件を満たしているかを問う評価である。
• Process Evaluation は、その subject が、どのような process、どの responsibility、どの governance、どの evidence、どの continuity のもとで生成・判断・昇格されたかを問う評価である。

より短く言えば、

• Outcome は 「何ができたか」
• Process は 「それがどのように成立したか」

を問う。

PCE 2.0 は、この二つを相互に代替可能とはみなさない。
どちらか一方だけでは、merge、promotion、close の可否を十分には判断できない。

このページが言いたいことは単純です。
正しい結果に見えること と
正しい process を通って得られたこと
は同じではありません。

PCE 2.0 は、この二つを明示的に切り分けたうえで、必要な場所で統合します。

---

なぜこの区別が必要なのか

PCE 2.0 が Outcome と Process を分ける理由は、AI 時代の開発では次の二つが容易にずれるからです。

1. 結果が正しく見えても、process が壊れていることがある

たとえば次のようなケースです。

• tests は通っている
• 仕様にも一見合っている
• 出力形式も問題ない

しかし同時に、

• required approval を飛ばしている
• prohibited capability を使っている
• scope を逸脱している
• rationale が失われている
• stale な context をそのまま使っている
• memory promotion に値しない内容を durable に入れようとしている

ことがあります。

このとき outcome だけを見ると「成功」に見えますが、
PCE 2.0 ではそれを十分な成功とはみなしません。

2. 結果が未達でも、process から価値ある学習が得られることがある

たとえば feature 実装自体は失敗しても、

• reusable な failure lesson
• 有効な rejection rationale
• future use に耐える checklist
• rollback anchor
• scope clarification

が得られることがあります。

このとき artifact outcome だけを見ると「失敗」ですが、
process 全体としては durable に残す価値のある差分が含まれています。

3. merge や promotion は「出力があったこと」では正当化できない

PCE 2.0 における merge と promotion は、
future process の前提条件を書き換える行為です。
したがって、結果の見た目だけでなく、その生成・評価・承認の経路が問われます。

この区別があるからこそ、
No merge without eval は
単なる testing rule ではなく、process rule になります。

---

Outcome Evaluation とは何か

Outcome Evaluation は、ある評価対象が 結果として何を達成したか を問います。

典型的に問うもの

• correctness
• completeness
• requirement fit
• acceptance criteria satisfaction
• performance threshold
• regression absence
• output format validity

典型的な問い

• 仕様を満たしているか
• 期待された成果物になっているか
• テストを通過しているか
• 要求された形式で返ってきているか
• 期待された business / local goal に到達しているか

典型的な evidence

• code diff
• test results
• generated artifact
• approved summary
• benchmark result
• acceptance checklist

短く言えば、Outcome Evaluation は
「できたものは役に立つか / 合っているか / 要求を満たしているか」
を問います。

---

Process Evaluation とは何か

Process Evaluation は、ある結果が どのような経路で成立したか を問います。
PCE 2.0 では、process の良し悪しは単なる「手順の多寡」ではありません。
少なくとも次の観点に分解されます。

1. Procedural Validity

所定の process を通っているかを問います。

• required phase を飛ばしていないか
• 必要な handoff が成立しているか
• child / parent frame の関係が壊れていないか
• required checkpoint を持っているか
• rollback / replan 条件を無視していないか

2. Governance Validity

統治条件を満たしているかを問います。

• approval point を通っているか
• prohibited capability を使っていないか
• scope 制約を破っていないか
• visibility 制約を破っていないか
• required authority を持つ actor が ratify しているか

3. Evidence Sufficiency

結果を future process の前提にしてよいだけの evidence があるかを問います。

• rationale があるか
• tests / reports / refs が揃っているか
• provenance が追えるか
• summary に根拠があるか

4. Continuity Integrity

継続可能性が保たれているかを問います。

• handoff loss が大きすぎないか
• recovery 可能か
• pending gates を失っていないか
• stale context を盲目的に流用していないか

5. Promotion Discipline

durable state を汚さない規律が守られているかを問います。

• canonical と provisional を混同していないか
• memory promotion に専用 criteria を使っているか
• raw transcript や speculative note をそのまま昇格していないか
• duplicate / supersession の扱いがあるか

短く言えば、Process Evaluation は
「この結果は、正しい責任構造・統治条件・根拠・継続条件のもとで成立したか」
を問います。

---

Outcome と Process は直交する

PCE 2.0 では、Outcome と Process は一方が他方を保証しません。
両者は直交する軸として扱います。

Outcome が良くても Process が悪いことがある

• テストは通った
• しかし approval を飛ばした
• あるいは prohibited capability を使った
• あるいは stale context で進めた

Process が良くても Outcome が悪いことがある

• required gates は守った
• rationale も明確
• evidence も揃っている
• しかし結果物は要求を満たしていない

このため PCE 2.0 では、
Outcome pass だけでは merge できず、
Process pass だけでも目的達成とは言えない
という立場を取ります。

---

Subject-relative Outcome と Upstream Task Outcome

ここは誤解しやすいので分けておきます。

Subject-relative Outcome

いま評価している対象そのものが、何を達成しているかです。

例:

• artifact delta なら「正しい code patch か」
• decision delta なら「採用可能な rationale か」
• failure memory candidate なら「再利用可能な失敗知か」
• recovery point なら「再開可能な保存点か」

Upstream Task Outcome

元の大きな仕事全体として成功したかどうかです。

例:

• feature delivery 全体として出荷できたか
• incident 全体として解消したか

この区別が重要なのは、
大きな仕事が失敗しても、ある局所 subject は成功しうる からです。

たとえば、

• feature 実装は未完成だった
• しかし失敗原因の分析は正確で再利用価値がある
• その failure memory candidate は promote 可能である

ということがあります。

つまり PCE 2.0 における Outcome Evaluation は、
常に その subject にとっての outcome を問います。
元の business task の成否だけを問うわけではありません。

---

四象限で見る Outcome vs Process

PCE 2.0 では、典型的に次の四象限で考えると分かりやすいです。

	Process 良	Process 悪
Outcome 良	理想的な成功。merge / promotion 候補。	見かけ上の成功。結果は良いが、そのまま canonical 化してはならない。
Outcome 悪	生産的な失敗。artifact は不採用でも、failure memory や rationale は残しうる。	失敗。通常は reject / rollback / replan / incident handling の対象。

この表で重要なのは、
Outcome 良 / Process 悪 を成功として素通ししないこと、
Outcome 悪 / Process 良 を完全な無価値とみなさないことです。

PCE 2.0 における process-aware evaluation の要点はここにあります。

---

Outcome-only が生む問題

Outcome だけを見ると、少なくとも次の種類の失敗を見落とします。

1. Accidental correctness

偶然に正しく見えるだけで、再現性がない。

2. Governance violation

required approval、scope、policy、authority の問題が隠れる。

3. Evidence loss

future process が使うべき rationale や provenance が残らない。

4. Memory pollution

「うまく見えたもの」をそのまま durable に残して project state を汚す。

5. Continuity breakage

handoff や recovery の品質が悪くても、直近の artifact だけ見ると気づきにくい。

短く言えば、Outcome-only は
いま目の前の結果の見た目 に偏り、
future process への影響を見落としやすいです。

---

Process-only が生む問題

逆に Process だけを見ると、別の失敗が起きます。

1. Bureaucratic success

手順は完璧だが、役に立つ結果が出ていない。

2. Formal compliance without value

checklist や gates は通ったが、要求された artifact が使い物にならない。

3. Over-preservation

「ちゃんとやった」ことを理由に、価値の低い memory を残しすぎる。

4. Risk-averse stagnation

process を守ること自体が目的化し、進行が過度に停滞する。

PCE 2.0 は process を重視しますが、
それは 結果を軽視すること ではありません。
あくまで両軸が必要です。

---

PCE 2.0 における統合判定

Outcome と Process は分けて評価されますが、
実務上は何らかの統合判定が必要です。

概念的には、次のように書けます。

admissible(subject, contract) iff
  outcome_verdict(subject, contract) is acceptable
  and process_verdict(subject, contract) is acceptable
  and required_approval(subject, contract) is granted

ここで重要なのは三点です。

1. acceptable は subject-relative である

artifact と memory candidate では acceptable の意味が違います。

2. process_verdict は単一スコアに還元しなくてよい

procedural validity、governance validity、evidence sufficiency、continuity integrity、promotion discipline を分けて見てよいです。

3. approval は eval と別軸である

process / outcome の両方が acceptable でも、required authority がなければ merge / promote できないことがあります。

つまり PCE 2.0 では、
結果の妥当性
過程の妥当性
authority による ratification
が揃ってはじめて、強い意味で admissible になります。

---

Eval Contract はこの二軸をどう扱うか

Eval Contract は、ただ評価項目を列挙するだけでは不十分です。
PCE 2.0 では、contract の中で次を区別するのが自然です。

Outcome criteria

• correctness
• completeness
• acceptance fit
• performance
• regression absence

Process criteria

• required phase completion
• gate compliance
• scope compliance
• evidence sufficiency
• handoff completeness
• recovery integrity
• promotion discipline

この区別があることで、

• tests は pass したが required approval は missing
• rationale は弱いが artifact 自体は正しい
• feature は失敗したが failure memory candidate は strong

といった状態を正しく評価できます。

---

Approval Point はどこに関わるか

Approval Points は、Outcome と Process のどちらか一方を評価するものではありません。
それは、評価を受けた subject を authority が ratify する地点 です。

したがって Approval Point は、通常次のあとに来ます。

1. required outcome evaluation
2. required process evaluation
3. evidence availability confirmation

そのうえで、

4. approve / reject / request_changes / escalate

が行われます。

つまり Approval Point は、Outcome vs Process の区別を消すものではなく、
両軸の評価結果を前提として動く authority gate です。

---

Memory Promotion では Process 軸が特に重要になる

Memory Promotion Rules と結びつけると、この区別はさらに重要になります。

artifact merge では Outcome 軸が強く見えます。
しかし memory promotion では、しばしば次の Process 軸が重要になります。

• provenance sufficiency
• scope boundedness
• decontextualizability
• non-redundancy
• governance compatibility
• maintenance cost
• promotion discipline

つまり、memory promotion では
「役に立ちそうに見える」 だけでは足りず、
future process の前提にしてよい process pedigree を持つか
が問われます。

この意味で PCE 2.0 の memory は、Outcome-only では設計できません。

---

Recovery と Handoff の評価も Process 軸に属する

Handoff や Checkpoint and Recovery は、
しばしば artifact outcome では測れません。
しかし process quality には直結します。

たとえば次は Process Evaluation の重要な対象です。

• handoff package completeness
• gate continuity preservation
• stale context invalidation
• recovery integrity
• legal next transition clarity
• authority continuity

これらは「今この成果物が正しいか」ではなく、
この仕事が壊れずに続けられるか を問う評価です。

PCE 2.0 が process を主語に置く以上、
この種の評価は二次的ではありません。

---

Outcome と Process の最小スキーマ

PCE 2.0 における二軸評価の最小スキーマは、次のように置けます。

dual_axis_evaluation:
  subject_ref:
  subject_kind:
  outcome_contract_ref:
  process_contract_ref:
  outcome_verdict:
    state:
    evidence_refs:
    notes:
  process_verdict:
    procedural_validity:
    governance_validity:
    evidence_sufficiency:
    continuity_integrity:
    promotion_discipline:
    overall_state:
    evidence_refs:
    notes:
  required_approval:
    state:
    authority_refs:
  admissibility:
    for_merge:
    for_promotion:
    for_close:

あるいは、もっと contract 寄りに書くなら次のようになります。

evaluation_view:
  subject_ref:
  subject_kind:
  outcome:
    criteria:
    verdict:
    evidence_refs:
  process:
    criteria:
      - procedural_validity
      - governance_validity
      - evidence_sufficiency
      - continuity_integrity
      - promotion_discipline
    verdict:
    evidence_refs:
  authority_gate:
    required_approval_points:
    approval_state:
  resulting_decision:

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

1. outcome と process を分けて持つ
2. process をさらに複数 facet に分けられる
3. approval を別欄で持つ
4. merge / promotion / close の admissibility を分けて判断できる

---

小さな例

例1: Code patch は正しいが process が壊れている

• tests: pass
• spec fit: good
• reviewer approval: missing
• prohibited file scope: violated

この場合、

• outcome evaluation: 良
• process evaluation: 悪

です。
PCE 2.0 では、そのまま merge してはなりません。

例2: 実装自体は失敗したが failure memory は強い

• feature outcome: 未達
• failed attempt の原因分析: 明確
• same issue の再発防止価値: 高い
• provenance / evidence: 十分

この場合、

• upstream task outcome: 悪
• failure memory candidate outcome: 良
• process evaluation: 良

となりえます。
artifact は不採用でも、failure memory は promote しうる、ということです。

例3: Process は丁寧だが結果が足りない

• required approvals: all present
• evidence: sufficient
• handoff / recovery: clean
• しかし spec requirement の一部未達

この場合、

• process evaluation: 良
• outcome evaluation: 悪

です。
丁寧に進めたこと自体は価値がありますが、subject が artifact なら pass にはなりません。

---

Outcome と Process をどう分けるべきか

実務上は、何を Outcome に置き、何を Process に置くかが曖昧になりがちです。
原則は次のように考えるとよいです。

Outcome 側に置くもの

• できたものの性質
• 要求との適合
• 結果物の品質
• performance / completeness / correctness

Process 側に置くもの

• どういう責任構造で作られたか
• どの gate を通ったか
• どの evidence が揃ったか
• どの scope / policy / authority を守ったか
• どれだけ future process に耐えるか

短く言えば、

• What was produced? → Outcome
• How was it produced and under what discipline? → Process

です。

---

Outcome と Process の強度は task ごとに違ってよい

この区別はすべての task に等しい強度で適用される必要はありません。
低リスク・短命・個人的な作業では、Process 軸は薄くてよいことがあります。

しかし、PCE 2.0 では次の条件が強くなるほど Process Evaluation の重要性が上がります。

• long-running
• multi-actor
• approval-heavy
• high-risk
• durable-state-updating
• memory-promoting
• governance-sensitive
• cross-session / cross-system

つまり、強度は変わってよいが、
Outcome と Process の区別自体は消さない
のが PCE 2.0 の立場です。

---

Outcome vs Process の不変条件

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

1. Outcome pass does not imply process pass

結果が正しく見えることは、process の妥当性を保証しません。

2. Process pass does not imply outcome pass

正しい手順を踏んだことは、結果物の十分性を保証しません。

3. No merge based on outcome alone

merge や canonical promotion は、Outcome のみで正当化してはなりません。

4. Productive failure must remain expressible

upstream task が失敗でも、failure memory や rationale のような subject は pass しうる構造を保たなければなりません。

5. Approval must not collapse the distinction

approval は outcome / process 評価を置き換えません。
それは authority による ratification です。

6. Memory promotion requires process-sensitive judgment

memory promotion は artifact correctness だけでは決めてはなりません。

7. Process evaluation must be about validity, not mere verbosity

長い説明、細かい手順、多くの steps が自動的に高い process quality を意味するわけではありません。

---

最低限の自己点検

ある評価設計が PCE 2.0 的に十分かどうかは、次で点検できます。

1. outcome と process を別軸として定義しているか
2. outcome pass だけで merge していないか
3. process pass だけで subject success と呼んでいないか
4. evaluation subject を明示しているか
5. upstream task outcome と subject-relative outcome を混同していないか
6. process evaluation に governance / evidence / continuity / promotion discipline が入っているか
7. approval を eval と混同していないか
8. failure から durable learning を抽出できる構造があるか
9. memory promotion に専用の評価軸があるか
10. admissibility を outcome + process + authority の組み合わせとして扱えているか

このどれかが欠けるなら、その評価はまだ PCE 2.0 の意味で dual-axis ではありません。

---

関連する概念

Outcome vs Process は、PCE 2.0 の評価哲学の中心として、次の概念と強く結びつきます。

• No merge without eval
• Eval Contract
• Process Frame
• Responsibility Bundle
• Process Delta
• Durable Project State
• Approval Points
• Handoff
• Checkpoint and Recovery
• Memory Promotion Rules
• Process Metrics
• Memory Promotion Criteria

---

暫定的なまとめ

Outcome vs Process が言っていることは、最終的には次の一文に集約できます。

PCE 2.0 において評価とは、「何ができたか」だけを見ることでも、「手順を守ったか」だけを見ることでもない。
結果の妥当性と、過程の妥当性を分けて見たうえで、その subject を future process の前提にしてよいかを判断することだ。

PCE 2.0 は、結果を軽視しません。
しかし process を結果の裏方にも置きません。
両者を分けることで初めて、

• 見かけ上の成功を canonical 化しない
• 生産的な失敗を durable learning に変える
• governance を評価に接続する
• memory promotion を artifact correctness と切り分ける

ことができます。

だから Outcome vs Process は、単なる評価観点の整理ではありません。
それは、PCE 2.0 において 何を project の現実として採用してよいかを見極めるための二軸評価原理 です。