はじめに
皆さんこんにちは。エーピーコミュニケーションズ ACS事業部 亀崎です。
今回はGitHubにおけるRepositoryの可視性について、組織のナレッジ共有という視点から考えてみたいと思います。
GitHub Repositoryの可視性
GitHubのリポジトリの可視性にはどういったものがあるかご存じでしょうか？
実は 3種類 存在します。 Public や Private はよくご存じだと思いますが、GitHub Enterpriseではもう１つ Internal という可視性が指定可能です。
その内容をまとめると次のようになります。
| タイプ | 内容 | 利用できるVersion |
|---|---|---|
| Public | インターネット上のすべてのユーザーが閲覧可能 | すべて（Free, Pro, Team, Enterprise） |
| Private | リポジトリと個別に招待された共同作業者（Collaborators）だけが閲覧可能 | すべて（Free, Pro, Team, Enterprise） |
| Internal | そのGitHub Organizationに所属しているメンバー（招待不要）が閲覧可能 | Enterprise |
PublicはOSS用のリポジトリで、それ以外はすべてPrivateで、と考えていた方も多いのではないかと思います。 ずばり、そんな皆様は損をしています。
たとえば「隣のチームが作った便利なライブラリがあるのに、Private設定のせいで存在を知らず、 自分たちもゼロから作り直してしまった」といったことはないでしょうか？ まさに組織内で「車輪の再発明」という状況になっていないでしょうか。
組織内ナレッジ共有
組織内のナレッジを共有・活用していくことは現代の重要課題です。これはAI駆動開発が中心となってきたことでその重要性が増しているとも言えます。 また、Platform Engineeringでも開発者プラットフォーム（IDP）を通じてIaCやCI/CDなどさまざまなものを共有することで実現します。
こうしたことから、これまでのようにリポジトリを「とりあえずPrivate（非公開）」とする選択は、組織内のナレッジ共有の最大の障壁になることがあります。 本記事では組織内ナレッジ共有を最大化するためのGitHubのリポジトリ可視性であるPublic/Private/Internalの使い分けを解説・推奨したいと思います。
デフォルトをInternalに
私は組織内のリポジトリの可視性は Internal をデフォルトにするのが最善・最強であると考えています。 それは次のような理由からです。
Platform Engineeringにおいても、開発チーム間の情報共有という点においても、その最大の目的は開発チームの認知負荷をさげることです。これを実現する文化が InnerSource です。 InnerSourceを成功するためには以下のような点が重要になります。
「見せる」ことで信頼を築く
エンジニアは中身がブラックボックスなものを嫌います。OSSが広く受け入れられているのもその中身を見ることができるからです。 可視性を Internal にし、組織内に公開することで、「中で何をやっているのか」「どのように実現しているのか」が見えるようになり、他チームの開発者からも信頼されるようになります。
「改善」のループをまわす
リポジトリが Internal であれば、他チームの開発者から疑問点や課題などの指摘（Issue）が 報告されることもあります。また場合によっては自ら修正案（Pull request）を提出してくれることもあります。 そのリポジトリの内容を担当するチームメンバー以上の目に触れるようにすることで、より多くの改善を実施することができます。
Privateの使いどころ
もちろん、すべてのリポジトリを無条件でInternalにすべき、ということではありません。 組織内であっても「意図的に閉じる」ことが正解となるケースも存在します。
プロジェクト初期の「仕込み」段階
コンセプトが固まっていない極初期の段階や、新規事業のステルスプロジェクトなど、 情報の出しどころをコントロールする必要がある場合。
限定的なライセンスや契約が絡む場合
外部ベンダーとの契約上、閲覧者を特定のチームに限定する必要があるソースコードや、 商用ライセンスの関係で組織全体への公開が制限されているツールなど。
高度な機密情報を扱う「管理用」リポジトリ
インフラの核心的な鍵管理設定や、人事情報などの機密データを扱うスクリプトなど、 万が一の誤操作や情報漏洩のリスクが組織内共有のメリットを上回る場合。
「とりあえず隠す」のではなく、「共有によるメリット（ナレッジ活用）」と 「隠すことによるメリット（リスク管理）」を天秤にかけ、 明確な理由がある場合にのみPrivateを選択する、というスタンスが重要です。
可視性の選択のポイント
リポジトリを Private にするということは、そのリポジトリ（情報資産）に関する対話を 「チーム内」に閉じ込めることを意味します。一方で Internal にすることは、組織全体に コラボレーションの門戸を開くことを意味します。
組織のエンジニアリング文化を変える活動にするために。まずは、あなたのリポジトリを一つ、 Internal に変更してみませんか？
弊社のサービスのご紹介
エーピーコミュニケーションズでは、GitHubを活用したDevOps導入・定着支援、GitHub Advanced Securityの導入などGitHubに関する導入支援を行っており、 「設定のベストプラクティスが知りたい」「組織全体への展開をサポートしてほしい」といったご要望に、経験豊富なエンジニアがお応えします。
セキュリティを「開発のブレーキ」ではなく「加速装置」へ。ぜひ私たちにお手伝いさせてください。
