要件レビューから実装、コードレビュー、テストと修正まで。重要な判断を人が担いながら、Waker が連携する様子を紹介します。
Waker が開発サイクルに参加する流れ
要件を話し合うグループで、プロダクト Waker が作成済みの PRD（製品要求仕様書）を持ち込み、担当の開発 Waker にレビューを依頼しました。
開発 Waker の結論は「条件付き承認」でした。早急に明確化すべきブロッキングの問題が3件、補足が必要な詳細が9件、さらに人の判断が必要な論点が6件ありました。それぞれに選択肢とトレードオフが示されています。ドラフトをどう保存するか、承認の境界をどこに置くか、テンプレートの上限をいくつにするか、といった技術的な取り決めです。
プロダクト Waker はグループ内で人間のプロダクト担当者と項目ごとに確認して PRD を確定し、開発 Waker は他のメンバーの確認に向けて Spec を作成しました。
14:20、開発メンバーが指示を出しました。release ブランチから作業ブランチを作成して実装を始め、完了後は別の開発 Waker に直接コードレビューを依頼する、という内容です。
15:31、レビュー対象の変更が提出されました。スナップショット境界エンジン、3つのデータベーステーブル、10本の HTTP ルート、7つの CLI サブコマンドを含み、差分は +5773/-4。150件のテストがすべて成功しました。
16:07、レビュー担当 Waker が最初の結果を返しました。3つのプロフィール項目で JSON が二重エンコードされるブロッキングの問題1件と、提案6件です。開発 Waker はその後20分以内に問題を修正し、提案のうち5件を採用しました。
16:34、再レビューが承認され、レビューのゲートがグリーンになりました。
17:55、テスト Waker は PRD と Spec に基づく36件のテストケースを作成・実行し、見つけた3件のバグをグループに報告しました。開発 Waker は修正後、開発責任者に個別メッセージを送り、マージしてよいか確認しました。
作業開始からマージ可能な状態になるまで、4時間未満でした。Waker は独立して考え、作業し、それぞれの役割の境界も明確です。権限が必要な場面では人を待ち、問題は隠さず報告します。チームメンバーは PRD やコードを自ら書いていませんが、方向性、役割分担、安全上の境界、技術的な取り決め、成果の受け入れという重要な判断をすべて担いました。
