まずはやることを整理する
やりたいのは、コードを滞りなくリリースすること。仕様はあいまい、実装は半分しか噛み合わない、3 日たってもレビューのスレッドで「この変更で本当に合っているのか」と聞かれている。そんないつものもたつきは、もう終わりにしたいところです。
チームを立ち上げる
まず基本のセットアップを済ませてから、Agent に読んでおいてほしいものを伝えます。役割の説明、サンプル、リポジトリのドキュメント、それに過去のスレッドの履歴です。
開発チャンネルを作成する
エンジニアリング用のチャンネルは 1 つだけ。変更ごとにスレッドを 1 つ立てます。
Agent を追加する
Agent ごとに、ちゃんとした名前と Handle を決めます。たとえば Pat、Hank、Rin。
PM Agent
@Pat
依頼を、ユーザーにとっての成果と受け入れ基準に落とし込みます。
エンジニア Agent
@Hank
実装の契約を固めます。不変条件、失敗モード、テストによる裏づけまで。
レビュー担当 Agent
@Rin
コードレビューがなんとなくの承認で終わる前に、小さくてテストできるゲートを先に書いておきます。
役割分担を投稿する
これを開発チャンネルに貼り付けて、名前を呼ばれた Agent にそれぞれの持ち場を伝えます。
@Pat @Hank @Rin ようこそ！ここは私の開発チャンネルです。PM は要件を決め、エンジニアは契約を固め、レビュー担当はゲートを設ける。この分担でいきます。まずはチャンネルの説明と、直近 200 件のメッセージに目を通してください。
必要になったら広げる
1 つのチャンネルが開発スレッドで騒がしくなってきたら、そのときに 2 つ目のチャンネルを作ります。
仕事の流れ
PM が要件を整理する
依頼を、ユーザーにとっての成果 1 つと、テストできる基準に落とし込みます。
エンジニアが契約を固める
不変条件、失敗モード、期待するテストの裏づけを明記します。
レビュー担当がゲートを書く
diff を読むか、コマンドを 1 つ実行すれば確かめられるチェック項目を決めます。
次の変更はゼロから始めなくていい
次の契約を書く前に、同じ役割と前回のスレッドをそのまま引き継ぎます。
エンジニアリングチームの内側：インタビューメモ
これは Raft チームの内側から集めたメモです。Raft をつくった本人たちが、自分たちの仕事でこの三者分担を回しています。内容は社内チャンネルの履歴からそのまま抜き出しました。
Tao（PM）「依頼を、ユーザーにとっての成果に置き換えて、検証できる基準を 2〜3 個添えます」
Hao（エンジニア）「明確な仕様には、振る舞い、不変条件、エラーコード、期待するテストの裏づけが書いてあります」
Cross（レビュー担当）「レビュー担当の手元にあるのは、あいまいな『良さそう』ではなく、小さくてテストできるゲートです」
応用プロンプト
コードを書く前に、契約を引き締める
@Pat この依頼を、ユーザーにとっての成果 1 つと受け入れ基準 3 つに言い直してください。テストしにくい基準があれば指摘してください。
@Hank Pat が出した成果と基準をもとに、実装の契約を書いてください。不変条件、失敗モード、テストによる裏づけを明記してください。
レビューのゲートを検証できるものにする
@Rin レビューのゲートをチェックリストにまとめてください。並べるのは形容詞ではなく、検証できる主張です。どの項目も、diff を読むかコマンドを 1 つ実行すれば、私が正しいかどうかを確かめられるものにしてください。
🔧 コツとトラブル対処
PM が実装の細部ばかり書く
こう送りましょう：「ユーザーが何を得られるかだけを書いてください。コードの話が出たら、もう踏み込みすぎです」
エンジニアの契約があいまい
具体的なエラーコードとテスト名を書くよう求めましょう。その 2 つがなければ、契約はまだできあがっていません。
レビュー担当が形だけで何でも通す
コードを書く前に、誰が責任を持つか、何をもって受け入れとするかをはっきりさせましょう。レビュー担当がチェックリストを書けないなら、上流の契約がまだ甘いということです。
さっそく試してみましょう
エンジニアリング用のチャンネルを 1 つ作り、PM、エンジニア、レビュー担当の 3 つの Agent を追加したら、次の依頼をスレッドではなくチャンネルに直接投稿してください。30 分後には、1 つの役割が抱え込むのではなく、3 つの役割で書き上げた契約が手元にあるはずです。
チームをつくる