かつてのバックログは、あなたと数人のチームメイトがタスクを引っ張ってくるリストでした。一番上の項目を読み、理解し、実行する。トリアージは簡単でした。唯一の問いは「誰に時間があるか」だけだったからです。ところが今、その項目のいくつかは人間ではなくコーディングエージェントが拾えるようになり、穏やかだったキューは、小さくて高くつくミスの温床へと変わってしまいました。誰も書き終えていないタスクにエージェントが着手し、2体のエージェントが重複する作業を奪い合い、「完了」列は誰も求めていない成果物で埋まっていくのです。
問題はエージェントではありません。人間向けに作られたバックログが、いつの間にかその役割を変えてしまったことです。それは To-Do リストであることをやめ、実行を起動しうるディスパッチキューになりました。1つの項目が実際の作業を引き起こせるようになると、タスクを動かす瞬間と、誰が担当するかを決める瞬間に、かつてはなかった結果が伴うようになります。
Sharkly はこのレイヤーに位置しています。コーディングエージェントはすでに手元にある。Sharkly はバックログに共通の意味を与えることで、それらをチームに変えます。タスクは作業の基本単位であり、バックログは未コミットの作業が待機する場所、トリアージは届いた項目が誰かの判断を待つ専用の受付キューです。本記事では、人間とエージェントが混在するバックログを、こうしたキューが混沌と化さないようにトリアージする方法を順を追って解説し、最後に今日から実行できるチェックリストを紹介します。
エージェントが作業を担えるようになった今、バックログとトリアージとは何を意味するのか
ここでは2つの定義がほとんどの役割を果たすので、正確に押さえておきましょう。
バックログとは、未コミットの作業の集合です。つまり、存在はしているものの、まだ誰も着手を決めていないタスクのことです。トリアージとは、新規または不明瞭な項目に対して下す受け入れ判断であり、受け入れる、断る、重複とする、後回しにする、のいずれかです。人間は昔からこの両方を非公式に行ってきました。変わったのは、人間とエージェントのチームではトリアージの結果に「どのエージェントがこれを実行するか」が含まれるようになり、タスクをコミットする行為そのものが実行を開始しうるという点です。
最初につまずきやすい境界線がこれです。バックログでタスクにエージェントを割り当てても、実行は始まりません。バックログは、実行前に作業を準備しておく待機場所です。実行が始まるのは、タスクがバックログを離れて作業可能なステータスになり、かつコンピュータとランタイムが利用可能になったときだけです。つまり「エージェントを割り当てる」ことと「エージェントを開始する」ことは別々のイベントであり、その間にバックログのステータスがゲートとして挟まっています。
もう一つ、はっきり述べておくべき境界があります。エージェントは自分専用のバックログを持ちません。エージェントが独力で処理し続ける隠れたキューは存在しません。エージェントが触れるすべての項目は共有ボード上にあり、だからこそ当て推量ではなくトリアージが可能になるのです。
DIY 構成がスケールしなくなる地点
スプレッドシートとカンバンボード、そしていくつかのターミナルという構成は、1人とエージェント2体なら問題なく機能します。しかし、ある一定の規模で必ず破綻し、その兆候はそれぞれ具体的な失敗として現れます。
ステータス列はエージェントにとって何の意味も持ちません。手動のボードでは、カードを「進行中」に動かすのはチームメイトへのメモにすぎず、何も実行されません。その結果、ボードと実際の作業が乖離していきます。カードは「進行中」なのにエージェントは1時間前に終えていたり、「To Do」なのに誰かがターミナルで起動したせいでエージェントがすでに3コミット分も進んでいたりする。誰もボードを信用しなくなり、誰も使わなくなります。
トリアージの判断が1人の頭の中にしかない。受け付け担当者は、あるバグがすでに報告済みであること、ある機能が前四半期に却下されたこと、あるタスクにはまずデザインのインプットが必要であることを覚えています。その人が不在になれば、重複が作られ、受け入れ段階で断るべきだった作業にエージェントが着手してしまいます。キューには記憶がないのです。
割り当てとスコープが、同じ慌ただしい瞬間に決められてしまう。人間がタスクを拾って質問してくれれば、曖昧なスコープでも何とかなります。しかしエージェントは質問するために立ち止まりません。与えられた情報だけで実行し、自信満々に間違った結果を返してきます。薄いトリアージのコストは、「チームメイトが一瞬戸惑う」から「エージェントが誤った対象に実行とレビューサイクルを浪費する」へと移りました。
混在バックログをトリアージする手順
人間とエージェントのバックログを健全に保つ手順は次のとおりです。各ステップには、それが防ぐ失敗を明記します。
1. バックログに触る前に受付キューを片付ける。新規リクエストはバックログに直接入るのではなく、Triage に入ります。各項目は、受け入れる、断る、重複とする、後回しにする、の4つの判断のいずれかで処理します。トリアージは受付キューであり、保存済みフィルタでもフォームビルダーでもないため、判断は明示的に記録されます。防ぐ失敗：断った作業や重複作業が、いつの間にか実際のタスクになり、後でエージェントが拾ってしまうこと。
2. エージェントに割り当て可能になる前にタスクを整形する。受け入れた項目はタスクになりますが、受け入れ基準を書き、リポジトリを紐づけ、制約を記入している間はバックログに留まります。時間に追われると省略されがちなステップです。防ぐ失敗：1行のタイトルだけでエージェントが実行し、文言には技術的には合致するものの意図を外した成果物を返してしまうこと。
3. 担当者を決め、「どのエージェントか」を本当の選択として扱う。人間に向くタスクもあれば、エージェントに向くタスクもあります。さらにエージェントの中でも、リファクタリング、テスト作成、ドキュメント更新では適任が異なります。暇なエージェントにデフォルトで回すのではなく、意図的にルーティングしましょう。コーディングエージェントのルーティングガイドでは、その判断の下し方を解説しています。防ぐ失敗：適性の低いランタイムが、不向きなタスクを延々と処理してしまうこと。
4. 本当に準備が整うまでバックログに置いておく。これがゲートです。タスクは完全に割り当て済みでも、実行が始まらないままバックログに留まることができます。これを活用しましょう。スコープが固まり、実際に作業を始めたいと思うまでは動かさないこと。防ぐ失敗：誰かが誤った列にドラッグしたせいで、書きかけのタスクが実行を起動してしまうこと。
5. コミットして、実行を開始させる。タスクを準備完了ステータスに移すか、スプリントに取り込みます。準備完了のエージェントが割り当てられたタスクがバックログを離れ、コンピュータとランタイムが利用可能であれば、実行が始まります。これでステータス変更と作業が同一のイベントになり、まさにそれが狙いです。
サイクルを回すチーム向けに、人間とエージェントのチームのためのスプリントプランニングでは、同じコミットのステップが単一タスクではなくタイムボックスを対象にする方法を示しています。
バックログのステータスが実行ゲートになる
マインドセットの転換はこうです。人間のボードでは、ステータスは現実を説明するラベルです。人間とエージェントのボードでは、ステータスは現実を変えるレバーです。タスクをバックログから動かすことがエージェントを起動する行為であり、つまりトリアージの規律がそのまま安全機構になります。
このゲートは、人間とエージェントの契約が属する場所でもあります。エージェントは調査し、実行し、テストし、報告します。人間は何をバックログに入れ、何をコミットし、何を出荷するかを決めます。自動化は、チームの判断が必要なところで止まります。Plan ビューはバックログ、スプリント、プロジェクトを1か所にまとめるので、コミットの判断がターミナルに埋もれず可視化され、実行、ブロッカー、結果、レビューはいずれもプライベートセッションに散らばらずタスクに戻ってきます。
だからこそ、エージェントを使う場合はバックログの衛生管理がより重要になるのです。乱れた人間のバックログは、ただの散らかりにすぎません。乱れたエージェントのバックログは、時折ひとりでに動き出す散らかりです。ボードは、コンテキスト、オーナーシップ、進捗、結果、人間によるレビューを、受け入れからリリースまで可視化し続けます。これが、あなたが管理するキューと、あなたを管理するキューの違いです。受け入れではなくレビューが滞留するようになった場合、それは別のボトルネックであり、人間によるレビューが真の制約である理由で扱っています。
ボリュームが少なければ、スプレッドシートと手動の規律でも運用できます。すでに安定した受け入れ処理をこなし、複数のエージェントを動かしているなら、Sharkly がトリアージキュー、バックログのゲート、単一の共有ボードを提供し、そうした判断があなたの頭の中だけに留まらなくなります。同じワークフローをより広い視点で見たい場合は、AIエージェントのタスク管理のガイドと、トリアージと個人用Inboxの違いをご覧ください。
今日から実行できるトリアージチェックリスト
現在のボードに対してこれを実行してください。「いいえ」はすべて、エージェントがあなたを驚かせる箇所です。
- 新規リクエストはバックログの前にどこかへ入りますか？受け入れが直接「To Do」に行くなら、受け入れ／却下／重複のステップがなく、重複は避けられません。
- すべてのバックログタスクのスコープは、他人に渡せる品質ですか？新入社員に渡して十分でないなら、エージェントにも十分ではありません。
- タスクを動かすと実際に何かが始まりますか？ステータス変更が単なるラベルなら、ボードと作業は乖離していきます。
- 割り当ては、どのエージェントかを含めて本当の判断ですか？暇なエージェントに任せるのはルーティングではありません。
- 今この瞬間、各エージェントが何に取り組み、何がレビュー待ちかを答えられますか？その答えが誰かの記憶やターミナルのスクロールバックにあるなら、トリアージには共有された信頼できる情報源がありません。
- 終わった作業はプライベートセッションではなくタスクに戻りますか？結果、ブロッカー、差分は共有記録上にあるべきで、そうしてこそレビューが動けます。
エージェントの数を増やす前に、最初の2つを直しましょう。クリーンな受け入れステップと誠実なタスクスコープが、高くつく失敗のほとんどを防ぎます。それ以外は、すでに意味を持つバックログの上での磨き込みにすぎません。
