エピック、イシュー、タスク、OKR

(トップページはこちら) - (作業の計画を始める)

(ご注意) OKR は、フィーチャーフラグ okrs_mvc でコントロールされています。デフォルトでは、Disableとなっておりますので、利用できません (参考)。

GitLabは、コード管理だけでなく、プロジェクト全体の計画から実行までを一元管理できるプラットフォームです。本記事では、GitLabが提供する4つの主要なワークアイテム（エピック、イシュー、タスク、OKR）を使った、実践的なプロジェクト管理手法を解説します。

1. なぜGitLabのワークアイテムなのか

従来、プロジェクト管理ツールとコード管理ツールは別々に運用されることが多く、情報の分断が課題でした。GitLabのワークアイテムは、以下の点で開発チームに価値を提供します：

• 単一のプラットフォーム - コード、CI/CD、プロジェクト管理がすべて統合
• トレーサビリティ - 戦略的目標から個別のコミットまで追跡可能
• 柔軟な階層構造 - プロジェクトの規模に応じて使い分けられる
• 自動化との連携 - マージリクエストやパイプラインと直接連携

2. 4つのワークアイテムの全体像

GitLabでは、プロジェクトの規模や目的に応じて、4つのワークアイテムを使い分けます。

2.1. ワークアイテム比較表

ワークアイテム	用途	期間の目安	階層	主な機能
エピック	大規模な機能開発	数ヶ月〜1年	最大9レベル	ロードマップ、子エピック
イシュー	機能、バグ、タスク	数日〜数週間	単一レベル	ボード、テンプレート、外部連携
タスク	イシューの細分化	数時間〜数日	イシューの子	重み、ステータス、時間追跡
OKR	目標設定と測定	四半期〜年次	最大9レベル	進捗率、ヘルスステータス

3. エピック：戦略的な機能開発の管理

3.1. エピックの本質

エピックは、複数のイテレーションにわたる大規模な機能開発を管理するためのワークアイテムです。単なるイシューの集合ではなく、戦略的な目標と日々の作業を結びつける役割を果たします。

エピックが解決する課題：

• 大規模な機能開発の全体像が見えない
• 複数チームにまたがる作業の調整が困難
• 長期的な進捗が把握しづらい
• ステークホルダーへの報告が煩雑

3.2. 実践例：新しい認証システムの開発

3.3. エピックの主要機能

ロードマップ表示： エピックの子アイテムをタイムライン上に可視化し、プロジェクト全体の進捗を一目で把握できます。

階層構造（Ultimateティア）： 最大9レベルの子エピックを作成でき、大規模プロジェクトを段階的に分解できます。

クロスプロジェクト対応： 異なるグループ階層のイシューもエピックに追加でき、組織横断的なプロジェクトに対応できます。

4. イシュー：開発の中核となる作業単位

4.1. イシューの役割

イシューは、GitLabにおける作業管理の基本単位です。機能開発、バグ修正、技術的負債の解消など、あらゆる作業をイシューとして管理します。

イシューの強み：

• テンプレート機能 - バグレポート、機能リクエストなど、用途別のテンプレートで標準化
• イシューボード - カンバン方式で視覚的に管理
• 外部ツール連携 - Jira、Zoom、メールなどと統合
• 自動クローズ - マージリクエストのマージ時に自動でクローズ

4.2. 開発フローとの統合

イシューは、GitLabの開発フローと密接に統合されています。

実践的な使い方：

1. イシューからブランチを直接作成
2. コミットメッセージやマージリクエストでイシューを参照
3. マージリクエストに Closes #123 と記載して自動クローズ
4. CI/CDパイプラインの結果をイシューで確認

4.3. イシューボードでの可視化

イシューボードを使うと、チームの作業状況を一目で把握できます。

典型的なボード構成：

• バックログ - 未着手のイシュー
• To Do - 次に取り組むイシュー
• In Progress - 作業中のイシュー
• Review - レビュー待ちのイシュー
• Done - 完了したイシュー

5. タスク：イシューの細分化と実行管理

5.1. タスクの位置づけ

タスクは、イシューをより小さく追跡可能な単位に分割するためのワークアイテムです。イシューが「何を作るか」を定義するのに対し、タスクは「どう作るか」の具体的なステップを表現します。

タスクを使うべき場面：

• イシューが複数の技術的ステップに分かれる場合
• 複数人で作業を分担する場合
• 進捗を細かく追跡したい場合
• 作業の見積もり精度を上げたい場合

5.2. 実践例：ログイン機能の実装

5.3. タスクの主要機能

重みの設定（Premium/Ultimate）： 各タスクに重みを設定し、親イシューで合計重みと進捗率を自動計算できます。これにより、イシュー全体の進捗を定量的に把握できます。

ステータス管理（Premium/Ultimate）： 基本的なオープン/クローズだけでなく、「進行中」「レビュー待ち」「完了」など、カスタムステータスで細かく追跡できます。

時間追跡： 見積もり時間と実績時間を記録し、作業効率を分析できます。

マージリクエストとの連携： マージリクエストの説明にクロージングパターンを使用すると、マージ時にタスクが自動クローズされます。

5.4. タスクの活用パターン

パターン1：技術的な分割

イシュー: ユーザー検索機能の実装
├─ タスク: Elasticsearchインデックス設計
├─ タスク: 検索APIエンドポイント実装
├─ タスク: 検索結果UIコンポーネント作成
└─ タスク: パフォーマンステスト実施

パターン2：チーム間の分担

イシュー: 決済機能の実装
├─ タスク: バックエンドAPI実装（サーバーチーム）
├─ タスク: フロントエンド実装（フロントエンドチーム）
├─ タスク: 決済ゲートウェイ統合（インフラチーム）
└─ タスク: セキュリティ監査（セキュリティチーム）

6. OKR：目標設定と成果測定

6.1. OKRの本質

OKR（Objectives and Key Results）は、組織の戦略的目標を設定し、測定可能な成果で追跡するフレームワークです。GitLabのOKRは、開発作業と組織目標を直接結びつけることができます。

OKRの基本原則：

私/私たちは、（日付）までに（目標）を達成します。それは以下の指標（主要な結果）を達成することによって実現します。

目標（Objective）： 意欲的で定性的なゴール（例：「業界最高のユーザー体験を提供する」）

主要な結果（Key Result）： 測定可能な定量的指標（例：「ページ読み込み時間を2秒以下にする」）

6.2. 実践例：パフォーマンス改善プロジェクト

6.3. OKRの主要機能

進捗の自動計算： 子OKRの進捗を入力すると、親OKRの進捗が自動的に平均値で更新されます。手動で上書きすることも可能です。

ヘルスステータス： 目標達成のリスクを「順調」「要注意」「危険」などのステータスで可視化できます。

チェックインリマインダー： 定期的（毎週、月2回、毎月）にチームへリマインダーを送信し、進捗更新を促すことができます。

6.4. OKRと開発作業の連携

OKRの強みは、戦略的目標と日々の開発作業を直接結びつけられることです。

連携の例：

1. 目標 を四半期の戦略的ゴールとして設定
2. 主要な結果 を測定可能な指標として定義
3. イシュー を主要な結果に関連付け
4. タスク で具体的な実装作業を管理
5. マージリクエストがマージされると、関連するタスク、イシュー、主要な結果の進捗が更新される

7. ワークアイテムの統合活用

7.1. 実践的なワークフロー

実際のプロジェクトでは、4つのワークアイテムを組み合わせて使用します。

7.2. レイヤー別の使い分け

戦略レイヤー（四半期〜年次）：

• OKR で組織目標を設定
• エピック で大規模イニシアチブを管理
• ロードマップでタイムラインを可視化

戦術レイヤー（週次〜月次）：

• イシュー で具体的な機能やバグを管理
• イシューボードでスプリント計画
• マイルストーンでリリース管理

実行レイヤー（日次）：

• タスク で日々の作業を細分化
• マージリクエストで実装
• CI/CDパイプラインで自動テスト・デプロイ

7.3. リンクされたアイテムの活用

ワークアイテム間の関係性を明示することで、依存関係やブロッカーを可視化できます。

リンクの種類：

• 関連する（relates to） - 一般的な関連性
• ブロックする（blocks） - このアイテムが他をブロック
• ブロックされている（is blocked by） - このアイテムが他にブロックされている

活用例：

イシュー #123: API実装
├─ ブロックする → イシュー #124: フロントエンド実装
└─ 関連する → 目標: Q2パフォーマンス改善

タスク #456: データベーススキーマ変更
└─ ブロックする → タスク #457: マイグレーションスクリプト作成

8. 導入のベストプラクティス

8.1. 段階的な導入アプローチ

フェーズ1：イシューから始める（1〜2週間）

1. 既存のバグや機能リクエストをイシューに移行
2. イシューボードを設定してカンバン方式を導入
3. マージリクエストとイシューを連携

フェーズ2：タスクで細分化（2〜4週間）

1. 複雑なイシューをタスクに分割
2. 重みを設定して見積もり精度を向上
3. チーム内で作業を分担

フェーズ3：エピックで大規模管理（1〜2ヶ月）

1. 複数イテレーションにわたる機能をエピックで管理
2. ロードマップを作成してステークホルダーと共有
3. 階層構造を活用して複雑なプロジェクトを整理

フェーズ4：OKRで目標連携（四半期単位）

1. 組織目標をOKRとして設定
2. エピックやイシューをOKRに関連付け
3. 定期的に進捗をレビュー

8.2. チーム規模別の推奨構成

小規模チーム（3〜5人）：

• イシューとタスクを中心に使用
• エピックは大規模機能のみ
• OKRは四半期単位で設定

中規模チーム（10〜20人）：

• エピックで機能単位を管理
• イシューボードを複数作成（チーム別、機能別）
• タスクで詳細な進捗管理
• OKRでチーム目標を設定

大規模組織（50人以上）：

• 階層的なエピック構造を活用
• OKRで組織全体の目標を管理
• プロジェクト横断的なロードマップ
• カスタムワークフローとステータス

8.3. よくある落とし穴と対策

落とし穴1：過度な細分化

• すべてのイシューをタスクに分割する必要はない
• 1〜2日で完了するイシューはそのまま管理

落とし穴2：階層の深すぎる構造

• エピック > 子エピック > イシュー > タスク の4レベルで十分
• それ以上深くすると管理が煩雑になる

落とし穴3：OKRの設定ミス

• 目標は定性的、主要な結果は定量的に
• 主要な結果は3〜5個程度に絞る
• 達成不可能な目標は避ける

落とし穴4：リンクの乱用

• すべてのアイテムをリンクする必要はない
• 本当に依存関係がある場合のみリンク

9. まとめ：GitLabで実現する統合的な開発体験

9.1. GitLabのワークアイテムがもたらす価値

GitLabのワークアイテムは、単なるプロジェクト管理ツールではありません。コード、CI/CD、プロジェクト管理が統合されたプラットフォームだからこそ、以下の価値を提供できます：

1. 完全なトレーサビリティ

組織目標（OKR）
  ↓
大規模機能（エピック）
  ↓
具体的な作業（イシュー）
  ↓
実装単位（タスク）
  ↓
コード変更（マージリクエスト）
  ↓
デプロイ（CI/CDパイプライン）

2. 情報の一元化

• プロジェクト管理ツールとコード管理ツールを行き来する必要がない
• すべての情報が単一のプラットフォームに集約
• チーム全体で同じ情報を共有

3. 自動化による効率化

• マージリクエストのマージでイシュー・タスクが自動クローズ
• CI/CDパイプラインの結果が自動的にイシューに反映
• 進捗が自動計算され、常に最新の状態を把握

4. 柔軟性とスケーラビリティ

• 小規模チームから大規模組織まで対応
• プロジェクトの成長に合わせて段階的に機能を追加
• カスタマイズ可能なワークフローとステータス

9.2. 次のステップ

GitLabのワークアイテムを活用して、チームの生産性を向上させましょう。

今日から始められること：

1. 既存の作業をイシューに移行 - バグトラッカーやスプレッドシートからイシューへ
2. イシューボードを作成 - カンバン方式で作業を可視化
3. マージリクエストとイシューを連携 - Closes #123 で自動クローズ

1ヶ月後に目指すこと：

1. タスクで作業を細分化 - 見積もり精度の向上と進捗の可視化
2. エピックで大規模機能を管理 - ロードマップでステークホルダーと共有
3. チーム全体でワークフローを統一 - テンプレートとラベルの標準化

四半期後に実現すること：

1. OKRで組織目標と開発作業を連携 - 戦略的な意思決定をデータで支援
2. 完全な自動化 - コミットからデプロイまでの全プロセスを自動化
3. 継続的な改善 - メトリクスを分析してプロセスを最適化

GitLabのワークアイテムは、開発チームの生産性を飛躍的に向上させる可能性を秘めています。まずは小さく始めて、チームの成長に合わせて段階的に活用範囲を広げていきましょう。