【実務・中級編】複数チーム・大組織向けLinear運用：Cross-team ProjectsとParent-Child Issuesで部門間連携をスムーズにする設計手法 – プロジェクト・ナレッジ管理活用バイブル

組織がスケールしても「透明性とスピード」を失わない：複数チーム開発のためのLinear極限運用術

テックリードやエンジニアリングマネージャー（EM）として、組織が数名から数十名、そして複数チームへとスケールする瞬間を経験したことがあるだろうか。

最初は数人の阿吽の呼吸で回っていたLinearのワークスペースが、チームが分かれた途端に「情報のサイロ化」「誰が何をやっているか分からないブラックボックス化」「チーム間依存関係のデッドロック」という悪夢に侵食される。

「あの機能のリリース、バックエンド側のチームの進捗どうなってるんだっけ？」
「この巨大プロジェクト、どのチームがどこまで責任を持つべき？」

Jiraへの出戻りを検討し始める前に言いたい。問題はツールではない。構造（Design）の欠如だ。

Linearはその圧倒的なモダンさと高速性ゆえに、規律なくだらだらと使うと、ただの「きれいなタスクリスト」に成り下がる。しかし、そのポテンシャルを極限まで引き出す設計思想――特に Cross-team Projects と Parent-Child Issues をマスターすれば、組織がどれだけ巨大になっても、スタートアップのような圧倒的なベロシティを維持できる。

本稿では、複数チーム体制におけるLinearの限界を突破し、部門間連携をスムーズにするための実践的な設計手法を、私の実体験（数々の失敗談）を交えて徹底的に解説する。

—

1. 失敗談：なぜ複数チームのLinear運用は崩壊するのか？

組織がスケールした初期、私たちはよくある罠に陥った。

「とりあえずチームごとにワークスペースを分けよう」の悲劇

チームごとに独立したワークスペースや、完全に切り離されたTeam（例: `FE`, `BE`, `DATA`）を作った結果、プロダクト全体の機能開発（Cross-functional Project）の際に、イシューが各チームに散らばり、誰も全体像を把握できなくなった。

「ラベル地獄」の到来

「どのチームの誰の管轄か」を無理やり管理しようと、`team:frontend`, `priority:Urgent`, `status:blocked` などのラベルを乱立させ、誰もメンテしないカオスなバックログが誕生した。

「巨大イシュー」の放置

「決済基盤リニューアル」という巨大な親イシューを作り、その中に数ヶ月終わらないサブタスクがぶら下がり続け、進捗率（Progress）が永遠に「12%」のまま凍結した。

これらを解決するために私たちが導き出した結論は、「チームの垣根を越えたプロジェクト駆動」と「構造化された親子イシュー」の徹底である。

—

2. Cross-team Projects（クロスチームプロジェクト）による全体最適

Linearの `Projects` 機能は、単なるマイルストーン管理ではない。「複数チームにまたがる利害関係者を1つのゴールに向かわせて同期させるためのハブ」である。

設計の極意：チームの枠を超えた「Project Lead」の配置

複数チームが絡むプロジェクト（例：「Q3グローバル決済基盤移行」）において、各チームから1人ずつアサインするやり方は失敗しやすい。「誰が最終責任を持つか（Single Point of Accountability）」が曖昧になるからだ。

アンチパターン: 各チームのリード全員をProject Leadにする。
ベストプラクティス: プロダクトの価値に最も責任を持つ1名を Project Lead に据え、他チームのメンバーは Project Members として参画させる。

ドキュメントとUpdatesの活用

プロジェクト画面の `Updates` 機能は、週に一度のステータス報告（On track / At risk / Off track）をチーム全体にプッシュする最強のツールである。
ここに、Linear内蔵のMarkdownで「今週のブロック要因」「他チームへの依頼事項」を簡潔に記載する文化を強制せよ。Slackの流れるログに頼るな。すべての文脈はプロジェクトページに集約する。

—

3. Parent-Child Issues（親子イシュー）のデザインパターン

巨大な機能を複数チームで分担する際、親イシュー（Epic的役割）と子イシューの切り方にセンスが問われる。

❌ 失敗する切り方：レイヤー分割（縦割り）

親: 「新・検索機能の実装」
子: 「フロントエンド実装（FEチーム）」
子: 「バックエンドAPI実装（BEチーム）」
子: 「DBスキーマ変更（DBAチーム）」

この構造の何がダメか？ 「機能（Value）」ではなく「作業（Task）」で分解しているため、ユーザー価値としてのインクリメントが見えない。 フロントが終わってもバックエンドが終わらなければ、進捗はゼロのままだ。

⭕ 成功する切り方：垂直スライス（Value Slice）分解

親: 「新・検索機能の実装」
子: 「[Search-BE] フィルタリング用APIの最低限のエンドポイント実装」
子: 「[Search-FE] APIモックを使った検索結果一覧のレンダリング」
子: 「[Search-BE] 検索インデックスのパフォーマンス最適化（2次フェーズ）」

ポイント: チームをまたぐ場合でも、「ユーザーに届く最小限の価値の単位（Vertical Slice）」ごとに子イシューを切り、それぞれのイシューがどのTeamに所属するかを明確にする。Linearでは、親イシューと子イシューで異なるTeam（例: 親はProductチーム、子はBE/FEチーム）を割り当てることができる。これにより、全体のマイルストーン（親）の下で、各専門チーム（子）がそれぞれのバックログで並行して作業を進められる。

—

4. 開発スピードを劇的に高める「裏技」キーボードショートカット

プロのエンジニアはマウスを使わない。Linearの真価は、その圧倒的なキーボードショートカットの網羅性にある。これらをチーム全員の共通言語にしろ。

特に Cmd + K（コマンドパレット） は神機能だ。イシューを開いた状態でこれを押し、「Move to…」と打てば、チーム間のイシューの移管がマウス操作ゼロで完了する。

—

5. 絶対入れるべき神インテグレーション（プラグイン）

Linear単体でも強力だが、複数チーム開発では以下のインテグレーションが「組織の潤滑油」となる。

1. GitHub / GitLab インテグレーション

理由: プルリクエストのタイトルやブランチ名にイシューID（例: `ENG-123`）を含めるだけで、Linear側のステータスが自動連動する（In Review -> Done）。「PR出したのにLinearが更新されてなくて進捗が見えない」というエンジニア特有の怠慢をシステムで強制排除する。

2. Slack インテグレーション

理由: 単なる通知ボットとして使うな。Slackのメッセージから `/linear` コマンドで即座にイシューを作成できるようにせよ。雑談やバグ報告のチャットから、1秒でバックログへ直行する導線を作ることで、タスクの「こぼれ落ち」をゼロにする。

3. Figma インテグレーション

理由: デザインとエンジニアリングの乖離を防ぐ。LinearのイシューにFigmaのフレームを直接埋め込み、デザインが更新されたらLinear側にも通知が飛ぶようにする。複数チーム間で「今どのデザインが正なのか」迷う時間を完全に消し去る。

—

6. チーム開発で役立つ設定の共有化ルール（ガバナンス）

組織がスケールすると、好き勝手にラベルやステータスを作る輩が現れる。これを防ぐための「最低限のガードレール」をワークスペース全体で共有せよ。

カスタムステータスの最小化

デフォルトのステータス（Backlog, Todo, In Progress, Done, Canceled）に極力従う。独自のステータス（例: `QA待ち`, `レビュー中`）を増やしすぎると、かえってワークフローが停滞する。レビューはGitHubのPRステータスに任せ、Linear側はシンプルに保つのが鉄則。

Triage（トリアージ）チームの活用

外部からのバグ報告や他部署からの要望は、直接各開発チームのバックログに入れない。Triage（未整理）という専用の受信箱を用意し、そこに一旦集約する。専任のプロダクトマネージャーやテックリードが毎日10分だけトリアージを行い、適切なチームのプロジェクトに割り振る。この門前払いのフィルターがあるだけで、開発チームの集中力（Deep Work）は劇的に守られる。

—

7. 実用的な設定・自動化のベストプラクティス構成例

Linearの強力な機能の一つが、ワークフローの自動化（Linear Automations）とAPI/Webhookによる拡張だ。ここでは、複数チーム連携を自動化するための設定例を紹介する。

1. ワークフロー自動化ルール（UI設定推奨事項）

PRマージ時の自動完了:
Condition: イシューに関連付けられたGitHubのPRが `Merged` になったとき
Action: ステータを `Done` に変更する
サブイシュー連動の原則:
Condition: すべての `Child Issues` が `Done` になったとき
Action: 親イシューのステータスを自動的に `In Review` または `Done` の手前にする（※完全自動完了はリスクがあるため、通知を飛ばして人間が確認することを推奨）

2. Linear Webhook 連携ペイロード例 (JSON)

複数チーム間での依存関係（Dependency）がブロックされた際、Slackや外部のDatalakeへ自動通知するためのWebhookペイロードの設計概念を示す。チーム間のブロッカーをリアルタイムで検知するための基盤となる。

{
“action”: “update”,
“type”: “Issue”,
“createdAt”: “2023-10-25T08:00:00.000Z”,
“data”: {
“id”: “uuid-issue-1234”,
“identifier”: “ENG-456”,
“title”: “[Search-BE] フィルタリング用APIの実装”,
“priority”: 1,
“state”: {
“name”: “Blocked”,
“type”: “unstarted”
},
“assignee”: {
“name”: “Taro Engineer”,
“email”: “taro@example.com”
},
“team”: {
“key”: “BE”,
“name”: “Backend Core Team”
},
“project”: {
“id”: “uuid-project-789”,
“name”: “Q3グローバル決済基盤移行”
},
“relations”: {
“blockers”: [
{
“identifier”: “DATA-89”,
“title”: “ユーザー属性マスタのスキーマ変更”,
“team”: “DATA”
}
]
}
},
“updatedFrom”: {
“state”: {
“name”: “In Progress”
}
}
}

> 実装のヒント: このようなWebhookをAWS LambdaやZapier等で受け取り、`Dataチーム` のイシューが `Backendチーム` のイシューをブロックしている状態（Blocked）が24時間以上続いた場合、自動的にSlackの `#alert-cross-team` チャンネルにメンション付きで通知する仕組みを構築せよ。組織の心理的安全性を保ったまま、部門間コミュニケーションの遅延をシステムが強制的に炙り出してくれる。

—

8. おわりに：ツールは思想を映す鏡である

Linearは、単に「きれいなUIのチケット管理ツール」ではない。そこにどのような構造（Cross-team Projects）と粒度（Vertical SliceなParent-Child Issues）を流し込むかによって、組織のコラボレーションの質が決定される。

チームがスケールしたとき、ツールに逃げるのではなく、「組織のコミュニケーションパスをLinearの構造にどう落とし込むか」を設計してほしい。

プロのエンジニアリング組織であれ。コードだけでなく、タスクと情報のフローをも美しくデザインし尽くせ。その先にあるのは、部門間の壁が溶け、全員が同じリズムで疾走する、圧倒的な開発ベロシティである。