Skip to main content

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

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

はじめに

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

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

リポジトリを作成する

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

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

  • 製品リポジトリ: 特定の製品に関する作業とゴールを追跡する大規模な組織は、そのコードや他のファイルを含む 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 の理解

Note

GitHub Copilot のサブスクリプションが必要です。 詳しくは、「GitHub Copilot とは何ですか?」を参照してください。

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

issue の確認

  1. GitHub の issue に移動します。

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

    GitHub Copilot Chat パネルが表示されます。 パネルのサイズ変更を行うには、上端または左端をクリックしてドラッグします。

  3. パネルに Copilot との以前の会話が含まれている場合、Copilot パネルの右上にある プラス記号アイコンをクリックして、新しい会話を開始します。

  4. 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 Octocat のフロントエンド作業" という issue のスクリーンショット。 右側のサイドバーの [ラベル] セクションに [フロントエンド] ラベルが適用されています。

プロジェクト (クラシック) に issues を追加する

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

プロジェクトの例

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

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

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

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

次の手順

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