WBSを作っていると、「設計」「開発」「テスト」といったフェーズ名やプロセス名と、実際に担当者が行うタスクが同じ階層に混在してしまうケースがよくあります。このままJiraに落とし込むと、課題間リンクや依存関係が本来の作業順序を示さなくなり、Plan上ではきれいに見えても、実務では扱いづらい見た目だけのWBSになりがちです。
Jiraの標準階層は「エピック → ストーリー／タスク → サブタスク」で、Plan（旧 Advanced Roadmaps）もこの構造を前提に動きます。Premium/Enterpriseではエピックより上の階層は追加できますが、タスクより下の細かい階層はサブタスクまでに限られるため、WBSのように多段で細かい作業構造をそのまま再現するには限界があります。
そのため、より深いタスク階層や本格的なWBSを表現したい場合、WBS Gantt-Chart といったアドオンで詳細構造やガントチャートを補完するケースが一般的です。Planは上位ロードマップ、アドオンは詳細WBSという役割分担を取ると無理がありません。
ここで大切なのは、ツール設定より先に「何をタスクと呼ぶか」を組織として定義することです。
また、フェーズ名やプロセス名は スペース（プロジェクト）のワークフローステータス側に組み込む のが自然です。
例えば、ある機能開発を考えると、KANBANでは
Backlog
To Do
In Progress
Review
Done
と進みます。この「In Progress」は、WBSでいうところの「開発」というフェーズに相当しますが、Jiraでは“フェーズ”をタスクにするのではなく、“タスクのステータス”が開発段階を示します。
もしWBSアドオン側にも「開発」「テスト」といったフェーズ名を配置してしまうと、Jiraでは本来ステータスで表現すべき概念を“タスクのように扱う”ことになり、二重管理になってしまいます。これが混乱の元です。
タスクの粒度と階層ルールをそろえたうえで、Planとアドオンを適切に使い分けること
これが、意味のある依存関係と現場にフィットするWBSを両立する最も現実的な運用になります。