監査役も社員も助かった！監査フローが開発スピードを落とさないGitHubの使い方

みなさん、はじめまして。
Wantedlyの監査等委員の高原明子です。 2014年の4月から監査役としてWantedllyの監査に携わり、2015年の11月から監査等委員に就任しました。

さて、このブログで書かれているように Wantedlyでは、開発に限らず様々なプロセスでGitHubを活用しています。

今回は、監査等委員である私が、監査業務の一環としてGitHubをどのように有効活用しているかをご紹介します。「監査対応面倒臭いな〜」と思っているエンジニアの皆さんに日頃どんな点に注意を払っておくべきか何か気づきになることがあれば幸いです。

1. そもそも、監査等委員ってなんですか？

監査等委員というのは、簡単に言うと取締役が適切に職務を遂行しているかを様々な視点から確認する仕事です。（因みに、「監査役」も同じ仕事です。）

ところで、どうして、Wantedly “Engineer" Blogに監査等委員が登場するのでしょうか？それは、エンジニアが作ったシステムを使わずに業務が進む会社はなく、監査等委員としてはそのシステムの内容を確認する必要があるからです。

つまり、エンジニアが作ったシステムが、
・正しい情報を登録しているか？
・情報の加工が限定または管理されているか？
・法律違反になるような情報の取り扱いをしていないか？
といったことを確認するのです。

2. 具体的にどんなところを確認しているの？

基本的に　
　「どんなリスクがあるのか？」
ということを洗い出し、　
　「そのリスクをどうやって最小限にとどめているか」
ということを確認しています。

例えば、システムに関連するリスクとしては、こんなことが考えられます。

リスク1：粉飾、架空の取引が行われる
権限がある人だけが、情報を入力・修正できるシステムになっているか。　

リスク2：お客様の個人情報が流出する
大事な情報が権限保有者以外にアクセスできないところに保管されているか。　

リスク3：Wantedlyのシステムが停止する
突然、停止するようなシステムではないか。また、停止した場合の対策はどのようなものか。

他にも様々なリスクが考えられます。そして、考えられるリスクが最小限になる対応が取られているかを確認しています。

3. どういう風に確認するの？

残念ながら、監査等委員である私はコードが読めません。　

以前に勤務していた会社の監査では、　
(1) リスクを洗い出す　
(2) 要件定義書や仕様書で「リスクを最小限に留める仕様になっているか」を確認し、　
(3) その仕様書通りにシステムが出来上がっているかを確認
という手順をとっていました。

つまり、システムの改変がある度に、ドキュメントを確認して、さらに、実際のシステムのアウトプットがその通りに出てくるかを確認することになります。これが、一般的な確認の手順です。

しかし、Wantedlyはエンジニアが直接、企画してシステム改善に取り組みます。 そのため、監査を実施するにあたっては、エンジニアとのコミュニケーションが必要になります。

そこで、活用するのがGitHubです。 Wantedlyの場合、要件や仕様がGitHubに集約されます。まず私は、GitHubに書かれた仕様を理解し、そして、GitHubに記録された手続きを見て、その開発が手順通りに行われるかを確認しています。

4. WantedlyのGitHubを活用した開発手順

Wantedlyでは、システム開発にGitHubを活用しています。

流れは以下の通りです。
(1) Issuesでバグ・課題点などが提起されます。
これは、エンジニアだけでなく、CSメンバーが集めたお客様からのアドバイスやSalesメンバーからのアイデアも提起されます。
(2) 担当のエンジニアが解決策を検討します。
必要があれば、CSやSales、 Corporateのメンバーにもヒアリングし、どんな仕様にするかを書き込んで記録に残します。
(3) 優先度が高いものから、エンジニアがコードを書きます。
(4) 自動テストを行い、不備がないかチェックします。
(5) Pull Requestで、責任者にコードチェックの依頼をします。
(6) 責任者はコードをチェックし、承認されれば、Mergeして本番のシステムに反映されます。

これで変更が完了です。

５. 私がGitHubで何を見ているか

では、監査等委員の私はGitHubで何を見ているのでしょう？

システムをチェックするポイントは変わりません。
(1) リスクを洗い出す。
(2) リスクを最小限に留める仕様になっているかを確認する。　
(3) その仕様通りにシステムが出来上がってるかを確認する。

私はGitHubで、以下の点を確認しています。

(1) Issuesで「リスクを最小限に留める仕様になっているか」を確認します。
Issuesにつけられたラベルを見て、重要なもの、影響が大きそうな内容のものから確認します。
Wantedlyでは、「Why 」「What」という観点で課題をまとめています。 監査では「Why」を特に注目して読みます。「Why」には現状の問題点、つまり、考えられるリスクが書かれているからです。

(2) そのリスク対策として、何が行われるかを確認します。
ちなみに、Wantedlyでは、その仕様に関わる部門の人の意見も求められます。
例えば、新しいサービスを立ち上げる場合は、
・販売するSalesチーム
・お客様の問い合わせに対応するCSチーム
・売上の計上処理をするCorporateチーム
が内容を確認し、疑問に感じる点や問題になりそうな点があれば、Issuesに書き込み対策などを議論します。その経緯を読んで、リスク対策と仕様の内容を確認します。

(3) Pull Requestで手順通りに開発されていることを確認します。
Wantedlyは、開発手順のルールが前述のように決まっています。自動テストで問題ないことが確認できないとPull Requestが送れませんし、エンジニアの担当責任者の相互チェックを経ないとリリースできません。 Pull Requestの記録を見て、手順がしっかり守られ、権限のある人がチェックしていることを確認しています。