大規模開発でJiraが「負債」化しないために：プロジェクト設計の極意
こんにちは。現場で苦労を重ねてきたエンジニアの皆さん、あるいはこれから大規模開発の荒波に漕ぎ出そうとしている皆さん。
Jiraを導入したばかりの頃は「これでタスク管理が完璧だ！」と思うものです。しかし、半年も経つとどうでしょう。「どのチケットがどこにあるか分からない」「依存関係がスパゲッティ状態」「経営層のレポートのために毎日手動で集計している」……そんな悲劇に陥っていませんか？
それは、あなたが悪いのではありません。Jiraの設計思想を「箱」としてではなく「情報の血管」として捉えられていないだけなのです。今日は、大規模開発で破綻しないための「Jiraポートフォリオ設計」の神髄を、魂を込めて伝授します。
—
1. 大規模開発におけるJiraの「設計思想」
まず、Jiraを「タスクをメモする場所」と考えるのをやめましょう。Jiraは、チーム間の「期待値」と「依存関係」を同期させるための通信プロトコルです。
破綻を防ぐための3つの原則
1. 「プロジェクト＝チーム」ではない： プロジェクトは「提供価値の単位」です。
2. 階層を深追いしない： Jiraの標準機能に「エピック以上の階層」を無理やり作ると、管理コストで自滅します。Advanced Roadmaps（旧Portfolio）の活用が前提です。
3. 「コンポーネント」を生存戦略にする： チームを跨ぐ依存関係の追跡には、プロジェクトを跨いだ共通の「コンポーネント」定義が最強の武器になります。
—
2. 最強のセットアップ：HelloWorld的な「プロジェクト構造」
これからJiraを設計するなら、まずこの「黄金比」をセットアップしてください。
① プロジェクトの粒度設計
個別の機能開発をプロジェクトにするのは厳禁です。
- 推奨： 「製品（Product）」や「領域（Domain）」を1つのプロジェクト単位にする。
- 理由： ワークフローや権限管理の爆発を防ぐためです。
② コンポーネントを「アーキテクチャの地図」にする
各チームに任せきりにすると、コンポーネントが「フロントエンド」「バックエンド」のような曖昧なものになります。組織全体のアーキテクチャ図と1対1で対応するコンポーネントを「共有コンポーネント」として定義しましょう。
コンポーネント設計のイメージ（命名規則は厳格に）
チーム間での依存関係を可視化するための設計思想
Components:
- Name: “Auth-Service” # 認証基盤チームが担当
Lead: “auth-team-lead”
- Name: “Payment-Gateway” # 決済チームが担当
Lead: “pay-team-lead”
これにより、どのタスクが「どの技術領域に依存しているか」が自動で抽出可能になります
—
3. 動作確認：依存関係の可視化を体験する
設計ができたら、正しく機能しているか確認しましょう。「HelloWorld」的な動作確認はこれです。
ステップ：
1. 「依存関係のリンク」を作成する： プロジェクトAのチケットから、プロジェクトBのチケットに対して「is blocked by（ブロックされている）」リンクを貼る。
2. JQLで抽出する： 以下のクエリを入力し、全貌を俯瞰する。
プロジェクトを跨いで「ブロックされている」タスクを抽出するJQL
これが経営層が見たがる「ボトルネックの可視化」です
issueLinkType = “is blocked by”
AND statusCategory != Done
ORDER BY priority DESC
なぜこれが重要か？
このクエリを保存し、ダッシュボードに貼り付けるだけで、PMは「今、組織全体のどこが止まっているか」を即座に把握できます。いちいち各チームの進捗会議に出る必要はありません。
—
4. 経営層を味方につける「ポートフォリオ」設計
経営層が知りたいのは「個別のチケット」ではなく、「計画に対して今どの位置にいるか」です。
- Advanced Roadmaps (プラン) の活用：
Jiraの「プラン」機能を使って、複数のプロジェクトから「エピック」を吸い上げてください。ここで最も重要なのは、「ターゲット終了日」をチームのベロシティから自動計算させることです。
- 「手動更新」という悪習を断つ：
「今週の進捗を報告してください」というメールは廃止しましょう。すべての進捗は、Jiraの「プラン」上でリアルタイムに計算されます。設計さえ正しければ、あなたが寝ている間に、Jiraが勝手に進捗レポートを作成してくれるのです。
—
最後に：ツールは「文化」を強制する
私が長年アジャイルコーチをしてきて確信していることがあります。それは「Jiraの設計は、その組織のコミュニケーション構造そのものである」ということです。
複雑すぎるJiraは、複雑すぎる組織の現れです。もしJiraが使いにくいと感じるなら、それは設計の問題ではなく、チーム間の意思疎通がうまくいっていないサインです。
まずは今日、「共有コンポーネント」の整理から始めてみてください。それが、大規模開発を成功させるための最初の、そして最も強力な一歩です。
何かに行き詰まったら、いつでも聞いてください。あなたの開発が、もっと軽やかで、もっと価値あるものになることを願っています。応援していますよ！