Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2022-10-12. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい

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

GitHubの計画及び追跡ツールを使って、Teamあるいはプロジェクトの作業を管理するために必要なこと。

はじめに

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

このガイドでは、人々のグループとコラボレーションするためのリポジトリの作成と設定、Issue テンプレートの作成、Issue のオープンと作業を分割するためのタスク リストの利用、Issue を整理して追跡するためのプロジェクト ボードの確立の方法を学びます。

リポジトリを作成する

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

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

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

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

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

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

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

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

README の例

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

READMEの例の作成

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

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

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

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

Issueテンプレートの例

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

Issueテンプレートの例の作成

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

Issueテンプレートの例の選択

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

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

問題の例

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

大規模なイニシアティブのissueの例の作成

タスクリストの例

タスクリストを使って、大きなIssueを小さなタスクに分割し、大きなゴールの一部としてIssueを追跡できます。 詳しい情� �については「タスク リストについて」を参照してく� さい。

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

Issueの例へのタスクリストの追� 

チー� としての意思決定

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

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

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

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

Issueの例でのコラボレーション

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

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

詳細については、「ラベルの作成」を参照してく� さい。

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

ラベルの例

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

Issueの例へのラベルの追� 

プロジェクトボードへのIssueの追� 

を使用することができます。 プロジェクトボードは、Issue、Pull Request、選択した列内でカードとして分類されるノートから構成されます。 機能の作業、高レベルのロードマップ、さらにはリリースチェックリストのためにプロジェクトボードを作成できます。 詳細については、「プロジェクト ボードについて」を参照してく� さい。

プロジェクトボードの例

以下は、サンプルのProject Octocatのプロジェクトボードで、作成したIssueと、そのIssueをブレークダウンした小さなIssueが追� されています。

プロジェクトボードの例

次の手� �

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