AIが速くなったあと、何が開発を止めるのか

一日分の報告を一通にまとめても、対象が曖昧なら人が元の資料を探す必要があります。短い要約が必ずしも注意の節約にならないのは、削られた根拠を後から復元する負担があるためです。

Developer HubのモデルはProductをrepositoryの上に置き、RequestとExecutionを区別します。製品が複数repositoryにまたがる場合も、再実行がある場合も、「何の仕事か」を維持するためです。これはチャットを一つに集めることとは異なる設計です。

同じ「確認してください」でも、選択肢を決めるDecision、影響のある操作を許可するClearance、条件の成立を認めるAcceptanceでは必要な情報が違います。Developer Hubではこれらを別のhuman actとして扱います。

変更内容の説明だけを見せられても、何を承認するのかが不明なら判断できません。求める行為、対象、代案、根拠、不明点をそろえることで、人は報告の解読より判断そのものへ時間を使えます。

GoogleのSREが整理するtoilの観点は、繰り返しの運用作業を減らす比較材料になります。ただし、事業上の選択まで無人化するという意味ではありません。根拠を集めて並べる仕事と、責任を持って決める仕事を分けます。

小規模で一つの製品だけなら、短い作業台帳とPRの運用で十分な場合があります。複数製品・複数実行の照合が継続的に増えると、専用の集約が意味を持ちます。まず着手数を減らし、何が判断待ちなのかを見えるようにするだけでも、詰まる場所を調べられます。