なぜ要るか
前の術で、1つの仕事を任せられるようになりました。ここから先で詰まるのは量です。
作るものが増えると、頼む相手は1人のままでは回りません。ゲーム、記事、投稿、集計、経理。全部を同じ相手に頼むと、毎回全部の前提を説明することになります。
だから持ち場を分けます。 担当ごとに、見る場所と守る決まりを固定します。
これを僕は「AI社員」と呼んでいます。呼び方は何でもよくて、大事なのは分け方です。
使う道具: なし（テキストファイルと記録）
AIプロンプト
この術の作業をAIへ任せるときは、これをそのまま貼ってください。
1)（ここへ担当の決まりを貼る）
6-3 の履歴の丸を、勝敗だけでなく出した札も見えるようにして。
2) 今日やったこと、次にやること、詰まったことを progress.md へ3行で追記して。
担当の決まりは「やってみる」の2で書いた5行を貼り、作業の内容は自分の依頼に置き換えてください。
分け方は「見る場所」で決めます
役割で分けたくなりますが、それだけだと曖昧になります。 実際に効くのは、触るフォルダで分けることです。
僕の分け方はこうなっています。
事務・統括の担当（5人）
統括 全体の状態を見て、次を決める
マーケティング 数字を見て、次の一手を決める
記事作成 原稿を書く
記事投稿 媒体へ出す
日誌 その日の記録を残す
開発の担当（7人）
リポジトリ1つに対して1人。触る場所が重ならない
リポジトリというのは、1つの作品のファイルをまとめて置いている場所のことです。1-4でGitを入れたあのフォルダが、そのままリポジトリです。
開発の担当は、リポジトリと1対1です。 これが要点です。
担当A → /path/to/game-a この中だけを触る
担当B → /path/to/game-b この中だけを触る
こうすると、7-4で書いた「同時に走らせると壊れる」が起きません。持ち場が物理的に分かれているからです。
担当ごとに書くのは3つだけ
1人ぶんの定義は短く済みます。僕は1ファイルに3つだけ書いています。
name 担当の名前
description 何をする担当か
developer_instructions 守る決まりと、始業時にやること
長い経歴書は要りません。「何をして、何をしないか」だけです。
そして呼び出しは1行にしておきます。
<AIのコマンド> -C <その担当が触るフォルダ> "<担当の決まり>\n\n<今日の依頼>"
-C は「このフォルダを作業場所にして始めて」という指定です。担当の決まりと今日の依頼を、続けて1つの文として渡しています。
フォルダを渡すのが効きます。 これだけで「他の持ち場を触らない」がほぼ守られます。
進捗の正を1箇所に置きます
ここが一番大事です。担当を増やすと、状態がバラバラになります。
やってはいけないのは、担当ごとにメモを持たせることです。
| 駄目な形 | 起きること |
|---|---|
| 担当ごとにメモファイル | 全体が見えない。同じ話が2箇所に書かれる |
| チャットの履歴だけ | 探せない。前回どこまでやったか分からない |
だから進捗はデータベース1つに集めます。 僕はSQLiteのファイル1つを正にしています。SQLiteは、ファイル1つで動く小さなデータベースです。6-4で出てきたサーバーのDBと違い、サーバーを立てずにそのまま使えます。
いまの中身を数えるとこうです。
記録（notes） 197件
進捗（entries） 133件
決定（decisions） 9件
学び（learnings） 10件
詰まり（blockers） 2件
担当ごとの記録数はこうなっています。
simple-puppet 47
tdmodeler 41
skill-cli 37
マーケティング 18
game-ninlabo 17
aireporter 15
cnp-tradingcard-online 9
その他 13
偏っていて構いません。 むしろ偏りが、いまどこに力を入れているかを表しています。
見る画面は「生成物」にします
状態を人が読む形にも出します。ただし手で書きません。
<!-- 生成物。手書き禁止。正はデータベース。 -->
### 統括
- status: waiting_review
- summary: 日次の改善ループを設計・実装
- next: ダッシュボードの送信失敗の原因特定
生成物というのは、元のデータから機械が作り出したファイルのことです。だから手で書き換えても、次に作り直した瞬間に消えます。1行目のコメントは、未来の自分に対する注意書きです。
各担当について3つだけ出します。
| 項目 | 中身 |
|---|---|
status |
いまの状態（作業中、レビュー待ち、詰まり） |
summary |
直近で何をしたか |
next |
次にやること |
next があるのが要点です。 これが埋まっていれば、次に呼んだとき説明が要りません。空なら、その担当は止まっています。
そしてこの画面は必ず生成物にします。 手書きすると、データベースと画面で違うことが書かれる日が来ます。6-1から繰り返している「正は1つ」です。
学びを溜める場所を作ります
これが効くまでに時間がかかりますが、効き始めると大きいです。指摘されたことを、担当の記憶ではなく記録に残します。
僕の記録にはこういうものが入っています。
・記事の結びは「！」で終える。中間の文まで無理に！にはしない
・書く前に狙い（動かす数字・仮説・根拠・成功条件・中止条件）を宣言する
・基準値は実データから都度取る。過去の会話に出てきた数字を再利用しない
・バナーは装飾の指定を省かない。「情報量は抑える」と書いて自分で装飾を禁止しない
全部、一度失敗して指摘された内容です。
大事なのは形です。「何を」だけでなく「なぜ」を書きます。 理由が無い決まりは、状況が変わったときに守るべきか判断できません。
そして溜めた学びは、次に呼ぶとき読ませます。 読ませないなら溜める意味がありません。
統括を1人置きます
担当が5人を超えたあたりから、誰に頼むかを決めるのが仕事になります。
そこで統括を置きます。やることは2つだけです。
| 統括の仕事 | 中身 |
|---|---|
| 状態を見る | 全担当の status と next を読む |
| 割り振る | 次にやることを、担当へ渡す |
統括は自分で作業しません。 ここを守らないと、統括が全部やり始めて、担当が空になります。僕はこれを一度やりました。
やってみる
持ち場を2つに分ける
最初は2人で十分です。触るフォルダが違うものを選んでください。フォルダが違えば、同時に頼んでも書き込みがぶつかりません。7-4で書いた並列の事故を、分け方だけで避けられます。
担当1 → ゲームのフォルダ 担当2 → 記事や告知のフォルダ1人ぶんの決まりを5行で書く
name: game-dev description: 三つの的の開発を担当する instructions: - 触るのは my-first-game の中だけ - 変更前に commit する - npm test が通らない状態で終わらない - 迷ったら進めずに質問して止まる4行目を必ず入れてください。 7-4と同じ理由です。
進捗の置き場を1つ決める
最初はファイル1つで構いません。担当ごとに分けないことだけ守ってください。
progress.md 全担当の記録をここに追記するデータベースにするのは、探しづらくなってからで間に合います。
呼ぶときにフォルダと決まりを渡す
<AIのコマンド> -C ./my-first-game "<担当1の決まり> 6-3 の履歴の丸を、勝敗だけでなく出した札も見えるようにして。"終わったら記録を追記させる
今日やったこと、次にやること、詰まったことを progress.md へ3行で追記して。「次にやること」を必ず書かせてください。 ここが次回の入り口になります。
保存する
git add . git commit -m "担当を2つに分けて、進捗の置き場を決めた" git push
つまずきどころ
担当を増やしたのに、結局全部自分で説明している
決まりが担当のファイルに書かれていません。毎回説明している内容が、そのまま決まりです。 書き写してください。
同じ話が2箇所に書かれている
進捗の置き場が分かれています。1つに寄せてください。担当ごとのメモは作らないのが原則です。
前回どこまでやったか分からない
next を書かせていません。終了時に必ず書かせてください。
統括が全部やってしまう
「統括は自分で手を動かさない」を決まりに書いてください。書いていないと、できる相手はやってしまいます。
担当が多すぎて管理が仕事になった
分けすぎです。触るフォルダが同じなら、同じ担当にまとめてください。役割の名前で分けるのは後です。
担当が学ばない
学びを記録していて、それを読ませていないパターンです。呼ぶときに読ませる形になっているかを確認してください。
Windows の場合
フォルダの渡し方が変わるだけで、考え方は同じです。パスの区切りに注意してください。
次の一歩
いま自分がやっている作業を、2つの持ち場に分けてください。
紙に書くだけで構いません。「これはどちらの持ち場か」を迷う作業が出てきたら、そこが境界の設計ミスです。 その1件が、分け方を教えてくれます。
持ち場が分かれて回るようになりました。次は、使うAIそのものを目的で使い分けて、費用を想定内に収めます！
