まえがき
年に一回の外向け記事を公開する日がやってきてしまいました。仙波です。
この記事はfreee Developers Advent Calendar 2018 の13日目です。
例年ちょっとエモい記事ばかり書いているので、今年はちょっと渋い（他社さんがどうやっているか気になる）ところを書いていきたいと思います。
さて、まずは本業である今年の蕎麦ですが、得意先の粉屋によると相次ぐ災害により不作で、夏の北海道産はもとより、新そばの本命である信州産もよろしくない状況だそうです。悲しいですね。
蕎麦以外のエンジニア業についてですが、自分はいまSREチームからエンジニアの生産性を向上するチームに移動しています。
相方は各マイクロサービスの Rails の Major Version Up やら ChatOps 用の Bot を扱っており、自分の方は開発環境の初期セットアップを超高速化したりとか、開発・レビュー向けの asset の build を10倍速にしたりとか、DBの初期データ投入を10倍速にしたりとか、おおよそ一人チームに近い様相を呈しつつ、それぞれが自分なりに考えた生産性上がりそうな Hack をしています。
今回は GitHub の Organization アカウントによるメンバー管理を自動化したりした知見を書いていきます。
本題
優秀なエンジニアと対面する上で避けて通れない問題がありますよね。
そう、アカウント管理（名寄せ）です。
ただでさえネットとリアルで異なる人格を持つ我々エンジニアは、愛称・あだ名とはまた別に、パーソナルリアリティの体現たるハンドルネーム/IDを持っています。
また、ほとんどの Web サービスでは ID の重複が許されず早いもの勝ちなので、各サービスごとに微妙に異なる ID を使用している可能性があります。名前とアカウント名が異なると、このアカウントは誰のもの？と捜索依頼を出すことも…。
弊社では OneLogin の事例にも載っているとおりたくさんの SaaS を利用していますが、 GitHub はまだ IdP の管理対象外です。それというのも弊社はいろいろな Web サービスのアーリーアダプターでもあるので、今やモダンな Web 開発に必須の GitHub のプランも旧プランであり、 SAML/SCIM に対応していませんでした。
GitHub のアカウント管理をするためには、プランをアップグレードするか、温かみのある手作業で対応するか、自前で自動化するしかありません。
とはいえ BtoE のサービスに関しては社員数によっては使用しているプランを上げると、いきなり数百万、数千万のコスト増になってしまったりで、これはよっぽどインセンティブが働かないとすぐには導入できないのが営利企業です。
また、プランをアップグレードして対応するにしても、どういったフローで適切な権限を個々人に付与し、管理するかといった制度設計としての部分はおざなりにできるものではありません。GitHub さんの SAML/SCIM でのアカウント管理方法がこちらの要件とあっていないという情報もあるため、管理運営を行っている諸兄につきましては現状について知見をいただきたい次第です。
そういったわけで、今回は直近でおこなった GitHub のアカウント管理フローの設計と運用について書きます。
GitHub のアカウント管理フローの設計と運用について
いままで
メンバー招待
- （たくさんいる）Owner 権限を持っているメンバーが手動で Organization に招待
- エンジニアチームの総務が各方面に連絡を取って手動で Organization に招待
主に上記の2パターンでした。
権限管理
- （たくさんいる）Owner や Team メンテナが手動で Team に所属させる
- 各リポジトリごとに直接 collaborator に追加
といった感じで 200をゆうに超えるアカウントが運用されており、これをエンジニアチームの総務が頑張って GitHub から SpreadSheet に転記して入退社情報と照らし合わせながら個別に退職処理をしたり棚卸しを行っていました。
また、アクセス権限は必要に応じて追加する方式で明文化されたルールはなく、社員エンジニアの良識によって運用されていました。
現在
メンバー招待
誰も彼もが勝手に招待する手段があるのがあかんのや。という訳で Owner 権限をガッツリ絞って各リポジトリごとに Team 単位で権限をきちんと割り振りました。 エンジニアの入社フロー自体に手を加えることで、オンボーディングメンバーが各自の判断で開発に必要な適切な権限を割り振ることが出来るようになってます。
- Organization への招待は Google Form 経由
- Team への追加も同時に行う
- 手動で触らない
- 在籍確認先を同時に入力してもらう
- 在籍確認はレポートラインと招待者が責任を負う
- 利用者は雇用形態に関係なく Organization に所属する
このあたりは Google Form から Google Apps Scirpt と GitHub API を利用して手動で招待を行う場面を無くし、すべての履歴が監査可能な形で残るようにできました。
権限管理
アカウント棚卸しの共通ルールを設定して API で自動化しました。 30日ルールというわかりやすい運用方針で、30日間 Pull Requestを作らなかったアカウントを自動的に Organization から remove しています。
GitHub には過去メンバーだった人を再招待するさいに直前の権限を簡単に復元する機能が付いているので、長期的に使用を止める場合は remove したほうが安全です。
- 在籍確認をしてから30日間 Pull Requestを作らなかったアカウントは自動的に棚卸し
- 在籍確認日の更新フォームを提供
- QAやUX、支払いアカウントに machine user などレビューや管理が主体的なアカウント用の AllowList の提供
- 業務委託さんの招待者向け在籍確認メールの運用
- 業務委託さんの在籍状況を一括更新
- 所属メンバー一覧のスナップショット取得
- 棚卸しボットによるお知らせの強化
上記の対応のために Owner 権限の削減とあわせて Team の整理も進めたおかげで、メンバー招待から利用までがスムーズに行えるようになり、事業側が管理するプロジェクトについても、運用の管理下に置くことが出来るようになりました。
remove や所属メンバー一覧の取得も Organization Members API を使用しています。
振り返り
ここまでのアカウント管理はエンジニア総務の方が管理しやすいように、すべて SpreadSheet に記録されるようになっています。操作ログが残るし。
Google Apps Script & TypeScript に GitHub API のおかげで大きなコストを掛けること無く動くものを短い期間で提供できたのは良かったと思います。GASの認証と権限管理が出来るところ、すごく楽でよいです。実装より運用の周知の方が大変でした。
あと、事前のアカウント整理と確認を手作業で行っていた際にオペミスででかい Team を消してしまって真っ青になりました。 ワンオペ手作業ほんとよくない。駆逐してやる。
これから
導入の効果が大きそうなところは運用が開始されたので、以降も空き時間を使って Team 管理の provisioning を自動化したりしようかなと言った感じです。
実務的なアカウント管理をしていると、外部サービスやオフィスの入退室管理の権限も含めてライフサイクルすべてを管理するための組織マスタ欲しい！ってなりますよね。
今回は実装コストを小さくするために GSuite に乗っかりましたが、細やかな権限管理となると人事労務 freee と連携させたい…。
もっと柔軟でわかりやすく監査可能な仕組みをバックオフィスに導入して最適化を行いたい方、蕎麦を肴に自分と飲みましょ。
というわけで今回はあらためてバックオフィス業務のもどかしさを体感しました。ベストプラクティス的なものが出来たら積極的に公開していきたいと思います。
また、こういった業務の改善は広く知見を共有し合うことが大切だと思うので、こういった方法があるよといった情報も大歓迎です。
オフィスに遊びにきてもらうもよし、ボードゲーム会に遊びに来るもよし。
https://www.facebook.com/freeeboardgame/
よろしくお願いします。
最後に
明日は新進気鋭のSRE id:atkmr による「くーべるねいてぃす」こと K8s の記事です！お楽しみに！
