作業の計画を始める
(トップページはこちら)
「タスクがどこまで進んでいるかわからない」「誰が何をやっているのか見えない」「スプレッドシートとチケットシステムを行き来するのが面倒」。こうした課題を抱えているチームは少なくありません。
GitLabには、プロジェクトの計画から実行、追跡までを一貫して管理できる機能が揃っています。本記事では、GitLabの計画機能を活用して、透明性の高い効率的なワークフローを構築する方法を、実践的な視点で解説します。
1. 全体像: 計画から分析までの流れ
作業計画は、開発ワークフロー全体の起点です。適切な計画があってこそ、その後のコーディング、テスト、デプロイが円滑に進みます。
GitLabでは、これらすべてのステップを一つのプラットフォームで完結できます。ツールを切り替える手間がなく、情報が一箇所に集約されるため、チーム全体の見通しが良くなります。
2. ステップ1: タイムラインの定義
最初に、チームがプロジェクトの目標とタスクにどのようにアプローチするかを考えます。ここで決めるのは「いつ、何をリリースするか」という大枠です。
2.1. マイルストーンでリリースを定義する
1.0、2.0、3.0のようなマイルストーンを使ってリリースを定義します。メジャーリリースとマイナーリリースの両方を行うかどうかも決定しましょう。
例えば、以下のような設定が考えられます:
-
v1.0- 初回リリース(2025年3月) -
v1.1- バグフィックス(2025年4月) -
v2.0- 新機能追加(2025年6月)
2.2. イテレーションで標準的なリズムを作る
チームが標準的な計画サイクルを使いたい場合は、イテレーションを活用します。イテレーションは、スプリントに似た時間枠で区切られた期間です。
例えば、2週間ごとのイテレーションを設定すると:
- イテレーション1: 1月6日〜1月19日
- イテレーション2: 1月20日〜2月2日
- イテレーション3: 2月3日〜2月16日
このリズムが確立されると、チームは「次のイテレーションで何をやるか」という共通認識を持ちやすくなります。
活用できる機能:
- マイルストーン - リリースバージョンの管理
- イテレーション - スプリント的な時間枠の設定
3. ステップ2: 作業の計画と整理
リリースのリズムを決めたら、作業を整理していきます。GitLabでは階層的に作業を管理できるため、大きな目標から小さなタスクまで、一貫した構造で扱えます。
3.1. 作業の階層構造
3.2. OKR(目標と主要な結果) - 組織レベル
プロジェクトの目標を組織全体の目標と整合させるために、OKRを作成してエピックに関連付けます。
例:
- 目標(Objective): 第1四半期のユーザー満足度を向上させる
-
主要な結果(Key Results):
- ユーザー満足度スコアを80%以上にする
- 検索機能の利用率を50%向上させる
- ページ読み込み時間を2秒以内にする
測定可能な主要な結果を定義することで、進捗を追跡し、組織全体の目標への影響を評価できます。
3.3. エピック - プロジェクトレベル
プロジェクトの主要な目標を広く概観し、チームの取り組みを全体的なビジョンと整合させます。
例: 「検索機能の改善」「ユーザー認証の強化」「パフォーマンスの最適化」
3.4. イシュー - 機能レベル
特定のバグやユーザーストーリーを表します。イシューは以下のように管理できます:
- チームメンバーへの割り当て
- ラベルによる分類と優先順位付け
- 完了までの各段階の追跡
例: 「全文検索の実装」「検索結果のソート機能」「検索履歴の保存」
3.5. タスク - 実装レベル
イシュー内で、作業をさらに小さく実行可能な項目に分解します。
例: 「Elasticsearchの導入」「APIエンドポイントの作成」「フロントエンドUIの実装」
この階層構造により、経営層は「OKRの達成度」を、マネージャーは「エピックの進捗」を、開発者は「タスクの完了状況」を、それぞれ適切な粒度で把握できます。
活用できる機能:
- OKR - 目標管理
- エピック - 大きな機能や目標の管理
- イシュー - 具体的なタスクやバグの管理
- タスク - イシューの細分化
4. ステップ3: ワークフローの可視化
イシューボードは、プロジェクトのワークフローを視覚的に表現します。カンバン方式で作業の流れを一目で確認でき、チーム全体の状況把握が容易になります。
4.1. イシューボードの構成例
4.2. イシューボードでできること
- ステータス別の表示 - 「未着手」「進行中」「レビュー待ち」「完了」などの列でイシューを整理
- ドラッグ&ドロップ - イシューを列間で移動させることで、ステータスを更新
- ボトルネックの発見 - 「レビュー待ち」の列にイシューが溜まっていれば、レビュー体制の見直しが必要
4.3. 実際の使い方
- 朝会でイシューボードを開く
- 各メンバーが自分の担当イシューを「進行中」に移動
- 完了したイシューを「レビュー待ち」に移動
- レビューが終わったイシューを「完了」に移動
この流れを毎日繰り返すことで、チーム全体の作業状況がリアルタイムで共有されます。
活用できる機能:
- イシューボード - カンバン形式のタスク管理
5. ステップ4: コラボレーションとコミュニケーション
効果的なコミュニケーションは、プロジェクト成功の鍵です。GitLabでは、作業の文脈に沿った議論ができるため、情報が散逸しません。
5.1. ラベルによる整理
bug、enhancement、high priorityのような説明的なラベルをイシューに割り当てることで、特定の作業領域を識別し、フィルタリングできます。
実践的なラベル設計例:
-
種類:
bug、feature、refactoring、documentation -
優先度:
priority::high、priority::medium、priority::low -
ステータス:
status::blocked、status::needs-review -
担当領域:
frontend、backend、infrastructure
これらのラベルを組み合わせることで、「優先度の高いバックエンドのバグ」といった条件で素早く絞り込めます。
5.2. コメントとスレッドでの議論
イシュー内のコメントとスレッドは、議論、フィードバック、コラボレーションのための集中的なスペースを提供します。
チームメンバーは以下のことができます:
- 質問をする - 「この実装方針で問題ないでしょうか?」
- 進捗を共有する - 「APIの実装が完了しました。次はフロントエンドに取り掛かります」
- アイデアを出し合う - 「こういうアプローチもあるかもしれません」
- お互いの作業をレビューする - 「この部分、エッジケースの考慮が必要そうです」
重要なのは、これらの議論がイシューに紐付いているため、後から「なぜこの実装になったのか」を追跡できることです。
5.3. メンション機能
コメント内で@yamada_taroのようにメンションすると、相手に通知が送られます。議論に参加してほしい人を簡単に呼び込めます。
使用例:
-
@suzuki_hanakoさん、このデザインでUIの実装をお願いできますか? -
@tanaka_ichiroさん、セキュリティ面でのレビューをお願いします
活用できる機能:
- ラベル - イシューの分類と優先順位付け
- コメントとスレッド - 文脈に沿った議論
- メンション - 特定のメンバーへの通知
6. ステップ5: 進捗の追跡
進捗の追跡には、タスク、マイルストーン、プロジェクト全体の目標の状態と完了度を監視することが含まれます。数値で進捗を把握することで、客観的な判断ができます。
6.1. ロードマップによる戦略的な視点
エピックとマイルストーンのタイムラインを可視化し、進捗を追跡します。ロードマップは戦略的で長期的なプロジェクトビューを提供します。
ロードマップを見ることで、以下のことがわかります:
- 主要な成果物がいつ予定されているか
- 複数のエピックが並行して進んでいるか
- リソースの競合が発生していないか
6.2. 時間追跡
各イシューに費やした時間を記録することで、進捗を監視し、将来の作業を見積もるのに役立ちます。
使い方:
- イシューに
/estimate 4hとコメントして見積もり時間を設定 - 作業開始時に
/spend 2hとコメントして実績時間を記録 - イシューの詳細画面で、見積もりと実績の差分を確認
これを続けることで、「検索機能の実装は平均して見積もりの1.5倍かかる」といった傾向が見えてきます。
6.3. マイルストーンバーンダウンチャート
特定のマイルストーンに向けた進捗をグラフで表示します。バーンダウンチャートは、時間経過に伴うイシューの開始数、完了数、残数を示します。
チャートの読み方:
- 理想線より上 - 進捗が遅れている。リソース追加やスコープ調整を検討
- 理想線より下 - 進捗が順調。余裕があれば追加タスクを検討
- 実績線が横ばい - 新しいイシューが追加され続けている。スコープクリープに注意
バーンダウンチャートでは、縦軸に残タスク数、横軸に日付を取り、理想的な進捗を示す直線(理想線)と実際の進捗(実績線)を比較できます。実績線が理想線より上にあれば遅延、下にあれば順調という判断ができます。
活用できる機能:
- ロードマップ - 長期的な計画の可視化
- 時間追跡 - 工数の記録と見積もり精度の向上
- マイルストーンバーンダウンチャート - 進捗の定量的な把握
7. ステップ6: レポートと分析
時間の経過とともに、アナリティクスを使ってチームのパフォーマンスと生産性に関する洞察を得られます。データに基づいた改善を継続的に行うことで、チームの生産性を向上させられます。
7.1. イシューの分析
以下の条件でフィルタリングして分析できます:
- ラベル - 「バグの修正にどれくらい時間がかかっているか」
- マイルストーン - 「v2.0に向けてどれだけ進んでいるか」
- イテレーション - 「今週のイテレーションで完了したタスク数」
7.2. グループ化による整理
優先度、カテゴリ、その他のカスタム基準でイシューをグループ化できます。
分析の例:
- 担当者別の完了数 - チームメンバーの負荷バランスを確認
- ラベル別の所要時間 - どの種類の作業に時間がかかっているか
- 作成日と完了日の差 - イシューのリードタイムを測定
7.3. 継続的な改善サイクル
例えば、分析の結果「レビュー待ちの時間が平均3日かかっている」とわかれば、「レビュー担当者を増やす」「レビュー時間を確保する」といった改善策を打てます。
活用できる機能:
- GitLab使用状況の分析 - チームのパフォーマンス測定
- カスタムレポート - プロジェクト固有の指標の追跡
8. ステップ7: ドキュメント作成と知識の共有
プロセス全体を通じて、進捗と手順を文書化できます。ドキュメントは、新しいメンバーのオンボーディングや、過去の意思決定の振り返りに不可欠です。
8.1. 要件定義
要件は、特定の機能やタスクに対する期待される成果、受け入れ基準、制約を定義します。イシューやWikiに文書化することで、何を提供する必要があるか、成功をどのように測定するかを明確に理解できます。
要件の書き方例:
## 機能: 全文検索
### 目的
ユーザーが記事を素早く見つけられるようにする
### 受け入れ基準
- [ ] キーワードで記事を検索できる
- [ ] 検索結果が1秒以内に表示される
- [ ] 検索結果が関連度順にソートされる
- [ ] 検索履歴が保存される
### 制約
- Elasticsearchを使用する
- 既存のデータベース構造を変更しない
8.2. Wikiによる知識管理
Wikiは、プロジェクトのドキュメントと知識管理の主要なハブとして機能します。チームメンバーがプロジェクトに関連するコンテンツを作成、編集、整理できる協働スペースを提供します。
Wikiに含められる情報:
- プロジェクトガイドライン - コーディング規約、ブランチ戦略、レビュープロセス
- 技術仕様 - アーキテクチャ図、API仕様、データベーススキーマ
- ベストプラクティス - よくある問題と解決策、パフォーマンスチューニングのコツ
- オンボーディング資料 - 開発環境のセットアップ手順、よくある質問
Wikiの利点は、Gitで管理されているため、変更履歴が残り、マージリクエストでレビューできることです。
活用できる機能:
- 要件 - 受け入れ基準の明確化
- Wiki - プロジェクト知識の集約
9. まとめ: 今日から始める3つのアクション
GitLabの計画機能を活用することで、以下のような効果が期待できます:
- 透明性の向上 - 全員が同じ情報にアクセスでき、プロジェクトの状況を把握できる
- 説明責任の明確化 - 誰が何を担当しているかが明確になる
- 効率的なプロジェクト管理 - 一つのプラットフォームで計画から実行まで管理できる
9.1. 今日から始められること
すべてを一度に導入する必要はありません。まずは以下の3つから始めてみてください:
1. マイルストーンを1つ作る
- 次のリリース予定日を設定
- そこに向けたイシューを紐付ける
2. イシューボードを開く
- 「未着手」「進行中」「完了」の3列を作る
- 既存のイシューを配置してみる
3. 1つのイシューで時間追跡を試す
-
/estimate 2hで見積もりを設定 -
/spend 1hで実績を記録 - 見積もりと実績の差を確認
これらを1週間続けてみて、チームに合うかどうかを確認しましょう。うまくいけば、徐々にエピック、OKR、ロードマップと範囲を広げていけます。
9.2. 最後に
重要なのは、ツールに振り回されるのではなく、チームの働き方に合わせてカスタマイズすることです。GitLabの計画機能は柔軟性が高いため、チームの成長に合わせて進化させられます。