こんにちは！チームの開発スピードを限界まで引き上げるアジャイルコーチの先輩です。
数名だったスタートアップのチームが、5人、10人、そして30人……とスケールしていく。開発組織が大きくなるにつれ、こんな悩みに直面していませんか？
- 「あの機能の実装、今どのチームがどこまで進めているんだっけ？」
- 「バックエンドとフロントエンドで、イシューの粒度がバラバラで依存関係が見えない」
- 「気づいたら、部署間を行き来するだけの無駄な進捗確認ミーティングが増えている」
もしあなたが今、複数チームでの開発のモヤモヤを感じているなら、朗報です。今回は、次世代の開発チームで圧倒的なシェアを誇る「Linear」を使い、複数チーム・大組織の壁を鮮やかにブチ破る設計手法を伝授します。
これをマスターすれば、部門間の連携ミスや「言った・言わない」の泥沼から解放され、チーム全体のベロシティ（開発速度）が劇的に跳ね上がりますよ。さあ、一緒にLinearの奥深い世界へ足を踏み入れましょう！
—
1. なぜLinearなのか？ 大規模開発でツールが破綻する本当の理由
組織が大きくなったとき、よくある失敗が「Jiraなどの重厚長大すぎるツールを導入して、入力すること自体が目的になってしまう」という罠です。チケットのステータスを変えるだけで数クリック、カスタムフィールドが山のようにあり、エンジニアが「ドキュメント係」と化してしまう。これではアジャイル開発の魂である「個人の対話と動くソフトウェア」が死んでしまいます。
Linearが神がかっている理由は、「圧倒的な速度」と「キーボード駆動のUX」、そして何より「美しい階層構造のシンプルさ」にあります。
これから解説する設計手法を取り入れれば、ツールに縛られるのではなく、ツールがチームの神経系のように滑らかに連携する体験が手に入ります。
—
2. 【基礎セットアップ】複数チーム体制の土台を作る
まずは、組織がスケールしても情報のサイロ化（孤立）を防ぐための、Linearの基本設計を整えましょう。まだLinearに触ったばかりの方でもわかるように、ステップ・バイ・ステップで解説します。
ステップ①：チーム（Teams）の適切な切り方
Linearでは、組織単位（Workspace）の下に「Team」を作ります。ここでよくある間違いが、「プロダクト全体で1つのTeamにする」か「細かすぎる機能ごとにTeamを作る」ことです。
【黄金律】Teamは「デプロイの単位」または「独立した価値提供の単位」で切れ。
- ❌ 悪例：`フロントエンドチーム`、`バックエンドチーム`（職能別はサイロを生みます）
- ⭕️ 正解：`Checkoutチーム`、`Core Infrastructureチーム`、`Growthチーム`（機能・ドメイン別クロスクロジカルチーム）
ステップ②：ワークフロー（Workflow）の標準化
複数チームが連携するためには、共通言語が必要です。Linearの設定画面（Settings > Teams > Workflow）から、全チーム共通のステータスを定義します。
- `Backlog` （未着手・アイデア）
- `Triage` （新規流入の受口）
- `Todo` （今スリントでやる）
- `In Progress` （開発中）
- `In Review` （レビュー・QA中）
- `Done` （完了）
- `Canceled` （中止）
この基本の7つをブラさないことが、チーム間の連携の第一歩です。
—
3. 【実践：Hello World的動作確認】最初のCross-team Projectを作ってみる
百聞は一見にしかず。実際に複数チームが絡むプロジェクトをLinear上で立ち上げてみましょう。ここでは、「決済システムの全面リニューアル（Checkout & Core APIの連携）」を例にします。
3-1. Cross-team Projects（クロスチームプロジェクト）の活用
Linearの「Projects」機能は、単なるラベルではありません。複数のチームにまたがるゴールを束ねる強力なコンテナです。
1. サイドバーの「Projects」から `+ New Project` をクリック。
2. Project名に `【Q3】次世代決済基盤リニューアル` と入力。
3. ここがキモ！ 「Lead（責任者）」を設定し、「Teams」のセクションで `Checkout` チームと `Core Infra` チームの両方を追加します。
これで、異なるチームのイシューを1つのプロジェクトの傘下に集約できるようになりました。どちらのチームが進捗を更新しても、プロジェクト全体の進捗バーがリアルタイムで連動します。もう「相手の進捗どうなってる？」とSlackで聞き回る必要はありません。
—
4. 巨大な機能を攻略する！Parent-Child Issuesのデザインパターン
数ヶ月かかるような巨大な機能（Epic級のタスク）を、そのまま単一のイシューとして起票していませんか？ 複数チームで分担する場合、これでは確実に破綻します。
ここで使うのが、Parent-Child Issues（親子イシュー）です。
失敗談から学ぶアンチパターン
> 【ある日の悲劇】
> 「新決済フローの実装」という巨大なイシューを1つ作り、CheckoutチームとCore Infraチームのメンバーをアサインした。結果、誰がどこまでやったのか分かりにくくなり、お互いのプルリクエストがコンフリクトの嵐に。納期前夜、誰も全貌を把握していないカオスが生まれた……。
【極意】Parent-Childによる責任分界点のデザイン
巨大な機能は、以下のように「ツリー構造」に分解します。
📁 [Parent] 新決済フローの全面刷新 (Project: 次世代決済基盤リニューアル)
┣ 📜 [Child 1 – Core Infra] 決済トランザクションAPIのv2エンドポイント作成
┃ ┗ 🛠️ [Grandchild] DBスキーマのマイグレーション実装
┗ 📜 [Child 2 – Checkout] 新APIに対応するUIコンポーネントの改修
┗ 🛠️ [Grandchild] エラーハンドリングのE2Eテスト追加
Linearでの実装手順：
1. 親イシュー（例: `新決済フローの全面刷新`）を起票する。
2. キーボードショートカット `Cmd + Shift + I`（またはメニューから）を使い、子イシューを次々と生み出す。
3. 親イシューは「Team: All（またはプロジェクト全体のオーナーチーム）」に置き、子イシューはそれぞれの専門チーム（Core Infra / Checkout）に割り当てる。
これにより、親イシューを見れば「プロジェクト全体の完了率」が一目でわかり、子イシューを掘り下げれば「各チームの具体的なタスク」にダイレクトにアクセスできます。情報の階層化が美しく決まると、開発チームの認知負荷（Cognitive Load）が劇的に下がるのです。
—
5. チーム間依存関係（Dependencies）の可視化でブロックを防ぐ
複数チーム開発で最もプロジェクトを遅延させるのは「依存関係のデッドロック（Aチームが終わらないと、Bチームが始められない）」です。
Linearには、イシュー同士に「Blocked by（何にブロックされているか）」を設定する機能があります。
- Checkoutチームの子イシューを開く。
- 右側のプロパティから「Add dependency」を選択。
- Core Infraチームの子イシュー（API実装）を指定する。
これで、Core Infra側のタスクが完了するまで、Checkout側のイシューには「Blocked（ブロック中）」の視覚的なアイコン（🛑）が自動でつきます。
さらに美しいのは、依存している親タスクが完了すると、自動的にブロックが解除され、次のチームに通知が飛ぶという仕組みです。人手によるメンテンス不要で、システムが勝手に交通整理をしてくれます。
—
6. おわりに：ツールはチームの「思考の鏡」
今回は、Linearを用いた複数チーム・大組織向けの組織設計と、Cross-team Projects・Parent-Child Issuesのデザインパターンを解説しました。
- Teamの単位は「価値提供の単位」で切る
- 複数チームのゴールは「Cross-team Projects」で束ねる
- 巨大な機能は「Parent-Child Issues」でツリー状に分解し、チームへ適切に委譲する
- 「Dependencies」でチーム間の足並みを自動制御する
ツールはあくまでチームの「思考の鏡」です。組織のコミュニケーションがぐちゃぐちゃであれば、どんな高価なツールを入れても単なるゴミ箱になります。しかし、今回紹介したようなクリーンな設計思想をLinearに落とし込めば、ツールがあなたたちのチームワークを優しく、力強く支えてくれるはずです。
これをマスターすれば、毎日の作業が、そしてチーム全体の開発が、劇的に、心地よく楽になりますよ。さあ、明日からのスプリント設計に、早速取り入れてみてください！