GitHubと聞くと、プログラマーがコードを置く場所を思い浮かべるかもしれません。

ところが、就業規則や情報セキュリティ規程といった社内規程を、GitHubで管理している会社があります。単に文書の置き場にしているだけではありません。担当者が改訂案を出し、責任者が承認して正式版に反映する。その手続きにもGitHubを使っています。

コードは書けない。でも、文書を直して、確認してもらい、承認をもらう仕事なら毎日やっている。そんな人に読んでほしい話です。

社内規程をGitHubで管理している会社

公開されている記事やリポジトリ（GitHub上の、履歴付きでファイルを保管する場所）で確認できた例を並べます。どれも公表した時点の情報で、いまも同じ運用を続けているかまでは確かめていません。

会社	公表・導入時期	管理している文書	使い方
クックパッド	2019年6月の記事公開時点で移行済み	就業規則、賃金規程、情報セキュリティ文書など	原則として責任者の承認がないと改訂案を反映できない設定にしている。社員向けには読みやすいWebページを自動で作る¹
ウォンテッドリー	2019年のISMS認証取得以降。紹介記事は2021年7月公開	情報セキュリティ（ISMS）関連の規程	議論と文言の変更提案をGitHub上で行い、承認者をCTO（最高技術責任者）に絞っている²
hey（現：STORES）	2022年6月の記事公開時点で移行済み	社内規程	法務担当者の発案で、セキュリティ部門などと協力して移行。社員は普段使っている情報共有ツール「esa」から読む³
37signals（Basecamp）	2017年5月2日にハンドブックの一般公開を発表	社員ハンドブック（福利厚生、働き方、副業の扱いなど）	誰でも読める形で公開し、変更の履歴を追えるようにしている⁴

例えばクックパッド社では、規程の本文をMarkdownという、見出しや箇条書きを簡単な記号で表すテキスト形式にしています。Wordなどで管理していた文書を、この形式に移してGitHubで扱うようにしたそうです¹。

同社では全社員にGitHubのアカウントが発行されていて、人事部門や法務部門もGitHub上のやり取りに慣れていました。導入がすんなり進んだ理由として、記事ではこの点が挙げられています¹。

仕事の流れは、いつもの規程改訂とほぼ同じ

流れがいちばん分かりやすいのは、ウォンテッドリー社の例です²。

ISMS（情報セキュリティを管理する仕組み。国際規格にもとづく認証がある）を導入した当時、外出先でパソコンを使うときのルールは「盗み見に注意して業務を行う」だけでした。覗き見防止フィルターを使うかどうかは、社員それぞれに任されていたそうです。

ここで、ある社員から、外出先での盗み見対策を強化したほうがよいのでは、という提案が出ます。議論の場になったのは、GitHubのIssue（議題ごとに立てる掲示板のようなもの）でした。事務局も交えて話し合った結果、フィルターを全社員分購入し、外出先での業務では装着を必須にすると決まります。

結論が出たら、担当の事務局が規程の修正案を作り、プルリクエスト（「この文章をこう変えてよいですか」という変更の提案）として出します。承認者のCTOが内容を確認して承認すると、修正案を正式版に取り込めるようになります。この取り込みを「マージ」と呼び、完了すると規程の改訂が反映されます²。

並べてみると、やっていることはこうなります。

問題提起 → 関係者との協議 → 文案の作成 → 責任者の承認 → 正式版への反映

文案を作り、関係者が確認し、責任者が承認する。文書の改訂作業としては、普段の仕事と共通しています。GitHubでは、議論の経緯と、実際に書き換えた文言を結び付けて残せます。ウォンテッドリー社は、当時のGoogleドキュメントとの比較で、起案する人と承認する人をはっきり分けられる点、議論の過程を見える形で残せる点を評価して、GitHubを選んだと書いています²。

※ここで紹介しているのは文書管理の仕組みです。就業規則の変更に際して法令上必要となる意見聴取、届出、周知などの手続きが、GitHub上の承認に置き換わるわけではありません⁵。

全員がGitHubを覚えるわけではない

読んでいて面白かったのが、この点です。

hey社の場合、規程の管理はGitHubで行い、社員が読むのは使い慣れたesaです³。クックパッド社も、規程をそのまま見せるのではなく、読みやすいWebページを自動で作って社員に届けています¹。管理する人に必要な仕組みと、読む人が使いやすい画面を、分けて考えているわけです。

日常の編集作業も、必ずしも黒い画面でコマンドを打つ必要はありません。GitHubには、ブラウザ上でファイルを直接編集する機能があります⁶。クックパッド社では、Git未経験の同僚には、まずこの編集機能を使ってもらったそうです。仕組みをすべて覚えてもらうのではなく、使う機能を限定して移行を進めています¹。

hey社の法務担当者も、もともとGitHubを使ったことがなかったそうです。エンジニアが用意した使い方のドキュメントが助けになり、約70の文書をMarkdown形式に書き換えたと紹介されています³。

もともと使い慣れていた人だけの話ではない。ただし、未経験者がいきなり一人で導入したわけでもない。使う機能を絞ったり、手順書を用意したりする工夫があったところも、参考になります。

どんな文書に向いているのか

ここで挙げた例は、どれも社内規程や社員ハンドブックでした。変えるときに手続きが要り、後から「いつ、誰が、なぜ変えたのか」を確かめたくなる文書です。

逆に言えば、どんな文書でもGitHubに移せばよい、という話にはなりません。ウォンテッドリー社の記事でも、表や台帳はスプレッドシートのほうが管理しやすいケースがあること、頻繁に変える業務ルールはGoogleドキュメントのように気軽に編集できる形式が楽な場合が多いことを挙げています²。変更をきちんと確認したい文書と、日々すばやく書き換えたい文書では、扱い方が違ってよさそうです。

GitHubで管理することと、インターネットに公開することも別の話です。 37signals社のハンドブックは、あえて一般公開しています⁴。一方、非公開のリポジトリにすれば、見られる人を限定できます⁷。社内規程を扱うなら、まずは非公開での管理を前提に、閲覧・編集できる範囲を検討することになるでしょう。

また、非公開にするだけで、責任者の承認が必須になるわけではありません。承認を必須にするには、権限や保護ルールの設定が必要です。利用できる機能は契約プランや公開範囲によって異なるため、導入時には確認が必要です⁸。

自分の職場で、改訂の経緯をたどれなくて困った文書はないでしょうか。どれがいつ変わったのか分からない手順書や、誰が了承したのか分からないルール。思い当たるものがあれば、GitHubがどう役に立つのかを考える入り口になると思います。

クックパッド開発者ブログ「Markdown と GitHub で社内規程を便利に管理」（2019年6月26日）。承認フローには、軽微な修正を担当者の判断で取り込める文書などの例外も記載されています。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Wantedly Corporate Team Blog「GitHubで始める社内規程管理」（2021年7月9日）。Googleドキュメントとの比較や使い分けは、同記事で紹介されている当時の判断です。 ↩ ↩² ↩³ ↩⁴ ↩⁵
STORES note「社内規程をGitHubにお引越し。雑談から始まったheyの横断プロジェクト」（2022年6月6日）。heyは記事公開時点の社名です。STORESの会社沿革によると、2022年10月1日にヘイ株式会社からSTORES株式会社へ商号変更しています。 ↩ ↩² ↩³
basecamp/handbook（GitHub）。一般公開の時期は、公式ブログ「Basecamp’s Employee Handbook is Public!」（2017年5月2日）によります。 ↩ ↩²
厚生労働省「スタートアップ労働条件」Q&A「就業規則の変更はどのように行えばよいのでしょうか。」。本稿は文書管理の活用事例を紹介するもので、就業規則の変更手続きや変更の有効性を解説するものではありません。 ↩
GitHub Docs「ファイルを編集する」 ↩
GitHub Docs「リポジトリについて」 ↩
GitHub Docs「保護されたブランチについて」。非公開リポジトリでのブランチ保護の提供範囲を含め、機能・契約プランの説明は2026年10月15日に確認しています。 ↩