組織運営の全てを GitHub Issue で管理していく
AnyPay社では、エンジニアチームは勿論のこと、全部署でGitHubを利用しており組織運営を行っています。
特にGitHubのIssue機能はAnyPay社を効率的に組織運営する上での鍵となっています。
「全社的にGitHub上で管理する」というのは手法は他社事例もある通り、組織運営のトレンドになってきつつあるようです。
社員が日常的にオフィスづくりにコミットできるよう、全部署が業務で利用している「GitHub」上にissueを挙げる形で環境や設備の要望を取りまとめます。設計を委託するオフィス・パートナーのトレイルヘッズ株式会社と常にissueを共有しながら、継続的なオフィスづくりが可能な環境を整えています。
https://press.plaid.co.jp/data/20180530/
監査法人とともに、IT内部統制対応なども実施していますが、いかにGitHubのIssue機能がよく出来ているのかを日々感じます。
今回、弊社のGitHub活用事例をご紹介したいと思います。
1. 社内情報システム依頼
AnyPay社の info-system リポジトリの中にissueを起票します。基本的には依頼者がissue作成を作成して頂いています。
情シス対応も全て情報をオープンにしています。GitHub上のやりとりは #info-system チャンネルにも同様に通知が飛びます。
一度Issueでやりとりが出来れば、次回以降同じ依頼がある場合は、GitHub上で過去の似たような作業を検索すれば作業方法が分かるので効率的です。
PCが故障するケースなど、情シスがPCの回収から修理連絡、対応まで全てを巻き取って対応している組織もあると思います。
弊社の現状としては社内全体で作業を分担できるようにしています。
(社内SEのリソースが限られているという理由もありますが)「PCが壊れた場合、対応は自分でする必要がある」というリスクも社員全体認識として負ってもらうことで、結果としてPCも丁寧に扱って頂いています。
修理中に支給する代替マシンに関しては基本的にスペックが下がるので、「早く直したい」というモチベーション維持の仕組みも入れています。
社内SEに関しては弊社でも採用予定なのでぜひ、さらなる効率化をさせたい方、ご連絡お待ちしております。
2. 法務チェック
契約書締結などのリーガル関連の依頼に関してはAnyPay社の初期の頃は整備されておらず、個別に口頭、email、Slack上のメッセージでやりとりをしていました。
こういった状況の中、AnyPay管理部の方からも「システム導入等も含めて運用整備をしたい」ということで検討しました。外部のグループウェアの導入なども含めて比較検討したところ、最終的にはリーガルのリクエストもGitHubのIssueで管理するようになりました。
採択理由としてはいくつかありますが、具体的な例を上げる以下の通りです。
- 時系列で議論が見れること
- 監査法人などにすぐに必要な情報を探して開示できること
- 開発プロジェクトとも連携ができること
- 専用のツールが増えないこと
エンジニア視点では開発プロジェクトと連携できることも非常に大きな強みです。AnyPay社のようなFinTech領域では、プロジェクト進行にあたり法務確認は常に必要不可欠です。
プロジェクト進行にあたり、PoCや実装を進めていきながら同時並行で法務確認をするケースも勿論あります。GitHubではPR/Issue同士のリンクを貼り付けると自動的に表示上リファレンスを貼ってくれます。開発PRを作って、そこに参照 Issue として法務チェックの Issue を紐付けることも可能のため、エンジニア、プロジェクトマネージャ、管理部、BizDevなどの各チームが簡単に相互の状況を確認し、プロジェクト進行を円滑に進めることが出来ます。
GitHub仕様上、基本的に Private Issueというものは存在しないので、情報は全てオープン化が必要です。
ただし、一部機密性の高い契約条項などのケースもあるため、そういったケースでは、GitHub上の Issueのタイトルを工夫し、添付ファイルとしてGoogle Driveのリンクを付与する運用にしています。
個人的な感想ですが、リーガル関連の議論は非常にリアルで学びが多い & 面白いので、このGithubリポジトリは常にウォッチしています。
3. イベント準備
弊社では広報や、エンジニア向け企画など各種イベントも定期的に開催しています。イベント運営の外部公開などのケースでは connpass などに投稿しますが、アイキャッチ画像の制作といった社内のデザイナのリソースが必要になるケースがあります。
このように Issue で管理させることで、制作に関しての情報もやりとりをしています。簡単な制作画像のアップロードであれば Issue にそのまま貼り付け可能ですので、デザイナとのやりとりも容易です。
イベントは基本的に定期的に開催するものも多いため、過去の同一イベントのIssue 同士に対してreferenceを貼り付けると、簡単に過去の議論も参考に出来るため、非常に準備の効率も良くなります。
4. PCI-DSS準拠維持
内部向けだけでなく、外部のコンサルティング企業の方も巻き込んでIssue運用をするケースもあります。
弊社ではクレジットカード情報の保護保護のための国際統一基準である「PCI-DSS」に準拠しています。PCI-DSS取得にあたり、同様にGithubのIssue運用でプロジェクトを進めました。
PCI-DSSでは資格準拠するためには約300件近いチェック項目があり、個別に組織に適応出来ているかを確認します。弊社ではこの準拠項目300件が書かれたIssueを作成し、それぞれ確認、ディスカッション、対応出来たらIssueクローズという方針で進めました。
一部のチェック項目の中には、内容の解釈が難しいものも含まれ、初回準拠の為には、知見のあるコンサルタントの方のヒアリングが必要になるケースもあります。
外部コンサルタントとのコミュニケーションをChatやEmailにしてしまうと、個別の準拠項目に関しての時系列議論を後から振り返るのが難しくなります。
「最終的に、なぜこのような運用と意思決定になったか」というWHYが重要です。時系列のディスカッションさえ残ってさえいれば、誰でも気軽に議論に参加することが出来ます。(そして1年後の自分も他人です。)
加えてセキュリティ準拠維持は一度取得して終わりではなく、毎年続きます。過去の時系列のディスカッションがあれば、内部のAnyPay社員だけではなく、PCI-DSSの審査員ともコミュニケーションがしやすくなります。
さらに弊社ではPCI-DSSの準拠維持のルールブック(社内規定)をGitHub上で管理させました。これにより、ルールブック変更の際には、Pull Request経由で承認フローを経由させることが出来ます。PCI-DSSの準拠維持も普段の開発運用と同じフローにすることで、エンジニアも含め気軽に確認でき、形式的なPCI-DSS準拠維持ではなく、実際の組織運用に役立つようにしています。
We’re hiring!
モダンなインフラ環境に興味のある方、ブロックチェーンに興味がある方、テクノロジーの力で世の中を変えたい方、運用自動化が好きな方、DevOpsが好きな方。AnyPay社ではエンジニアを全職種絶賛採用中です。皆様のご応募お待ちしております。