エンジニアリングマネージャーのワークフローにおけるAI活用: 本当に役立つものと、気づかないうちに壊してしまうもの
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
あらゆるIDE、プロジェクトトラッカー、standup botが今や「AIアシスタント」を搭載しています。その多くは自信たっぷりに間違った見積もりを出し、1:1のメモを無味乾燥なまとめに変換し、本当に重要な部分である「判断」をそっと省いてしまいます。「マネージャー向けAI」という触れ込みは、私にとって信頼を高める理由ではなく、むしろ懐疑心を強める理由になっています。
AIに反対しているわけではありません。私はClaudeとCursorを毎日使っています。準備にかかる時間を大幅に削減できました。ただ、正しそうに聞こえるがわずかに間違っている要約を信頼してしまい、痛い目に遭ったことも一度や二度ではありません。緊張した対立を「優先順位について話し合った」とまとめた1:1の概要。2人のエンジニアが互いのPRをレビューしなくなっているという事実を陽気に見落としたsprintの報告書。AIは、自分が見ていないものについては教えてくれません。
これは2年前にあれば良かったと思うplaybookです。EMの週次業務においてAIが価値を発揮する場面、静かに物事を壊す場面、そして仕事の本質を失わずに組み込むための30日間プランを紹介します。
なぜ今これが重要なのか
あなたはAIのスロップがチームに届くのを防ぐ最後の砦です。有用なAIのまとめと、幻覚によるものの違いを見分けられなければ、どちらか一方の行動をとることになり、どちらも良くありません。
ツールをまったく拒否すれば、同僚が週に4時間を静かに節約していく中、あなただけが取り残されます。逆に信頼しすぎれば、AIが作った「テーマ」ドキュメントを持ってキャリブレーションに臨み、モデルが1つのSlackスレッドから作り上げた幻覚の枠組みを繰り返し、モデルが発明した何かを根拠に昇進を推薦することになります。
どちらも6〜10人のエンジニアのマネージャーとして許容できません。AIが十分に使えるワークフローと、どれほど権限委譲したくても手放してはいけないワークフローを見極めることが、この仕事の本質です。
AIが本当に役立つ場面
この5つのワークフローは、1年間壊そうと試み続けた末に生き残ったものです。派手ではありませんが、確実に時間を取り戻せます。
1:1の準備まとめ
各1:1の前に、そのエンジニアの先週のメモ、マージされたPRのリスト、そして彼らが参加していたSlackスレッドをClaudeに投入します。プロンプト:
こちらは[名前]の先週のメモ、マージされたPR、Slackスレッドです。前回の1:1からの変化を最大5箇条でまとめてください。摩擦、ブロックされた作業、スコープのずれのように聞こえるものにはフラグを立ててください。感情についての推測はしないでください。スレッドが不明確な場合はそう伝えてください。
「感情についての推測はしない」という一文は重要です。これがないと、モデルは3つの短いメッセージを根拠にして誰かが「フラストレーションを感じているようだ」と親切に教えてくれます。それを持ち込んで尋ねると、エンジニアはあなたが正気を失ったかのような目で見てきます。
返ってくるのは90秒で読める内容で、私が見逃していたことを拾ってくれます。質問は自分で書きます。AIは、彼らが木曜日に移行作業をリリースしたことを忘れて「最近どうですか」という出だしにならないようにしてくれるだけです。
人事評価の下書きインプット
6か月分の1:1メモは相当な量になります。サイクルごとに、そのメモ（Slackでも PRでもなく、それは別のパスです）だけをClaudeに投入し、クラスタリングプロンプトをかけます:
これらの1:1メモを3〜5つのテーマに分類してください。各テーマについて、それを裏付けるメモからの具体的な出来事を2〜3個挙げてください。可能な限りメモからの引用を使用してください。少なくとも2つの異なるメモで裏付けられないテーマは生成しないでください。
これは有用です。ただし、下書きではありません。薄々気づいていたパターンを浮かび上がらせ、忘れていた具体的な瞬間を思い出させてくれます。そこから、自分の言葉で、自分の具体例を使って実際の評価を書きます。AIの出力はスクラッチパッドに入れて削除します。
AIが下書きした人事評価は、最悪の種類のスロップです。プロフェッショナルに聞こえるが何も意味しない。それを読んだエンジニアにはわかります。
PRコメントのまとめとコードレビューの権限委譲
日常業務でチームのコードレビュアーではありませんが、コードの流れを把握するためにdiffは読みます。PRが議論になっている場合、Claudeにdiffを渡して聞きます:
このPRスレッドの意見の相違をまとめてください。議論されているアーキテクチャ上の核心的な問いは何ですか? それぞれの側の最も強い論点は何ですか?
80件のインラインコメントを再読せずに設計上の判断に関与する必要があるときに役立ちます。以下のCursor + Claudeのパターンについて詳しく説明します。
sprintの分析と異常検知
ほとんどのsprintダッシュボードはノイズです。私が欲しいのは「このsprintはおかしい、理由はこれ」という情報です。サイクルタイム、レビューレイテンシー、チケットステータスのデータをClaudeに投入して1つのプロンプトをかけます:
このsprintのメトリクスを直近4回と比較してください。過去の移動平均から1.5標準偏差以上外れている数値にフラグを立ててください。原因を推測しないでください。異常なものだけを教えてください。
「原因を推測しない」という一文が重要な仕事をしています。これがないと、モデルはレビューレイテンシーが上がったことを根拠に「チームが燃え尽きを経験している」と自信を持って伝えてきます。実際には、シニアエンジニアが1人PTO中だっただけかもしれません。AIは「この数値はおかしい」を得意とします。「なぜかというと」は苦手です。
「なぜ」はあなたの仕事です。人に話しかけに行ってください。
カレンダーの準備
最も小さな効果であり、最後まで手放したくないものでもあります。準備できていないミーティングの5分前に、アジェンダ（またはタイトルと参加者だけ）と最新のドキュメントをClaudeに貼り付けます:
90秒のブリーフィング: このミーティングは何についてのものか、どんな緊張が生まれそうか、何について発言できるように準備すべきか。具体的に。わからなければそう言ってください。
魔法ではありません。「何に臨もうとしているのか」を強制的に考える瞬間であり、準備なしに入って最初の10分を状況把握に費やすことを防いでくれます。
AIが静かに物事を壊す場面
ここで挙げるのは、AIが助けているように見えて実際はそうではないワークフローです。他のマネージャーが被るのを見たものもあれば、自分で経験したものもあります。
判断を要する決断。 このエンジニアには挑戦的なプロジェクトが必要か、それとも支援が必要か。このチームは組織変更の準備ができているか、それとも1四半期先か。AIは賢明に聞こえる両論併記の答えを返してきます。あなたの仕事は選択することです。モデルには何の利害関係もなく、あなたのチームのことを知りません。
厳しいフィードバックの伝達。 言葉はあなたから、あなたの声で、相手の顔を見て伝えなければなりません。Slackでも、ドキュメントでも、微調整した「AI支援の下書き」でも駄目です。自分で書けないなら、それを伝えるだけの確信がないということです。相手はそれを感じ取ります。
採用の意思決定。 AIスクリーニングツールは偏見とシグナルの洗浄に傾きます。訓練データに似た候補者を優遇し、その偏見を自信に満ちたスコアで包み込みます。2年間の育児休暇があるというだけでシニアエンジニアの評価を下げたツールを見たことがあります。スケジュール調整、パネルのデブリーフ中のメモ取り、不採用メールの下書きにAIを使うのは構いません。人間のフィルタリングには使わないでください。
評価面談。 PIP、昇進の見送り、担当範囲の変更、報酬の話し合い。これらは法的な側面を持ち、感情的に重く、自分の言葉で精度が求められます。AI支援のPIPドキュメントで冷たくない、または間違っていないと感じたものを私はこれまで見たことがありません。多くの場合、その両方です。
戦略的な判断。 どの賭けに出るか、どのトレードオフを選ぶか、どの順序で進めるか。AIはもっともらしい選択肢を返してきます。チームが実際に実行できる選択肢、自分たちの政治的現実に合う選択肢、Directorが承認する選択肢は返してくれません。その統合があなたの仕事です。それがあなたの報酬に値する理由です。
「AIによる昇進資料」の罠
エンジニアから昇進資料が届きます。動詞は一般的（「推進した」「牽引した」「実現した」）。インパクトの記述は不思議と均一で、3箇条、各2行、各数値あり。声がありません。全体がLinkedInの誰かへの推薦文のようです。
Claudeです。わかります。skip-levelにもわかります。
重要なのは: 仕事が悪かったということにはほぼなりません。エンジニアの自己叙述が空洞であることを意味していて、それはコーチング可能な別の問題です。仕事自体は優秀かもしれません。壊れているのはストーリーです。
恥をかかせずにコーチングする方法: 「これはAIですか」とは聞きません。「ヘッドラインとなるインパクトを自分の言葉で話してください」と尋ねます。話せるなら、ストーリーは本物で、書くことを外注しただけです。それで構いませんが、次は自分で書くよう促します。なぜなら書くことが考えることだからです。話せないなら、それが本当の問題であり、一緒に取り組みます。どちらの場合も、1:1でAI探偵の真似はしません。
資料は書き直す必要があります。AIの文章はキャリブレーションルームでは生き残りません。他のマネージャーもあなたと同じように読み、候補者は他の全員と同じように聞こえるとして評価を下げられます。
コードレビュー権限委譲のためのCursor + Claudeパターン
具体的なパターンを紹介します。その後に重要な注意点を添えます。
レイヤー1: Cursorのエージェントモード。 チームのlintとスタイルルールで設定します。明らかな問題を検出します: テスト不足、未使用のimport、型エラー、命名の不一致。エンジニアはPRを開く前に自己修正します。
レイヤー2: diffへのClaude適用。 PRが開かれると、CIステップ（またはエンジニアが手動で）でdiffをClaudeに通します:
このdiffをレビューしてください。フラグを立てるもの: (1) 50行を超える関数、(2) 新しい分岐のテストカバレッジ不足、(3) 認証、課金、またはデータ削除パスへの変更、(4) 命名が不明確な箇所。スタイルはコメントしないでください。それは処理済みです。承認もブロックもしないでください。フラグを立てるだけです。
出力はPRへの単一コメントとして追加されます。レビュアーはヒューマンレビューの前にチェックリストとして読みます。
レイヤー3: ヒューマンレビュー。 レビュアーはアーキテクチャ、命名の意図、システムの方向性との適合、抽象化の妥当性に集中できます。センスが必要な部分です。
このパターンが機能しなくなる場面。 認証、課金、決済、データ削除、またはPIIに触れるものは、セキュリティのトレーニングを受けた人間がエンドツーエンドでレビューします。AIは意思決定のループに入りません。チームがこれまで構築してきたことのない新しいドメインも同様。重要なマイグレーションも同様。このパターンはルーティンなコードには適していますが、実際にリスクのある作業には適していません。
このパターンを信頼しているのは、Claudeのパスが実際のバグを見逃すのを見て、何を見逃すかを把握しているからです。diffと向き合って失敗するのを観察したことがなければ、それを使うだけのキャリブレーションがまだできていません。レビューサイクルを短縮する前に、1か月間フルのヒューマンレビューと並行して動かしてください。
30日間の導入プラン
ゼロから始めるなら、5つのAIワークフローを一度に導入しないでください。実際に時間を節約しているものと、静かにスロップを生産していて後で修正する羽目になっているものを把握できなくなります。1つずつ。
第1週: ワークフロー1つだけ。1:1の準備を選んでください。 その週の全ての1:1で使います。各1:1の後、1行書いてください: 「AIが見逃したこと」。金曜日までに6〜10行が揃い、モデルの盲点がわかります。それが信頼するための土台になります。
第2週: もう1つ追加。sprint異常検知またはカレンダー準備のどちらかを選んでください。 同じドリル。AIの出力を自分の直感と比較する。一致する場所では時間を節約できます。一致しない場所では、どちらかが間違っています。どちらかを探ってください。
第3週: 振り返り。 メモを引き出す。AIが正味で時間を節約した場所と、スロップを修正するのにそもそも自分でやるより時間がかかった場所はどこか。後者のカテゴリーにあるワークフローはすべて削除する。1:1の準備で週20分節約できて、sprint分析で30分の二度手間が生まれているなら、sprint分析は外す。
第4週: チームの「AI使用規範」ドキュメントを書く。 1〜2ページ、あなたが書く。推奨するもの、注意事項付きで許可するもの、禁止するものを記載する。共有する。質問を受け付ける。
ドキュメントのたたき台:
AI使用規範: [チーム名]
推奨: 1:1の準備まとめ（マネージャー限定）、カレンダー/ミーティング準備のブリーフィング、コードレビューの初回パス（Cursor + Claudeのフラグのみ、自動承認なし）、sprintメトリクスの異常検知、コンテキストのためのドキュメント要約、機密性の低いメールの下書き。
注意事項付きで許可: 人事評価のテーマクラスタリング（インプットのみ、下書きは絶対に不可）。昇進資料のアウトライン（アウトラインのみ、文章はエンジニア自身が書く）。standupメモの要約（チームが同意した場合のみ）。
禁止: 人事評価、キャリブレーションドキュメント、PIPの最終下書きとしてのAI。人に直接届ける厳しいフィードバックの言葉としてのAI。候補者のAIスクリーニング。AI生成の報酬正当化。認証、課金、PIIに触れるPRの自動承認。
理由: AIはジュニアアシスタントです。下書き、要約、フラグ立てには十分です。人についての判断を下すには十分ではありません。そして、人についての判断こそが私たちの業務のほとんどです。
そのドキュメントがチームに必要なアーティファクトです。ツールリストではありません。何を人間が行うかについての共通理解です。
オプション: ACEフレームワークのレンズ
組織全体のAI導入を追跡していて、エンジニアリングマネジメントがACEフレームワークのどこに当てはまるか聞かれた場合のクイックマッピングです。控えめに使ってください。このフレームワークは個人のワークフローよりもプロダクトの意思決定に役立ちます。
- Ingest（取り込み）: 1:1メモ、PRデータ、Slackスレッド、sprintメトリクスを単一の作業コンテキストに収集する
- Analyze（分析）: sprint異常クラスタリング、人事評価テーマクラスタリング、PRスレッドの要約
- Predict（予測）: サイクルタイム予測と「このsprintはリスクか」の判断。極めて慎重に使用すること。これらは最も幻覚が起きやすい出力です。
- Generate（生成）: 下書きインプットのみ、最終成果物は不可。1:1ブリーフ、カレンダーブリーフ、異常報告。
- Execute（実行）: 禁止。人に影響するアクションの引き金は常に人間が引く。例外なし。
実行ステップは、チームへのAI展開のほとんどが失敗する場所です。「レビュアーを自動割り当て」は問題ありません。「N行以下のPRを自動承認」はインシデントレビューの始まりです。
よくある落とし穴
AIの見積もりを信頼すること。 自信満々に聞こえます。あなたのコードベースを含まない訓練データから構築されています。最善の場合でもサニティーチェックにしかなりません。
届けるフィードバックをAIに書かせること。 自分で書けないなら、届けるべきではありません。書くことは信じることの一部です。
1:1をシグナルを失う形でまとめること。 5箇条の要約は緊張した会話を「優先順位について話し合った」に圧縮します。生のメモも読んでください。
単一ツールへの依存。 価格は変わり、モデルは廃止され、ベンダーは方針を転換します。スキルはワークフローであり、ツールではありません。準備システム全体がClaudeがこの価格帯で永遠に無料であり続けることに依存しているなら、継続性の問題があります。
成功の測定
次のことが当てはまるとき、ワークフローが機能しています:
- 週に2〜4時間を準備と統合で節約できている。10時間ではありません。10時間を売り込んでいる人はスロップを売っています。
- チームは厳しい会話があなたから、あなたの言葉で、対面で届くと信頼しています。
- AI生成コンテンツが、未編集の状態で人事評価、採用の意思決定、キャリブレーションルームに届くことがない。
- どのワークフローをAIに任せ、どれを任せないか、それぞれ1文で説明できる。
- 直属の部下も自分の業務について同じことを説明できる。なぜなら規範ドキュメントを書き、彼らがそれを読んでいるからです。
それが基準です。AIはジュニアアシスタントです。仕事、つまり判断、厳しい会話、誰も下したくない決断は、あなたのものです。ワークフローが判断を委ねることを誘惑するなら、それが禁止すべきワークフローです。
関連記事
Principal Product Marketing Strategist