こんにちは、@tshunskです。

Incrementsではエンジニアでないスタッフも全員がGitHubアカウントを持っていて、社内の稟議もGitHub上で起票しています。

今日は稟議のシステム化をご検討されている方のためにIncrementsが行っているGithub稟議のやり方と導入する際の手順を簡単にご紹介したいと思います。

背景

会社の規模がある程度以上になると社内の承認プロセスとして稟議という手続きが間違いなく必要になってきます。いくつかのワークフローシステムも試したのですがいまいちパッとしたものがなかったため、それではGitHub上でやってしまおうということになりました。

GitHubに決めた理由

• スタッフ全員がアカウントを持っていて、使い慣れているので導入・運用のコストがかからない。
• 稟議の内容に対するコメントや修正履歴なども後から見ることができるし、誰がいつ承認したのかという記録もシステム上でしっかりと残る。
• 承認後の改竄が不可能。

稟議承認までの流れ

弊社では、GitHub上での稟議の起票から承認を以下のような流れで行っています。

• テンプレートに沿って稟議内容をPull Requestとして作成し承認者にメンション
• 承認者は内容を確認後、Pull RequestをMergeする。
  • 複数の承認者がいる場合、各自Approvedで承認の意思を明示し、最終承認者がMergeをする。

次は、GitHub稟議をはじめる際の手順をご紹介します。

GitHub稟議の導入の仕方

1. GitHub上に稟議専用のリポジトリを用意する
   当たり前ですが、稟議専用のプライベートリポジトリが必要になります。
   名称は「ringi」でも「request-for-approval」でも、みんなが分かりやすいもので設定しましょう。

2. READMEに「稟議フォーマット」や「タイトルの書き方」などルールを記載する
   フォーマットを用意してあげると、稟議を書き慣れていない人でもスムーズに起票することができるので、ここをしっかりと準備しておくことが大事です。

タイトルは、それを見ただけで概要がわかるように書いてあると良いでしょう。
例) 2016●●●●_◯◯◯法律事務所との顧問契約.md

フォーマットについては弊社は以下のものを利用しています。

稟議を出す人と承認者では稟議対象について同じレベルの情報は持っていません。
そのうえで、承認者が「目的や検討のプロセスが適切かどうか」で判断できるように、「代替案やリスクについては検討されているか」などの内容が網羅できるようなフォーマットになっています。

---
申請日: 20●●年●月●日
申請者: 申請者の氏名
承認者: 承認者の氏名
---

## 実施の経緯及び目的 (必須)

## 実施内容 (必須)

## 結論にいたった理由 (必須)

## 必要な費用 (必須)

## 実施日時 (必須)

## 期待される効果 (必須)

## 他の選択肢

## 実施しなかった場合の影響

社内への周知

日常的にGitHubを利用していないスタッフもいるので、READMEに簡単な解説を書くだけでなく、IncrementsではQiita:Team上でも画面キャプチャ付きのドキュメントを用意し稟議の作成手順を周知していきました。

結果、全社的にスムーズにGitHub上で稟議の承認フローを回すことができています:)
稟議のシステム化をご検討されている方のご参考になれば幸いです。