Skip to main content

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

GitHubの計画及び追跡ツールを使って、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を作成できます。

octo-org/project-octocat リポジトリの README.md ファイルのスクリーンショット。プロジェクトの詳細と team への問い合わせ方法が表示されています。

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

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

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

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

Issueテンプレートの例

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

新しい issue テンプレートを作成するためのフォームのスクリーンショット。 フィールドへの入力が完了し、"Project Octocat のバグ レポート" という名前のテンプレートが作成されています。

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

octo-org/project-octocat の [新しい issue] ページのスクリーンショット。"Project Octocat のバグ レポート" テンプレートを使うオプションが表示されています。

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

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

問題の例

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

"Project Octocat のフロントエンド作業" という issue のスクリーンショット。 issue の本文には、完了するタスクの一覧が含まれています。

タスクリストの例

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

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

「Project Octocat のフロントエンド作業」イシューのスクリーンショット。 イシューの本文にはタスク一覧が含まれており、各イシューのリンクの前にはチェック ボックスがあります。

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

Note

issue の種類、sub-issue、および高度な issue の検索は、現在、組織のオプトイン パブリック プレビュー にあります。 詳細を確認し、待機リストに組織を追加するには、「GitHub ブログ」を参照してください。

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

チームとしての意思決定

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

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

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

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

"Project Octocat のフロントエンド作業" という issue のスクリーンショット。 @codercat と @octocat の両方のコメントでは、作業の最新の状態を説明しています。

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

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

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

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

ラベルの例

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

"Project Octocat のフロントエンド作業" という issue のスクリーンショット。 右側のサイドバーの [ラベル] セクションに [フロントエンド] ラベルが適用されています。

Project (Classic) に issues を追加する

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

プロジェクトの例

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

"Project Octocat" プロジェクトのテーブル ビューのスクリーンショット。[タイトル]、[担当者]、[状態]、[ラベル]、[メモ] の列がある issue の一覧が含まれています。

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

"Project Octocat" プロジェクトのボード ビューのスクリーンショット。issue が [状態なし]、[To do]、[進行中]、[完了] の列に整理されています。

次の手順

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