101 - Issue で困らない

目的

GitLab を使って通常業務を計画・管理する方法のクイック概要です。このページの目的は、Group、Project、Issue、Board の使い方を学び、自分の仕事およびチームの仕事を計画・管理できるようになることです。

注: Issue の提出方法だけを知りたい場合は、Issues in Action（Issue の実践）まで進んで構いません。

全体像

整理する

GitLab は Group、Sub-Group、Project を提供し、組織の仕事を構造化して、複数のメンバーに一度にアクセス権を付与できるようにしています。たとえば、

  • Group - Account Management
    • Sub-group - Regions - AMS、EMEA、APAC
      • Project - Countries - North America (AMS 内)、France (EMEA 内)、Singapore (APAC 内)

仕事を整理する

定義する

GitLab では、関連する仕事を Epic、Sub-epic、Issue（仕事の最小単位）の形式でグループ化できます。たとえば、

  • Epic - 年次事業計画
    • Sub-epic - 四半期事業計画（例: Q1、Q2、Q3、Q4）
      • Issue - 個別顧客のプラン

仕事を定義する

計画する

GitLab は、開始日と終了日を持つロードマップ、マイルストーン、ラベルで仕事の計画を支援します。たとえば、

  • Group Roadmap - 年次事業計画のタイムライン
    • Group Milestone - 計画中の主要マイルストーン - 例: Q1、Q2、Q3、Q4 計画の開始日と終了日
      • Project Milestone - 特定の顧客向けデプロイメントのマイルストーン

仕事を計画する

仕事を進める

Project は厳密に Issue 追跡用に使うこともできますし、ソースコード、ビルド、テスト、アプリケーションのデプロイを含む技術プロジェクトの開発に使うこともできます。

仕事を進める

全体をまとめる

GitLab Agile Planning ＆ Reporting Structure

詳細

GitLab Group

複数のプロジェクト（プロジェクトのポートフォリオ）を管理するために、GitLab Group は事業施策のデリバリーまでを戦略的に計画・追跡できるエンティティです。Group レベルでは、サブグループ、プロジェクト、Epic、マイルストーン、ロードマップ、Group レベルの Board を管理できます。Group を使うと、関連するプロジェクトをまとめて、メンバーに複数のプロジェクトへのアクセス権を一度に付与できます。Group はサブグループとして入れ子にすることもできます。

GitLab Group

GitLab “Project”

GitLab における Project は、仕事を整理、管理、追跡、デリバリーする中核的な構成要素です。GitLab の Project は、チームが Issue（ユースケース／要件）、Issue Board（カンバン）、マイルストーン（スプリント）の形で仕事を計画・コラボレーションできるようにします。GitLab の Project を使うと、コードベースをホストするプロジェクトを作成し、Issue トラッカーとして使い、コードのコラボレーションを行い、組み込みの GitLab CI/CD でアプリを継続的にビルド、テスト、デプロイできます。プロジェクトは、公開、内部、プライベートのいずれかを選択できます。GitLab はプライベートプロジェクトの作成数を制限していません。

GitLab Project

GitLab Project は単なるプロジェクト管理よりもはるかに、はるかに、はるかに強力です。GitLab Project は、業界をリードするソースコード管理リポジトリと CI/CD パイプラインの力を解き放ちます。マージリクエストは Issue と実際のコード変更とのつながりです。マージリクエストは、設計、実装の詳細（コード変更）、議論（コードレビュー）、承認、テスト（CI パイプライン）、セキュリティスキャンを記録します。

GitLab Repository

Group vs Project

Group

  • Group は「フォルダ」のようなものです

GitLab Group

Project

  • Project は Issue、リポジトリ、マージリクエストなど、多くの「もの」を持っています。

GitLab Project

ハンズオン: Group と Project を探索する

Label

GitLab の Label は、仕事をタグ付けし追跡するための柔軟で強力な仕組みです。Label は Issue Board の列を定義するために使われ、共通のテーマに関連する Issue やマージリクエストを簡単に検索・発見できるようにします。Label は Group または Project レベル のいずれかで定義できます

Label は、bug、feature request、docs のような説明的なタイトルで Issue やマージリクエストを分類できるようにします。各 Label にはカスタマイズ可能な色も付けられます。Label は、関心のある Issue やマージリクエストを素早く動的にフィルタリング・管理することを可能にし、Issue やマージリクエストが配置されている GitLab のほとんどの場所で表示されます。

ハンズオン: Group と Project の Label を探索する

これら 2 つの Label の例を探索してください:

Issue

GitLab の Issue は基本的な計画オブジェクトです。チームが説明欄でユースケースを文書化し、アプローチを議論し、サイズ／工数（Issue weight）を見積もり、実際の時間／工数を追跡し、仕事を割り当て、進捗を追跡する場所です。Label により、チームは Issue にタグを付け、ステータスを追跡し、Issue を異なる施策に紐づけることができます。Issue は Project の一部です

Issue には無限の用途があります。たとえば、Issue は新しいアイデアの実装議論、機能提案の提出、質問の投稿、バグ報告などに使用できます。

Issue

Issue の実践: 一般的なユースケース

Issue はほぼあらゆる種類のやり取りやリクエストに適しています。機能提案、バグ報告、一般的な議論などです。Issue の目的が何であれ、効果的に使うために、作成者は次の 2 つを伝える必要があります:

  • 想定される対象者
  • 対象者が非同期で対応できるようにするために必要な情報

以下の演習では、両方を伝えるためのベストプラクティスを紹介します。

ハンズオン: Ad Hoc Issue を作成する

Issue は Project に存在するため、Issue を作成する最初のステップは、トピックと対象者に適した Project を見つけることです。この例では、GitLab101: Account Based Marketing Sample Project で Account Based Marketing チームに質問する、アドホックな自由記述形式の Issue を作成します。Issue を作成するには:

  • Project のメインページを開きます。
  • 左側のナビゲーションの Issues リンクをクリックして、Issue リストを表示します。
  • 画面右上の緑色の New Issue ボタンをクリックします。
  • 質問やコメントを要約する Title を追加します。
  • メールのように Description フィールドにコメントや質問を入力します。このフィールドは Markdown をサポートしており、入力中にプレビューを確認できます。
  • ステークホルダーや他の関係者に通知や To-Do リスト アイテムを送るために @mention できます。この演習では、テストメッセージで同僚をスパムしないように、自分自身を @mention してください。
  • Issue を自分自身に割り当てます。これでこの Issue は、ページ上部の紫色のツールバーの右隅にある Issues アイコンをクリックすることでアクセスできる、現在の Issue リストにリンクされます。
  • 重要: GitLab の 透明性 (Transparency) の価値観により、Issue のデフォルトの View 設定は 公開 です。Issue に顧客情報やその他の機密データが含まれる場合は、「This issue is confidential and should only be visible to team members with at least Reporter access.」の横のチェックボックスをオンにしてください。
  • 緑色の「Submit Issue」リンクをクリックします。

おめでとうございます！Issue を作成できました。Issue のサマリーを含むメールが届くはずで、そのメールに返信するだけで Issue の会話に追加できます。

よく使われる Group Issue Board には以下があります:

ハンズオン: テンプレート化された Issue を作成する

複雑なリクエストに必要な情報をすべて提供するためのやり取りを最小限にするため、Project オーナーは最も一般的なユースケース向けに Issue テンプレートを作成しています。これらのテンプレートには、必要な情報のすべての説明と、リクエストを完了するためのフォーマットが含まれています。多くの場合、提出前に作成者がレビューするためのチェックリストも提供されています。

テンプレート化された Issue を提出する際は、説明全体を読み、提出前にチェックボックス（[ ]）に対応するための時間を取ってください。

この演習では、Enablement テンプレートを使ってセールスイネーブルメントリクエストを作成します。

イネーブルメントセッションをリクエストするには:

  • Product Marketing Group ページ を開きます。
  • 左側のナビゲーションの Issues リンクをクリックして、Issue リストを表示します。
  • 画面右上の緑色の New Issue ボタンをクリックします。
  • Template ドロップダウンメニューから Enablement を選択し、オレンジの Apply Template ボタンをクリックします。
  • 各セクション（例: 「Learning Objectives / Key points」）の詳細をできるだけ完全に記入します。必要に応じて項目を追加したり、不要な箇条書きを削除したりしてください。
  • 前の演習と同様に @mention を使ってステークホルダーや他の関係者を特定します。
  • ある場合は Due Date を追加します。これによって作業がこの日までに必ずデリバリーされることは保証されませんが、リクエストを受け取ってトリアージする Project オーナーにとっては文脈になります。
  • Issue の下部にある /label コードを削除・変更しないでください。これにより、適切なルーティングを保証する Label が割り当てられます。
  • Issue を自分自身に割り当てないでください。リクエストの処理が遅れる原因になります。Product and Solution Marketing 内の各 Group には、Issue をトリアージして割り当てるプロセスがあります。
  • これは活発なプロジェクトなので、実際にイネーブルメントセッションをリクエストしているのでない限り、緑色の Submit Issue ボタンを クリックしないでください。

その他のよくあるテンプレート化されたユースケース:

アセットのリクエスト
人員のリクエスト
イベントのスポンサーシップ／支援のリクエスト
アカウントのサポートとアクセス

一般的なライセンス、顧客アクセス、テクニカルサポートの問題については、適切な Issue テンプレートにアクセスするために、ハンドブックの Internal Support ページ をご覧ください。

Board

Board はプロジェクトを視覚的に管理するための柔軟で動的なアプローチを提供します。Board を使うと、チームはリストを作成し、Issue をあるリストから別のリストへ移動することが簡単にできます。Board のリストは Label、Assignment、または Milestone によって定義できます。ここでチームは仕事のバックログを管理し、項目に優先順位を付け、Issue をチームやプロジェクトの特定のステージに移動できます。Board の各リストは関連する Issue の合計サイズ（weight）を計算するため、チームはどれだけの仕事が割り当てられているかを把握できます。Board は Group または Project のいずれかで利用できます

Project Issue Board は、機能や製品リリースに対するワークフローを計画、整理、視覚化するために使用されるソフトウェアプロジェクト管理ツールです。カンバンまたはスクラムのボードとして使用できます。Issue 追跡とプロジェクト管理を完璧に組み合わせ、すべてを同じ場所に保つので、ワークフローを整理するために異なるプラットフォームを行き来する必要がありません。GitLab Issue Board では、割り当てられた Label に対応するリストで Issue を整理し、それらのリスト全体でカードとして設計された Issue を視覚化します。 Board

Group レベルの Issue Board によって、プロジェクトおよびサブグループの監視とガバナンスが可能になります。このビューを使うと、特定の Issue がライフサイクルをどのように流れているかを簡単に確認でき、チーム全体のキャパシティを把握できます。 GitLab Kanban Board

ハンズオン: Board で遊ぶ

Milestone

Milestone は、スプリントや特定の Issue 群とコード変更をデリバリーするための目標日を確立します。Milestone により、チームはスプリントのように作業の特定の開始と終了を設定するか、Milestone を固定の時点とすることができます。Milestone は Group または Project のいずれかです

| GitLab の Milestone は、特定の期間内に広範な目標を達成するために作成された Issue とマージリクエストを追跡する方法です。Milestone を使えば、Issue とマージリクエストを、オプションの開始日とオプションの期日を持つ一貫したグループに整理できます。 | Milestone burndown chart ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾ |

Group レベルの計画

Epic

関連する Issue のグループを追跡するため、GitLab Epic はプロダクトオーナーやリーダーが長期間にわたる仕事をリンクし管理する能力を提供します。Epic を使った仕事の計画では、親 Epic と子 Epic を作成できます。Epic は複数のマイルストーンにまたがることができ、仕事の全体的な流れと優先順位を管理しやすくします。Epic は Group のみ です

| Epic を使えば、プロジェクトとマイルストーンを横断するテーマを共有する Issue のグループを追跡することで、より少ない労力でプロジェクトのポートフォリオをより効率的に管理できます | Epic |

Roadmap

| Roadmap は Group のさまざまな Epic を視覚的に表現したものです。Roadmap ビューは Label でフィルタリングでき、Epic の開始日／終了日で整理することで、仕事の順序を視覚化できます。現時点では、GitLab は Issue や Epic 間の依存関係を作成しません。 | GitLab Roadmap ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾ |

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License