AI-DLC のガバナンス 第1部：バックログは「人間の意思決定のキュー」になる
ゆうべ、6 つのリポジトリで 40 件のエージェント実行が終わりました。今朝、誰かがそれをどうするか決め なければなりません。この一文が変化のすべてであり、あなたのプロジェクト管理ツールはそのほとんど何も 想定して作られていません。
念のため用語を 1 つ。AI-DLC（AI-Driven Development Life Cycle）は、定義されたプロセスの内側で AI エージェントが「作る」を担い、人間は決められた地点で判断する、というデリバリーの進め方です。 インテントを書くと、システムがそれを作業単位に分解し、エージェントが並列で作り、人間は途中で質問に 答えたり承認したりします。それが何で、どうセキュアにするかは以前に書きました。
この記事は、誰も私に警告してくれなかった部分についてです。それが回り始めたあと、プロジェクト管理 に何が起きるのか。ガバナンスのアーキテクチャでもツールの調達でもなく、「いま何が起きているかを知り、 どうするか決める」という日々の営みのほうです。
短く言えば、あなたのボードはいま、仕事の「間違ったほうの半分」を測っています。
トラッカーが黙って置いている前提
Jira と、そこから派生したすべては、あまりに当たり前すぎて文書に一度も現れない前提の上に建っています。 高くつくのはソフトウェアを書くことだ、という前提です。
いちど見えると、あらゆるところに見えます。見積もりがあるのは、作るのが遅くて予測が要るから。担当者の 割り当てがあるのは、作るのが特定できる 1 人の人間だから。ベロシティがあるのは、作ることがボトルネック で、その速度を知りたいから。
3 つとも同じ問い — どれだけ作れるか — への答えです。そしてその問いは、静かになりました。
2 つの列を見てください。左では、1 枚のチケットが 1 つの成果物を生み、人間の判断がおよそ 1 回必要で、 その周りに数日の余裕がありました。右では、1 つのインテントが 4 つを並列で生み、人間の判断は相変わらず 必要で、余裕は数時間に潰れています。
作ることは安くなりました。決めることは安くなっていません。 そしてあなたのトラッカーには ストーリーポイントの欄はあっても、「これはどれだけの判断を消費したか」の欄はありません。最近まで、 誰もそれを必要としなかったからです。
トラッカーに AI を後付けすると、役に立っている気はするのに数字が動かないのも同じ理由です。 Atlassian はまさにそれをやっています — 作業項目をプルリクエストに変える Jira のコーディング エージェント、ボードに配線されたエージェント。まっとうな製品ですし、売れると思います。そしてそれは、 すでに速かったほうの半分を速くしています。
だからバックログは「意思決定のキュー」になる
私にとってすべてが噛み合った言い換えがこれです。バックログをやるべき作業のリストと考えるのをやめて ください。いまそれは下すべき判断のリストであり、それを回す人の仕事は進捗を追いかけることではなく、 裁定することです。
左の列の 1 項目ずつが、先に進めない複数のエージェント実行の前に立っている人間です。面白いのは経過時間 の列です。停止した実行は新しい形の仕掛かり在庫であり、昔のそれと違って、置いておくコストはゼロで、 放置するコストは無限大です。
壁に貼る価値のある数字
エージェントを足せばいい世界では、ベロシティはほとんど何も語りません。平たい言葉で、5 つの代替案を。
- 意思決定レイテンシ — 止まった実行が人間を待つ時間。これがいまの本当のサイクルタイムであり、 あなたが実際に制御できる唯一の部分です。
- 巻き戻し率 — 承認したものが後で取り消される頻度。これがほぼゼロで、かつ承認ゲートがたくさん あるなら、誰も本気で読んでいません。
- 無人マージ比率 — 人間が経路に一度も入らずマージされた割合。下げるべき数字ではありません。 意図して選ぶ数字であり、そのうえで見張る数字です。
- ゲート迂回回数 — 誰が、何回ゲートを回避したか。
- 証跡の完全性 — マージ済みの作業のうち、聞かれたときに「誰が許可したか」の記録を丸ごと出せる 割合。最初の監査まで誰も測らず、そのあとは誰もこれしか聞きません。
まず見るのは巻き戻し率です。ループの中の人間が何かをしているのかを教えてくれる、唯一の数字だから です。
採用する価値のある 4 つの仕事
どの役割が生き残るかを綺麗に導くには、「機械に渡せないものは何か」と問うことです。3 つあります。 何を作るべきかを決めること、取り返しのつかないものを判断すること、そして後から記録に対して答えること。
いちばん強く推したいのはセンサー作成者です。ここで最もレバレッジの高い仕事でありながら、配置されて いるのをほとんど見たことがありません。
この世界でのセンサーとは、決まった地点で走って合格か不合格かを返すだけの自動チェックです。センサー 作成者の仕事は、誰かが手で繰り返しているレビューを、そのチェックに変えることです。
経済性は微妙な話ではありません。ある種類のミスを捕まえるレビューアは、毎回の実行であなたに注意力を 支払わせ続けます。そのレビューをチェックに変換したエンジニアは、一度だけ支払い、そのチェックは夜に 4 回動いても 400 回動いても同じコストです。それでも組織図にはレビューアがいて、センサー作成者はいま せん。「AI が通らなければならないテストを書く」という仕事が、誰も発明していない職種だからです。
私が最初にするのはこの採用で、あなたの最良のレビューアを充てます。（その人が実際に何を書くのかは、 深くてかなり美しい話題で、それ自体が 1 本の記事になりました。）
画面は統制の一部である
ここが意外なところで、プロジェクト管理の記事が最終的にセキュリティの話になる理由です。
これをうまくやっているプラットフォームは、すでに、曖昧なところでエージェントの実行を止めて人間に 尋ねます。結構なことです。ところが、その質問はどれも画面上で同じ見た目をしています。 「これを invoice と呼ぶか billing document と呼ぶか」という問い合わせが、main にマージしてエージェントに 請求サービスへの書き込み権限を与える承認と、同じリストに、同じ大きさで、同じボタンで並びます。
これは聞こえるより重要です。注意力は上限が固定で、当座貸越のない予算です。均一なリストは、確実に、 均一な反応を生成する装置になります。40 件目には、注意深く有能な人がクリックしています。これは研修で 直せる規律の問題ではありません。設計がそう出力しているのです。
画面が代わりにやるべきこと、短く 6 つ。
- 到着順ではなく、取り消しコスト順に並べる。
- 成果物ではなく結果を見せる。 「Stage 6 requires approval」は人間に何も伝えません。「main に マージし、請求サービスへの書き込みを与え、決済に触れる」は判断です。
- その変更が届く範囲を、決める瞬間に画面に出す — どのリポジトリ、どのシークレット、どのシステム。
- 手間を賭け金に合わせる。 無害なものはワンクリック。取り消せないものは確認文字列の入力と、 もう 1 人。
- 前回の類似承認から何が変わったかを見せる。 人間は絶対評価が苦手で、違いに気づくのは得意です。
- 後ろで何が待っているかを見せる。 3 レーンが止まっていると知っている人は、違う判断をします。 そうあるべきです。
これの代償
意思決定キューの指標は馴染みがなく、操作しやすい。 とくに巻き戻し率は正直さを罰します。悪い変更を 素早く戻すチームは、放置するチームより数字が悪く見えます。インシデント件数と並べて見せないと、まさに 逆の教訓を教えます。
「センサー作成者」は、自動化の問題の服を着た再スキル化の問題です。 最良のレビューアに、その人が 知られている仕事をやめてくれと頼むことになります。喜ぶ人もいます。面白い仕事から外されたと受け取る 人もいて、調子の悪い週には、それはまったくの的外れでもありません。
重要度バナーは、その背後のモデルの信頼性までしか信用できません。 自信満々に間違った「これは 取り消せません」は、バナーがないより悪い。本当に重要な 1 回のために必要な信頼を先に使ってしまうから です。信号機を作る前に、各ステップが何に届くのかの棚卸しを作ってください。
そしてチームの出荷が遅いなら、これは何も当てはまりません。 人間がまだ全部をレビューしていて、 その時間もあるなら、あなたのボードは問題ありませんし、私は変えないよう説得します。この設計全体は、 あなたにはまだ来ていないかもしれない「量」への対応です。
月曜にやること
- チケットではなく、判断を数える。 1 週間、エージェントの実行が止まって人間を待った回数をすべて 記録してください。それがあなたの本当のバックログで、書き出して見たことのあるチームはほとんど ありません。
- 承認の抜き打ち点検をする。 直近で誰かが押した 20 件の承認を取り出し、予告なしに「そのうち 3 件は実際に何を許可したのか」を尋ねる。20 分です。私が設計したシステムを含め、初回でうまく いったことはありません。
- センサー作成者を名指しで決める。 1 人。最良のレビューアの時間をそこに充て、繰り返しのレビューを チェックに変えてもらう。
どれも予算も、ベンダーも、組織変更も要りません。
要するに
アジャイルのために作った計器は、1 つの問いへの答えでした。十分に作れるか？ 良い答えでした。その問い は機械が片付けてしまい、その下にある問い — 取り返しのつかないことについて、十分に速く、十分にうまく 決められるか？ — には、まだ計器が 1 つもありません。
それを作るのが今後 2 年の面白い仕事で、始まりは地味です。自分のボードを見て、簡単なほうの半分を測って いると認めるところから。
この分野の仕事は、進むにつれて書いています。こうしたプログラムを回している方は、 LinkedIn で連絡が取れます。私がメンテナンスしているツールは shenril と BlueSquadron にあります。