ウォーターフォール開発におけるJIRA活用術：ブレない進行と確実な課題管理
はじめに
JIRAというと「アジャイル開発で使うもの」というイメージが強いですが、ウォーターフォール開発においても非常に強力な課題管理ツールとして活用できます。
本記事では、ウォーターフォール開発プロジェクトでのJIRAの活用方法と、フェーズごとの課題管理のコツを紹介します。
1. ウォーターフォール開発におけるJIRAの立ち位置
ウォーターフォール開発は「要件定義 → 設計 → 実装 → テスト → 納品」という流れで、各工程を順に進めるモデルです。
JIRAを使うことで、
- 各フェーズの課題を明確に分離・管理できる
- 担当者・スケジュール・成果物のトレースがしやすくなる
- リスクや変更要求も履歴付きで管理できる
といったメリットがあります。
2. プロジェクト構成と課題タイプの使い分け
プロジェクト構成の例
- プロジェクト名：
顧客管理システム刷新 - コンポーネント：要件定義 / 基本設計 / 詳細設計 / 実装 / テスト / リリース
- イシュータイプ：
- Task：作業単位の課題（設計書作成、レビューなど）
- Bug：不具合
- Change Request：顧客や関係者からの仕様変更要求
- Document：成果物ドキュメント管理（設計書、テスト仕様書など）
3. 各フェーズでのJIRA運用例
✅ 要件定義フェーズ
- ヒアリング事項、未確定要件を課題として登録
- 課題に会議記録や議事メモを添付
- ステータス：「収集中」→「合意済み」
✅ 設計フェーズ
- 設計作業タスクを担当者ごとに登録
- 各ドキュメント（基本設計書、詳細設計書）を課題単位で管理
- レビュー依頼・フィードバックもサブタスクで記録
✅ 実装・テストフェーズ
- 実装タスクを詳細化して進捗管理
- 不具合はBugタイプで管理し、修正→レビュー→完了まで追跡
- テスト仕様書の進捗も課題でトレース
✅ リリース前後
- 移行作業、手順確認、リリース判断課題を作成
- リリース後の問い合わせや障害報告も記録
4. ステータスとワークフローの設計例
To Do → In Progress → Review → Fixed → Done
↘ Rework
- 各工程に合わせて、状態遷移を明確化
- レビュー待ちや再作業（Rework）も明示的にすることで、「どこで止まっているか」が一目瞭然
🎯 ポイント：ウォーターフォールは「工程間の明確な区切り」が重要。そのため、JIRAのワークフローは承認フェーズを重視すると効果的です。
5. 見落とされがちなポイント：変更要求管理
ウォーターフォールでは、後半フェーズでの仕様変更が大きなリスクになります。
- Change Requestタイプを活用
- 影響範囲、工数、期限、関係者の承認状況を記録
- 元の要件課題とリンクしてトレース可能に
6. ダッシュボード活用例（ウォーターフォール向け）
ウォーターフォール開発では、進捗・滞留・リスクを可視化することが重要です。
📊 ダッシュボードウィジェット例
- 各フェーズごとの課題数（To Do / In Progress / Done）
- 担当者別の課題数・対応状況
- 「期限超過」「未着手」「レビュー滞留」のフィルター表示
7. ドキュメントと成果物もJIRAで一元管理
- 設計書・議事録・試験仕様書などを課題に添付
- Confluenceとの連携で、設計レビューコメントも一元化
- ドキュメント作成タスクにレビュー担当者をアサイン
8. チーム運用ルールの整備が成功の鍵
ウォーターフォールプロジェクトでは、進捗の遅延が後工程に大きく影響します。JIRA活用を成功させるには、
- 状態更新のルールを明文化（レビュー依頼時は必ずステータス変更）
- 週次で全体進捗を確認するミーティングでJIRAを必ず使用
- 課題の粒度は「1日以内で終わるレベル」に分解
9. UATフェーズで多数のバグが発生した場合の対処と管理法
UAT（ユーザー受け入れテスト）フェーズでは、実運用を想定した観点からユーザーによる本番同等テストが行われます。このタイミングで多数のバグが発見されると、品質と納期への重大な影響が生じる可能性があります。
ここでは、JIRAを用いた適切な課題管理・トリアージ方法を解説します。
✅ UATバグ専用のフィルター/コンポーネント/ラベルの活用
-
フィルター例:
project = XXX AND issuetype = Bug AND labels = UAT -
ラベル例:
uat-found,uat-critical,uat-ui,uat-logicなどで分類 - コンポーネント: "UAT", "業務テスト", "UATフィードバック" などを設定
✅ バグの優先度と影響度を明確化
- JIRAの「優先度」フィールドに加えて、**カスタムフィールド「業務影響度」**を追加すると分析がしやすくなります。
- 例：
- 優先度 = High, 影響度 = Critical（業務停止レベル）
- 優先度 = Medium, 影響度 = Minor（UI不具合）
✅ トリアージ（優先度整理）会議を定期開催
- 発生したバグを毎日 or 隔日レビューし、対応可否・優先順位・スケジュールを確認
- JIRAの「コメント」や「リンク機能」で仕様・設計課題との関連も記録
✅ バグ修正状況の可視化
ダッシュボードに以下のウィジェットを追加：
- 「UAT起因バグ件数（状態別）」
- 「修正済・未修正の推移グラフ」
- 「部門別 / 機能別のバグ分布（パレート分析）」
🛑 注意：UATバグの中には「仕様の誤解」や「要件漏れ」が混在していることもあります。
「不具合」か「仕様変更」かを明確に切り分け、課題タイプをBugからChange Requestに変更するなどの整理が重要です。
まとめ
ウォーターフォール開発では、計画に対して実績をいかに正確に管理できるかが成否を分けます。
JIRAはその強力な支援ツールとなり、要件のトレーサビリティ、工程ごとの進捗管理、品質向上に貢献します。
特にUATフェーズのように不確実性が高まる場面では、JIRAによるバグ管理の可視化と整然としたトリアージがプロジェクトの成功を左右します。
Discussion