Collaborator として同僚を招待する

Private リポジトリは、デフォルトでは作成者しか見られません。同僚に編集してもらうには、明示的に招待する必要があります。

招待された側はメール通知＋GitHub上の通知でリンクが届くので、それをクリックして承諾すれば共同編集者になります。承諾すると、両者がそのリポジトリの内容を見て、編集できる状態になります。

権限の違い（個人リポジトリの場合）

個人リポジトリでは、Collaboratorは「全権限を持つ協力者」になります（読むだけ・コメントだけのような権限分けはできません）。機密度の高いリポジトリは、信頼できる同僚にだけ招待するのが原則です。細かい権限管理は、Part 5 で扱う Organization リポジトリで実現します。

Issue──議題と質問の入口

Issue（イシュー）は、リポジトリ単位で立てる「議題ボード」です。Slackのスレッドや、メールの議題、付箋に書いたToDoのような役目をひとまとめにしたものです。

Issueでよくある使い方

• マニュアルの修正提案「このページの手順が古いです。〇〇に直してください」
• 質問「この用語の定義はどこにありますか？」
• タスク管理「今期中に追加するFAQ 5本」
• バグ報告（業務文書版）「規程の番号が重複している箇所があります」

Issueの立て方

Labels の効果的な使い方

Issueにはラベル（タグ）をつけて分類できます。よく使う組み合わせは次の通りです。

Issueを閉じる（Close）タイミング

議題の決着がついたら、Issueは Close ボタンで閉じます。閉じたIssueも検索可能なまま残り、過去の意思決定を辿る資料として残ります。「議論したけど決まらなかった」「保留」「対応見送り」も全部 Close で構いません。重要なのは 「未解決のIssueが滞留しないこと」です。

Pull Request──変更を提案して承認をもらう仕組み

Pull Request（プルリクエスト、略してPR）は、GitHubで最も独特で、最も強力な機能です。「リポジトリの本筋（main）に対する変更を、いきなり反映せず、まずレビューしてもらってから取り込む」仕組みです。

なぜ PR が必要か

Word文書を「お疲れ様です。マニュアル更新したので確認お願いします（最新版.docx）」とメール添付で送る運用、よくあります。これには問題が3つあります。

• 修正点が分かりにくい（差分は受け取った人が手動で探す）
• レビューコメントの履歴が残らない（メール本文に消える）
• 誰が承認したか後から追えない

PRはこれら3つを構造的に解決します。変更箇所が色付き（緑＝追加、赤＝削除）で表示され、レビュー指摘・承認の履歴がそのリポジトリに永続的に残るのです。

PR の流れ（5ステップ）

## 変更内容
FAQの誤字を3箇所修正

## なぜ
営業から「読みづらい」とフィードバックがあったため

## レビューポイント
- 「お問合せ」→「お問い合わせ」の表記統一でOKか
- 各社向け文言が混在していないか

このPR運用は、最初は「面倒」に感じますが、3〜4回回すと「直接編集していたら絶対拾えなかった指摘」を1〜2件はもらえることに気づきます。これが組織の集合知が積み上がる仕組みです。

Reviewers と Comments──レビューの作法

レビューする側の操作も覚えておきます。指名された側で実際に行うアクション：

1. PRの Files changed タブで差分を見る（緑＝追加、赤＝削除）
2. 気になる行で ＋アイコンを押すとその行にコメントできる
3. 「Start a review」を選んで複数行にコメントしてから一括送信（おすすめ）
4. 右上の Review changes から
   • Comment──質問・意見だけ（承認はしない）
   • Approve──変更を承認（マージOK）
   • Request changes──修正を要求（マージ前に直してほしい）

レビューコメントのトーン

感情を抑えた、事実ベースの建設的な書き方がGitHubの文化です。日本語の社内運用でも次のテンプレが使えます。

• ×「ここダメじゃないですか？」
• ○「この箇所、〇〇規程の表現と合わせるなら『△△』が良さそうですが、いかがでしょうか」
• ×「もっと詳しく書いて」
• ○「このセクションの読者を経理担当者と想定すると、補足例があると判断しやすいかもしれません」

コメントは永続的に残るので、感情的な書き方は採用面接での評価にも影響しかねません。書き方の作法は組織の文化として最初に揃えておくと良いです。

Discussions──社内フォーラムとして使う

Issue が「具体的なタスク・問題」を扱うのに対して、Discussions は「もっとオープンな話題」を扱うフォーラム機能です。社内Slackの「相談チャネル」をGitHub上で持つようなイメージです。

Issue と Discussions の使い分け

Discussions を有効化する

新規リポジトリではデフォルトでオフになっています。Settings → General → Features → Discussions にチェックで有効化されます。チームに招待した直後に有効化しておくと、後から議論の置き場ができて便利です。

変更履歴（History）の読み方

GitHubの根幹は「履歴」です。リポジトリのファイル一覧画面で各ファイルを開くと、右上に History ボタンがあります。これがそのファイルの全変更履歴です。

履歴画面では次のことができます。

• 各コミットのメッセージと日時を一覧
• クリックすると、そのコミットでの「変更前→変更後」が色つきで表示
• 誰がそのコミットをしたか（アバター付き）
• 過去の任意のバージョンに戻ってファイルを見ることが可能

「3ヶ月前のマニュアルってどんな状態だったっけ」が、ボタン2回でわかります。Word文書の「変更履歴」とは比較にならないレベルで遡れる仕組みです。

Blame（ブレイム）──行単位で履歴を見る

ファイル右上の Blame ボタンを押すと、ファイルの各行が「いつ・誰が」書いたかを表示します。「この一文を書いたのは誰だっけ？」を即座に特定できる強力な機能です。

ちなみに「Blame（責める）」というネーミングは技術的な慣習で、責任追及のためではなく「経緯を追う」ために使うものです。社内文化としても、責める用途では絶対に使わないようにしてください。

通知の整え方──情報過多にならないために

GitHubのデフォルト通知は、メール＋ブラウザ＋アプリの3経路で来ます。チーム運用が進むと、1日に数十通の通知が来て「メールが埋もれる」状態になりがちです。

推奨設定

1. 右上アバター → Settings → Notifications
2. Watching の通知設定を「Participating, @mentions and custom」に変更（自分が関わるものだけ）
3. メール通知は「Pull Request reviews」「Direct mentions」だけにオン
4. その他の通知は GitHub内のNotificationタブでまとめて見る

メール通知が爆発する原因の多くが、「Watch」設定でリポジトリ全体を購読している状態です。慣れてきたら、本当に追いたいリポジトリだけ All Activity に上げて、それ以外は Participating だけにするのが続けやすい運用です。

Part 4 への橋渡し

Part 3 まで来たら、GitHubの基本動作はほぼマスターできています。Part 4 では、いよいよこの仕組みを使って 「AI用のコンテキストを社内で集約・活用する」具体的な実装に踏み込みます。Claude Code の CLAUDE.md、Cursor の .cursorrules、ChatGPT用のプロンプト集──こうしたAI関連ファイルをGitHubで管理する設計を、実例ベースで解説します。

本シリーズの全体像（再掲）

1. Part 1──GitHubとは何か（理論編）
2. Part 2──アカウント作成と最初のリポジトリ（個人ハンズオン）
3. Part 3（本記事）──編集・履歴・チーム共有（チーム運用入門）
4. Part 4──AI用コンテキストをGitHubで管理する実践（AI連携）
5. Part 5──組織導入と運用（情シス・経営層向け）