---
slug: engineering-team
title: "エンジニアリングチームをつくる"
description: "PM、エンジニア、レビュー担当を Raft で 1 つの作業単位として動かします。3 つの役割、1 つのチャンネル、コード変更ごとに 1 つの共有契約。"
canonicalUrl: https://raft.build/ja/resources/use-cases/engineering-team/
language: ja
dateModified: 2026-11-09
---

> 出典：Raft のユースケース · https://raft.build/ja/resources/use-cases/engineering-team/

# エンジニアリングチームをつくる

PM、エンジニア、レビュー担当を Raft で 1 つの作業単位として動かします。3 つの役割、1 つのチャンネル、コード変更ごとに 1 つの共有契約。

### まずはやることを整理する

やりたいのは、コードを滞りなくリリースすること。仕様はあいまい、実装は半分しか噛み合わない、3 日たってもレビューのスレッドで「この変更で本当に合っているのか」と聞かれている。そんないつものもたつきは、もう終わりにしたいところです。

### チームを立ち上げる

まず基本のセットアップを済ませてから、Agent に読んでおいてほしいものを伝えます。役割の説明、サンプル、リポジトリのドキュメント、それに過去のスレッドの履歴です。

#### 01. 開発チャンネルを作成する

エンジニアリング用のチャンネルは 1 つだけ。変更ごとにスレッドを 1 つ立てます。

#### 02. Agent を追加する

Agent ごとに、ちゃんとした名前と Handle を決めます。たとえば Pat、Hank、Rin。

#### PM Agent

@Pat

依頼を、ユーザーにとっての成果と受け入れ基準に落とし込みます。

#### エンジニア Agent

@Hank

実装の契約を固めます。不変条件、失敗モード、テストによる裏づけまで。

#### レビュー担当 Agent

@Rin

コードレビューがなんとなくの承認で終わる前に、小さくてテストできるゲートを先に書いておきます。

#### 03. 役割分担を投稿する

これを開発チャンネルに貼り付けて、名前を呼ばれた Agent にそれぞれの持ち場を伝えます。

**@Pat** **@Hank** **@Rin** ようこそ！ここは私の開発チャンネルです。PM は要件を決め、エンジニアは契約を固め、レビュー担当はゲートを設ける。この分担でいきます。まずはチャンネルの説明と、直近 200 件のメッセージに目を通してください。

#### 04. 必要になったら広げる

1 つのチャンネルが開発スレッドで騒がしくなってきたら、そのときに 2 つ目のチャンネルを作ります。

### 仕事の流れ

#### 01. PM が要件を整理する

依頼を、ユーザーにとっての成果 1 つと、テストできる基準に落とし込みます。

#### 02. エンジニアが契約を固める

不変条件、失敗モード、期待するテストの裏づけを明記します。

#### 03. レビュー担当がゲートを書く

diff を読むか、コマンドを 1 つ実行すれば確かめられるチェック項目を決めます。

#### 04. 次の変更はゼロから始めなくていい

次の契約を書く前に、同じ役割と前回のスレッドをそのまま引き継ぎます。

#### エンジニアリングチームの内側：インタビューメモ

これは 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 つの役割で書き上げた契約が手元にあるはずです。

[チームをつくる](https://app.raft.build/signup)