Teamもしくはプロジェクトの作業の計画と追跡

はじめに

個別のプロジェクトで作業しているにしても、機能横断的なチームで作業しているにしても、GitHubのリポジトリ、Issue、プロジェクトやその他のツールを使って作業の計画と追跡ができます。

このガイドでは、People のグループとコラボレーションするためのリポジトリの作成および設定、Issue テンプレートおよびフォームの作成、Issue のオープンおよび作業を分割するためのタスク リストの使用、Issue を整理および追跡記録するためのProject (Classic)の確立を実行するための方法を説明します。

リポジトリを作成する

新しいプロジェクト、イニシアティブ、機能を開始するとき、最初のステップはリポジトリの作成です。 リポジトリにはプロジェクトのすべてのファイルが含まれ、他者とコラボレーションしたり、作業を管理したりする場所を提供します。 詳しくは、「新しいリポジトリの作成」を参照してください。

必要に応じて、様々な目的のためにリポジトリをセットアップできます。 以下は、いくつかの一般的なユースケースです。

• 製品リポジトリ: 特定の製品に関する作業とゴールを追跡する大規模な組織は、そのコードや他のファイルを含む 1 つまたは複数のリポジトリを持つことがあります。 それらのリポジトリは、ドキュメンテーション、製品の改善性、あるいは製品の将来の計画のためにも使われることがあります。
• プロジェクト リポジトリ: 作業をしている個々のプロジェクト、あるいは他者とコラボレーションしているプロジェクトのためにリポジトリを作成することができます。 短期間のイニシアティブやプロジェクトなどのための作業を追跡する、たとえばコンサルティングファームなどの組織では、プロジェクトの健全性に関するレポートや、人々をスキルや要求に応じて様々なプロジェクト間で移動させる必要があります。 こうしたプロジェクトのためのコードは、多くの場合1つのリポジトリに含まれます。
• チーム リポジトリ: 人々をチームにグループ化し、開発ツール チームのようなそれらのチームにプロジェクトを割り当てる組織では、コードは追跡が必要なさまざまな作業に対する多くのリポジトリに分散される場合があります。この場合、そのチームが関わるすべての作業を追跡するための 1 つの場所として、チーム固有のリポジトリがあると便利な場合があります。
• 個人リポジトリ: 個人リポジトリを作成して、自分のすべての作業を 1 か所で追跡し、将来のタスクを計画し、さらには保存しておきたいメモや情報を追加することもできます。 この情報を他者と共有したい場合は、コラボレータを追加することもできます。

ソースコードに様々なアクセス権限を設定し、Issueやディスカッションを追跡したい場合には、複数の個別のリポジトリを作成することもできます。 詳しくは、「Issue だけのリポジトリの作成」を参照してください。

このガイドの以下の例では、Projet Octocatというサンプルリポジトリを使います。

リポジトリ情報のコミュニケーション

リポジトリにREADME.mdファイルを追加して、Teamやプロジェクトを紹介し、それらに関する重要な情報を伝えることができます。 リポジトリにアクセスした人が最初に見るのはREADMEのことが多いので、ユーザやコントリビュータがプロジェクトとどのように関わり始めたらいいのか、そしてチームとどのように連絡を取ればいいのかに関する情報を提供することもできます。 詳しくは、「READMEについて」を参照してください。

特に、バグ修正のIssueのオープンや改善のリクエストの方法といった、ユーザやコントリビュータがチームやプロジェクトに貢献して関わるやりかたのガイドラインを含む、CONTRIBUTING.mdファイルを作成することもできます。 詳しくは、「リポジトリコントリビューターのためのガイドラインを定める」を参照してください。

README の例

新しいプロジェクトであるProject Octocatを紹介するREADME.mdを作成できます。

Issue テンプレートを作成する

Issueを使って、機能横断的なチームやプロジェクトがカバーする様々な種類の作業を追跡したり、プロジェクト外のチームやプロジェクトから情報を集めることができます。 以下は、いくつかの一般的なIssueのユースケースです。

• リリース追跡: Issueを使って、リリースやローンチ日を完了させるステップの進捗を追跡できます。
• 大規模なイニシアティブ: Issueを使って、大規模なイニシアティブやプロジェクトの進捗を追跡できます。それらは、より小さなIssueにリンクされます。
• 機能リクエスト: チームやユーザは、Issueを作成して製品やプロジェクトに改善をリクエストできます。
• バグ: チームやユーザは、Issueを作成してバグを報告できます。

作業をしているリポジトリやプロジェクトの種類によっては、特定の種類のIssueを他よりも優先することになるかもしれません。 チームで最も一般的な Issue の種類を特定できたら、リポジトリに Issue テンプレートやフォームを作成できます。 Issue テンプレートとフォームを使うと、リポジトリで Issue をオープンするときにコントリビューターが選べる標準化されたテンプレートのリストを作れます。 詳しくは、「リポジトリ用に Issue テンプレートを設定する」を参照してください。

Issueテンプレートの例

以下、Project OctocatでバグレポートのためのIssueテンプレートを作成しています。

バグレポートのIssueテンプレートを作成したので、新しいIssueをProject Octocatで作成する際に選択できるようになりました。

Issueのオープンとタスクリストを使用した作業の追跡

Issueを作成することで、作業を整理し、追跡できます。 詳しくは、「Issue の作成」を参照してください。

問題の例

以下は、Project Octocatの大規模なイニシアティブであるフロントエンドの作業のために作成されたIssueの例です。

タスクリストの例

タスクリストを使って、大きなIssueを小さなタスクに分割し、大きなゴールの一部としてIssueを追跡できます。 Issue の本文に追加されたタスク リストには、追加の機能があります。 issue の先頭では全体のうち完了したタスクの数を確認でき、タスク リストにリンクされた issue がクローズされると、そのチェックボックスは自動的に完了とマークされます。詳しくは「タスクリストについて」をご覧ください。

以下では、Project OctocatのIssueにタスクリストを追加し、小さなIssueに分割しました。

sub-issue を使用して作業を分割する

sub-issue を issue に追加することで、大きな作業をタスクに簡単に分割できます。 sub-issue により、issue 間の関係が作成されて、GitHub での issue の階層のサポートが追加されます。 ユーザーやチームが必要とする詳細さにタスクを分割することでプロジェクトを正確に表す sub-issue の複数のレベルを作成することができます。「sub-issue の追加」および「sub-issue の閲覧」を参照してください。

チームとしての意思決定

Issueやディスカッションを使い、プロジェクトの計画された改善や優先順位についてコミュニケーションを取り、チームとして意思決定することができます。 Issueは、バグやパフォーマンスレポート、次の四半期の計画、新しいイニシアティブのデザインといった、特定の詳細に関するディスカッションのために作成すると役立ちます。 ディスカッションは、コードベース外でリポジトリをまたぐオープンエンドのブレインストーミングやフィードバックのために役立ちます。 詳しくは、「GitHub でのコミュニケーション」を参照してください。

チームとして、Issue内の日々のタスクの更新についてコミュニケーションを取り、全員に作業の状況を知らせることができます。 たとえば、複数の人が作業をしている大きな機能についてのIssueを作成し、各チームメンバーがそのIssue内で状況を更新したり質問を投げたりできるようにすることができます。

プロジェクトのコラボレータとのIssueの例

以下は、Project OctocatのIssueで作業状況を更新するプロジェクトのコラボレータの例です。

プロジェクトのゴールとステータスをハイライトするためのラベルの利用

Issue、Pull Request、ディスカッションを分類するために、リポジトリにラベルを作成できます。 GitHubは、すべての新しいリポジトリにデフォルトのラベルを提供します。それらは編集したり削除したりできます。 ラベルは、プロジェクトのゴール、バグ、作業の種類、Issueのステータスを追跡するための役に立ちます。

詳しくは、「ラベルを管理する」を参照してください。

リポジトリにラベルを作成すると、それはリポジトリ内の任意のIssue、Pull Request、ディスカッションに適用できます。 そして、すべての関連する作業を見つけるためにラベルでIssueやPull Requestをフィルタリングできます。 たとえば、Issue を front-end および bug ラベルでフィルター処理し、プロジェクト内のすべてのフロント エンド バグを見つけます。 詳しくは、「Issue及びPull Requestのフィルタリングと検索」を参照してください。

ラベルの例

以下は、作成した front-end ラベルの例で、Issue に追加されています。

Project (Classic) に issues を追加する

GitHub上のprojectsを使用して、チームの作業を計画および追跡できます。 プロジェクトはカスタマイズ可能なスプレッドシートで、GitHub上のIssueやPull Requestと統合されており、自動的にGitHub上の情報を最新の状態に保ちます。 IssueやPull Requestのフィルタリング、ソート、グループ化によってレイアウトをカスタマイズできます。 プロジェクトを使い始めるには、「Projects のクイック スタート」をご覧ください。

プロジェクトの例

以下は、作成したProject OctocatのIssueが展開されたサンプルプロジェクトの表レイアウトのビューです。

同じプロジェクトをボードとして見ることもできます。

次の手順

これで、作業の計画と追跡のためにGitHubが提供するツールについて学び、機能横断的なチームやプロジェクトのリポジトリのセットアップを始めることができました！ 以下は、さらにリポジトリをカスタマイズし、作業を整理するのに役立つリソースです。

• リポジトリの作成について詳しくは、「リポジトリについて」をご覧ください
• issue を作成および管理するためのさまざまな方法について詳しくは、「Issueで作業を追跡する」をご覧ください
• issue テンプレートについて詳しくは、「Issueとプルリクエストのテンプレートについて」をご覧ください
• ラベルの作成、編集、削除方法について詳しくは、「ラベルを管理する」をご覧ください
• タスク リストについて詳しくは、「タスクリストについて」をご覧ください - プロジェクトについて詳しくは、「Projects について」をご覧ください
• プロジェクトのビューのカスタマイズ方法について詳しくは、「ビューのレイアウトを変更する」をご覧ください