EMのMaker/Manager Schedule——AIエージェントで会議の隙間に開発を取り戻す

EMになった日から、コードを書く時間は急激に減っていく。1on1が3本入り、スプリントレビューがあり、採用面談もある。気づけば午後が会議で埋まり、残った30分でSlackの通知をさばいて1日が終わる。「今日もコードを書けなかった」。そう思いながら帰路につくEMは珍しくない。

この問題を最初に言語化したのは、2009年のPaul Grahamだった。そして2026年の今、AIエージェントがその問題に対して初めて現実的な答えを出しつつある。

「1つの会議が午後全体を破壊する」——Grahamの指摘は今も有効か

Paul Grahamは「Maker's Schedule, Manager's Schedule」の中で、時間の使い方を2種類に分けた。マネージャーは1時間単位で予定を組む。プログラマーや作家のような「何かを作る人」は、最低でも半日単位の連続した時間が必要だ、と。

記事の中でGrahamはこう書く。

"A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in."

1つの会議が午後を2等分し、どちらも深い作業には短すぎる断片になる。さらに「午後に会議が入っている」と朝から知っているだけで、その前に難しい仕事に集中する気が失せる、という心理的コストも指摘した。

この構造は、2026年の日本のプレイングマネージャーEMに対して、そのままほぼ完璧に当てはまる。

Clockwiseの調査（80,000人超のソフトウェアエンジニア、150万件超の会議を分析）によると、ICエンジニアとEMの週間時間配分はこうなっている。

EMになると、フォーカス時間がICの半分以下になる。EMConf JP 2025では、ohbarye氏のセッションで「調査に基づくとEMの大半はプレイングマネージャーであり、エンジニアリング業務にマネジメント業務が上乗せされる状況にある」という構造的課題が指摘された。

Grahamが提示した解決策は「会議を夜にまとめるオフィスアワー制」だった。理論としては正しいが、他のチームやステークホルダーに合わせて動く立場のEMには、現実問題として採用しにくい。

コンテキストスイッチが「見えない残業」を生む

会議の時間的コストだけが問題ではない。会議が終わった後に元の作業へ戻るためのコストが、実は同じくらい重い。

UC Irvineの研究（複数の実践報告で引用されている）によると、中断後に完全に集中を取り戻すまで平均23分15秒かかる。平均的な開発者の1日の重大な中断が31.6回だとすると、12〜15回のコンテキストスイッチだけで、1日4.5時間以上のフォーカス損失が生まれる計算になる（推計値：2025年コンテキストスイッチコスト調査）。

EMの「断片時間」の問題はさらに複雑だ。会議と会議の間の30分は、新しい実装を始めるには短すぎる。でも何もしないほど短くもない。その結果、Slackの返信、メールのトリアージ、軽い承認作業で埋まり、「仕事をしたが、何も前進していない」という感覚だけが積み重なる。

プレイングマネージャーのEMがコーディング業務に費やす時間は全体の5〜15%とも言われる。em-tools.ioのEM日次スケジュール分析によると、「コーディング時間が20%を超えているEMは、他の何かを犠牲にしている」という状態になっているとされる。

Grahamが2009年に問題を定義したが、解決策が15年間存在しなかった。それが今、変わろうとしている。

「30秒投入→5分待機→30秒フィードバック」というリズム

MachineラーニングスタートアップのCTO、Zachary SussmanはSubstack記事でこう書いている。

「AIへの指示は30秒のテキスト入力 → 5分の待機 → 30秒のフィードバック」

Sussmanは2024年1月からCTO業務に専念し、エンジニアリング業務を一度完全に離脱した。Claude Codeを使い始めたことで「2025年の全期間よりも、先週1週間のほうが多くのコードを書いた」という転換点に達した、と述べている。

この「30秒→5分→30秒」というリズムは、会議と会議の隙間に正確にはまる。30分の断片時間があれば、1〜2タスクを投入して待ちながら次の会議に出て、戻ったときに結果を確認できる。Maker時間の確保ではなく、Manager時間の断片をMaker時間に変換する、という発想の転換だ。

Change Alchemistというニュースレターでは、この発想を「Momentum Schedule」と呼んでいる。

AIがコンテキストを保持するから、長時間ブロックがなくても作業を継続できる。

「プロジェクトごとにAIスレッドを1本維持し、再開時に『前回のサマリーから続けて』と指示するだけ」——Change Alchemistの記事はそう説明する。人間がコンテキストをすべて頭に保持しなくてよくなった分、断片時間からでも再開できる。

Sussmanの戦略：「内部ツール」に集中する

Sussmanが実践で重視したのは、「複雑なシステムより内部ツール」という選択だった。チーム全体の状況が見えるCTOの立場を活かし、他のプロジェクトのボトルネックを解消する小規模な実装に特化する。コードベース全体を把握していなくても完結する、独立性の高いタスクを選ぶということだ。

Manager Scheduleの隙間でコードを動かす4パターン

「30秒→5分→30秒」というリズムを実際に回すには、適切なツールを選ぶ必要がある。Claude Codeには、EMの断片時間に合わせた機能群がある。

Ultraplan：会議前に計画を投げ、会議後に承認する

Ultraplanは、実装計画の作成をAnthropicのクラウドにオフロードし、ローカルのターミナルをすぐに解放する機能だ（2026年4月ローンチ）。

使い方は単純だ。会議前の5分で /ultraplan "認証モジュールをOAuth2.0対応にリファクタリング" を実行する。会議中にクラウドがコードベースを並列で分析し、実装計画を作成する。会議後の10分でブラウザから計画を確認し、コメントをつけてClaudeが修正する。承認後にPRを作成する、という流れだ。

「2〜4時間かかる手動での設計書作成」を比較対象にすると、この待機時間の意味が変わる。

Routines：夜間・朝に自動実行して「知っておくべきこと」を届ける

Claude Code Routinesは、定義したプロンプトをクラウド上でスケジュール実行する機能だ（2026年4月14日ローンチ）。ラップトップが閉じていても動作する。

EMが実際に使えるパターンを3つ挙げる。

朝9時の自動PRサマリー

前日から当日オープンのPRを全件サマリーし、レビュー優先度を判定してSlackに投稿する。EMは朝の最初の1on1に入る前に、チームの状況をSlackで確認できる。

PR作成時の自動コードレビュー

GitHub Webhookで pull_request.opened をトリガーに、セキュリティ・パフォーマンス・ロジックエラーをチェックしてインラインコメントを追加する。「Claudeがすでに確認済み」な状態でEMがレビューに入れるため、人間のレビューをアーキテクチャ判断に集中できる。

夜間のバックログ整理

毎晩22時に新着Issueにラベル付け・担当者アサイン・優先度スコアリングを自動実行する。翌朝のスタンドアップ前に、バックログが整理された状態になっている。

Proプランでは1日5回、Maxでは15回のデイリー実行上限がある。

Code Review：EMのレビュー時間を「判断する時間」に変える

Claude Codeのコードレビュー機能（Team・Enterprise向けResearch Preview）は、PRを開くと複数の専門エージェントが並列でコードを分析し、インラインコメントを投稿する。平均完了時間は20分。

EMが @claude review とPRにコメントするだけでレビューが始まる。REVIEW.md に「新規APIルートには必ずインテグレーションテストが必要」などのチーム固有のルールを定義しておくと、Claudeがそのルールに従ってレビューする。

コスト面では平均$15〜$25/PRとなる。ただし、EMが会議の合間にレビューをこなす代わりに、アーキテクチャ判断やプロダクト方向性の議論に時間を使えるなら、対価として十分に成立するかどうかは組織の状況次第だ。

Slack MCP：ながら進行でエージェントの進捗を把握する

Slack MCPサーバーを組み込むと、Claude Codeがエージェントの進捗をリアルタイムでSlackチャンネルに投稿する。

EMは専用チャンネルを作り、パッシブモニタリングで進捗を把握するだけでよい。コードレビュー結果の自動投稿、日次スタンダップの自動生成、インシデント発生時の原因分析・対応PR案の自動投稿。これらをSlackで受け取ることで、開発状況の把握にかける能動的な時間を削減できる。

Addy OsmaniはGoogleのエンジニアリングブログで、クラウド非同期エージェントについて「タスクを投げてラップトップを閉じ、戻るとPRがある」という使い方が2026年に本番品質に達したと述べている。ただし並列エージェントを3〜4個同時に動かすと「精神的に疲弊する」とも正直に書いており、実用的な上限は1〜2個だと言う。

明日から始めるための最初の一手

Jellyfish の2025年エンジニアリングマネジメントレポートによると、AIコーディングツールの利用率は90%（前年61%から急増）で、「AIで生産性25%以上向上」と回答した割合は62%に達している。一方で「AI効果の測定ができている」と回答したのはわずか20%だった。

ツールが使える状態にあっても、ワークフローへの統合が進んでいないのが現実だ。

EMConf JP 2025でカミナシのすずけん氏は「AIサービスによってプレイングマネージャーのプレイヤー業務は大幅に圧縮でき、マネジメント業務のための可処分時間を確保できる」という仮説を提示した（レバテックLABインタビュー）。

まだ試したことがなければ、この順番で入ってみてほしい。

Routinesで「朝のPRサマリー」を設定する（30分）

Claude Codeのdashboard.claude.aiから新規Routineを作成し、「毎朝9時にオープンPRを一覧して優先度をつけ、Slackの #dev-summary に投稿する」というプロンプトを設定する。これだけで、毎朝10分かけていたSlackでの状況確認がゼロになる。

REVIEW.mdを作成してチーム固有のルールを書く（10分）

リポジトリのルートに REVIEW.md を作成し、「APIエンドポイント追加時はOpenAPIスペックの更新が必須」「テストカバレッジが下がるPRはマージ不可」といったルールを書く。Claude Codeが自動レビューの際にこのルールを参照する。

次のリファクタリングタスクでUltraplanを試す（5分投入）

予定している技術的負債の解消や機能追加について、会議前の5分で /ultraplan に投げてみる。会議から戻ったときに計画が出来上がっている体験を一度すると、ワークフローへの統合の判断がしやすい。

広木大地氏が基調講演で述べた「全てのエンジニアは、AIをメンバーにもつエンジニアリングマネージャーになる」という言葉は、「EMがコードから離れざるを得ない」という現実への問いでもある。AIがコードを書く時代に、EMが何を担うべきか。その答えの1つは、AIとチームをオーケストレーションしながら、断片時間の中でもMaker感覚を失わないことだと、私は考えている。