GitHubをクラウドでのコード管理に利用しているというプロジェクトは増えました。ただ実際現場にいくと「mainブランチで作業フォルダを決めて、各々はコミット・プッシュ・プルしかしない」と、GitHubをソースコードの共有場所にしか使っていない話を往々に聞きます。

そこで、改めてGitHubフローについて整理し、小さな規模のチームがどのように運用することができるかを考えることができればと思います。

GitHubフローとは

GitHubフローとは、GitHubが提唱するブランチベースのワークフローです。

「参加者全員にGitHubアカウントが必要」みたいなそもそも必要な手続きはおいといて、GitHubフローに求められてるのは以下の手続きです。

1. 作業用ブランチを作成する

2. 変更する

3. プルリクエストを作成する

4. 第三者がレビューする

5. プルリクエストがマージされる

バージョン管理のためだけに用いる最も原始的なGitHubの使い方は「ひたすらmainブランチにプッシュする」であることを考えると、このGitHubフローはひとつのレポジトリでコラボレーションするための最低限の手続きといえるでしょう。

GitHubフローにIssue活用を追加しよう

現場においては、コードを書く人間が当人の判断だけで仕様を決めて実装することは稀です。仕様が指示されたり、またはこうやって改善すべきとチームで決め、その優先順を整理して実装（GitHubフロー）に移る必要があります。

そういう時にこそ、GitHubのIssueが活躍します。Issueはそのプロジェクトにおけるアイデア、フィードバック、タスク、不具合をまとめ、議論するためのスレッドタイプの機能です。

GitHubワークフローは、すでに決まってる作業内容を進めるためのワークフローです。当然ながら作業内容が決まっていない中ではじまることはありません。そこで、実プロジェクトにおいては、まず作業内容を決めるためのIssueの議論があり、そして方向性が決まったものから担当者が決まり、作業に入る必要があります。

手続き的には以下のようになるでしょう。

1. アイデア、フィードバック、タスク、不具合をIssueに書き出す

2. Issueの中で優先度を決め、個人のタスクとして落とし込む

3. GitHubワークフローに沿ってプルリク・レビュー・マージする

4. 同時にIssueがクローズされる

厳密には3と4は区分される必要はありません。プルリクエストの本文に

と表記することでそのプルリクエストがマージされると自動的にクローズされます。

こうすることで、プロジェクトにおけるIssue（アイデア、フィードバック、タスク、不具合）と作業を密に結合しながら進めることができます。

実務におけるIssue活用のヒント

徳島の機械工具・水道部品販売事業者「小田商店」

有限会社小田商店では、顧客向けアプリ、また社内で利用している商品のピックアップなどに使うアプリはすべて内製しています。これらのアプリで欲しい新機能や、うまく動かなかったという報告はすべてGitHubのIssue上で行うルールとなっています。

Issueを作らないと開発チームのタスクに乗ることはありません。

そのため、事務作業スタッフも、現場スタッフも、GitHubのアカウントを持ち、Issueをつくることができます。

「GitHubは開発者のためのもの」という風潮が強いですが、このようにプロジェクト管理ツールとして使うことで現場とのシームレスな開発体制を強力にバックアップすることができます。

ちなみに、小田商店では外部開発者も参画しているため、プルリクエストのクローズは開発者は行いません。リリース後、Issueを立てたスタッフがアプリをさわって修正されているのを確認し、クローズします。

Issueとプルリクエストは報告でもある

開発のワークフローとしてIssueを使うだけではプロジェクト管理としては片手落ちです。「管理」というからには、チームメンバー、そしてマネージャーが進捗を確認する必要があります。管理では大まかに「何をやったか（成果）」「今、何をやっているのか（現状）」「これから何をするのか（プラン）」がみれる必要があります。

そして、これはGitHubでどれもをみることができます。

1. 何をやったか

マージされたプルリクエスト数をみるのが一番簡単ですよね。先月の成果をみようと思えば先月のプルリクエストを見せるのが最も手っ取り早い。

GitHubでTermプランを利用している場合はInsightsでより定量的なデータをみることができます。指定期間にどれだけのプルリクエストがマージされかや、どれだけのIssueがCloseされたか、また貢献者のコミット数やコード変更数などをみることができます。

デフォルトでどんなものがみれるかは、アクティブなOSSのレポジトリをみるのがもっとも把握しやすように思います。

また、Projects Insightを使ってカスタマイズすることも可能です。詳細は以下をご覧ください。

このように何をやったかの振り返りもIssue + GitHubフローを採用していれば容易に行うことができます。

ちなみに最初に紹介したようなコミットしかしないようなワークフローでもコード変更数はとれますが、どの課題をどれだけ解決したのかという本質的なところはみることはできません。正直なところ、コード変更数がほしければ、Prettierのルール変更して実行すれば山のようにとれますしね。

2. 何をやっているか

何をしてるかは大まかに「何に着手していて、どこまで進んでいるか」でみることができます。そのため、着手した段階でプルリクエストをつくっておくことをお薦めします。

よくある運用としては、プルリクをつくる時のタイトルの先頭に[Draft]とつけておき、作業を進めます。Draftは作業中でありまだレビューを受けることができる段階でないことを明示しています。

そして、作業が進みコミットしてプッシュする度に、プルリクエストにコミット履歴が表記されていきます。こんな感じですね。（fix #162 は対応するIssue番号を貼っています）。

以下のように、プルリクをつくったあとのコミットはすべてGitHubのプルリク上でみることができます。

このことで、進捗を確認する人は

• この人は今、どの作業を行っていて

• 毎日どうやって進捗しているか

を確認することができます。

これから何をするのか

「何が割り振られているか」はIssueのAssignees機能（担当者機能）を使えばIssueで容易にみることができます。

Issueはラベルで管理することができるので、優先度を決めて次取り掛かる作業にはラベルをつけておくのもいいでしょう。特に粒度が小さく重要ではないIssueは放置されることが多いので、そういうIssueには「chore」などのラベルを用意しておき、1週間でひとりあたり1つは片付けるなどのルールをつくることをおすすめします。

日報の代わりにGitHubを活用しよう

実装というのは第三者からするとしっかり追わないと何をしているかわからず、ブラックボックスの中での作業だと思われがちです。そのため、「上司からするとどんな作業を先月したか把握できない」という問題も往々に起き、それを管理するために日報で「先月はこういった作業をしました」と書くような現場も往々としてあります。

けれど、ここまでみてきたように、GitHubをちゃんと利用したワークフローをつくればその中で、何をやって、現在何に取り組んでおり、次はこれに取り組もうと思ってるといったことをデータとしてみることもできます。

定性的な気づきであったり、また出勤簿と日報が紐ついているなど様々なパターンがありますが、実作業に紐ついたデータがとれるので、GitHubを使いながら日報で改めてこういったことを報告している場合、GitHubを使ったワークローを見直すことでぜひ報告というスタイルを考え直してもらえればと思います。

まとめ

いろいろ書きましたが、ワークフローを変えようというところは、ぜひまずIssuesに現在の問題やアイデアなどをすべて書き出してください。そして関係者で共有し、Issueをアイデアや課題のプラットフォームとし、ここで集中管理することからワークフローを見直していくことをおすすめします。

多くのプロジェクトにおいて、スプレッドシートで二重管理する必要はありません。現場に上司に取引先にGitHubアカウントをつくってもらいましょう！！

それではまた。