こんにちは。あるいはこんばんは＜VTRyo＞です。

2022年6月に一人Product SREだった僕もようやくメンバーが増え、チームとしてコミュニケーションを成立させねばという気持ちになってきました。

タスク管理ツールといったチームに閉じているものは基本的にチーム単位で選定できるのがマネーフォワードの良いところです。我々マネーフォワードクラウドHRソリューションのSREグループ（以降SREグループと表記）では、GitHubを使って以下のことをしています。

チームの概要情報（ミッション、責任範囲、スキルスタックなど）
タスク管理
メンバー間の情報共有
所有するコードの管理（issue template、GitHub Actionsなど）

今回は、社員の方からこんな声を頂いたことをきっかけに執筆しています！

なぜ、チームコミュニケーションをGitHubに寄せたのか

最も強いモチベーションとしてあったのは「GitHubに寄せてしまえば行ったり来たりせずに済む」点

日常的に使うツールが分散していると「あれどこに書いてあったっけ」「ログインしないと見れない」といった小さなストレスが積み重なってだんだん疲れてきます。

たとえば、プロジェクト管理がJIRAで情報共有ツールがKibelaで、メンバー個々人の予定共有がスプレッドシートで……となるのは個人的には避けたいと考えていました。

普段使い慣れたツールで完結するならそれが一番ヨシ！　というのが正直な心意気です。

「最低限の、情報共有とプロジェクト管理ができる」ということ

他チームが必ずしもGitHubでプロジェクト管理しているとは限りません。

しかしSREグループは本格的にアプリケーション開発をするチームではないので、JIRAを採用するのは高機能すぎた点。Asanaはタスク管理の自動化ワークフローが課金制であり、過去実際に使ってみて管理コストが高かった経験から避けることにしました。

GitHubのProjects(beta)であれば、カンバン管理を始めとしたタスクリストをすぐに管理できることがわかっています（後述）。

また、情報共有ツールは全社的に採用されているものがありますが、こちらは44あるプロダクト（2021/11月時点）の情報で溢れかえっています。さらに千名以上の従業員が在籍しているため、キーワード検索しても個人日報がヒットしてしまったりと探したい記事の検索コストが高いという課題があります（その日報が役に立つこともあります！）。

結局うまく検索できずに同じような記事を書いてしまうこともありました。

GitHubリポジトリのWikiに書いておけば、まずそこを参照しようと思います。目次の設定もできます。話が長くなりそうなら、GitHub DiscussionsにしておけばこのSREグループに閉じた議論がそこできるので見失いにくいと考えられました。

自動化との相性が良い

これも元をたどるとGitHub内で完結するという点です。

GitHubが元から用意している自動アクションもありますが、こちらで設定することで自動化できるものもあったりします。どれにしろ、他のツールを挟まないのは管理コスト的にも設定コスト的にも低いでしょう。

issue -> Discussionsへの変更（下記画像）
issue作成 -> Projects(beta)への自動追加
予定共有のGitHub Discussions、月次ふりかえりGitHub Discussionsの自動作成など（後述）

具体的な活用方法

ここからはどうやって活用しているのかを紹介していきます。

Wiki

主に新規参画者の方に読んでもらう目的があります。

SREグループに関する最初に知っていてほしいマニュアル的な情報を集約させています。プロダクトチームに配属になった方向けにもこのWikiを使ってSREグループがどのような仕事で支援するかを説明することもあり、ミッションや責務範囲やこれまで作成したロードマップ資料も記載しています。

全社共通の情報共有ツールに書くべきかの線引きは、SREグループに閉じた情報であるかどうかです。プロダクトにも影響する内容であれば、全員が見える場所に記載します。

Projects (beta)

Product SREsの特性上、各プロダクトに紐付いたタスクがあります。別のリポジトリのissueでもProjects (beta)に紐付けられるので管理がしやすいです。

またProjects (beta)ではカンバンだけでなく、リスト表示、検索・ソート機能も実装されているのでより柔軟な管理ができるようになっています。

また、issueを作成した時点でこのProjects (beta)にissueを追加するようにGitHub Actionsで設定しているため、いちいち「カンバンに追加して〜」といったトイルは発生しません（そのGitHub ActionsのコードはこのGitHubリポジトリで管理しています）。

issueをProjects (beta)に追加するGitHub Actionsはこちらを参照ください。

GitHub Discussions

非同期コミュニケーションの実施に活用しています。

その日の予定や出退勤の共有、相談事をSlackでやると時系列と共に過去のものとなり、見返すこともなくなっていくのでDiscussionsで展開しています。案外、この相談事というのは残しておいたほうが有用だと思っています。

キーワードで検索すれば話題ごとに見ることができるので、新規参画者も遡りやすいのではないでしょうか。 issue同様にlabelを付与することができるので、話題に合わせて貼っておくと検索も捗ります。

また、SREグループの月次ふりかえり報告や、グループ単位の決定事項のアナウンスにも使用しています。

先述したとおり、全社的に導入されている情報共有ツールはありますが「ある部署のあるグループに閉じた情報」のため、このGithubリポジトリ内に絞ったほうが探しやすいと思っています。

重要な事項やホットな相談事はPin止めができるのでこれをうまく利用しています。

コメントがされるとTopに上がってくるので、盛んに議論されているものに注目しやすくなる点も個人的に好きなポイントです。

なお現時点で公式によるDiscussionsコメントのSlack通知機能がないため、GitHub Actionsでイベントを拾ってコメント通知を設定しています。

HRBrainさんの記事が参考になります。【GitHub Actions】GitHub DiscussionsをSlackで通知する

GitHub Actions

毎日作成する日報的Discussionsや月次ふりかえりDiscussionsはGithub Actionsを使って自動生成させています。

プロジェクト管理で発生するような繰り返し作業であったり、古くなったissueの整理もGitHub Actionsに任せることで負担を軽減させています。他のプロジェクト管理ツールでもこのような自動化はできると思いますが、GitHubで完結するのではるかに気持ちは楽です。

月次ふりかえりDiscussionsの作成

name: Create monthly retrospective Discussions

on:
  schedule:
    - cron: "0 0 10 * *"
  workflow_dispatch: {}

jobs:
  create-issue:
    runs-on: ubuntu-latest
    steps:
      - uses: rerost/issue-creator@v0.1.17
        with:
          template-issue: xx
          discussion: true

このように操作する例はGitHub ActionsのMarketにたくさんあるのでぜひ御覧ください。

その他Tips

GitHub CLIによるissue起票

個人的にGitHub CLIを使ってissueの起票はどこからでもできるようにしています。画面からやってもいいのですが、いくつもissueを作らないとならないときは面倒だったりするのでTerminalからもできるようにしています。

画像はTerminalから起票するケースです。

# install for Mac
brew install gh

gh issue create -t "issue title" -a "@me" -l documentation

issueの概要文をエディタで書けます。

Slackからissue起票する

issit（イシット）を利用させていただいてます。

Slackにあるコメントをそのままissueにすることができるので、とりあえず急ぎ作っとこみたいなときは使用します。

一ヶ月運用してみての感想

GitHubリポジトリには様々な機能がありますが、大活躍しているのはGitHub Discussionsという印象です。

チーム間で発生する、急ぎの用事やその場回答で十分な問い合わせはSlackで問題ないですが、日にちをまたぎそうな話や分散してほしくない情報、過ぎ去ってしまうと困る情報をGitHub Discussionsにまとめるようになってからやり取りがスムーズになりました。いちいち検索しなくても活発な議論はいつも上にあって見つけやすい、というだけで随分変わると思います。