仕様駆動開発をチームに入れたら、最初に変わったのはチームの時間割だった
はじめに: ツールを入れたのに、なぜチームは速くならないのか
Copilot、Cursor、Devin。AIコーディングツールが次々と登場して、個人の生産性は明らかに上がりました。
ところが、チームとしてのアウトプットは比例して上がらない。この感覚を持っている方は少なくないのではないでしょうか。
自分自身、これまでの開発経験を通じて感じていたのは、個々の実装速度が上がっても、レビュー待ちの時間は変わらないこと。仕様の認識ズレによる手戻りは増えるし、レビュー担当エンジニアの判断待ちがボトルネックになりがちだということでした。
原因はツールではなく、チームの時間の使い方がAIのいない時代のまま据え置かれていたことにあるのでは？——そう考えて、新プロジェクトの立ち上げで新しいメンバーとチームを組むタイミングで、開発のリズムそのものを最初から設計し直すことにしました。
この記事では、BtoB SaaSを開発する5人チームでSDD（仕様駆動開発）を実践する中で、チームの仕事のリズム・時間設計をどう組み立てたかを共有します。技術論としてのSDDはすでに多くの良記事があるので、ここではPMの視点から「チームの時間割をどう組み立てたか」に焦点を当てます。
私たちのチーム
まず前提の共有です。
| 項目 | 内容 |
|---|---|
| プロダクト | BtoB SaaS |
| チーム構成 | フロントエンド1名、バックエンド2名、PM兼バックエンド1名（筆者）、インフラ1名 |
| 開発スタイル | SDDの思想をベースに、AIエージェント（Devin等）を組み込んで現在進行形で運用中 |
5人の少人数チームなので、一人ひとりの時間の使い方がチーム全体のアウトプットに直結します。大規模組織の制度設計ではなく、小さなチームの実践記として読んでください。
Before: よくある開発リズムの問題点
AIエージェントを活用する前の、典型的な開発チームの1日はこんな流れだと思います。
09:30 朝会（進捗共有・ブロッカー確認）
10:00 各自実装開始
（PMも実装しつつ、合間に仕様の質問に答える）
15:00 実装がひと段落、PRを出す
16:00 他メンバーのPRレビュー開始
17:00 レビューコメント対応 → 翌日に持ち越し
珍しくない流れです。もともと実装前にレビューや方針確認の場はあるチームが多いでしょう。ただ、Slackでの軽い確認や口頭のすり合わせが中心だと、「合意した」という状態が曖昧なまま実装に入りがちです。
結果、こういう問題が起きます。
🚦 レビュー渋滞
午後に一斉にPRが出て、レビューが翌日に押し出される。翌朝コメントを返し、対応されるのはさらにその翌日。実装自体は数時間なのに、マージまで2〜3日かかる。
🤔 「思っていたのと違う」問題
口頭で方針を確認したはずなのに、出てきたコードが想定と違う。口頭ベースだと、双方の解釈がずれていても気づけない。
⏳ PMの判断が埋もれる
PMがバックエンドの実装も兼任している場合、日中はコードを書きながら仕様の質問に答え、合間にレビューをする。どれも中途半端になり、判断のスピードが落ちる。
これらはAIツールを入れる・入れないとは無関係の構造的な問題です。ツールで個人の実装速度を上げても、この構造がそのままならチーム全体のアウトプットは変わりません。
転換点:「エージェントは夜も動ける」という当たり前の事実
先述のとおり、「夜間にエージェントを回して、朝にレビューするサイクルにしてはどうか」という提案はエキスパートからもらったものです。
言われてみれば当たり前なんですが、エージェントは夜間でも稼働できる。人間は昼間に判断する生き物です。この2つの性質が違うのに、全部を同じ時間帯・同じリズムで回そうとしていた。そこに構造的なムダがあったわけです。
参考：Addy Osmani "Your AI coding agents need a manager"（2026年1月）
後から調べてみると、Addy Osmaniがまさにこの考え方を2つのモードとして整理していました。
- ローカル・高タッチモード: アーキテクチャ判断、複雑なリファクタリング、曖昧な要件——人間がリアルタイムで介在すべき作業
- クラウド・非同期モード: 仕様が明確な機能追加、テスト生成、ドキュメント更新——投げてPRを待てばいい作業
自分たちが感覚的にたどり着いた「人間の時間とエージェントの時間を分ける」という発想が言語化されていて、腑に落ちました。
この分離をチームの仕事のリズムとしてどう形にするかが、PMとしての設計の出発点です。
After: 再設計した日次リズム
現在のチームで運用している1日のリズムはこうです。
【夜間】 AIエージェントがタスクを実行 → PRが上がる
【 朝 】 エンジニアがPRレビュー
（事前に合意したDesignドキュメントとの整合性チェック）
【 午後】 ブロッカー解消・認識合わせ
次の開発内容の設計・仕様策定
Designドキュメントの作成
「エージェントを夜に動かしただけ」に見えるかもしれませんが、本質的な変化は別のところにあります。
エンジニアの仕事が変わった
従来、エンジニアの主務は「コードを書く」ことでした。レビューや設計ももちろんやりますが、1日の大半は実装作業です。
SDDを導入した現在、エンジニアの主務は設計とレビューになっています。
午前中はエージェントが生成したPRをレビューします。ただし従来のコードレビューとは性質が違い、事前にDesignドキュメントとして設計を言語化しチームで合意しているので、レビュー観点は「Designドキュメントに沿っているか」に絞られます。
午後は次の開発サイクルに向けたDesignドキュメントの作成と、設計上の論点整理に時間を使います。
PMの判断タイミングが前倒しになった
PMの仕事——判断とブロッカー解消——はもともと変わっていません。変わったのは、判断がいつ行われるかです。
従来も実装前に方針の確認はしていましたが、口頭ベースだと実装が進んでから「この方針で合ってたっけ？」が走りがちでした。SDDではDesignドキュメントの段階で方針を明文化して合意を取るため、PMの判断が実装の「前」でしっかり完結します。
午後の時間も「実装中に発生した問題への対処」ではなく、「次のサイクルの仕様を固める議論」に変わっています。
誰もコードを書いていないが、開発は進んでいる
この体制で回してみて印象的だったのは、日中にチームの誰もコードを書いていないのに、毎朝新しいPRが上がってくるという状況でした。人間は設計し、レビューし、判断する。実装はエージェントが担う。
もちろん、すべてのタスクがこの流れに乗るわけではありません。後述します。
チーズモデル: レビューの蓋を前段に分散させる
ここまで読んで、こう思った方もいるかもしれません。
「エージェントが夜に大量のPRを出して、朝レビューするって、結局レビューがボトルネックになるのでは？」
正しい懸念です。自分もまさにこの問題——コードレビューの負荷をもっと軽くできないか——をエキスパートに相談したところ、提案されたのがスイスチーズモデルの考え方でした。
スイスチーズモデルとは品質保証やリスク管理の概念で、1枚のチーズ（チェック工程）には必ず穴がある。しかし複数枚重ねれば、穴を通り抜けるリスクを最小化できる、という考え方です。
コードレビュー1枚に品質保証を集中させると負荷が高くなりすぎるし、エージェントが書くコード量が増えればさらに上がります。そこで前段に複数の「蓋」を設けています。
蓋① Specレビュー（仕様の合意）
機能の要件と振る舞いをドキュメントとして言語化し、PM・エンジニア間で合意します。「何を作るか」のブレをここで潰します。
蓋② 設計レビュー会（Designドキュメントのチームレビュー）
全エンジニアが参加し、Designドキュメント（技術設計・データモデル・インターフェース定義など）をレビューする場です。「どう作るか」の方針を全員で確認します。
従来でも方針確認はありましたが、口頭やSlackベースだと「何が合意されたか」が曖昧になりがちでした。Designドキュメントという成果物をベースにすることで、合意が明文化され、後段のレビュー基準にもなります。
蓋③ コードレビュー（整合性チェック）
前段2枚の蓋を通過しているので、コードレビューは「Designドキュメント通りに実装されているか」の確認に集中できます。設計方針の妥当性をこの段階で議論する必要がありません。
タスクの3分類: 何をエージェントに渡し、何を渡さないか
時間割設計の前提として、すべてのタスクを同じように扱わないことが重要です。Addy Osmaniの記事[1]を参考に、3つに分類して運用しています。
① 完全委任（Delegate）
仕様が明確で、Designドキュメントが書き切れるタスク。エージェントに投げてPRを待ちます。
- 仕様確定済みのCRUD機能の実装
- テストコードの生成
- ドキュメントの更新
② チェックポイント付き委任（Checkpoint）
途中で人間の確認が必要なタスク。エージェントに着手させつつ、特定ポイントで方向修正を入れます。
- 複数サービス間のインターフェースを伴う実装
- データマイグレーション
- 影響範囲が広いリファクタリング
③ 委任しない（Own）
人間が主導すべきタスク。アーキテクチャ判断、セキュリティ設計、「そもそも作るべきか」の意思決定です。
- アーキテクチャ上の重要な判断（ADRとして記録）
- セキュリティ・認証周りの設計
- プロダクトスコープに関わる意思決定
この仕分けをPMがスプリント計画時に行うことが、時間割設計の第一歩です。
何を夜間エージェントに渡し、何を設計レビュー会で扱い、何を隔週のアーキテクチャレビューに持ち込むか。タスクの性質でチェックのタイミングと密度を変える。この判断がなければ、時間割を組み替えても機能しません。
まとめ: 変えるのはツールではなく時間割
SDDをチームに導入して起きた最も大きな変化は、新しいツールを覚えたことではありません。
チーム全員の時間の使い方が変わったことです。
エンジニアは「コードを書く人」から「設計とレビューの人」に。PMは判断のタイミングを実装後から実装前に前倒しした。その変化を受け止めるために、1日のリズム、レビューの構造、タスクの仕分け方を設計し直しました。
SDDの技術面——仕様書のフォーマット、エージェントへのプロンプト設計、ツール選定——ももちろん重要ですが、それ以前に「チームの時間をどう設計するか」を考えなければツールのポテンシャルは発揮されません。
正直なところ、今の運用が最適解かどうかはまだわかりません。プロジェクトを回しながら日々調整しているし、「これは違ったな」と思って変えた部分もあります。ただ、AIエージェントと一緒に働くチームの時間割を自分たちで設計できるというのは、純粋に面白い。この手探りの過程も含めて、同じようにチームの開発リズムを模索している方の参考になれば嬉しいです。
-
Addy Osmani, "Your AI coding agents need a manager", 2026年1月 ↩︎
Discussion