システム開発を外部ベンダーに委託するなかで、「GitHub Organization への招待メールを送ります」「最新のソースは GitHub にプッシュしていますのでご確認ください」と言われ、戸惑った経験はないでしょうか。頷いて話は進んだものの、仕組みが分からないまま会議が終わり、後になって「あれは自分が承認してよかったのだろうか」と不安になる、という声は発注側のマネージャーからよく聞かれます。
「バージョン管理」「Git」「GitHub」はITの現場では当然のように登場しますが、発注者の立場で本当に知りたいのは仕組みそのものの細部ではなく、「自分は何を確認すべきか」「成果物であるソースコードを、自社の資産としてどう確保すべきか」という判断基準のはずです。しかし検索上位に並ぶ記事の多くはエンジニア向けの機能解説か、法務目線の契約論に偏っていて、その間をつなぐ実務的な指針はなかなか見つかりません。
本記事では、まずバージョン管理・Git・GitHub の用語を最短ルートで整理し、そのうえで「発注者として確認・依頼すべきチェックポイント」と「契約書と GitHub 上の設定をどう対応させるか」「プロジェクト終了後にソースコードを確実に受け取る方法」まで踏み込んで解説します。
読み終えたときには、委託先との打ち合わせで「リポジトリの Admin 権限は発注側で持たせてください」「プロジェクト終了時はこの方法でソースコードを引き渡してください」といった具体的な要望を、自信を持って言葉にできる状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
バージョン管理とは？ファイルの変更履歴を記録して安全に共同作業するための仕組み
バージョン管理とは、ファイルの変更履歴を時系列で記録し、いつでも過去の状態に戻せるようにしておく仕組みのことです。システム開発の現場では、ソースコードと呼ばれる大量のテキストファイルを複数人で同時に触るため、「誰が・いつ・どのファイルを・なぜ変更したのか」を追跡できる仕組みがなければ、すぐに作業が破綻してしまいます。
発注者の立場からすると、バージョン管理は「委託先の作業の透明性を担保する記録簿」であり、「トラブル時に被害を最小化するための保険」でもあります。つまり単なる開発者の便利ツールではなく、発注者が成果物の品質とリスクを管理するための基盤でもある、と理解しておいてください。
バージョン管理システム（VCS）とは何か
バージョン管理を実現するソフトウェアを、バージョン管理システム（Version Control System、略してVCS）と呼びます。VCSはファイルの変更を「スナップショット」や「差分」として保存し、履歴一覧からいつでも任意の時点の状態に戻せるように設計されています。
代表的なVCSには Git・Subversion（SVN）・Mercurial などがありますが、2020年代の新規システム開発ではほぼ Git が業界標準です。ベンダーから「SVN を使っています」と言われた場合は、技術スタックがやや古い可能性があり、開発体制や引き継ぎ時の取り扱いを少し慎重に確認しておくと良いでしょう。
Word の「変更履歴」との違い（ファイル間の関係・ブランチ・チーム規模）
「変更履歴なら Word にもあるのでは」と感じた方もいるかもしれません。Word の変更履歴は1つのファイルの中で「誰がどこを直したか」を記録する機能で、たしかにバージョン管理の一種と言えます。しかし、システム開発のバージョン管理には、次のような大きな違いがあります。
- 対象ファイルが数百〜数千規模: システムは1つのファイルではなく、大量のファイルが相互に連携して動きます。バージョン管理はプロジェクト全体を一括で履歴管理します
- ブランチ（分岐）がある: 「本番に適用している安定版」と「新機能を開発中の検証版」を並行して管理し、完成後に統合できます
- 大人数の同時編集が前提: 10人、100人が同じプロジェクトを同時に編集しても破綻しない仕組みが組み込まれています
- プログラム的に操作される: 手作業で履歴を残すのではなく、保存・統合・切り戻しが自動化されています
この違いを踏まえると、システム開発の発注者がソースコードの状態を把握したいと思ったとき、「Word感覚でファイルを送ってほしい」とは言えない理由が見えてきます。コードは Git のような専用の仕組みを通じてやり取りする前提になっている、ということです。
Gitとは？分散型バージョン管理システムの仕組みをシステム開発発注者向けに解説
Git（ギット）は、現在のシステム開発で最も広く使われている分散型のバージョン管理システムです。2005年に Linux の開発者であるリーナス・トーバルズ氏らによって作られ、現在は世界中の開発プロジェクトの事実上の標準となっています。
発注者として Git の技術的な詳細まで把握する必要はありません。「開発チームが何を使って、どういう単位でコードをやり取りしているのか」をイメージできるだけで十分です。ここでは、打ち合わせや議事録で用語が出てきたときに困らない程度に整理します。
Gitが「分散型」である意味（各メンバーの手元に完全なコピーがある）
Git の最大の特徴は「分散型」であることです。分散型とは、プロジェクトの全履歴を含む完全なコピーを、開発者一人ひとりが手元のパソコンに持っている、という意味です。
以前主流だった「集中型」VCS（SVN等）では、中央のサーバー上にだけ履歴があり、手元には現在のファイルしかありませんでした。分散型では、各開発者が自分のコピーに対して作業し、区切りのよいタイミングで中央（GitHub などの共有サーバー）に変更を送ります。
発注者視点で重要なのは次の点です。コードが中央サーバーだけでなく、関係者全員の手元にも存在している、ということ。つまりもし何らかの事情で中央のGitHubアカウントにアクセスできなくなっても、開発者の手元には完全なコピーが残っている可能性が高い、という冗長性があるわけです。
発注者が覚えておくべき最小限のGit用語（リポジトリ / コミット / ブランチ / プッシュ・プル）
議事録や進捗報告で頻出する4つの用語だけ押さえておきましょう。
- リポジトリ（Repository、略称 Repo）: プロジェクトのソースコードと全履歴を格納する「倉庫」。システム1本につきリポジトリ1つが基本です
- コミット（Commit）: 変更を履歴として記録する単位。「どのファイルを・なぜ変更したか」というコメントとセットで保存されます。発注者が過去の変更理由を追いたいとき、コミットログを見れば時系列で把握できます
- ブランチ（Branch）: 作業の分岐線。「main（本番用）」と「feature/login（ログイン機能開発用）」のように分けて、完成したら main に統合します
- プッシュ（Push）/ プル（Pull）: 手元のコピーと中央サーバーの間でコードをやり取りする操作。プッシュが「送る」、プルが「取ってくる」です
この4語を知っていれば、「今週は feature ブランチで機能開発を進めて、金曜に main にマージ（統合）する予定です」といった進捗報告の意味が分かるようになります。
集中型（SVN 等）との違いは発注者の視点でどう影響するか
発注者が意識しておきたい違いは、次の2点です。
1つ目は、オフラインでの作業耐性です。分散型では各開発者が手元にフルコピーを持っているため、中央サーバーに一時的に接続できなくても作業が継続できます。これはプロジェクト継続性のリスクを下げる要素です。
2つ目は、ブランチ運用の柔軟性です。Git ではブランチの作成・統合が非常に軽量で、複数の機能を並行開発する文化が前提になっています。その結果、後述するプルリクエストを使ったコードレビュー文化が育ちやすく、品質担保の仕組みが組み込まれた開発が一般的になりました。
「委託先は Git を使っているが、ブランチ運用やレビューのルールが曖昧」という場合、技術的な基盤は最新でも運用面でリスクが残ります。後続の章で述べる「ブランチ保護設定」の確認が有効です。
GitHubとは？Gitリポジトリをクラウドで共有するホスティングサービス
GitHub（ギットハブ）は、Git のリポジトリをクラウド上で保管し、チームで共有・共同作業するためのサービスです。米国 GitHub 社が運営しており、2018年からは Microsoft 傘下で運営されています。類似サービスに GitLab・Bitbucket などがありますが、日本のシステム開発現場では GitHub が事実上の標準です。
発注者として理解しておきたいのは、「Git = 仕組み（ツール）」「GitHub = その仕組みを使ってチームでコードを共有するためのクラウドサービス」という整理です。Microsoft Word と OneDrive の関係に近い、とイメージすると分かりやすいかもしれません。
Git と GitHub の違い（ツール vs サービス）
具体的な違いは次の通りです。
項目 | Git | GitHub |
|---|---|---|
正体 | バージョン管理の仕組み（ソフトウェア） | Git を使ったクラウドホスティングサービス |
提供元 | オープンソース（無償） | GitHub社（Microsoft傘下） |
動作場所 | 各開発者のパソコン内 | クラウド（Webブラウザでアクセス） |
主な役割 | 変更履歴の記録・ブランチ管理 | リポジトリ共有・レビュー・Issue管理・CI/CDの起点 |
議事録では「Gitにプッシュしておきました」ではなく「GitHubにプッシュしておきました」が正確です（プッシュするのは通常 GitHub 等のリモートサーバー先）。ただし、実務では混同されがちなので厳密に直させる必要はありません。発注者としての意思疎通では、どちらを指しているか文脈で判断できれば十分です。
Organization・リポジトリ・メンバーの3階層
GitHub の構造は、発注者視点で次の3階層を押さえておけば十分です。
- Organization（オーガニゼーション、略称 Org）: 会社やチーム単位の入れ物。複数のリポジトリとメンバーをまとめて管理する単位です。委託先が「弊社のOrganizationに招待します」と言う場合、このOrgのことを指します
- リポジトリ: Organizationの中に作られる個別プロジェクトの倉庫。1システム＝1リポジトリが基本です
- メンバー: Organizationに招待されたユーザー（個人アカウント）。各リポジトリに対して、それぞれ異なる権限レベルを設定できます
ここで発注者が特に注意すべきなのが「どの Organization に、あなたのリポジトリが置かれるか」です。委託先のOrganizationの中に置かれるのか、発注者側のOrganizationに置かれるのかで、プロジェクト終了時のコード引き継ぎ方法が大きく変わります。この論点は後の章で詳しく扱います。
GitHub で行われる主な開発活動（プルリクエスト・Issue・Actions）を発注者の視点で一望する
GitHub は単にコードを置く場所ではなく、開発の様々な活動のハブになっています。発注者が議事録で遭遇しそうな用語を整理しておきます。
- プルリクエスト（Pull Request、略称 PR）: 「このブランチの変更を main に統合してよいか」をチームで議論・レビューする仕組み。変更内容・差分・レビューコメントが一元表示されます。発注者が見ると「どんな機能が、どんなレビューを経て統合されたか」が追えます
- Issue（イシュー）: バグ報告・機能要望・タスクを記録するチケットシステム。発注者側もIssueを書いて不具合報告に参加できる場合があります
- Actions（アクションズ）: コードが変更されたときに自動で動かすワークフロー（テスト・デプロイなど）。いわゆる CI/CD の実行基盤です
発注者としては、毎週 PR 一覧を眺めるだけでも「今どの機能が開発中か」「レビューがどれだけ丁寧に行われているか」が見えるので、進捗モニタリングの道具として活用できます。
関連記事: CI/CDとは？発注者が知っておくべきメリット・コスト・確認リスト完全ガイド
バージョン管理がシステム開発で重要な5つの理由（履歴・ロールバック・協働・品質・監査）
バージョン管理はエンジニアにとっての便利ツールというだけでなく、発注者にとっても「リスクを下げ、品質を担保する基盤」です。ここでは発注者目線で、なぜバージョン管理が重要なのかを5つの観点から整理します。
変更履歴が残るから「誰が・いつ・なぜ」を監査できる
コミット履歴には「誰が・いつ・何を・なぜ変更したか」が記録されます。これは単なる開発ログではなく、委託先の作業実態を発注者が後から確認できる監査記録でもあります。
たとえば、リリース後に問題が発生したときに、「この機能はいつ・誰が追加し、どんなレビューを経たか」をリポジトリの履歴だけで追跡できます。仕様書や議事録だけでは分からない「実際のコード変更の経緯」を、発注者側でも検証できるというのは大きな価値です。
ロールバック（過去バージョンへの復元）で障害時の被害を最小化できる
新しいバージョンをリリースした直後に重大な不具合が発覚したとき、バージョン管理があれば「一つ前の安定していたバージョンに戻す」という作業が数分〜数時間で完了します。これをロールバックと呼びます。
バージョン管理がない時代は、障害発生時に手作業でバックアップから戻す必要があり、復旧に半日〜1日かかることも珍しくありませんでした。バージョン管理はビジネス継続性の観点から、事業停止時間を劇的に短縮してくれます。
ブランチ運用で複数人が並行作業しても衝突しない
ブランチを使えば、複数の機能を複数人で並行開発しても、お互いのコードを壊し合うことがありません。完成した機能から順に main ブランチに統合していくため、プロジェクト進行のスピードが上がります。
発注者視点では、ブランチ運用が適切にできている委託先は、スケジュール遅延のリスクが構造的に低いと判断できます。逆に「ブランチを切らずに全員が main を直接編集する」運用をしている場合、それだけで品質管理体制に疑問符がつきます。
プルリクエストによるレビュー文化が品質を担保する
プルリクエストは、変更を main に統合する前に「他のメンバーにレビューしてもらう」仕組みです。別のエンジニアの目が入ることで、バグやセキュリティリスク、設計上の問題を事前に発見できます。
発注者としては「プルリクエストでのレビューが何人以上の承認を必須としているか」を確認することで、委託先の品質担保プロセスの強度が分かります。レビュー必須ルールがないチームと、2名以上のレビュー承認がないと統合できないチームでは、品質に大きな差が出ます。
バージョンタグで「何が本番に入っているか」を明確化できる
Git には「タグ」という仕組みがあり、特定のバージョンに「v1.0.0」「2026-03-release」のような目印をつけておけます。このタグを使うと、「今本番で動いているのはどのバージョンか」「先月のリリースに含まれていた機能は何か」を明確に追跡できます。
発注者としては、リリースのたびにタグが付けられているか、タグに対応したリリースノート（変更点の説明）が残されているかを確認すると、運用の成熟度が見えてきます。
関連記事: デプロイとリリースの違いとは？発注者が知るべき確認ポイントを解説
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
発注者がGit/GitHubで必ず確認すべき5つのポイント【チェックリスト】
ここからが本記事の核です。委託先との開発プロジェクトで、発注者が必ず確認・依頼すべき5つのポイントを具体的に示します。それぞれ「なぜ重要か」「委託先に何を依頼するか」のセットで整理しました。
① Organization の所有権は誰が持つのか（委託先 Organization か、発注者 Organization か）
なぜ重要か: GitHub のリポジトリは、必ずいずれかの Organization または個人アカウントに所属します。もし委託先の Organization に置かれた場合、その Organization の Owner（最高権限者）は委託先の社員です。契約終了後に Organization を閉じられたり、アカウントごと消されたりすると、リポジトリへのアクセスを失うリスクがあります。
委託先に依頼すること:
- 新規プロジェクトの場合は、発注者側で GitHub Organization を作成し、そこにリポジトリを作ってもらうのが最も確実です
- 既に委託先 Organization にリポジトリがある場合は、プロジェクト開始時または完了時に発注者 Organization への Transfer（移譲）を行う合意を取り付けます
- 少なくとも「Organization の所有権がどちらにあるか」を書面で確認しておきます
② 発注者側に Admin または Owner 権限が付与されているか（最低でも Read ではなく、少なくとも Maintain 以上を想定）
なぜ重要か: GitHub のリポジトリには複数の権限レベルがあり、発注者がどの権限で招待されるかで、できることが大きく変わります。Read 権限だけだと「見る」ことしかできず、権限設定を変えたり、メンバーを追加したりできません。
GitHub の Organization レベルのリポジトリ権限は、上位から Admin → Maintain → Write → Triage → Read の5段階です（GitHub Docs: Organizationのリポジトリロール）。
権限 | 概要 | 発注者が持つべきか |
|---|---|---|
Admin | 全設定の変更・メンバー管理・削除 | ○（少なくとも発注窓口1名は推奨） |
Maintain | 設定変更の一部・リリース管理 | ○(最低限のライン) |
Write | コードのプッシュ・ブランチ作成 | △（開発に参加する場合） |
Triage | Issue・PR のトリアージ | △（読み取り+α） |
Read | 閲覧のみ | ×（発注者が取るには弱すぎる） |
委託先に依頼すること: 少なくとも発注側の担当者1名に Admin（または Organization Owner）権限を付与してもらいます。「コードを読めないから Read で十分」ではなく、「何かあったときに権限変更や引き継ぎができる状態」を確保することが目的です。
③ README・設計書・運用手順がリポジトリ内に揃っているか（コードを読めなくてもドキュメントで把握できる状態）
なぜ重要か: 発注者がソースコードを読めなくても、リポジトリに同梱されているドキュメント（README・設計書・運用手順）を見れば、システムの概要・動かし方・運用時の注意点を把握できます。これらが整っていないと、将来別のベンダーに引き継ぐときに多大な調査コストがかかります。
委託先に依頼すること:
- README（リポジトリの入口ドキュメント）に、システム概要・使用技術・起動手順・連絡先を記載してもらう
- 設計書（アーキテクチャ図・ER図・API仕様など）をリポジトリ内の
docs/ディレクトリに同梱してもらう - 本番運用手順書（デプロイ・障害対応・監視）もリポジトリ内に置いてもらう
- ドキュメントがソースコードの更新と同じフローで更新されることを契約時に確認する
これが揃っていれば、仮に将来ベンダーを変更する事態になっても、新しいベンダーは README から出発して全体像を把握できます。
④ ブランチ保護・レビュー必須設定が入っているか（main ブランチへの直接pushが禁止されているか）
なぜ重要か: GitHub には「ブランチ保護ルール」という機能があり、「main ブランチに直接 push させない」「プルリクエストで必ず1名以上のレビュー承認を必要とする」といったルールを強制できます。この設定が入っていないと、誰かが勝手に未レビューのコードを本番ブランチに入れてしまうリスクがあります。
委託先に依頼すること:
- main ブランチ（または本番ブランチ）に対してブランチ保護ルールを有効化してもらう
- プルリクエストによる統合を必須にし、最低1名以上のレビュー承認を必要条件とする
- 可能であれば自動テスト（CI）の成功をマージ条件に追加してもらう
- 設定画面のスクリーンショットを提出してもらい、発注者側でも設定を確認する
⑤ プロジェクト終了時のソースコード引き渡し方法が契約で明文化されているか（Transfer / Archive のエクスポート / 発注者 Organization へのフォーク）
なぜ重要か: 「ソースコードを納品する」という契約文言だけでは、実際にクラウド上にあるリポジトリをどう引き渡すかが曖昧です。プロジェクト終了後に「GitHubのアクセス権が切れて過去の履歴もIssueも見られない」という事態を防ぐため、引き渡し方法を具体的に定めておく必要があります。
委託先に依頼すること:
- 契約書に「プロジェクト終了時のソースコード引き渡し方法」を具体的に記載する
- 選択肢としては、発注者 Organization への Transfer、最新コードの ZIP または Clone による配布、履歴込みのアーカイブ提供などがあります（次の章で詳しく解説します）
- 引き渡し対象にソースコードだけでなく、Issue・プルリクエスト・Wiki・CI 設定なども含めるかを明記する
ソースコードの著作権と成果物確保——契約書と GitHub 設定の対応関係
「契約書にソースコードを納品すると書いた」だけでは、残念ながら成果物の確保としては不十分です。法的な取り決め（著作権）と、実際のクラウド上の運用（GitHub 設定）の両方が揃って、初めて発注者は成果物を自社資産として確実に確保できます。
著作権は原則としてベンダーに帰属する（譲渡条項がなければ利用許諾ベース）
日本の著作権法では、委託して作成されたソフトウェアの著作権は、原則として作成者（ベンダー）に帰属します（著作権法第17条等）。発注者がソースコードを自由に使えるようにするためには、契約書で以下のいずれかを明記する必要があります。
- 著作権譲渡: 著作権をベンダーから発注者へ完全に譲渡する（著作権法第27条・第28条を含むことを明記）
- 利用許諾（ライセンス）: 著作権はベンダーに残るが、発注者が業務で利用・改変・再委託できる権利を許諾する
参考: 「システム開発における著作権は誰のものか」の法務解説（発注ラウンジ）、および「ソフトウェア開発委託契約におけるベンダのソースコード提供義務」（IT法務.COM）が参考になります。
発注者としては「譲渡」が理想ですが、ベンダー側が自社ノウハウの他案件転用を考えている場合、譲渡ではなく広範な利用許諾で合意するケースもあります。どちらにせよ、契約書に明記されていなければデフォルトはベンダー帰属という点を理解しておいてください。
契約書に盛り込むべき条項（著作権譲渡 or 利用許諾、ソースコード引き渡し義務、第三者コード・OSSの扱い）
契約書に盛り込みたい条項を整理します。
- 著作権の帰属または利用許諾: 譲渡するのか、許諾するのか。許諾の場合は利用範囲（業務利用・改変・第三者再委託）を明記
- ソースコード引き渡し義務: プロジェクト終了時・契約解除時に、発注者が指定する方法でソースコードを引き渡す義務を明記
- ドキュメント引き渡し義務: 設計書・運用手順などもコードと合わせて引き渡す対象にする
- 第三者コード・OSSの扱い: 使用しているOSS（オープンソースソフトウェア）のライセンス一覧を提出してもらい、ライセンス条件を遵守している旨を保証してもらう
- 契約解除時の取り扱い: トラブルで契約解除に至った場合でも、支払い済みの成果物分は発注者が使える状態を担保する
GitHub 設定で契約を裏付ける（所有 Organization の確認 / Admin 権限 / プロジェクト終了時の Transfer 手順）
契約書の条項は、実際の GitHub 設定と対応付けて初めて機能します。次のような対応関係を意識してください。
契約条項 | 対応する GitHub 設定 |
|---|---|
著作権譲渡・利用許諾 | 所有 Organization の確認（発注者 Orgにあるか） |
ソースコード引き渡し義務 | 発注者担当者への Admin 権限付与・Transfer 手順の事前合意 |
ドキュメント引き渡し義務 | README・ |
OSS の扱い | ライセンス一覧ファイル（LICENSE・依存ライブラリ一覧）の確認 |
契約解除時の取り扱い | 定期的な ZIP エクスポートのバックアップ取得 |
契約書は「権利の設計図」、GitHub 設定は「その設計を現物で裏付ける仕組み」と考えてください。両方が揃うことで、発注者は成果物を法的にも物理的にも確保できます。
プロジェクト終了後もソースコードを確実に受け取る3つの方法
「委託先の Organization にあるリポジトリが、契約終了後に消えてしまったらどうしよう」という不安に対する、実務的な3つの回答を提示します。
① 発注者 Organization を最初から所有側にする（最も確実）
プロジェクト開始前に、発注者側で GitHub Organization を作成しておき、その Organization の中にリポジトリを作ってもらう方法です。
メリット:
- Organization の Owner は発注者なので、契約終了後も Organization 自体はそのまま残る
- 委託先のアカウントを削除（招待解除）するだけで、アクセス権を即座に切り離せる
- Issue・プルリクエスト・Wiki などの履歴もそのまま残る
デメリット: GitHub の Organization プラン料金（Team プランの場合メンバー1人あたり月額約4ドル、2026年時点）が発注者負担になります。ただし、成果物確保のコストとしては十分許容範囲でしょう（料金は変動する可能性があるため最新情報はGitHub の料金ページで確認してください）。
初期設定の手間はありますが、プロジェクト開始時点でこの体制を取るのが最もリスクが低い方法です。
② プロジェクト終了時にリポジトリを Transfer してもらう（事前合意が前提）
委託先の Organization にあるリポジトリを、プロジェクト終了時に発注者の Organization へ移譲（Transfer）してもらう方法です。
メリット: 履歴・Issue・プルリクエスト・Wiki などがすべてそのまま移ります。Web上のURLも移譲先に自動的にリダイレクトされます。
デメリット:
- 事前に Transfer の合意を契約書で取り付けておく必要があります
- 発注者側にも受け入れ用の Organization が必要です
- トラブルで契約解除に至った場合、委託先が協力してくれない可能性があります
契約書に「プロジェクト終了時にリポジトリを発注者指定の Organization へ Transfer する」と明記しておくことが前提です。
③ ZIP エクスポート・clone によるアーカイブ受領（最終手段）
GitHub のリポジトリをZIPファイル形式でダウンロードしてもらう、または git clone という方法で全履歴込みのコピーを作ってもらう方法です。
メリット: 操作が簡単で、Organization の付け替えが不要です。定期的にバックアップとして取得しておくこともできます。
デメリット:
- ZIP 形式だとコミット履歴が失われます（最新コードのみ）
- Issue・プルリクエスト・Wiki・GitHub Actions の履歴などは含まれません
git cloneで履歴を取得しても、それだけでは GitHub 上のIssue/PR履歴は移せません
この方法は補助的なバックアップとしては有効ですが、これだけに頼るのは避けてください。 履歴や議論の経緯が失われると、後からトラブル対応・機能改修に必要な情報が欠落します。
どの方法が適しているかは「継続運用の有無」と「契約形態」で決まる
選択肢の選び方をまとめます。
ケース | 推奨される方法 |
|---|---|
プロジェクト完了後も自社で継続運用する（保守フェーズあり） | ① 発注者 Organization 所有 |
一度きりの開発で終わるが、将来改修する可能性がある | ② プロジェクト終了時の Transfer |
短期プロジェクトで、履歴は参考程度にあれば十分 | ③ ZIP アーカイブ受領（①②併用推奨） |
委託先との関係が切れるリスクを考慮したい | ① を最優先 |
いずれの場合も、契約書で明文化しておくことと、プロジェクト途中でも定期的にバックアップを取ることは共通して重要です。
まとめ——バージョン管理の知識は発注者の「成果物を守る武器」になる
本記事では、バージョン管理・Git・GitHub の基本から、発注者として確認すべきポイント、契約と設定の対応、プロジェクト終了時の引き渡し方法までを解説しました。要点を振り返ります。
- バージョン管理は発注者にとってもリスク管理の基盤: 単なる開発者の便利ツールではなく、変更履歴の監査・障害時のロールバック・品質担保の仕組みを支える基盤
- Git と GitHub の違いを押さえる: Git はバージョン管理の仕組み、GitHub はそれを共有するクラウドサービス
- 発注者は権限を持つべき: 最低でも Admin 権限を1名に確保し、Organization 所有権・ブランチ保護・ドキュメント・引き渡し方法の5点を確認
- 契約書と GitHub 設定はセットで機能する: 著作権譲渡・引き渡し義務などの契約条項は、発注者 Organization 所有・Transfer 手順などの実運用で裏付ける
最後に、今日から始められる次のアクションを3つ提案します。
- 委託先に Organization 構成を確認する: あなたのプロジェクトのリポジトリは、委託先の Organization にありますか、それとも発注者側の Organization にありますか。まずこの1点を確認するところから始めてください
- 権限ロールを確認する: あなた自身（または発注窓口の担当者）は、どの権限レベルでリポジトリに招待されていますか。Read しか付与されていない場合は、Admin 権限の付与を依頼しましょう
- 契約書と GitHub 上の引き渡し方法を照合する: 契約書の「ソースコード納品」の条項は、具体的にどの方法（Transfer・ZIP・Organization 移管）を指しているか、今すぐ見直してみましょう
バージョン管理の知識は、発注者が成果物を自社の資産として守るための武器になります。本記事が、次の打ち合わせで自信を持って委託先とコミュニケーションを取るための一助になれば幸いです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- すでに開発が始まっていて委託先のOrganizationにリポジトリがある場合、今から発注者側のOrganizationに移せますか？
はい、GitHubの「Transfer（移譲）」機能で途中からでも移せます。ただし委託先側のAdmin権限者の協力が必要なため、プロジェクト開始時に契約書へ「終了時にTransferする」と明記しておくことが前提です。
- 発注者が現時点でRead権限しか持っていない場合、Admin権限を後から追加してもらうよう委託先に依頼できますか？
依頼できますし、拒否される理由はありません。「コードを読めないが成果物の統制権限を持つ必要がある」と説明し、Admin権限または最低でもMaintain権限の付与を文書で依頼してください。
- GitHubのOrganizationを発注者側で作るとコストはどれくらいかかりますか？
TeamプランはメンバーひとりあたりUS$4/月が目安です（2026年時点、変動あり）。開発期間中のメンバー数で概算でき、成果物を確保するコストとして多くのケースで許容範囲に収まります。
- 契約書に「ソースコードを納品する」と書いてあれば十分ですか？
不十分です。「GitHubリポジトリをTransferする」「全コミット履歴・Issue・PRを含む」「発注者指定のOrganizationへ移譲する」まで具体的に記載しないと、ZIPファイル1枚だけの納品も契約上は有効になってしまいます。
- プロジェクト終了後、委託先エンジニアの手元にソースコードのコピーが残るリスクはどう防げますか？
GitHubの権限を削除しても、git cloneで取得したローカルコピーは削除できません。契約書の秘密保持条項に「契約終了後はすべての複製を破棄し誓約書を提出する」と定めることが現実的な対策です。
