マネージャーがエンジニアに求めるたった 1 つのこと — コンテキストを GitHub repo に残してほしい、要約は AI が吸収する
社内の GitHub Discussions やドキュメントをマネージャーの立場で眺めると、議論は十分に厚いのに「結局このプロダクトは次の四半期に何をやろうとしているのか」「どのチームに影響が出るのはいつ頃か」がパッと読み取れない場面が頻繁にあります。書き手であるエンジニアの言語化不足ではなく、書き手と読み手で必要としている情報粒度が違うのが本質です。
最近この種の場面で、開発組織のメンバーに対して同じことを繰り返しコメントしています。「コンテキストを GitHub の repo に残しておいてくれれば、こちらは AI を使って必要な粒度で要約して判断できる。だから、マネージャー向けに翻訳した文章を別途書いてもらう必要はない。フローでもストックでもいいので、いま分かっている範囲のコンテキストを repo に残しておいてほしい」と。
本記事はそのマネージャー側からのお願いを、一般化した運用論として書き留めるものです。具体的なツール例として Claude Code や Codex を挙げますが、ツール名は具体例で、本質は「コンテキストが repo に載っていれば、マネジメント向け要約は AI で吸収できる」という運用の話です。
マネージャーが読み手として欲しいのは「決められる粒度の情報」
エンジニアどうしの議論は、実装の選択肢、トレードオフ、過去の経緯、エッジケースなど、内容が深くなりがちです。それは健全で、密度を下げると意思決定の品質が落ちます。書き手のみなさんには、まずその密度を保ったまま書き続けてほしいというのが、マネジメント側の前提です。
一方、マネージャーや経営層が同じ Discussion や Issue を眺めるときの問いは、もっと粗い粒度です。
- いつまでにどこまでやる予定なのか
- 他チームのスケジュールに影響するか
- 必要な人員、予算、判断はあるか
- リスクが顕在化したらどのくらいの規模で何が壊れるか
この粒度の答えは、たいていのスレッドには明示的には書かれていません。詳細を読み込めば再構成できますが、複数プロダクトを横断して見ているマネージャーが、日々上がってくる多数の Discussion を一次資料として読み下すのは現実的ではありません。
ここで「マネジメント向けの説明文を別途書いて」とエンジニアにお願いするのは、マネージャー側から見ると稼働の浪費です。詳細議論と意思決定の間にあるギャップは、書き手の負荷を増やすのではなく、コンテキストが repo に載っている前提で、AI で吸収するのが筋がいいと考えています。
エンジニアのみなさんにお願いしたい唯一のこと — コンテキストを repo に残す
マネージャー側からエンジニアのみなさんにお願いしたいことは、シンプルに 1 つです。「コンテキストを GitHub の repo に残しておいてほしい」。
ここでいう「コンテキスト」は、特定の形式に限定しません。フロー情報でもストック情報でも、どちらの形でも構いません。
- 確定している情報 はストック情報として、リポジトリ内のドキュメント（README、docs/、ADR など）に commit してほしい
- 未確定だが現時点でこう考えている情報 はフロー情報として、Discussion や Issue に雑に書いておいてほしい
「いま自分の頭にあるコンテキストが、repo のどこかで見える状態」になっていれば十分です。それさえあれば、マネージャー側で AI に対して「次の四半期に何が起きるか」「どこにリスクがあるか」「他チームへの影響は」といった問いを投げて、必要な粒度で答えを引き出せます。
逆にお願いしないこと、つまり書かなくてよいことも明確にしておきます。
- 経営層向けに翻訳した「サマリ文書」を別途作成すること
- 進捗を表現するためのスライドを毎週作成すること
- 1 つの Issue の議論を Markdown レポートとして再パッケージすること
これらは repo にコンテキストが載っていれば AI で吸収できるので、エンジニアの貴重な時間を投下する必要はありません。
フロー情報とストック情報の使い分け
「フロー」「ストック」という呼び方はエンジニア界隈ではよく知られた考え方ですが、改めて整理しておきます。コンテキストを repo に残すとき、書き手は「これはフローか、ストックか」だけ意識して場所を選んでください。
フロー情報 — そのときのスナップショット
- 置き場所: Discussion、Issue
- 書き方: 雑でいい、思考の流れをそのまま書く、決着がついたら close する
- 例: 「今週時点での検討結果」「いまの自分の理解」「現時点での仮の方針」
「今時点での意思決定だが、明日変わるかもしれない」「いまの自分の理解だが、来週には書き換わっているかも」というレベルの内容は、Discussion や Issue に雑に書き散らかして問題ありません。完璧に整える必要はなく、思考の流れをそのまま残すほうが、後から議論を辿るときに役立ちます。書き手としては「ガンガン書いて、ガンガン close する」を基本動作にしてもらえれば十分です。
ストック情報 — 恒久的に参照される情報
- 置き場所: リポジトリ内のドキュメント（README、docs/、ADR など）に commit
- 書き方: 整理する、半年後に読んでも意味が通る粒度にする
- 例: ロードマップ、設計判断の根拠、API 仕様、運用ルール
ストック情報は「半年後にチームに加わったメンバーが読んでも意味が通る必要がある」レベルの情報です。具体的には、README、docs/、ADR（Architectural Decision Record）といったリポジトリ内のドキュメントに commit するイメージです。
書き手がフローとストックを意識して場所を選ぶ、というだけで、自然と Discussion や Issue は気軽に書ける場所になり、リポジトリは長期参照に耐える場所になります。
マネージャー側としても、フロー情報については AI に拾わせる前提なので、生々しいまま雑に書いてもらって構いません。ストック情報については AI 要約だけに頼らず、原典として一次資料を読みに行きます。
マネージャー側で実際にやっているプロンプト
「結局マネージャー側でどう要約しているのか」を共有しておくと、書き手側も「この粒度で書けば AI 側で吸収できる」というイメージが掴みやすいと思います。私が日常的に使っているプロンプトをいくつか書き留めておきます。
例 1: AWS のコスト最適化 — Fargate の Savings Plans と RDS の Reserved Instances
インフラコストを見直す場面で、AWS の Fargate オンデマンド料金 から、Fargate などのコンピュートを Savings Plans に寄せ、RDS を Reserved Instances に切り替える判断は、マネージャー視点での意思決定マターです。1 〜 3 年のコミットメント、使い切れなかった場合の金銭リスク、ピーク時の柔軟性とのトレードオフなど、エンジニア単独では決められない金銭判断が伴います。
repo の docs/ や Discussion に「現状の Fargate / RDS の利用状況」「インフラ構成の今後の方針」がフローでもストックでも残っていれば、AI に次のように頼みます。
添付した利用ログとインフラ方針メモを読み、Fargate に適用する Compute Savings Plans と、RDS に適用する Reserved Instances（1 年 / 3 年、前払いオプションあり）について、それぞれ「想定割引率」「コミット期間」「柔軟性のトレードオフ」「現状の利用パターンとの相性」をざっくり比較してください。最後に、私が判断する上で他チームと確認が必要な事項を 3 つ挙げてください。
返ってくる比較表は精緻ではないですが、判断会議で詰めるべき論点（コミット期間を 1 年にするか 3 年にするか、Fargate のスケール変動にどこまで Compute SP のコミットを当てるか、RDS RI の前払い比率をどう取るか）が見えてきます。エンジニアが「現状の利用状況」「想定する将来のワークロード変化」といったコンテキストを repo に残しておいてくれていれば、マネージャー側でも AI の補助で意思決定の輪郭を描けます。逆に、利用状況も方針も repo に何も書かれていないと、AI は一般論しか返せず、私からの確認依頼が現場のエンジニアに何往復も飛ぶ展開になります。
例 2: ドキュメントが薄いプロダクトのキャッチアップ
新任で関わるプロダクトや、しばらく見ていなかったプロダクトの現状把握には、AI に過去 90 日分の動的状況を再構成してもらいます。
このリポジトリの過去 90 日分の PR、Discussion、Issue を読み、現在進行中のテーマを 3 〜 5 個に分類してください。それぞれについて「いま誰が動かしているか」「次のマイルストーンは何か」「ブロッカーがあれば何か」をまとめてください。
ここで重要なのは、リポジトリにコンテキストが少しでも残っていれば（フローでもストックでも）、AI はそれを優先的に拾ってくれることです。逆に、フローもストックも何も書かれていない repo だと、AI も推測ベースの返答になりがちで、マネージャー側での裏取りコストが跳ね上がります。これが「コンテキストを repo に残してほしい」とエンジニアにお願いしている直接的な理由です。
例 3: 長い議論スレッドの要約
長い Discussion スレッドそのものを要約するのも AI の得意分野です。
このスレッド全体を読み、意思決定者にとって重要な事項を 5 行以内で箇条書きにしてください。意思決定が必要な事項は「[要判断]」というラベルをつけてください。
書き手は議論を厚く書くことに集中でき、読み手は粒度を自分側で調整できます。書き手と読み手の両方が幸せになる分業の形です。
「概算でいい」を組織の共通言語にする
この運用を組織として走らせるうえで一番大事なのは、マネージャー側から「概算でいい」「フローでもストックでも repo に載っていれば十分」を明確に宣言することだと考えています。
書き手であるエンジニアにとって、一番嫌な作業は「いまから 30 分かけて、確定しきっていない情報を確定したように書く」ことです。マネジメント側が「正確な情報を 1 回だけください」と要求する文化だと、書き手は完璧な資料を作るプレッシャーで動きが鈍ります。
マネージャーから「未確定の情報は Discussion や Issue にフローのまま雑に置いておけばいい。確定したらリポジトリの docs/ や README に commit してほしい。残りはこちらで AI に吸収させる」と明文化しておくと、書き手は「いま分かっている範囲のコンテキスト」を気軽に書き出せるようになります。
この宣言は、エンジニアの心理的負担を下げるだけでなく、マネージャー側にとっても利点があります。完璧な資料が遅れて上がってくるよりも、未確定でもいいから早めにコンテキストが見えるほうが、意思決定のレイテンシが下がるからです。
まとめ — エンジニアのみなさんへのお願い
マネージャーの立場として、エンジニアのみなさんにお願いしたいことを改めてまとめます。
- コンテキストを GitHub repo に残してください。フロー情報でもストック情報でも、形式はどちらでも構いません
- 未確定の情報は Discussion や Issue にフローとして雑に書き、ガンガン close してください。完璧に整える必要はありません
- 確定した情報は README、docs/、ADR などのドキュメントに commit してください。半年後のメンバーが読んでも分かる粒度を意識してください
- マネジメント向けの要約文を別途書くのは不要です。コンテキストが repo にあれば、マネージャー側で AI 活用して吸収します
- 「概算でいい」を信じてください。確定していない情報を確定したように書く必要はありません
書き手と読み手の情報粒度のギャップを、書き手の負荷で埋めていた時代から、AI で吸収する時代に移りつつあります。コンテキストが repo に残っているという最低限の前提さえ揃えば、エンジニアのみなさんが本来やるべき「深く考える」「実装する」「議論する」という仕事に集中できる時間が、確実に増えていきます。
以上、フルリモート組織でマネージャーとして AI 活用前提の運用を組み立てている、現場からお送りしました。