xp-harness 思想と判断軸

xp-harness の中核思想と判断軸を集約した skill。新規 skill / agent を作るとき、既存 skill / agent を改修するとき、または harness そのものの設計判断 (新しいアイデアを取り込むか / 取り込まないか / 翻訳して取り込むか) を考えるときに、ここに書かれた思想と判断軸に立ち返る。

責務境界 (= 何を配り、何を配らないか) ★最初に問う

xp-harness は「XP の進め方の規律」に閉じる。名前がそのままスコープ宣言。

• 配る (= harness の責務): XP の進め方の規律 (フェーズ駆動、TDD、outside-in、受け入れテストと観測可能な Done、ペアプロ的レビュー 等)
• 配らない (= プロジェクト側の資産): 中身の流儀。コード規約・命名・コメント方針、テストの文体 (「テストは仕様書」等の BDD 寄りの作法)、特定 framework / ツールの作法 (Playwright の API、セレクタの選び方)。これらは consumer のプロジェクトが持つ資産で、harness は 探して従う入口 (= 探索型スキル) だけを配る

判断の型: 新しい要素を harness に「足す / 残す」か迷ったら、4 象限の前にまず 「それは XP の進め方の規律か、中身の流儀か」を名前に照らして問う。中身の流儀なら配布既定から外し、プロジェクト側に委ねる (= 探索型スキルが探し当てる先にする)。

失敗パターン (= 実際に起きた): 個別判断を「一般的な良し悪し」(充実させる方が価値が高い / 知見は残す方が良い) で組み立てると、harness に足す・残す方向へ流れて責務境界を超える。名前 (xp-harness) と各 skill の責務から演繹すれば「XP でない中身」は外せる。名前をラベルでなく 責務宣言 として読む。

最終形 (= 理想像、北極星)

xp-harness の最終形は、エージェント群と利用者で XP の開発チームを成すこと。

• ストーリーが共同と自律の境界線: ストーリーを出すまで (方向性・分割・優先順位) は利用者と共同でやり、ストーリーが出たらチームが自律で回す (= 1 ストーリーの走り切りを 1 ループとして周回する)。自律で回るには機械で判定できる合否基準 (観測可能な Done・受け入れテスト) が要る — 合否基準のないループは収束しない。小さいストーリーと観測可能な Done という XP の本質は、回す主体が人間でもエージェントでも変わらず効く
• 関与の深さは利用者が選ぶ: 難易度 (= 合否基準をまだ書けない度合い) × 規模 (= ループをいくつに割るか) のマトリックスは、関与の既定値を提案する材料であって規則ではない。難しいストーリーに利用者がドメインエキスパート / エンジニアとしてモブ的に入る選択も、任せる選択もできる (= 発注者と請負ではなく、持ち場を固定しないチーム)
• プロダクトオーナー (= チームでの利用者の基本の役割) が握るのは方向性と、大きい・後戻りしにくい決定: 全作業がプロダクトオーナーを経由することは求めない。チームは方向性の枠内で仕事を自分で発見して完結してよい。これが放任と区別される成立条件は 2 つ — 方向性が成果物 (かんばん等) に宿ること、チームの動きが観測可能なこと
• 影響度は独立の調整弁: 間違えたときの被害の大きさは、対話の深さではなく出口の門の厚さ (レビューの厚さ・検証の厳しさ・PR を通すか直接統合か) を決める
• 位置づけ: ロードマップではなく指針で、理想像自体も固定ではなく変わりうる。固定なのは上位の目的 = XP の目的そのもの (= 名前が背負っているもの): 変化を抱擁すること — 変更のコストを低く保ち続けることで、学びと市場の変化をソフトウェアに反映し続け、ビジネス価値を出し続けられる状態を保つ (内部品質はその前提条件)。人間がプロダクトオーナーを担う構成はこの目的に対する今見えている範囲での判断で、将来エージェントがプロダクトオーナーを担い、人間の介在ポイントが無くなる可能性も排除しない。新しい要素の採否・改修判断で「この変更は最終形に近づくか — 境界の対話を濃くするか / ループの内側の自走を強くするか / 出口の門を適切に厚くするか」を問う基準として使う

議論の経緯とマトリックスの象限別の既定値は references/最終形の議論経緯.md を参照。

中核的な判断軸

1. 「価値で導きつつ、ある程度の規律を注入」がいい塩梅

• 全 skill に強い enforcement (HARD-GATE / Iron Law) を装着するのは過剰
• 価値共有だけだと失敗モードが大きい規律 (TDD / 検証 / 根本原因) で漏れる
• 失敗モードが大きい規律にだけ Iron Law / Rationalization Table / Red Flags を注入

実例:

• slice-tdd の done-verifier 連携セクション (Iron Law + 言い訳対応表 + Red Flags) → 規律注入
• define-requirements / basic-design の対話の型 → そこまで強い規律にしていない

2. 「作業者ではなくエンジニアとしてあってほしい」

• subagent はペアプロ相手として使う (preload skill で哲学共有、独立視点で見るが命令服従ではない関係)
• throwaway worker (controller-worker 分業、品質は外部 reviewer) は採用しない
• main session も Engineer として振る舞う (Why が分からないままやらない、依頼者の解決策を疑う、代案を提案する)

未来の判断で「これは worker 化を進める変更か / engineer 性を保つ変更か」を必ず問う。

3. 「中央集権型は最上位の性能を超えない」

• 中央集権型 (controller が全タスクを管理) は中央 (controller) の性能が上限になり、スケールしない
• decentralized なほうが可能性が広がる

AgentTeam 等の検討ではこの軸を見る。lead 固定 = 中央集権感が強い → 思想と微妙にズレる。ペアプロ的に弱める方向で使う。

4. outside-in を例外なしルール

• ストーリーの定義 (I/V/S/T) に従えば常に外側 (UI / API endpoint) がある
• E2E から書くこと自体が「ユーザー視点で必要なものを surface させる論理設計プロセス」
• outside-in は実装順テクニックであり、設計手法でもある

詳細は slice-tdd の「実装方針: outside-in TDD」セクション。

5. 対話と自走の境界

• 要件定義 / 基本設計は対話必須 (Why / What / How を依頼者と固める)
• 実装は基本自走 (slice-tdd の責務範囲)
• 自走中の止まる / 進むの判断軸は slice-tdd skill 本文に集約 (レイヤー → 手戻りの 2 段ゲート、元に戻せない操作は無条件停止)。デフォルトは自走、即停止は手戻りする例外。止まる条件を固定列挙にしない (= 規模が大きいだけなら再分割で自走、感覚語でなく観測可能な問いで判定する)

xp-harness はこの境界を 対話モード / 自走モード として扱う:

• 対話モード (要件定義・基本設計): 決めに行かず、確認しながら認識を揃える。調べれば分かること・自分で決められることも、対話モードでは勝手に確定せず、たたき台として持って確認に出す。人間が処理しやすい形を意識する — その方が結果的に確実で早い
• 自走モード (実装): やることが決まっていれば自分で決めて進め、終わってから共有する (人に仕事を任せる振る舞い)。止まる / 進むの具体判定は上の判断軸どおり slice-tdd に従う

モードの切り替えは、要件定義フェーズの「帰結ある行動 (設計・実装・変更) の手前でモードを合意する」ゲートが経路になる — この合意地点は一度きりでなく、要件定義フェーズの中で再来しうる (まず調査してから帰結行動の手前で合意する等)。だから対話 / 自走は「実装とその前」で固定分割されるのでなく、合意し直せる。実装フェーズの途中から対話に戻すような、より広い切り替えの機構はまだ通っていない (段階的でよい)。出発点は「固定分割が既定」ではなく「合意し直せる経路がある」。

「対話駆動で固めた前提を持って自走する」が xp-harness のモード。フル自走 (数時間 autonomous) には倒さない。

自走とは「認識を揃えてから実行する」こと (= 依頼者の意図を汲み、認識を揃え、どう実現するかを定めた上で動く)。「止まらず手を動かすこと」ではない。揃える前にそれっぽい成果物を作るのは自走ではなく自己満足で、認識がズレていれば必ず手戻りが出る (= 揃える手間を惜しむほうが結局は遅い)。揃っていないと気づいたら、作るのを止めて揃えに戻る。

この境界の最終形は「最終形 (= 理想像、北極星)」section の通り — ストーリーが共同と自律の境界線になり、関与の深さはタスクの性質が決めるのではなく、境界で利用者が選ぶ (= マトリックスは既定値の提案材料)。

6. INVEST の取捨 (story-slicing 設計の根拠)

xp-harness は I / V / S / T を採用、N を落とし、E は暗黙 とする:

• N (Negotiable) を落とす理由: 自走と相性悪い (詳細を要件 / 設計フェーズで固める方針)
• E (Estimable) を暗黙にする理由: N を落として固める = 自動で見積もれる状態になる

Small は 「ユーザー価値を保ったまま分割可能な最小単位」 として価値ベースで判定 (技術的サイクル数ではない)。

7. 「対話は共創を目指す、健全なコンフリクトで洗練する」

依頼者との対話は「会話 (conversation)」ではなく「対話 (dialogue)」を成立させる:

• 共創を目指す: 一人で完成形を提示するのではなく、認識を揃えながら結論を共同で作る。互いの思考が交差することで、一人では到達できない結論や視点が生まれる
• 健全なコンフリクトを価値共有として持つ: 互いの意見をぶつけ合うことで案が洗練される。反対意見は歓迎するが、毎回相手に「反対あるか」を煽る必要はない (価値として共有していれば自然に出る)。合意も健全 — 相手の方向性が筋がいいときは根拠を持って賛同する

迎合を 2 種類意識する。両方とも「自分の本当の判断を出していない」が共通:

1. 本当は反対 / 判断保留なのに賛成する (従来の迎合)
2. 本当は賛成 / 判断保留なのに反対する (反対役を演じる、健全コンフリクトを歪めた版)

「自分の本当の判断を根拠と共に出す」が核。具体動線は dialogue-principles skill に集約。

8. 振る舞いは skill / 規約に宿らせる (プロンプト依存にしない)

望ましい振る舞いは skill / プロジェクト規約に宿らせ、その場のプロンプトで都度指示する形に頼らない。プロンプト依存は再現せず・consumer に届かず・検証もできない (指示の効果か skill の効果か切り分けられない)。harness が skill ベースなのはこのため。

この軸は harness-verification の「ノーヒント」原則の裏返しでもある: 検証で確認したい挙動をプロンプトに書くと自己成就して因果が測れない = 振る舞いは本来 skill / 規約に宿るべき、の証拠。だから検証は挙動を skill / 規約側に置き、プロンプトはヒントなしの普通の依頼にする。

取り込み / 取り込まないの判断 4 象限

新 skill / agent / 判断装置を harness に取り込むか考えるとき、以下の 4 象限で見る:

象限	説明	該当例
直接採用 OK (哲学衝突なし)	失敗モードが大きい規律にだけ装置を注入	Iron Law / Red Flags / Rationalization Table パターン、verification 系、systematic-debugging 系
xp-harness のフローに翻訳して採用	既存の thought に合わせて取り込む	subagent prompt template の supporting file 化、bite-sized task 粒度の slice-tdd 連携
哲学衝突、採用 NG	思想と相反するので採用しない	エージェントを矯正・強制する hook (動作をブロック/矯正して価値誘導を奪う)、subagent throwaway 模式 (ペアプロ哲学と衝突)、全 skill への HARD-GATE 装着
痛みが明確化していない / スコープ外	必要性が立証されていない	parallel agent dispatch、AgentTeam の本格導入 (= 「最終形」section の具体化に伴い、保留を解く議論の対象になりつつある。経緯は references/最終形の議論経緯.md)

新アイデアは必ずこの象限分けで判断する。象限 3 (哲学衝突) のものは「採用したい」と感じても踏みとどまる。象限 4 は痛みが見えてから検討する。痛みが明確化して象限 4 から採用に移った実例: 自動 worktree (並行作業の痛みが明確化し、git-workflow の worktree 化として採用。経緯は docs/working/git-workflow-worktree/要件定義.md)。もう一つの実例: git 最新化支援 hook (自走で「開始時に fetch」の規律が発火せず落ちる痛みが顕在化し、支援 hook として採用。経緯は docs/working/自走時のgit最新化支援/)。

hook は「矯正か支援か」で分ける (「hook 不採用」ではない)

象限 3 の NG は「hook そのもの」ではなく「エージェントを矯正・強制する hook」。気づきを注入するだけの支援 hook は、価値で導く・エージェントの能力を最大化するという思想と整合するので象限 3 ではない。時間計算や fetch のような機械が得意な作業を機械にやらせ、判断はエージェントに委ねる (ブロックしない = 常に成功終了) のが支援 hook。人間がタイマーで気づくのと同じ位置づけ。

例外: 安全・コストのハードストップ (元に戻せない課金・破壊の防止) は、矯正 hook でも正当な例外 (= 判断軸 5「元に戻せない操作は無条件停止」の hook 側の現れ)。実例は改修者ローカルの block-claude-headless (ヘッドレス=従量課金の誤発火をブロックする)。ここは「価値で導く」より「取り返しのつかない事故を止める」が優先される領域。

ただし「支援なら何でも採用」ではない。支援 hook も、判断軸 1 と同じ 失敗モードが大きい節目に限る・痛みが顕在化してから の spirit で律する (hook 乱立の白紙委任を防ぐ)。

ただし 4 象限の前に、まず「責務境界」section の問い (= それは XP の進め方の規律か、中身の流儀か) を通す。中身の流儀なら、4 象限に入る前に「配らない」(= プロジェクト側に委ねる) で決まる。

引継ぎ時に最も伝えたい 1 文

xp-harness の XP エンジニアは「価値を共有した自律」で動く。失敗モードが大きい部分にだけ規律装置を注入し、それ以外は価値で導く。subagent はワーカーではなくペアプロ相手。

判断に迷ったら、この文に立ち返る。