チャットからバックログへの変遷
3ヶ月前、私のタスク管理は単なるチャットウィンドウでした。タブを閉じれば、計画は消えてしまいました。
現在、それはPostgresのバックログになっています。Claude Code、Codex、Grokという3つの異なるAIエージェントが、そこからタスクを取り出します。彼らは属性（attribution）を刻印し、gitの履歴に基づいてタスクを完了させます。
プロジェクト管理システムを作るつもりで始めたわけではありません。ただ、壁にぶつかり続けていただけでした。問題を一つ解決するたびに、新しい問題が現れたのです。
私の仕事量は膨大です。Nexusという個人用データプラットフォームを運営しており、約100のリポジトリを管理しています。ある期間には、35日間で55万7,000行のコードをリリースしました。そのボリュームは、私が試したあらゆる計画手法を無効にしました。
私のシステムがどのように進化してきたかを紹介します。
フェーズ1：対話によるプランニング
計画はチャット履歴の中にありました。考えを口に出し、良いアイデアが浮かんだら、すぐに構築を開始するというスタイルです。
- 問題点：チャットが終わると計画が蒸発してしまいました。優先順位を付けたり、他の誰かに引き継いだりすることができませんでした。
フェーズ2：リポジトリごとのTODOファイル
各リポジトリでTODO.mdファイルを使うようにしました。単純なチェックリストの使用をやめ、代わりに小さな仕様書を書くようにしました。
各項目には以下を含めました：
- ステータスと日付。
- トリガー（なぜこれが緊急なのか）。
- 事前に決定した手順（計画）。
- 既知のリスク。
- 問題点：100ものリポジトリがあると、全体像が見えなくなりました。やるべきことすべてを一つの場所で確認することができなかったのです。
フェーズ3：オペレーター・バックログ (OB)
タスクをPostgresデータベースに移行しました。これにより、グローバルなキューが作成されました。 承認ゲートを追加しました。タスクは私がレビューした後に初めて「実体」となります。これにより、AIがバックログにゴミを放り込むのを防いでいます。 以下のステータスレーンを使用しました：
requires_triagerequires_decisionrequires_investigationautonomous_safe- 問題点：私がボトルネックになってしまいました。レーンを十分に速いスピードで消化することができませんでした。
フェーズ4：マルチエージェントによる実行
バックログは現在、複数のAIエージェントのための共有キューになっています。
- 同一タスクへの重複作業を防ぐため、リース（lease）を使用します。
- 誰が何をしたか把握できるよう、属性（attribution）を記録します。
- タスクの引き継ぎが可能です。あるエージェントがタスクの実行不可能を判断した場合、前提条件となるタスクを新たに作成できます。すると、別のエージェントがその前提条件を引き継ぎ、元のタスクを完了させることができます。
教訓はシンプルです。成功するためにフェーズ4まで到達する必要はありません。
もし何か一つだけ盗むなら、フェーズ2のフォーマットを盗んでください。タスクを書く際に、ステータス、トリガー、事前に決定した手順、そしてリスクを記載するのです。コストはゼロですが、すべてが変わります。
最も重要なルールはこれです。常に真実に基づいて計画を立ててください。推測や要約に基づいて計画を立ててはいけません。古いデータに基づいた完璧な計画は、計画がない場合と同じくらい、あっけなく失敗します。
学習コミュニティ（任意）: https://t.me/GyaanSetuAi