📚 ナレッジベース

GitHub_経営者向け完全ガイド

最終更新 2026年05月13日 ／ 21_ナレッジベース/プロダクト開発/GitHub_経営者向け完全ガイド.md

GitHub 経営者向け完全ガイド

「Gitコミット見せて」を拒否する開発会社は、議事録を見せない営業と同じ。
発注者・経営者目線で、Git/GitHubの本質と開発会社評価の決定的観点をまとめた完全版。

30秒で全体像

観点 一言
核心 コミット = 仕事の証拠そのもの。見せられないのは隠したい何かがある
キーワード コミット / ブランチ / PR / リポジトリ / 透明性
使う人 開発会社に発注する経営者 / SCALE開発体制を運用する全員
読了目安 15分
きっかけ 2026-05-13 X炎上事例（開発会社がGitコミット開示を拒否）

Section 1: Git と GitHub の違い

Git    = ローカルPCで動く「履歴管理ソフト」（無料・オープンソース）
GitHub = Gitの履歴をネット上に置けるサービス（Microsoft社・大手）

たとえ話

  • Git = Excelの「変更履歴を記録」機能の超高機能版
  • GitHub = そのExcelファイルをGoogle Driveに置いて共有する感じ
  • コミット = Ctrl+S（保存）の度に「何をなぜ変えたか」のコメント付き

類似サービス

  • GitHub（Microsoft）— 世界シェア80%以上・圧倒的本命
  • GitLab — 自社運用可能・大企業で採用多い
  • Bitbucket（Atlassian）— Jiraと連携重視

Section 2: 中核概念5つ

1. コミット（Commit）

「セーブポイント」。1コミット = 1つの変更単位。

コミット例:
- 日時: 2026-05-13 14:23
- 作者: 山田太郎 <yamada@dev.co.jp>
- メッセージ: "ログイン画面のバグ修正"
- 変更行: +15行 / -3行
- 変更ファイル: src/login.tsx

→ 「いつ・誰が・何をしたか」の完全な証拠。改ざんほぼ不可能。

2. ブランチ（Branch）

「並行世界」。本番コード（main）を壊さずに、別バージョンで開発する仕組み。

main ─────●────●────●────────●─── 本番
              \              /
               ●──●──●──●──●  ← 新機能の開発ブランチ
                feature/login

3. プルリクエスト（PR / Pull Request）

「この変更、mainに取り込んでいい？」という提案書。

  • 変更内容のサマリー
  • どのファイルが変わったか
  • レビュアー（先輩エンジニア）の承認
  • テスト結果

→ コードレビュー文化の中核。良い開発会社はここで品質が出る。

4. マージ（Merge）

PRが承認されたら、開発ブランチを本番ブランチに合体させる作業。

5. リポジトリ（Repository / Repo）

プロジェクト1個分の「フォルダ全体」。SCALE Baseなら scale-base リポジトリ。

Section 3: なぜ「コミット見せて」は当然の要求か

2026-05-13 X炎上の件、100%発注者が正しい。理由：

コミット = 「働いた証拠」そのもの

職種 仕事の証拠
営業 議事録・架電履歴・商談録画
デザイナー Figmaの編集履歴・バージョン
ライター Google Docsの編集履歴
エンジニア Gitコミット

→ コミットを見せない = 議事録を見せない営業と同じ。普通あり得ない。

コミットでわかること（経営者にも重要）

項目 何がわかるか
コミット数 どれくらい働いたか（量）
コミット頻度 毎日コツコツか、最後にまとめてか（質）
コミットメッセージ プロかどうか（"fix" だけは素人、ちゃんと内容書く人はプロ）
変更行数 大規模 vs 小規模変更
PR数とレビュー チーム開発の文化があるか
コミット作者 本当にその担当者が書いたか（外注の外注疑惑）

拒否する legitimate な理由はほぼない

「拒否理由」 実態
「企業秘密」 発注者があなたの場合、コードはあなたの資産。秘密じゃない
「他社のコードも混ざっている」 プロは1リポジトリ=1顧客にする。混ぜてる時点でアウト
「NDA違反になる」 あなたのプロジェクトのコミットを見せるのにNDAは関係ない
「見せる文化がない」 = Gitを使ってない（=2026年に致命的）or 単に隠したい
「準備に時間がかかる」 5秒で見せられる。GitHubの画面共有1発

拒否されたら疑うべきこと

大赤信号5パターン
1. そもそもコードを書いてない（他社製品を転売）
2. AIに丸投げで嘘の見積もり（プロが書いた風に装って実は1日で生成）
3. 海外の格安エンジニアに外注（中抜き構造で発注者に知られたくない）
4. 過去案件のコードを使い回し（あなただけのオリジナル品ではない）
5. そもそもGitを使ってない（= モダンな開発手法じゃない = 品質低い）

Section 4: 開発会社に確認すべき質問リスト

契約前に必ず聞く5問

1. リポジトリは弊社が所有しますか？（オーナーシップ）
2. GitHubアカウントを作って、そこにコードをpushしてもらえますか？
3. 開発進捗は週次でPR単位で確認できますか？
4. コミットメッセージは日本語/英語どちらでもOKですか？
5. 引き継ぎ時、コード+ドキュメント+README一式もらえますか？

→ 1つでも渋るところは即NG。

契約後の運用

タイミング 確認すること
週次 コミット数・PR数を確認（ゼロなら警告）
マイルストーン毎 デプロイ前のコード確認・READMEの更新確認
完了時 リポジトリのフルアクセス権譲渡

健全な開発会社の見分け方

コミットを見せて即対応
READMEがちゃんと書いてある
コミットメッセージが具体的（"Add login validation" など）
PRレビューの文化がある
テストコードがある
デプロイ手順がドキュメント化

「コミットは社内資産」と渋る
READMEが空
コミットメッセージが "update" だけ
ブランチが1個しかない（mainに直接push）
1コミットで10万行変更（= 丸ごとAI生成の疑い）

Section 5: 非エンジニアでもチェックできる方法

GitHubにログインして、相手のリポジトリを開いたら：

A. コミット履歴の見方

GitHub画面 → リポジトリ → "Commits" タブ

見るポイント：

  • 日付 — 毎日（または定期的）コミットがあるか
  • 作者 — 担当者本人か（他人の名前ばかりなら外注疑惑）
  • メッセージ — 「fix」「update」だけなら素人
  • 変更ファイル — 1コミットで100ファイル変更は赤信号

B. PR履歴の見方

GitHub画面 → リポジトリ → "Pull requests" タブ → "Closed"

良いPR例:
- タイトル: "ログイン画面にバリデーション追加"
- 説明: 「ユーザーがメール未入力でログインボタンを押せる問題を修正」
- レビュアーのコメントあり
- マージ済み

悪いPR例:
- タイトル: "update"
- 説明: なし
- 一人で作って一人でマージ（レビューなし）

C. リポジトリ全体の健康度

GitHubトップに表示される指標：

  • Issues（バグ・要望管理）が活発か
  • Releases（バージョン管理）があるか
  • READMEが充実してるか
  • Stars / Forks はOSS用なので気にしなくてOK

Section 6: SCALE側でやるべきこと（自社視点）

ゲンカイ + 4エンジニア + 22サービスの体制なら、社内ルール化しておくと外部から見ても信用される。

必須セットアップ

# やること 目的
1 GitHub Organization作成（scale-group とか） 全プロダクトを1箇所に
2 22サービス全部をリポジトリ化 履歴管理・属人化防止
3 メインブランチを保護 勝手に変更されない
4 PRレビュー必須化 品質担保
5 README必須化（READMEだけは絶対書く） 引き継ぎ可能に
6 コミットメッセージ規約 "feat: 〇〇追加" / "fix: 〇〇修正"

既に Claude Code でやってる「changelog.ts」との関係

changelog.ts = 「ユーザー向け」の変更履歴（ニュース）
Gitコミット = 「開発者向け」の変更履歴（コード差分込み）

両方あるとベスト。changelog.tsは「機能追加しました！」、Gitは「具体的にこのファイルのこの行をこう変えた」を残す。

大串が今すぐできること

# 1. SCALE Base のローカルディレクトリで状態確認
cd "/Users/oogushiyuuki/Library/CloudStorage/GoogleDrive-y-ogushi@scale-group.co.jp/マイドライブ/AI/scale-base/"
git log --oneline -20  # 直近20コミット表示
git status              # 今の状態

# 2. SCALE Lead も同様
cd ~/株式会社SCALE/scale-lead/
git log --oneline -20

→ これだけで「今までどんな変更してきたか」一覧で見える。

Section 7: 用語クイックリファレンス

用語 意味 SCALE文脈での例
リポジトリ / repo プロジェクト1個分 scale-base リポジトリ
コミット 変更1回分の記録 「ログイン修正」のコミット
ブランチ 並行開発の線 main / feature/x-pilot
PR / プルリク 「マージしていい？」提案 4エンジニアからのPR
マージ ブランチ合体 feature → main
クローン リポジトリをローカルに複製 git clone
プッシュ ローカル変更をGitHubに送る git push
プル GitHubから最新を取る git pull
コンフリクト 同じ箇所を別々に変更して衝突 エンジニア間で発生
リバート 変更を取り消す ロールバック
タグ / リリース バージョン番号付け v1.0.0
イシュー バグ・要望リスト バグレポート管理
アクション / CI/CD 自動テスト・自動デプロイ Cloudflare Pages連携
フォーク 他人のリポジトリを自分用にコピー OSSコントリビュート
README プロジェクト説明書 「これは何か」を書く
.gitignore Gitに含めないファイル指定 パスワードファイル等

Section 8: 経営判断に直結する「Gitリテラシー」

開発会社選定の決定的5問（再掲・最重要）

発注前にこの5問をぶつけて、すべて「Yes」が返ってくる会社だけ選ぶ：

1. リポジトリのオーナー権限を弊社に渡してもらえますか？
2. 週次でコミットログを共有してもらえますか？
3. PRレビュー文化はありますか？
4. 完了後、コード+README+デプロイ手順一式もらえますか？
5. 弊社エンジニアがGitHubで進捗確認できますか？

→ 1つでも渋るところは即NG。X炎上のあの会社、ほぼ全部NGの臭いがする。

既存パートナー（ゲンカイ・4エンジニア）への確認

社内体制でも同じ。「Git使ってる前提」で発注してるか？ を確認：

  • リポジトリどこにある？
  • 大串がアクセスできる？
  • 引退時に引き継げる状態か？

→ エンジニア依存リスク回避の核。1人辞めても全部GitHubに残ってる状態が理想。

今日からのアクション3つ

  1. GitHub.comでアカウント作成（無料）→ scale-group org 作る
  2. 既存システムのリポジトリ確認 → git log を眺めるだけでOK
  3. 次に発注する開発会社に Section 4 の質問リストをぶつける

学習リソース

レベル おすすめ
超入門 サル先生のGit入門（無料・日本語）https://backlog.com/ja/git-tutorial/
GitHub操作 GitHub公式ドキュメント（日本語あり）
動画派 YouTube「Git 入門 たにぐち」シリーズ
経営者向け 『Gitが、おもしろいほどわかる基本の使い方33』

注意ポイント

やってはいけないこと
パスワード・API キーをGitにコミットする（漏洩リスク）
.env ファイルをコミットする（同上）
大容量バイナリ（動画・画像大量）をコミット（リポジトリ肥大化）
git push --force を main ブランチに（履歴破壊）
他人の作業中ブランチを勝手にマージ

やるべきこと
.gitignore で機密情報を除外する設定を最初に書く
コミットメッセージは具体的に書く（"何を" だけでなく "なぜ"）
PR は小さく分けて出す（1PRで100ファイル変更は嫌われる）
README は「他人が初めて見ても動かせる」レベルで書く

関連ノート

改訂履歴

日付 内容
2026-05-13 初版作成。X炎上事例（開発会社がGitコミット開示拒否）をきっかけに、経営者・発注者目線でGit/GitHub完全ガイド化