気づいたら jira のスペース（プロジェクト）が増えすぎて、どれを見ればいいか分からない
多くのチームで聞く悩みですが、これは jira の設定が悪いのでも、メンバーのマナーが悪いのでもありません。
原因の多くは、「開発標準がない」か「あっても運用されていない」ことにあります。
加えて、最近の Jira では「プロジェクト」から「スペース」という名称に変わりました。
この名前の変更の意図を理解していないと、従来どおり「なんでも新規プロジェクトを作る」という発想のままになり、結果としてスペース乱立につながります。
本記事では、
なぜスペース（プロジェクト）が乱立するのか
「スペース」という概念が何を意味しているのか
どの単位でスペースを作るべきか
を整理し、今日から着手できる実践的な対策をまとめます。
1. 「プロジェクト」から「スペース」へ：名前の変更が示すもの
1-1. プロジェクトは「始まりと終わり」がある活動
従来の「プロジェクト」という言葉は、
始まりがあり
終わりがあり
期間も目的も限定されている
といった、一時的な活動をイメージさせます。
ウォーターフォール型の開発や、期間限定の案件には適した概念です。
1-2. プロダクト開発は「終わりのない継続活動」
一方で、今の多くのプロダクト開発は、
リリースして終わりではなく、
ユーザーの反応を見て改善し続ける
日々、小さな価値を出し続ける
といった「終わりのない」活動が前提です。
ここで重要になるのは、「プロジェクト管理」よりも、「バリューストリーム（価値の流れ）をどう設計して支えるか」です。
1-3. その永続的な活動を支える場が「スペース」
この前提から、Jira は「プロジェクト」ではなく「スペース」という名前に変わってきています。
スペースは、一時的な案件ではなく
プロダクトやサービスの価値を継続的に生み出し続ける「場」
チームの活動・ナレッジ・タスクが集まる「長期的な器」
という位置づけです。
つまり、本来の意図としては：
「簡単に Jira スペース（プロジェクト）を増やす」のではなく、
「そのスペースがどのバリューストリームを支える器なのか」を考えてから作るべき
というメッセージが込められています。
2. なぜ jira スペースは乱立してしまうのか
2-1. 「誰が・いつ・何のために作っていいか」が決まっていない
よくあるパターンは次の通りです。
新しい機能開発のたびに、とりあえず新スペースを作る
チーム再編のたびに新しいスペースを作る
外部ベンダーごとに別スペースを作る
どれもその場では合理的に見えますが、
「バリューストリームとしてどう位置付けるか」の視点がないまま増やすと、半年〜1年でカオスになります。
本来は、最低限次を決めておく必要があります。
スペースを作ってよいロール（例：プロダクトオーナー、開発マネージャーなど）
スペース新設の条件（例：独立したバリューストリームとして継続するものに限る）
既存のスペースで表現できないかを検討するフロー
2-2. バリューストリームの設計がない
「スペース ＝ バリューストリームの器」と考えると、
先に決めるべきは「器の数」ではなく「価値の流れの構造」です。
例：
プロダクト A のユーザー価値を生み出す流れ
社内 IT サービスの申請〜対応の流れ
顧客サポートからフィードバックをプロダクト改善へ繋ぐ流れ
これらの流れが整理されていないと、
「とりあえずチームごと・案件ごとにスペースを作る」ことになり、乱立につながります。
2-3. 開発標準が jira 設定に落ちていない
Confluence には「標準」が書いてあるが、誰も見ていない
ワークフローやフィールドがチームごとにバラバラ
スペースの作り方が属人化している
こうなると、現場は結局「自分たちのやりやすい形」でスペースを作り始めます。
結果として、「バリューストリーム」ではなく「人や組織の都合」でスペースが増え続けます。
3. どの単位でスペースを作るべきか
3-1. 基本は「バリューストリーム/価値提供単位」
おすすめは、“価値の流れ単位”でスペースを設計することです。
例：
プロダクト単位
例：ユーザー向けWebサービス、モバイルアプリなど
サービス単位
例：社内 IT サービス、社内ポータル、コールセンター支援など
大きなイニシアティブ・プログラム単位
例：DX 推進プログラム、基幹システム刷新 など
短期の案件や一時的なタスクは、
基本的には同じスペース内で Epic / コンポーネント / ラベル などで表現します。
3-2. 「とりあえず新スペース」は禁止ワードにする
運用ルールとしてはシンプルに：
「バリューストリームとして説明できないもの」は新スペースにしない
「説明が難しいもの」は既存スペースの中で表現方法を工夫する
くらいにしてしまうのが現実的です。
4. 運用ルール：アーカイブよりも「そもそも増やし方」を整える
以前は、
一定期間動いていないプロジェクトはアーカイブする
半年に一度棚卸しする
といった“お片付け”の運用が非常に重要でした。
今もできればやったほうがよいのは変わりませんが、
「スペース ＝ 永続的な活動を支える器」
という前提に立つと、
そもそも簡単に増やさない
バリューストリーム単位で設計する
ことの方が優先度は高くなります。
アーカイブはあくまで「結果として不要になったスペースを整理するための手段」であり、
本当に大事なのは最初の設計と作成ルールです。
5. まず何から始めるか（小さく始めるステップ）
今あるスペースをざっくり分類する
プロダクト単位 / サービス単位 / 一時的案件 / よく分からないもの
「これはバリューストリームと言えるか？」という目線で見てみる
新規スペース作成の簡単なチェックリストを作る
「バリューストリーム単位でスペースを作る」という方針をチームで合意する
アーカイブや整理は、これらが少し回り始めてから、
優先度の低いものから順に検討していけば十分です。
まとめ
Jira の「スペース」という名前は、「終わりのある案件」ではなく「継続的な価値提供の場」を意図している
乱立の原因は、ツールよりも「開発標準」と「バリューストリーム設計」の不在
新スペースを作る前に、「これはどの価値の流れを支える器か？」を説明できるか確認する
アーカイブよりもまず、「増やし方」と「単位」を整えることが重要
「どのスペースを見ればいいか分からない」という状態は、
裏を返せば、バリューストリームの設計と開発標準を見直すチャンスです。
ツールをいじる前に、「スペースとは何のための器か？」という原点に立ち返って設計し直してみてください。
そこが整理されると、Jira は一気に“価値の流れを見える化するための基盤”として機能し始めます。