GitHubの活用事例(弁護士ドットコム株式会社)

当社では、長らく GitLab Self-Managed を開発基盤として利用してきました。開発組織やリポジトリ数の増加に伴い、インフラ運用、アップデート、脆弱性対応などの負荷が大きくなっており、最終的に GitHub Enterprise Cloud への移行を実施しました。

移行の詳細は当社の Creators Blog の記事「800リポジトリを1年半で GitLab Self-Managed から GitHub Enterprise Cloud へ移行した話」でも紹介しており、本記事では移行後の GitHub 活用、特に サプライチェーン攻撃への対策も意識したセキュリティ運用 を中心に紹介します。

ツール導入前の課題

主な課題は、GitLab Self-Managed の運用負荷が高く属人化しやすいことと、CI/CD・権限設定・セキュリティ設定がリポジトリごとに分散し、横断的に把握・統一しづらいこと でした。

• GitLab 本体やインフラの継続的な運用負荷
• CI/CD や権限設定の標準化
• GitHub 上でシークレット混入を検知・防止できる状態の整備
• 脆弱性検知における有効化状況や運用のばらつき

どのような状態を目指していたか

開発チームが日常的に利用する基盤を GitHub に集約し、SRE や Platform Engineering を含む横断チームが全体方針と標準化を支援できる状態を目指しました。

リポジトリ管理や CI/CD だけでなく、Secret scanning、Dependabot Alerts などのセキュリティ機能も同じ基盤で扱い、設定状況を Organization 単位で見える化したいと考えていました。

• GitLab Self-Managed
• GitLab SaaS

• インフラ運用の負荷を下げられるか
• CI/CD の標準化を進めやすいか
• セキュリティ機能を開発フローに組み込みやすいか
• SRE や Platform Engineering を含む横断チームが支援しやすいか

GitLab SaaS も、Self-Managed の運用負荷を下げられる有力な選択肢でした。既存の GitLab 利用体験を大きく変えずに移行できる点は、GitLab SaaS の大きな利点でした。 一方で、今回の移行では既存運用の延長ではなく、CI/CD、権限設定、セキュリティ運用を含めて開発基盤全体を見直すことを重視しました。

GitHub Enterprise Cloud は、単にリポジトリをホストする場所としてではなく、開発基盤全体を標準化する中心にしやすい と判断しました。開発者の日常的な開発フロー、セキュリティ検知・対応、横断チームによる標準化支援を同じ基盤上で進めやすい点を評価しています。

また、当社では Copilot 関連機能への関心も高まっていました。GitHub の AI 戦略や開発者支援の方向性に期待があったことに加え、検討時に担当営業やエンジニアへ相談しながら移行・運用面の具体的なイメージを持てたことも、GitHub Enterprise Cloud を選定する後押しになりました。また、開発者側にも GitHub を中心とした開発体験への関心があり、移行後の定着や改善を進めやすいと考えました。

改善したかった課題はどれくらい解決されたか

GitLab Self-Managed の運用負荷については、GitHub Enterprise Cloud への移行により、自社で GitLab のインフラや本体アップデートを継続運用する負担を大きく下げることができました。

GitLab Self-Managed では、アップデート対応のたびに事前調査や手順作成、レビュー、作業実施が必要で、月あたり10時間前後の定常的なメンテナンス工数 が発生していました。移行後は、この工数を GitHub 運用の標準化やセキュリティ施策に振り向けやすくなりました。

移行プロジェクト全体では、63チーム、293名の開発者、802リポジトリを対象に、1年半かけて段階的に移行しました。

どのような成果が得られたか

GitHub を起点に、リポジトリ管理、CI/CD、権限設定、セキュリティ設定を同じ基盤上で扱いやすくなりました。

特に大きかった成果は以下です。

• GitLab Self-Managed のインフラ運用や本体アップデートの負担を下げられた
• 802リポジトリを段階的に GitHub Enterprise Cloud へ移行できた
• GitHub を中心に CI/CD や権限設定を見直すきっかけになった
• Security coverage を起点に、リポジトリごとのセキュリティ設定を棚卸しできるようになった

GitLab から GitHub への移行は、リポジトリを移すだけでは完了しませんでした。GitLab CI やその変数、Issue、Merge Request などを GitHub 側でどう扱うかを整理する必要がありました。

各リポジトリの実態は開発チームごとに異なるため、SRE や Platform Engineering を含む横断チームが共通方針を整備し、各開発チームが確認と修正を行う形で進めました。

移行後も、リポジトリごとのセキュリティ設定にばらつきが残るため、継続的な棚卸しと是正の運用が必要でした。

GitHub Enterprise Cloud は、リポジトリ管理だけでなく、CI/CD とセキュリティ運用を同じ基盤で整えたい組織 にとって有力な選択肢だと思います。

大規模に導入する場合は、移行そのものよりも、移行後にどのような標準運用を作るかが重要です。誰が棚卸しし、どの範囲を強制し、どこをチーム判断にするのかを決めておくと進めやすいと考えています。

以下に取り組む予定です。

• Code Security / Dependabot の運用整理
• 依存関係更新における cooldown や minimumReleaseAge 相当の設定標準化
• セキュリティチェック用 reusable workflow の整備
• Org Ruleset と組み合わせたセキュリティチェック適用方針の整理

Code Security は、重要度の高いリポジトリから検知内容や運用負荷を確認し、段階的に導入を進める方針です。 reusable workflow と Org Ruleset については、開発体験を損なわない形でセキュリティ上必要なチェックをどの範囲に適用するか、開発チームとも調整しながら検討していきます。