ウォーターフォール開発におけるJiraの活用方法は？進行・課題管理のコツを解説

ソフトウェア開発の現場では、アジャイル開発が主流になりつつありますが、日本では大規模プロジェクトや要求が明確なプロジェクトにおいては、依然としてウォーターフォール開発が採用されています。また製造業では、ウォーターフォール開発とアジャイル開発の両方のアプローチが必要です。

Jira（ジラ）を使って、プロジェクトの各フェーズを透明化し、リスクを早期に発見・対処する方法、さらには変更要求管理までスムーズに行う秘訣をご紹介します。

ウォーターフォール開発における Jiraの役割は？

ウォーターフォール開発とは、その名の通り、滝のように上流から下流へ、つまり「要件定義」→「設計」→「実装」→「テスト」→「リリース」といった工程を、原則として前の工程が完了してから次の工程に進む線形（リニア）で順番通りの開発手法です。各フェーズで成果物が確定・承認されるため、計画通りに進めばプロジェクト全体の予測が立てやすいというメリットがあります。

ウォーターフォール開発での Jiraの役割は、「プロジェクト全体の進捗と課題の可視化」と「成果物・ドキュメントのトレーサビリティ（追跡可能性）の確保」です。

ウォーターフォール開発とアジャイル開発の違い

ウォーターフォール開発とアジャイル開発は、ソフトウェア開発における二大潮流ですが、そのアプローチと目指すゴールには大きな違いがあります。

ウォーターフォール開発は、事前に全体像を確定させ、計画通りに進行することで品質とスケジュールの確実性を高める手法です。しかし、一度決めた要件を途中で変更することが難しく、もし変更が必要になった場合、大きな手戻りやコスト増につながるリスクがあります。

一方、アジャイル開発は、短いサイクルで開発・テスト・改善を繰り返すことで、変化への対応力と顧客満足度を最大化する手法です。全貌が不確実な段階でも開発を始められますが、全体計画のコントロールが難しくなりがちで、大規模なシステム開発にはウォーターフォール型のアプローチが必要となることもあります。

Jiraは、元々アジャイル開発（特に Scrumや Kanban）のサポートツールとして認知されていますが、課題管理機能が柔軟なため、ウォーターフォール開発の「計画遵守」という側面にフォーカスした運用もできます。

Jiraでは、課題（作業）をエピックやバージョンで構造化し、厳密なワークフローで管理することで、ウォーターフォールの計画的な進行を助けます。カスタマイズ設定で層を複数設定し、課題（作業）に親子関係を持たせることができます。

ウォーターフォール開発におけるプロジェクトの構成例

ウォーターフォール開発を Jiraで管理する場合、「プロジェクト（2025年現在、名称を"スペース"に変更中）」と「課題タイプ」の構成が重要になります。

1. Jiraプロジェクト（スペース）の構成:

• 単一プロジェクト（単一スペース）: 開発対象となるシステム全体を一つの Jiraプロジェクト（スペース）として作成するのが一般的です。
  例：「請求システム開発プロジェクト」。
• バージョンの活用: ウォーターフォール開発の各主要フェーズやマイルストーンを、Jiraの「バージョン」機能として設定します。これにより、「要件定義完了」「設計完了」といったフェーズごとの達成度を追跡できます。

2. 課題タイプ（Issue /Work Type）の構成:

ウォーターフォール開発の特性に合わせて、管理対象を明確にするために課題タイプを設定することが推奨されます。

この構成により、最上位の「要求/エピック」を「要件定義」フェーズで作成・確定させ、それを満たすための具体的な作業を「タスク」として「設計」「実装」フェーズで実行するという、ウォーターフォール型の流れを Jira上で忠実に再現できます。

ウォーターフォール開発の各フェーズにおける Jiraの運用例

Jiraをウォーターフォール開発に適用する場合、各フェーズの「インプット」「アウトプット」「承認」を課題とワークフローに落とし込むことが運用成功の鍵となります。ここでは、フェーズごとの具体的なJiraの運用例を紹介します。

要件定義

このフェーズでは、全ての機能と非機能要件を明確にし、プロジェクトのスコープを確定させます。

• 課題の作成: 「要求/エピック」タイプの課題を作成し、顧客・ユーザーの全ての要求を網羅します。各課題の説明欄には、満たすべき要件の詳細を具体的に記述します。
• 承認フローの適用: ワークフローで「顧客承認待ち」のステータスを設定します。要求事項が確定したら、課題を「承認済み」ステータスに遷移させ、スコープの確定をJira上で記録します。未承認の課題は次のフェーズに進めません。
• 成果物との連携: 要件定義書（外部ツールで作成）を課題に添付するか、Confluence（Jiraと連携しやすいドキュメントツール）に作成し、Jira課題とリンクさせます。

設計

確定した要件を基に、システム全体の構造や詳細な仕様を定義します。

• タスクへの分解: 「承認済み」の「要求/エピック」課題を親として、それを実現するための「タスク」タイプの課題を作成します（例：DB設計、画面設計、API仕様作成）。
• 担当者の設定と進捗（ステータス）管理: 各タスクに設計担当者を割り当て、ステータス「設計中」→「レビュー待ち」→「設計完了」といったワークフローで状態を見える化します。
• 設計成果物の管理: 画面設計書やDB設計書などの設計成果物を課題に添付するか、Confluenceなどに保存しリンクさせ、トレーサビリティを確保します。

実装・テスト

設計書に基づきプログラミングを行い、機能が要件を満たしているかを検証します。

• タスクの細分化: 「設計完了」タスクをさらに「サブタスク」に分割し、開発担当者に割り当てます。
• コード管理との連携: GitなどのコードリポジトリとJiraを連携させ、コミットメッセージに Jira課題キーを含めることで、どのコード変更がどのタスクに対応するかを自動的に追跡できるようにします。
• バグ管理: テストフェーズでは「バグ」タイプの課題（作業）チケットを起票します。「発見」→「修正中」→「再テスト待ち」→「完了」といったステータスワークフローで管理し、関連する「タスク」課題（作業）とリンクさせます。

リリース前後

本番環境へのシステムリリースと、その後の運用・保守の準備を行います。

• リリースの追跡: 「バージョン」機能を使用し、リリース対象の課題をバージョンに紐づけます。リリース作業自体を「タスク」として作成し、手順をサブタスク化して管理します。
• リリース後のバグ対応: リリース後の障害対応も Jiraの「バグ」課題で一元管理し、緊急度（優先度）に応じて迅速に対応します。
• 完了の記録: プロジェクト全体の完了をもって、全ての「要求/エピック」や「タスク」を「完了」ステータスに移行させ、プロジェクトの正式な終了を記録します。

ウォーターフォール開発におけるステータスとワークフローの設計例

ウォーターフォール開発における Jiraの成功は、フェーズの厳密な移行を強制するワークフローの設計にかかっています。

ステータスとワークフローの設計例

ウォーターフォール開発では、各主要フェーズ（要件定義、設計、実装、テストなど）が Jiraの課題ステータスと密接に結びつきます。

設計を行う際のポイント

1. ゲートの明確化:

• ウォーターフォールでは、あるフェーズが完了しないと次フェーズに進めません。この「完了と承認」のポイントを Jiraのステータス（例：「要件定義完了」「設計完了」）として明確に定義します。
• これらのゲートステータスへの遷移には、「全ての必須フィールドが入力されている」「特定の権限を持つユーザー（PMなど）のみが遷移できる」といった「条件」を設定し、厳格な管理を徹底します。

2. トレーサビリティの確保:

• 「課題リンク」機能を用いて、「要求」課題と、それに対応する「設計」「実装」「テスト」のタスクを親子関係や関連付けで結びつけます。これにより、特定の要件がどの設計書・どのコード・どのテストケースに対応しているかを常に追跡できるようにします。

3. 情報の一元化:

• 「必須フィールド」を設定し、課題を次のステータスへ進める前に、担当者、期日、関連ドキュメントのリンクなどが必ず入力されるように強制します。これにより、必要な情報が常に課題に紐づいている状態を作り出します。

ウォーターフォール開発で見落とされがちな"変更要求管理"

ウォーターフォール開発において、開発途中の要件変更は原則として避けるべきとされていますが、現実には顧客の要望や外部環境の変化により、変更要求（Change Request: CR）は発生します。この変更要求管理（Change Management）への対応こそが、ウォーターフォールプロジェクトの成功を左右する重要なポイントであり、しばしば見落とされがちです。

Jiraを活用することで、変更要求をブラックボックス化せず、正式なプロセスに乗せて管理できます。

1. 専用の課題タイプ「変更要求」の利用:
   ◦ 「バグ」や「タスク」とは別に、「変更要求 (CR)」という専用の課題（作業）タイプを作成します。
2. 変更要求のワークフロー:
   ◦ 通常のタスクとは異なる厳格なワークフローを適用します。
   例: 「起票」→「影響度評価」→「PM/顧客承認待ち」→「承認済み/却下」。
3. コストと影響度の可視化:
   ◦ 「変更要求」課題に、「影響範囲 (関連する要件/設計)」や「見積もり工数/コスト」といったカスタムフィールドを追加し、承認前に変更がプロジェクト全体に与える影響を明確にします。
4. トレーサビリティの確保:
   ◦ 承認された変更要求は、関連する元の「要求/エピック」や「タスク」とリンクさせます。これにより、「この機能の変更は、どの変更要求に基づいて行われたのか」という経緯を監査可能な形で残せます。

このプロセスを経ることで、「変更要求は原則受け付けない」という建前と「変更を柔軟に管理する必要性」という実情との間でバランスを取り、曖昧なままの変更を防ぎ、PMがコストやスケジュールの観点から明確に Yes/Noの決断を下せるようにします。

ウォーターフォール開発向けの Jiraのダッシュボードレポート活用例

Jiraのダッシュボードを活用することで、進捗、滞留、リスクをリアルタイムで可視化し、適切な対策を打つことができます。以下のような切り口で見える化ができます。

• 進捗可視化: 全体スケジュールのどの位置にいるか、計画との乖離がないかを確認します。
• 滞留（ボトルネック）可視化: 特定のステータスや担当者でタスクが停滞していないかを確認し、早期にリソースを集中させます。
• リスク可視化: バグの件数や変更要求の増加傾向など、プロジェクトの健全性を脅かす要因をチェックします。

ウォーターフォール開発で使用するドキュメントや成果物もJiraで一元管理

ウォーターフォール開発では、ドキュメント（要件定義書、設計書、テスト計画書など）や成果物が、次のフェーズに進むための重要なインプットとなります。Jiraから参照できないと、タスクと成果物の対応関係が不明瞭になり、トレーサビリティが失われます。そこで、Confluence（コンフルエンス）との連携をおすすめします。

Confluenceで作成したドキュメントは、Jira課題のリンク機能を用いて関連付けます。Confluenceに Jira課題（作業）の URLを貼り付けると Jira側で記載のある Confluenceページを抽出して表示してくれます。Confluence側のドキュメントのタイトルや保存場所が変更されてもリアルタイムに引き継いでくれるため非常に便利です。

ウォーターフォール開発で Jiraを活用する際のポイント

ウォーターフォール開発における最大の課題は、進捗の遅延が発見されにくく、発見時には手遅れになっていることです。Jiraを効果的に活用し、進捗の遅延を確認・対策するためのポイントは、「早期の予兆検知」「即座の対策」です。

1. 期限（Due Date）とタイムトラッキングの徹底:

• 全ての「タスク」「サブタスク」のフィールドに具体的な期限 (Due Date)を設定します。

2. 遅延の確認と対策:

• 「期限を過ぎた未完了タスク」をリスト化する JQLフィルターを毎日確認します。
  例: due <= now() AND status not in ("完了", "却下")
• このフィルターの結果をダッシュボードに表示させ、赤信号の役割としてPMやチームが常に意識できるようにします。遅延を隠さず、オープンにして早期に対処する姿勢が重要です。
• 実工数が見積もり工数を大幅に超過しているタスクを抽出し、黄色信号とします。

ウォーターフォール開発の UATフェーズでバグが発生した際の対処および管理法

ウォーターフォール開発における UAT（ユーザー受け入れテスト）フェーズは、システムが要件を満たしているか、ユーザーが実際に使えるかを最終確認する重要な関門です。ここで発見されたバグは、リリース直前であるため、迅速かつ優先順位を明確にした対応が求められます。Jiraを活用し、混乱しがちな UATバグを適切に管理する方法を紹介します。

UATバグ専用のフィルター・コンポーネント・ラベルを活用する

UATフェーズで発見されたバグは、その後の保守フェーズで見つかるバグと区別して管理する必要があります。

• コンポーネントの活用: UAT期間中に発見されたバグに、「UAT_202510」のような専用のコンポーネントを必ず付与するようにテスターに徹底します。(事前にJiraコンポーネントが設定できるようJiraの課題・作業フィールドを設計する必要があります)
• 専用フィルターの作成: コンポーネントやラベル、またはバグが作成された「バージョン」を用いて、issuetype = Bug AND component = UAT_202510 のように、UATバグのみを抽出するJQLフィルターまたは検索フィルターを作成します。
  

  

• UAT専用ボード: このフィルターを適用した専用のJiraボード（カンバンボード）を用意し、UATバグの「起票」→「分析」→「修正中」→「再テスト待ち」のワークフローを迅速に追跡・管理します。

バグの優先度や影響度を明確にする

UATバグ全てをすぐに修正するリソースと時間はないため、優先度付けが最も重要です。

優先度の定義: バグチケットの「優先度 (Priority)」フィールドを明確に定義します。

「影響度」カスタムフィールド: 「リリースに与える影響度（大/中/小）」といったカスタムフィールドを追加し、機能的な重大さに加え、プロジェクト全体への影響（例：スケジュールへの影響）も記録します。この客観的な情報が、PMの迅速かつ正確な決断を支えます。

優先度整理に関する会議を定期的に開催する

UATバグの優先度付けは、PM、開発リーダー、テスター、そして顧客（ユーザー）も交えて行う必要があります。

• バグトリアージ会議: UAT期間中は毎日または隔日でバグトリアージ（仕分け）会議を短時間で開催します。
• 決定事項の記録: 会議で決定された「優先度」と「対応バージョン）」をその場でJiraに反映させ、即座に開発チームへ作業を割り振ります。
• 顧客との合意形成: 「最優先」以外のバグは、顧客とバグの対応タイミングについての合意を形成し、その決定を Jira課題のコメント欄などに記録します。

バグの修正状況を可視化する

UATバグの迅速な修正と再テスト状況を可視化し、バグが残っていることによるリスクを管理します。

1. バグ修正トラッキングボード: UATバグ専用の Jiraボード上で、「修正中」の課題が滞留していないか、「再テスト待ち」の課題がすぐにテスターに引き渡されているかを監視します。
2. バグバーンダウンチャート: UATバグの総数を横軸、残りのバグ数を縦軸にしたバーンダウンチャートを作成します。
3. テスターの負荷可視化: 「再テスト待ち」の課題を担当者（テスター）別に統計を取り、特定のテスターに負荷が偏っていないかを確認し、リソースの分散を行います。

ウォーターフォールとアジャイルの混合でJiraを使いたい...Jiraのサポートなら"リックソフトへ

「なんとなく」で終わらせない！Jira・Confluenceを使いこなすためのサポート、リックソフトにぜひご相談ください！

こんなお悩みはありませんか？

• Jiraを導入したけれど、いまいち活用しきれていない
• せっかくのツールを、もっときちんと使いこなしたい
• クラウド版の機能更新に追いつけていない

リックソフトは、お客様の「活かしきれていない」を「使いこなせる」に変えるサポートを徹底しています。

▼リックソフトが提供するメニュー

Jira ＝ アジャイルでもウォーターフォールでも管理可能

ウォーターフォール開発は、その特性上、初期の計画と厳密な管理が不可欠です。本記事では、プロジェクト管理ツール Jiraをウォーターフォール開発の各フェーズに適用することで、「進捗の透明化」「厳格なフェーズ移行の徹底」「変更要求の統制」を実現する方法を解説しました。 伝統的なウォーターフォール開発も、Jiraという強力なツールを活用することで、最新の知見と管理手法を取り入れ、より確実で成功率の高いものへと進化させることが可能です。本ガイドを参考に、ぜひ貴社のウォーターフォールプロジェクトで Jiraの活用を進めてください。