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

はじめに

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

このガイドでは、ユーザーのグループと共同作業するためのリポジトリを作成および設定する方法、issue のテンプレートとフォームを作成する方法、issue を開いて作業を分割する方法、issue の整理と追跡のために project を確立する方法について説明します。

リポジトリを作成する

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

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

製品リポジトリ: 特定の製品に関する作業とゴールを追跡する大規模な組織は、そのコードや他のファイルを含む 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で作成する際に選択できるようになりました。

Issue を開いて作業を分割する

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

問題の例

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

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

Sub-issue の例

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

Issue の種類を使うと、タスク、バグ、機能など、organization 全体のリポジトリ内の作業を分類できます。「組織での issue の種類の管理」を参照してください。

問題の説明の下にある sub-issue セクションのスクリーンショット。

タスクリストの例

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

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

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

ラベルの例

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

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

他の作業によって禁止されている、または他の作業を禁止している issue の表示

Issue の依存関係を作成することで、どの issue が他の issue によって禁止されているか、または他の issue を禁止しているかを簡単に把握し、共有することができます。これにより、チーム全体の調整を効率化し、ボトルネックを防ぎ、透明性を高めることができます。「Issue の依存関係の作成」を参照してください。

新しい issue の理解

メモ

GitHub Copilot にアクセスする必要があります。詳しくは、「GitHub Copilot とは何ですか?」をご覧ください。

なじみのない issue や複雑な issue に取り組む場合、GitHub Copilot を使うと、コンテキスト、履歴、重要な情報をすばやく理解できるため、より早く、より自信を持って作業を開始できます。

issue の確認

GitHub の issue に移動します。
GitHub の任意のページの右上で、検索バーの横にあるアイコンをクリックします。

GitHub Copilot Chat パネルが表示されます。パネルのサイズ変更を行うには、上端または左端をクリックしてドラッグします。
パネルに Copilot との以前の会話が含まれている場合は、Copilot パネルの右上にあるプラス記号アイコンをクリックして、新しい会話を開始します。
data variables.product.prodname_copilot_short %}チャットパネルの下部にある「Ask Copilot」ボックスに質問を入力し、Enterキーを押します。たとえば、次のように入力できます。
- Summarize the main points of this issue
- What’s the goal of this issue?

Copilot の要約は、作業の目的と範囲を把握するのに役立ちます。

履歴とコメントの理解

多くの場合、issue には、重要なコンテキストを示す可能性があるディスカッションと決定の履歴が含まれています。 Copilot を使うと、このような会話を要約し、提案された解決策や未回答の質問などの重要なポイントを特定できます。たとえば、Copilot に対して、最近のコメントを要約することや、既に行われた決定を強調表示することを依頼できます。その結果、最も関連性の高いことに集中し、チームの優先事項に沿ったコントリビューションができるようになります。

技術用語の明確化

Issue には、専門用語、コード、またはファイルが記載されていることがよくあり、すぐには理解できない場合があります。 Copilot を使うと、このような参照の説明やコンテキストを取得できます。たとえば、ファイルや関数の目的、または issue で言及されている特定の用語の意味について質問できます。その結果、ドキュメントやコードの検索に余計な時間を費やすことなく、詳細を理解することができます。

次の手順に関する提案の取得

Issue のコンテキストを理解したら、Copilot は、今後の進め方を理解するのに役立ちます。バグの修正や新機能の実装など、作業に取り組む方法についての提案を求めることができます。たとえば、「この issue を解決する最善の方法は何ですか?」、または「この問題を解決するにはどうすればよいですか?」と聞くことができます。 Copilot の提案は、作業をより効果的に計画する上で役立つ出発点となります。

チームとしての意思決定

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 への issue の追加

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