GitHubで始める社内規程管理

こんにちは、コーポレートチームの植田です。

主に法務やISMS関連の業務を行っています。

今回は、GitHubを使った社内規程の管理について紹介をしたいと思います。

Wantedlyでは、2019年に情報セキュリティ認証規格のISMS（ISO27001）を取得して以降、ISMS関連規程の管理をGitHubで行ってきました。

毎年行っているISMS審査においても、審査員からGitHub管理についてポジティブなフィードバックをいただいていますので、WantedlyがGitHubでの規程管理を始めた経緯、実際の運用方法、感じている課題などをシェアしたいと思います。

GitHub導入の経緯

ISMSは、PDCAサイクルに沿って継続的にセキュリティを改善していくマネジメントシステムであるため、社内のセキュリティルールの改定が定期的に発生することになります。

当初、社内ルールの管理方法としてGoogle Docs（「Docs」）とGitHubを比較検討したのですが、GitHubの方が以下の点でメリットがあると判断し、最終的にGitHubで管理をすることにしました。

ガバナンス

ガバナンスの観点から、ISMSルールの改訂は、改定案の起案プロセスと承認プロセスを明確に分離して進めています。

Docsの場合、複数メンバーで同時並行的に起案作業を行うことができるというメリットがある一方で、細かい権限設定ができないため、起案者と承認者を十分に分離できない（承認者を特定の者に限定できない）デメリットがあります。

しかし、GitHubの場合は、reviewer/merge権限を承認者に絞ることで、起案者（branchの作成）と承認者（branchのreview/merge）を明確に分離させることができます。また、規程の作成履歴・変更履歴が半永久的に残るため、誰が規程を変更し、誰が承認をしたのかを後から簡単にトラッキングすることができます。

バージョン管理

社内規程を閲覧している際に、検索で出てきたファイルや社内ポータルなどにリンクされていたファイルが、本当に最新版なのか分からないということは誰もが経験したことがあると思います。

Docsで編集をした場合、ファイルの編集履歴を確認することはできるのですが、より新しい別ファイルが存在する可能性を捨てきれません。

一方、GitHubで規程を管理する場合、マスターデータが常に最新版となるため、最新版かどうかの確認や別ファイルの有無を確認する手間はなくなります。また、逐一「第○版」という版付けをする必要もなくなります。

議論の可視化

規程を管理するにあたって、過去の改定経緯を残すことも非常に重要です。

Docsの場合もコメント機能を使うなどして、議事録を残すことはできるのですが、よりオープンにかつ視覚的に議論の過程を残すにはGitHubに分があるといえます。また、GitHubでは、レポジトリへのアクセス権限さえあれば、起案者以外のメンバーであっても気軽に議論への参加が可能です。議論の結果（issue）と実際の文言の改訂作業（pull request）のリンクも簡単にかつ視覚的に行なえます。

実際のGitHub運用

規程のCode化

ISMSの各規程は、マークダウン形式のファイルにしたうえで、ISMSレポジトリのCode上にまとめてアップしています。

Wantedlyの社員は、誰でもこちらにアクセスできますので、最新のセキュリティルールをいつでも確認することができます。

Issueでのオープンな議論

セキュリティに関する議論は、Issue上で行われます。

例としてWantedlyで数年前に行われた「覗き見防止フィルターの導入」に関する議論を見てみます。

WantedlyではISMS導入当時、外出時のPC利用について「盗み見に注意して業務を行う」というルールがあるのみで、覗き見防止フィルターの利用は各社員に委ねられていました。

しかし、ある社員から、外出先での盗み見対策を強化した方がよいのではないかという提案がなされ、Issue上で議論が始まりました（個人的にはこうした提案が、ISMS事務局以外のメンバーからも挙がることが大事かなと思っています）。

［Issue作成の場面］

事務局も交えた議論を進めた結果、社外業務における情報漏えいリスクを下げるため、覗き見防止フィルターを社員全員分購入し、外出先での業務においてはフィルター装着を必須とする内容にルールを変更することにしました。

規程変更のPull request

Issue上でルール変更の方向性について結論が出たら、次は、既存のルール内容を変更します。具体的には、ISMS事務局で社内ルールの修正案を作成したうえで（branchの作成）、既存ルールの変更リクエスト（Pull request）をします。

［Pull requestの場面］

［新旧差分の参照］

ISMSのレポジトリにおいては、Pull requestのReviewerは承認者であるCTOに絞られているので、CTOの承認（変更箇所のApprove）がなされると、Mergeが可能となります。Mergeが完了すると、覗き見防止フィルター装着に関するルールが無事に改訂されました。

［承認者による承認・Mergeの場面］

GitHub管理の課題

GitHubでの規程管理にもいくつか課題はあるように感じています。

• 表や台帳のようなものは、スプレッドシートの方が管理が楽なケースもある
• 監査などの場面でGitHub自体やその運用についての説明コストが発生する場合がある
• より頻繁に変更がなされる業務ルール（e.g. 給湯室の使い方など）は、Docsのような形式でカジュアルに変更ができたほうが楽な場合が多い

こうした課題も踏まえつつ、現在WantedlyではISMS以外の規程についてもGitHubでの管理を検討しています。

おわりに

規程管理について、より良いアイデアをお持ちの方がいらっしゃればぜひ色々と情報交換させてください！