社内規程は「最初の設計」が9割。設立前にGitHubで作ったドキュメントが、2年経っても運用しやすい話

「有給の申請方法ってどこに書いてありましたっけ？」

「最新版の経費ルールってどれですか？」

会社が大きくなるにつれて、どこの組織でも必ず出てくるこの質問。SOZOでは、会社の設立前からこの問題に先回りして手を打っていました。

答えはシンプルで、社内規程をすべてGitHubで管理し、エンジニアの開発と同じ「Issue → ブランチ → Pull Request → マージ」のフローで更新する、というものです。

そして約2年運用してきて確信しているのは、社内ドキュメントは「最初の設計」でほぼ決まるということ。今回は、その設計と、設計のおかげで運用がどれだけ楽になったかを、実際の画面と一緒に紹介します。

設立の25日前に、最初のコミット

SOZOの登記は2024年10月29日。

一方、社内ドキュメント用リポジトリ doc の最初のコミットは 2024年10月4日です。

最初に書いたのは会社のルールではなく、「DOCの更新方法」というドキュメントでした。

• ブランチ運用はトランクベース開発
• ブランチ名は issue-{イシュー番号}
• 変更するときは、まず Issue を立てる
• PR を出して、Development 欄で Issue と紐づける

つまり「ルールの中身」より先に「ルールの変え方」を決めたんです。会社のルールは一度作って終わりではなく、事業や人数の変化にあわせて何度も変わっていくもの。だからこそ、毎回同じ手順で、履歴を残して変えられる仕組みを最初に用意しました。

最初に決めた「型」

設立直後の2024年11月に、ほぼすべてのページを一気に書き上げ、ディレクトリ構成もこのタイミングで今の形に固めました。決めたのは大きく3つです。

① 番号付きのディレクトリ構成

フォルダもファイルも 01_ 02_ と番号から始め、各フォルダには 00_ディレクトリ.md という目次ページを置いています。新しい制度ができても「どこに置くか」で迷うことがありません。

② README からすべてのページに辿れる

ルートの README に全ページへのリンクを集約し、各ページの末尾には必ず「README へ戻る」リンクを置いています。入社した人はまず README を開けばいい。迷子になりません。

③ 全ページ共通のフォーマット

どのページにも、

• 目次
• 作成日
• 最終更新日
• 最終更新者(GitHubアカウントへのリンク付き)

が入っています。「これ、いつの情報？」「誰に聞けばいい？」がページを開いた瞬間にわかります。

最初の設計のおかげで、運用が「超」楽になった

1. 足すときに迷わない。2年経っても構成が崩れない

社内Wikiが荒れていく一番の原因は、「とりあえずここに置いておこう」の積み重ねだと思っています。

SOZOのdocは、現在 63ページ。その後も制度やルールはどんどん増えましたが、トップのディレクトリ構成は2024年11月に決めた 8つの棚(00〜07)から一度も変わっていません。番号付きの棚と共通フォーマットが最初にあるので、新しいページを足すときは「該当の棚に、同じ型で書くだけ」。ドキュメントが増えても、読みやすさが落ちないんです。

2. 変更履歴がすべて残る。「いつ・なぜ」変えたかが一目瞭然

Google ドキュメントや社内Wikiでもバージョン履歴は見られます。でも GitHub の場合、変更の理由が Issue と PR に必ずセットで残るのが決定的に違います。

「このルール、なんで変わったんだっけ？」と思ったら PR を開けば、経緯ごと確認できます。約2年で、コミット数は 299、マージした PR は 115件。会社のルールの変遷が、1件ずつ記録として積み上がっています。

3. 差分(diff)で「何が変わったか」だけが見える

規程の改定でありがちなのが、「新しいPDFが配られたけど、前と何が違うのかわからない」問題。

GitHub なら、変更点は赤と緑の差分でそのまま見えます。たとえば最近の例では、有給申請のフォーマットに「稼働時間」の記入欄を追加しました。この PR では、

1. 稼働時間の記載欄を追加
2. 項目名を「有給申請時想定稼働時間」に変更
3. 最終的に「月末の総稼働見込み時間」に集約

と、3回のコミットでルールを磨いていった過程がそのまま残っています。

4. エンジニアにとって「いつもの道具」で読める

弊社のメンバーの100%エンジニアです。

社内規程のために別のツールのアカウントを作ったり、使い方を覚えたりする必要はありません。普段の開発と同じ GitHub / Markdown で、いつでも最新版を読めます。

5. 「静的な情報」と「動的な情報」がきれいに分かれる

GitHub に置いているのは、あくまで静的な情報――つまり「ルール」「手順」「制度」です。

日々のやりとりは Slack、勤怠は勤怠システム、と役割を分けているので、Slack で同じ質問が何度も流れることがなくなりました。「それは doc のここに書いてあります」とリンクを貼れば終わり。説明する側の時間も、聞く側の気まずさも減ります。

ちなみに内勤向けの業務フロー(採用、入社受け入れ、出向、月末締めなど)も、別リポジトリ officework-doc で同じ型で管理しています。

これから社内ドキュメントを作る人へ

2年運用してきて、「最初にやっておいてよかった」と思うことをまとめるとこんな感じです。

• ルールより先に「変え方」を決める— Issue → ブランチ → PR の手順を最初に書く
• 棚(ディレクトリ)を先に作る — 番号付きで、各フォルダに目次ページを置く
• フォーマットを固定する — 目次・作成日・最終更新日・最終更新者・README へ戻るリンク
• 入口を1つにする — README から全ページに辿れるようにする

どれも最初にやれば数時間で済むことですが、後からやろうとすると何倍も大変です。

最後に

SOZOのミッションは「挑戦するなら、SOZO」。

会社の土台になる仕組みも、エンジニアらしく設計から考えて作っています。

• 社内ドキュメントまで GitHub で回している会社、ちょっと面白いかも
• 仕組みを設計するところから考えるのが好き
• 未経験だけど、エンジニアの文化が根づいた環境で成長したい

そんな方は、ぜひ一度カジュアルにお話ししましょう!