最近兼業情シス始めました。そのときにタスク管理ツールを作ってなかなか捗ったのでその知見を残しておきます。いくつかの記事を書こうと思いますが、今回は概論的な話です。
なお、この記事はタスク管理にGitHubを使う一連の記事の中の一つです。
- 情シスのタスクをGitHubのissueで管理するようにしたら捗った ←ここ
- プロジェクト管理ツールとしてGitHubを"普通に"使う
- Google Cloud Functions (Python) を使ってみた
- GitHub App を作ってPythonからAPIを叩いてみた
- Google Apps Script から Google Cloud Functions のHTTPトリガーを実行してみた
背景
現在勤めている会社で、開発業務に加えて情報システム(以下情シス)担当を兼任しています。情シスタスクは多岐にわたるのですが、中でも頻繁に行わなければならないのが各種サービスのアカウント発行やAWS・GCPのIAM管理などです。それらのタスクの一つ一つは小さいのですが、メインの開発業務の合間に色んな人から申請が来ます。
情シス担当者は現在二人。もともと前任者がいたところに自分がアサインされ、前任者がやめるのと同時にもうひとり担当者がアサインされました。
もともとのシステム
もともとのシステムは、Googleフォームで依頼者が入力をするとその内容がGoogleスプレッドシートに書き込まれ、そのスプレッドシートが更新されたことをメールで自分に通知するようにしていました。ここまではすべてGoogleの仕組みを利用しています。
問題点
自分がアサインされる前は前任者が一人で情シスのタスクを行っていたため、この仕組は開発工数をあまりかけずにシステムを作る良いアイディアだったと思います。ただ、メンバーが二人になったので、その依頼を誰が担当しているかを可視化する仕組みが必要だと感じました。
また、メールを見てスプレッドシートの該当箇所を確認し、Slackで自分が担当すると宣言してから実際に作業、そして終わったら依頼者にメールやSlackで伝えるという運用は作業にロスが発生し、そのたびに集中が乱されるのでだんだんと大変になってきました。
情シスタスクは地味なものが多く、成果の可視化がしにくいので、そのようなクローズドな運用を行っていると場合によってはサボっているように見えてしまう可能性もありました。
GitHubのissueを使う理由
そこで今回、GitHubのissueを使ってタスクを管理することにしました。GitHubを使う理由は
- メールやSlackを使わなくてもissue上で依頼者とやり取りができる
- BacklogやTrelloだと新しくアカウントを作成しなければならないがGitHubはみんなアカウント持ってる
- プロダクトのコードはGitHubのプライベートリポジトリ
- 依頼者のほとんどは技術者
- Assigneeを設定できるので誰が作業を行っているかわかる
- GitHubのProjectと併用すれば現在の進行状況が把握できる(これは別記事でも書きます)
- Organizationに登録されている人はリポジトリを見ることができるのでタスクを可視化できる
などです
アーキテクチャ
今回ノートに書きなぐった設計です。
実際に作ったものは多少違っていますが大体こんな感じです。
- Googleフォームからの入力
- Google Apps Script でフォームのサブミットをフック
- Google Cloud Functions のHTTPトリガーを発火
- HTTPトリガーはエンドポイントを知っていれば誰でも発火できるのでtoken渡す
- 確認
- OK
- Goolge Cloud FUnctions からGitHubのAPIを呼ぶ
- APIの認証は GitHub Apps を利用して個人のアカウントに紐づかない
- GitHubのAPIで以下の処理を行う
- issue作成
- issueに依頼者と作業者をアサイン
- issueにタグ付け
- issueをプロジェクトに追加
- 作成したissueのURLを返す
- 同上
- 同上
- Google Apps Script でissueのURLを依頼者と情シスメーリングリストに送信
Google Cloud Functions を使っている理由は、GitHubのAPIでJWT認証するときに Google Apps Script 側でキーの管理をしたり実装したりするのが大変そうだったからです。
運用
下の画像のように、Googleフォームから依頼されるとBotによってissueが立てられます。一説によれば割り込みタスクも5分以内に終われば集中がそこまで乱されないらしいので、即確認・対応・連絡してCloseします。もちろん手が空いていないときもあるのでそのときは別のメンバーにやってもらうか手が空いているタイミングでやります。（24時間程度で対応するとアナウンスしていてます）
依頼者にはメールが飛ぶのでissueが立てられたことを把握できます。
issueを立てるのと同時にBotがProjectの To do にそのissueを置き、作業するときに作業者が in progress に移動、そして終わってissueをCloseするとProjectの機能で自動的に Done に移動されます。こうしておけば依頼者もチームメンバーも今そのタスクの進行状況がどうなっているのかわかります。
また、月ごとに Done カラムを作ればその月に誰がどれくらい作業したのかも可視化できるので、開発タスクの見積もりの際にも情シス側のタスクを考慮できるので見積もりがしやすくなります。
入社対応のように、依頼をトリガーとしないタスクに関しては、issueのテンプレートでチェックリストを作って、必要になったときに手動でissueを立てます。
結果
まだ試験運用中ですが、上に書いたような問題点は解消して業務効率化につながったのではないかと思います。
お金のあり余っているような会社やその他の組織だったら高機能のサービスのライセンスを購入すれば済む話かもしれませんが、お金をかけなくても使い慣れているツールにちょっと手を加えるだけでも効率化ができるので我々のような小さな会社にとってはいい方法かなと思っています。
何よりこういうのを作るのが情シスっぽい。