Grok Build 101: Grok Buildと役割分担そしてDoD

Grok Buildを使っていて思うのは、これは単なる「AIにコードを書かせるツール」ではなく、一人でScrumを回すための強力なチームだということです。私はこの関係性をこう解釈しています。

• 自分 = Scrum Product Owner
• Grok Build = Scrum Master かつ 開発チーム

役割の整理

私(Product Owner)の責務

• プロダクトのビジョンと優先順位を決める
• 何を作るか、何を作らないかを判断する
• 最終的なProductionへのマージを承認する

Grok Buildの責務

• 計画の支援とプロセスのファシリテーション（Scrum Master）
• 実装・リファクタリング・テストコードの作成（開発チーム）
• Definition of Doneを満たした時点でStaging環境へのデプロイまでを実行する

この役割分担がうまく機能するかどうかの鍵は、Definition of Done（DoD）をPlanningの段階で明確に定義することにあります。

Definition of Doneの中核は「Playwright e2e」

私が現在運用しているDoDの中心はPlaywrightによるEnd-to-Endテストです。

• 機能が実装されただけでは「Done」ではない
• 関連するPlaywright e2eがすべてパスした時点で初めて「Done」とする
• Doneになった瞬間、GrokはGitHubのStagingブランチへのデプロイまでを自律的に実行してよい

言い換えれば、e2eが通っていない状態でStagingに上げることは許さない、というルールです。

このルールがあるおかげで、Grokにかなりの裁量を与えても品質が崩れにくくなります。

ワークフローの全体像

1. Planning
   機能の要件と、その機能を検証するためのPlaywrightシナリオを一緒に定義する
2. Development
   Grokが実装を進める。途中で必要に応じて計画を修正する
3. Definition of Done
   Playwright e2eがすべてパスする
4. Staging Deploy
   GrokがStaging環境へデプロイする（ここまでは自動化を許容）
5. Production
   人間がStagingを確認し、問題なければ手動でProductionへマージする

この最後の「人間によるProduction判断」を残している点が重要です。

Grokは非常に優秀ですが、ビジネス的・リスク的な最終判断はまだ人間の領域だと考えています。

なぜこのモデルがうまく機能するのか

• スピード
  実装からStagingまでを高速に回せる
• 品質の担保
  DoDをPlaywrightに固定しているため、機能追加のたびに回帰テストが強制される
• 責任の分離
  「作る」のはGrokで、「最終的にリリースする」のは人間、という明確な境界線がある
• 学習効果
  Planningでe2eシナリオを先に書く習慣が、要件定義の精度を自然に高めてくれる

まとめ

Grok Buildを使いこなすと、一人でも「Scrumチーム」を運営できるようになります。ただしそのためには「DoDをしっかり定義する」計画段階にしっかりと時間をかける必要があります。