マネージャーのための
GitHub入門

この教材は、プログラミングを学ぶためのものではありません。AIが猛スピードでコードを書く時代に、人間であるあなたが「何を見て、何を判断すればよいか」を身につけるための教材です。GitHubのコマンドは一切覚えなくて構いません。

多くの非エンジニアがGitHubを怖がる理由は、「全部理解しないといけない」と思い込んでいるからです。実際には、マネージャーが見るべきポイントは5つ程度に絞れます。この教材では、その5つに至るまでの「仕組みの思想」を順に理解していきます。

「最終版2」問題は誰もが経験しています。GitHubはこの問題を根本から解決します。すべての変更に「誰が、いつ、なぜ」という記録が付くため、過去のどの時点にも戻れます。マネージャーにとって重要なのは、この「戻れる」という性質です。戻れる仕組みがあるからこそ、部下やAIに思い切って仕事を任せられるのです。

AI時代の問題は「作れないこと」ではなく「作りすぎること」です。無検品でAIの成果物を本番に入れると、事故が起きます。GitHubは、AIの仕事を必ず一度「関所」に通す仕組みを提供します。マネージャーの仕事場は、まさにこの関所です。

Gitの本質は「タイムマシン」です。通常のファイル保存は上書きですが、Gitは上書きせず、変更のたびに新しい記録（コミット）を歴史に追加します。だから、1週間前でも1年前でも、任意の時点の状態を完全に再現できます。「消えない・戻れる」——これがすべての安心の土台です。

GitとGitHubは混同されがちですが、Gitが「記録の道具」、GitHubが「共同作業の場」です。重要なのは設計思想です。この仕組みは、失敗を禁止するのではなく、失敗してもすぐ戻せるようにすることで安全を作っています。マネジメントと同じで、ミスゼロを求めるより、リカバリー可能性を担保する方が組織は速く動けます。

ブランチは「コードのコピー」と説明されがちですが、イメージとしては「パラレルワールド」が正確です。本流という正式な世界はそのままに、実験用の並行世界を好きなだけ作れます。実験世界でAIが盛大に失敗しても、本流には一切影響しません。だからAIに「まずブランチでやらせる」のが鉄則です。

ブランチの真価はAIチーム運営で発揮されます。3体のAIに別々のブランチで同時に仕事をさせれば、互いに邪魔せず並行作業できます。マネージャーは各実験の途中経過を見る必要すらありません。「本流に合流させるか」という最後の判断だけに集中できます。

Pull Requestは「レビュー依頼」と訳されることが多いですが、本質は稟議です。「実験世界でこういう成果ができました。正式な世界に取り込んでよいですか？」という伺いです。承認するまで本流は何も変わらない——ここが重要です。PRが来た瞬間に何かが起きるわけではないので、慌てる必要はまったくありません。

PR画面を開くと大量のコードが目に入り、圧倒されます。しかし、マネージャーが読むべきは日本語（説明文とコメント）と信号の色（テスト結果の緑/赤）だけです。コード本体はAIレビュアーに読ませればよい。この割り切りが、GitHub恐怖症を治す最大の特効薬です。

マージは「正式採用の儀式」です。ここで初めて、実験の成果が本流の一部になります。重要なのは、マージすら最終決定ではないことです。Gitは歴史がすべて残る設計なので、「マージを取り消す」という操作（リバート）が標準で用意されています。つまり、マージの判断を間違えてもリカバリーできます。

Gitの「戻せる」設計は、マネージャーの意思決定スタイルを変えます。取り返しのつかない決裁なら100%の確信が必要ですが、GitHub上の判断はほぼすべて可逆です。したがって、7割の確信で承認して先に進み、問題が出たら戻す方が、チーム全体のスループットは上がります。これは経営判断における「可逆な意思決定は速く」という原則そのものです。

Issueは「仕事の依頼書」です。GitHubでは、仕事はすべてIssueという単位で管理します。チャットでの口頭依頼と違い、Issueは番号が付き、進行状況が見え、後からPRと紐づきます。「あの件どうなった？」が発生しない仕組みです。

人間の部下は曖昧な指示でも意図を汲みますが、AIは書かれたことに忠実です。つまりAI時代のマネージャーの実務スキルの中心は、コードではなくIssueを書く力です。「なぜやるのか」「何ができれば完了か」「何をしてはいけないか」。この3点を書ければ、AIへの委任は成功したも同然です。

これがAI時代の標準的な開発フローです。注目してほしいのは色分けです。真ん中の実装・申請・一次レビューはすべてAIが行い、人間は入口の「依頼」と出口の「最終判断」にだけ登場します。人間の役割が減ったのではなく、最も価値の高い2箇所に集中した、と捉えてください。

「AIが書いたコードをAIがレビューして意味があるのか」と思うかもしれません。あります。別のAIは別の視点で読むため、書いた本人が見落とした問題をよく見つけます。製造業の「自工程検査と検品の分離」と同じ発想です。これにより、人間に届く時点で技術的な粗は概ね除去済みとなり、人間は判断業務に専念できます。

ここが本教材の核心です。この5つの問いは、実は取締役会が投資案件を審査するときの問いと同じ構造です。「何のためか、なぜこの方法か、リスクは、撤退できるか、根拠はあるか」。コードが読めるかどうかは関係ありません。あなたは既にこの判断のプロです。GitHubはその判断力を発揮する場所が変わっただけです。

5問への答えは、部下に説明させるのと同じで、AIに説明させます。「わかるように説明できないなら承認しない」という態度で構いません。これは人間の稟議と同じルールです。むしろ、明快に説明できないPRは中身にも問題がある可能性が高い。説明の質は、成果物の質の優れた代理指標です。

マネージャーがコードを全部理解しようとするのは、経理部長が全仕訳を自ら起票しようとするのと同じで、役割の取り違えです。理解はエンジニアとAIの仕事、判断があなたの仕事。この線引きを受け入れた瞬間、GitHubは怖い場所ではなく、あなたの判断力が最も活きる場所になります。

AIチームを動かし始めると、最初に直面するのがこの問題です。AIは疲れず、夜中でもPRを出してきます。放っておくとレビュー待ちが数十件溜まり、古いPR同士が衝突し始め、収拾がつかなくなります。AI時代のチーム設計とは、AIを速くすることではなく、人間という制約をどう扱うかの設計です。

実務的な運用ルールは3つです。第一に、仕掛かり制限。同時に開くPRの数に上限を設け、新規着手より完了を優先させます。第二に、AI一次レビューの義務化。第三に、人間のレビューを5問チェックに限定し、時間を区切ること。この3つで、AIの速さを殺さず、人間も溺れないチームになります。

指揮者はバイオリンを弾けなくても、オーケストラを率いることができます。求められるのは、全楽器の演奏技術ではなく、曲全体の解釈と判断です。AI時代のマネージャーも同じです。「私は開発者ではない。AIチームのマネージャーである」——この一文を、GitHubを開くたびに思い出してください。

知識は体験で定着します。まず小さなリポジトリで、Issue→AI実装→PR→判断→マージ、そして意図的にリバート（取り消し）まで一巡してください。「本当に戻せた」という体験が、この教材のすべての理屈を確信に変えます。

この1枚がすべてです。専門用語は5つだけ、あなたの持ち場は2箇所だけ。AI時代に価値を持つのは、すべてを理解する能力ではなく、目的・価値・リスクを見極めて決める能力です。それは、あなたが管理職として毎日行ってきたことに他なりません。GitHubへようこそ。ここはあなたの判断力のための舞台です。