giboulz

私はスクラムマスターです。10年前は開発者でした。LLMと設計やトレードオフについて議論できる程度の背景はありますが、3ヶ月前、私はソロプロジェクトで意図的な賭けをしました：私は決してコードを読まない。

仕様がテストを定義する。テストがコードを制御する。コードはブラックボックスだ。

これが全員がやるべきことだとは主張していません。しかし、これは私の賭けであり、その結果、あるシステムが必然的に生まれることになりました。誰もコードを読まない場合、通常はコードを読む人間が提供する信頼を、プロセスが担わなければなりません。私はそのシステムをリファレンス実装として公開しました：backlog-as-data — 完全な解説、英語に翻訳されたClaude Codeスキル、そして私の日常環境からそのままのCLIソースコードです。

以下がその要約です。

バックログはgitのデータであり、文書ではない

ほとんどのエージェント用タスク管理ツールは、タスクを専用領域に保存します — tasks.json、データベース、backlog/フォルダなどです。私の賭けは異なります：バックログは仕様ファイルのYAMLフロントマターそのものです。 チケット1つにつき1ファイルで、チケットのステータスはフィールドであり、文書内の位置ではありません。 

---
id: PARSE-07
title: Tolerate CRLF in decklist import
type: ticket
status: todo
priority: should
exec:
  model: sonnet
  effort: think
  review: light
  matured: 2026-07-22
---

# PARSE-07 — Tolerate CRLF in decklist import

The spec body: design, contracts, test cases. The ticket file IS the spec.

Enter fullscreen mode Exit fullscreen mode

フロントマターより下は仕様です — 会話の中で私が述べた必要性に対してLLMが疑問を呈した後で、LLMが書いたものです。フロントマターはデータであり、小さなCLIが所有し、CLIを通じてのみ変更されます。同じファイルなので、決して乖離することはありません。

なぜ重要なのか：「Doneに移動する」という操作は存在しません。状態変更がテキストの移動を意味する場合、LLM（および人間）は文書を破損させます。ステータスをフィールドにすることで、すべての遷移が1行でべき等性があり、テスト可能な変更になります。私が見ているボード（各仕様へのGitHubディープリンク付きのサーバー上の小さなWebページ）と読みやすいマークダウンビューは生成された投影であり、編集禁止のsentinelによってロックされ、コヒーレンステストでカバーされています。

成熟化：チケットごとにモデル、労力、レビュー深度をデータとして決定する

チケットにコミットすることと、どれだけ深く考えるかを決定することは、別々の行為です。エージェントが実行する前に、チケットは三つ組で成熟化されます：

  • model — どのモデルで実装するか（haiku → fable）
  • effort — プロンプトに注入される推論の深さ
  • review — レビューの投与量：none、light（1人のレビュアー）、deep（3人）

些細なリネームはhaiku / none / noneになります。元に戻せないデータマイグレーションは、最も有能なモデル、最大の推論、3人のレビュアーを割り当てます。この決定はチケットとともにバージョン管理され、後から監査可能です（matured: <date>）。また、実装者サブエージェントは正確に成熟化したモデルで実行され、そのレポートはModel used: …で始まるため、決定は事後的に検証可能です。

これはエージェント予算へのリーン思考の適用です：欠陥がすり抜けるコストに比例して欠陥検出にコストを支払います。

ライフサイクルはフックによって適用され、誰かの記憶によるものではない

todo → wip → merged → shippedは、私のワークフローコマンドに接続されたフックによって設定されます — launchはwipを設定し、integrationはmergedを設定します（feat(TICKET-ID):コミットが実際にブランチ上にあるチケットのみ）、deployはshippedを設定します。人間もエージェントも、ライフサイクルの後半を手動で移動することはありません。フックは常に0で終了し（ライフサイクル自動化はデリバリーをブロックしてはならない）、外科的にコミットします（10以上の並列ワークツリーを持つ共有メインのチェックアウトは、git add specs/が隣のセッションの作業を巻き込んでしまうことを教えてくれました — 苦い経験から学び、日付が残っています）。

レビューゲート：何も知らないレビュアーたち

これが他で見ない部分です。実装者サブエージェントが（独自の分離されたgitワークツリーで）完了すると、オーケストレーターはfresh-contextレビュアーを生成します：チケットID、仕様パス、ワークツリー、コミットSHA、4つのレビュー軸を受け取ります。それ以外は何も。実装者が何をしたかの要約も、どこを見るべきかのヒントもありません。レビュアーのコンテキストを汚染することは、確証バイアスの主要な経路です。

インシデントから学んだ3つの詳細：

  • レビューの証拠はオーケストレーターによって生成され、監査対象のエンティティによって生成されることはない。 実装者は投与量を知らず、レビュアープロンプトを見たことがなく、レビューについて何も証明できません。SHAはgitからプログラム的に読み取られ（手書きで転記されたSHAが39文字で届いたことがあります）、git statusはレビューの前後にチェックされます。
  • 発見には正確に2つの出口がある：修正されるか、正当な理由とともにエスカレーションされる（仕様が間違っている / 既存の負債 / 修正が緑のテストを破壊する）。「大したことではない」は処理方法ではありません。
  • レビュアーは発見のみを報告し — 称賛はしない。 「他はすべて適合している」と書かれたレポートは、誤った信頼を生み出します。欠陥を見逃した決定を適合していると宣言したレポートを伴っていたことがあります。

これは機能するでしょうか？公開前日、私は公開リポジトリ自体に対してゲートを実行しました：新しいレビュアーが私の英語翻訳をフランス語原文と比較し、3つの発見を上げました — 英語版に従う人のレビューレジスタを静かに破損させる可能性のある、誤訳されたカウンターを含みます。ゲートは最初の公開運用で元を取ったのです。

人間が実際に行うこと

チケットごとの私の3つのタッチポイントはすべて決定であり、メカニズムではありません：必要性に同意する（会話の中で — LLMは私に疑問を呈し、その後仕様を書く）、"成熟化して実行せよ"と言う（レビューの投与量とともに）、デプロイを決定する。間にあるすべて — CLI呼び出し、仕様の執筆、エージェントオーケストレーション、統合 — はエージェントの仕事です。私はバックログコマンドを一度もタイプしません。CLIはエージェント向けです：決定論は、エージェントに手動編集パスがないことから来るのであって、私が帳簿付けを行うことから来るのではありません。

私が主張していないこと

  • コードを読むのをやめるべきだということ。これは私のソロプロジェクト、私のリスクプロファイルでの私の賭けです。
  • これが製品だということ。これは動作する設定から抽出されたリファレンス実装です — 読んで、アイデアを盗んで、部品を適応させてください。READMEには、どの部品がうまく移植できるかについてのセクションがあります。
  • システムが完成しているということ。最大の未解決問題はREADMEに正直に書かれています：すべてのルールは私が習慣で行ったインシデントレトロから来ている — このスキルはまだ自身の改善ループをトリガーしていません。

もしあなたが毎日コーディングエージェントを動かしていて、バックログがまだマークダウンのToDoリストで、エージェントが「何かをDoneに移動する」たびに破損しているなら — データモデルだけでも読む価値があるかもしれません：
github.com/giboulz/backlog-as-data。

コメントで何でもお答えします — 「コードを読まない」という賭けがまだ私を燃やしていないかどうかを含めて。