第5章 仕事で使えるGitHub運用にする
想定学習時間: 11分
GitHubは、単に開発中にコードを管理するツールではありません。プロジェクトの最終段階である納品、チーム内や外部との共有、そして将来の担当者への引き継ぎといった場面においても、その真価を発揮します。特に、継続的な修正や改善が前提となる制作物においては、単なるファイルの受け渡し以上の価値を提供します。
ファイルをZIP形式で渡したり、メールに添付したり、クラウドストレージで共有したりする方法は手軽です。しかし、コードやWeb制作物、AIが生成したツールなど、後から修正や改善が続く可能性のある制作物では、これらの方法だけでは情報が不足しがちです。
これらの情報はファイルそのものからは読み取れません。GitHubを使えば、これらの背景情報をリポジトリ内に体系的に残すことができます。
制作物を納品する際、単に「完成したファイル」を渡すだけでなく、「完成物の状態」を明確に伝えることが重要です。GitHubを利用することで、この「状態」を効果的に伝えることができます。
GitHubリポジトリのREADME.mdファイルは、納品物の説明書として機能します。以下のような情報を記載することで、受け取る側がプロジェクトの状況を深く理解できるようになります。
mainブランチ）例えば、LP制作を納品する場合、HTML、CSS、画像ファイルをZIPで渡すだけでは、相手は「スマホ表示の調整箇所はどこか」「問い合わせフォームは実装済みか」といった疑問を抱くかもしれません。READMEにこれらの情報を明記することで、納品後のスムーズな運用を支援できます。
AIを活用して制作された納品物では、見た目が整っていても、フォーム送信処理が未実装であったり、ダミーテキストや仮画像が残っていたりすることがあります。受け取る側が「すべて完成している」と誤解しないよう、READMEで未実装部分や注意点を具体的に明記することが不可欠です。
このリポジトリは、〇〇サービスLPの納品用です。
現在のmain branchが納品版です。
GitHub Pagesで確認用ページを公開しています。
フォームは見た目のみで、送信処理は未実装です。
画像は仮素材です。本番公開前に差し替えが必要です。
AI生成コードを含むため、公開前に人間による確認が必要です。
このように詳細を記載することは、納品時の誠実さを示すことにも繋がります。
チームメンバーや外部パートナーとの制作物の共有においても、GitHubは単なるファイル共有サービス以上の機能を提供します。共同作業を効率的に進めるための基盤となります。
GitHubでは、単にファイルを共有するだけでなく、以下の流れで共同作業を進めることができます。
branch）を作成してもらう。Pull Request）として提出してもらう。mainブランチに取り込む（マージする）。このプロセスにより、index_final.html、index_final_fix.htmlといったファイル名の混乱を避け、変更履歴を明確に保つことができます。安定版のmainブランチを保護しつつ、複数のメンバーが並行して作業を進めることが可能です。
共有においては、誰にどの程度の権限を与えるかを適切に管理することが重要です。全員に強い権限を付与する必要はありません。役割に応じて権限を分けることで、セキュリティを確保し、誤操作のリスクを低減できます。
外注先との共有の場合も同様に、案件終了後は速やかに権限を見直すなど、一時的な共有を放置しないよう注意しましょう。クライアント情報や秘密情報が含まれる場合は、共有範囲を慎重に決定する必要があります。
READMEに作業ルールを明記しておくことで、参加者が迷うことなく作業を進められます。特に新しいメンバーや外注先との連携では、口頭説明だけでなく文書に残すことが重要です。
作業は必ずbranchを作成して行ってください。
mainには直接commitしないでください。
修正が終わったらPull Requestを作成し、変更内容と確認してほしい点を記載してください。
APIキーや個人情報はcommitしないでください。
不明点はIssueにコメントしてください。
GitHubでは、「どこを見ればよいか」を明確にすることで、作業が整理されます。例えば、確認用URLはREADME、修正依頼はIssue、変更内容はPull Request、最新版はmainブランチ、試作はbranchといった具合です。
担当者の変更、外注先の交代、プロジェクトの再開など、引き継ぎの場面でGitHubは非常に大きな力を発揮します。コードそのものだけでなく、その背景にある情報を残すことで、新しい担当者がスムーズにプロジェクトを開始できるようになります。
引き継ぎで最も困るのは、コードの背景情報が不明なことです。「なぜこの構成なのか」「なぜこの機能は未実装なのか」「過去にどんな問題があったのか」といった情報は、コードだけでは分かりません。GitHubの以下の要素を活用することで、これらの情報を追跡できます。
README: プロジェクトの全体像、目的、運用状況Issue: 未対応の課題、過去の議論、バグ報告Pull Request: 大きな変更の理由、レビュー時のコメントcommit履歴: 作業の流れ、各変更の意図branch: 試作や未完了の作業これらの情報があることで、新しい担当者は不安なくプロジェクトに取り組むことができます。
通常のREADMEに加えて、引き継ぎに特化した情報を追記することで、さらに効果的な引き継ぎが可能です。
IssueリストAIが生成したコードを引き継ぐ場合、特に注意が必要です。見た目は動いていても、エラー処理が不十分だったり、セキュリティ上の問題があったり、コメントと実装がずれていたりする可能性があります。「どこまでAIが作ったのか」「どこを人間が修正・検証したのか」「どの処理が仮実装なのか」といった情報を明確に残すことで、引き継ぐ側が注意すべき点を理解し、安全に運用・改善を進められます。
このプロジェクトの初期コードはAI支援で作成しています。
主要な表示部分は確認済みです。
フォーム送信処理は未実装です。
API連携部分は仮実装のため、本番前に再確認してください。
AI生成コードを含むため、機能追加時は差分確認を行ってください。
納品、共有、引き継ぎの各場面において、GitHub上の文章はコードそのものと同じくらい重要です。コードだけでは伝わらない背景や意図を、READMEやIssue、Pull Request、commit履歴で補完することで、制作物は単なるファイルの集まりではなく、「説明付きの保管庫」となります。
AI時代においては、制作物の作成スピードが向上する一方で、その管理と引き渡し方の質が問われます。速く作ったものを雑に渡すのではなく、GitHubで整理し、必要な情報を付加して渡すことで、制作物は一回きりの納品物ではなく、将来にわたって価値を生み出す「資産」へと変わります。
納品前や引き継ぎ前には、チェックリストを作成し、Issueとして管理することが非常に有効です。「納品前チェック」や「引き継ぎ前チェック」といったIssueを作成し、項目をリストアップして確認が終わるごとにチェックしていくことで、作業の抜け漏れを防ぎ、見える化できます。
納品前チェック項目の例:
READMEは更新されているかmainブランチが最新の納品版かIssueは整理されているかまた、共有や引き継ぎで最も大切なのは、「未来の人が困らないようにする」という意識です。この「未来の人」には、他者だけでなく、数ヶ月後の自分自身も含まれます。時間が経てば記憶は薄れるため、重要な情報はREADME、Issue、Pull Request、commit messageといったGitHubの機能を使って残しておくことが、未来の自分への引き継ぎにもなります。
AIとの会話は流れてしまいがちですが、重要な判断や採用した案、修正の経緯などはGitHubに記録することで、AIとの協業も引き継ぎ可能なプロジェクトとして管理できるようになります。
GitHubを納品・共有・引き継ぎに活用する際、最初から完璧な運用を目指す必要はありません。まずはREADMEを整えることから始め、次にIssueで未対応項目を整理し、Pull Requestで変更確認を残すなど、少しずつステップアップしていくことが重要です。
GitHubは、制作物を「自分の手元にあるファイル」から「共有・引き継ぎ可能なプロジェクト」へと変貌させます。コードだけでなく、その背景にある「説明」「履歴」「注意点」「未対応項目」「確認方法」「権限」「引き継ぎメモ」といった情報をGitHub上に集約することで、制作物の価値を最大限に高めることができます。
AI時代の制作において、スピードと同時に管理の質を高めることは、信頼と資産形成に直結します。GitHubを使いこなすことで、あなたの制作物は単なる成果物ではなく、継続的に価値を生み出す「資産」となるでしょう。
人にたとえると
重要なプロジェクトの記録を保管し、関係者間で共有・引き継ぎを行う記録室での出来事。
新しい担当者が記録室にやってきました。彼はまず、入り口にある「全体の案内板」でプロジェクトの概要を把握します。次に、未解決の課題が書かれた「要対応リスト」を確認し、過去の変更点については「修正記録」を辿ります。もし記録に修正を加える場合は、「変更提案書」を提出し、承認を得てから正式な記録として反映させます。こうして、誰がいつ何のために記録を修正したのか、未対応の課題は何かといった情報が、常に整理された状態で保たれます。