こんにちは！開発チームのベロシティを上げる手伝いなら、僕に何でも聞いてください。
新しいプロジェクトが始まるとき、ワクワクする反面、「あれもこれもやらなきゃいけないのに、タスクがごちゃ混ぜになってチーム全体の見通しが悪い…」なんて悩んだ経験はありませんか？チャットツールには終わらないメンション、どこに何があるかわからないドキュメントの山。これでは、エンジニアのエネルギーが「管理」という名の無駄な摩擦で削られてしまいます。
そんな混沌としたプロジェクトを、まるで美しいオーケストラのようにスムーズに動かしてくれる魔法のツールが 「Linear（リニア）」 です。
今回は、Linearが持つ圧倒的なスピード感の源泉である、Projects（プロジェクト）、Milestones（マイルストーン）、Sub-issues（サブイシュー） の階層構造を徹底的に解説します。これをマスターすれば、複雑な開発タスクの分解が驚くほどクリアになり、毎日の作業が劇的に楽になりますよ。
初めてLinearに触れる方にも、その設計思想から実際のセットアップ、そして「動いた！」を実感するまでのステップを、優しく丁寧にガイドしていきますね。
—
1. なぜLinearなのか？（ツールの設計思想）
世の中にはたくさんのタスク管理ツールがありますが、多くのツールは「チケットを消化する場所」に留まっています。そのため、チケットが増えれば増えるほど全体像が見えなくなり、エンジニアは森の中で木を見ているような状態になってしまいます。
Linearの思想は、「エンジニアの認知負荷を限界まで下げること」 です。
キーボードショートカット主体でサクサク動くUIはもちろん、データ構造そのものが「人間の脳の認知構造」に極めて近く設計されています。
これから紹介する3つの要素（Projects、Milestones、Sub-issues）を正しく配置することで、「今、自分たちは何を作っていて、どこに向かっていて、今日何をすべきか」 が一目でわかるようになるのです。
—
2. 基礎セットアップ：Linearの全体像を理解する
まずは、Linearの全体像をつかみましょう。
Linearは、大まかに以下のピラミッド構造で世界を捉えています。
🌐 Organization (会社・組織全体)
└── 📂 Team (開発チーム：Frontend, Backend など)
└── 🚀 Project (大目標：決済機能リニューアル など)
└── 🏁 Milestone (中間目標：API実装フェーズ など)
└── 🎫 Issue (個別タスク：Stripe連携 など)
└── 🧩 Sub-issue (細分化：SDKのインストール など)
今回は、このピラミッドの中腹にあたる 「Project」「Milestone」「Sub-issue」 の3兄弟の正しい使い分けに焦点を当てます。
—
3. 3大要素の正しい使い分けと設計思想
それぞれの役割を、身近な例えを交えて紐解いていきましょう。
🚀 Projects（プロジェクト）
- 定義: 明確なゴールと期限を持つ、まとまった単位の大きな仕事。
- 例え: 「新しい家を建てる」
- 使い所: 数週間から数ヶ月かかるような、複数のチームメンバーが関わるまとまった機能開発（例：「決済機能の刷新」「OAuth2.0認証の導入」など）。
- 設計のコツ: 「誰がオーナー（責任者）か」を必ず1人明確にアサインします。オーナーシップの不在はプロジェクトを沈没させる最大の原因です。
🏁 Milestones（マイルストーン）
- 定義: プロジェクトという長い旅路の中の「通過点・キャンプ地」。
- 例え: 「基礎工事の完了」「上棟式」
- 使い所: Projectsの中を時系列やフェーズで区切るために使います。例えば、「Project：決済機能の刷新」の中に、以下のようなMilestonesを置きます。
1. `Phase 1: DBスキーマ設計とAPIモック作成`
2. `Phase 2: 外部決済Gatewayとの疎通`
3. `Phase 3: フロントエンドUI実装とE2Eテスト`
- 設計のコツ: 「ここまで終わったら確実に価値が検証できる（または次のフェーズに進める）」という区切りにします。
🧩 Sub-issues（サブイシュー）
- 定義: 親となるイシューをさらに細かく分解した最小単位の作業。
- 例え: 「コンクリートをミキサー車から流し込む」
- 使い所: 1人のエンジニアが1日〜数日で完了できる作業サイズに落とし込むために使います。「Issue：Stripe連携」のなかに、「Sub-issue 1: SDKの導入」「Sub-issue 2: Webhookのエンドポイント作成」のようにぶら下げます。
- 設計のコツ: 「3階層以上深くしないこと」。Sub-issueの下にさらにSub-issueを作りたくなったら、それはプロジェクトの設計が細かすぎます。親イシューに昇格させましょう。
—
4. ハンズオン：最初の「HelloWorld」を形にしてみよう
理論はこれくらいにして、実際にLinear上でこの構造を作ってみましょう！
ここでは、架空のプロジェクトとして 「ユーザープロフィール機能の実装」 を組み立ててみます。
Step 1: Projectを作る
1. 左サイドバーの `Projects` の横にある `+` ボタンをクリック。
2. Project名に `ユーザープロフィール機能のリニューアル` と入力。
3. ターゲット日（期限）を適当に設定して作成します。
Step 2: Milestoneを作る
1. 作成したProjectのページを開きます。
2. `Milestones` タブ（またはセクション）を選択し、以下の2つを追加します。
- `Milestone 1: バックエンドAPIの実装`
- `Milestone 2: フロントエンド画面の実装`
Step 3: IssueとSub-issueを作る（ここがキモ！）
1. `Milestone 1` に対して、親となるIssueを作ります。
- Issueタイトル: `プロフィール画像のアップロード機能を作る`
2. このIssueを開き、説明欄の下にある `Add sub-issue` をクリックして、作業を分解します。
- Sub-issue 1: `S3バケットのCORS設定とIAM権限の付与`
- Sub-issue 2: `POST /api/upload のエンドポイント実装`
- Sub-issue 3: `画像バリデーション（サイズ・拡張子チェック）の追加`
これで、見事に「プロジェクト → マイルストーン → イシュー → サブイシュー」の綺麗な構造が完成しました！
—
5. ベテランがこっそり教える、現場で活きる運用の極意
最後に、この階層構造を現場に導入したときに、チームのベロシティを爆発させるための「極意」を3つ授けます。
1. 「迷ったら一番浅く」の原則
タスクを切るとき、「これ、サブイシューにした方がいいかな？」と迷ったら、それは単なるイシュー（Issue）として並列に並べるべきサインです。人間は複雑な階層を追うのが苦手です。フラットに書けるものはフラットに書きましょう。
2. Sub-issueの完了をチームの達成感にする
朝会（Standup）などで、「昨日、このサブイシューが完了して、親の進捗が50%を超えました！」という会話ができるようになると最高です。小さな勝利（Small Wins）を積み重ねることで、チームのモチベーションが自然と高まります。
3. Projectsのステータスを毎週更新する
Linearには、プロジェクトの健康状態を `On Track`（順調）、`At Risk`（懸念あり）、`Off Track`（遅延）で表す機能があります。毎週金曜日の終わりに、Projectオーナーがここを更新する習慣をつけるだけで、マネージャーからの「進捗どう？」という無駄なチャットが驚くほど減ります。
—
おわりに
LinearのProjects、Milestones、Sub-issuesの使い分け、いかがだったでしょうか？
最初は少しルールが多く感じるかもしれませんが、この構造はすべて「開発チームのメンタルモデルを軽くし、コードを書くことに集中するため」に存在しています。
これをマスターすれば、複雑なプロジェクトも恐れるに足りません。明日からのスプリント計画で、ぜひ試してみてくださいね。あなたのチームの開発体験が、ぐっと素晴らしいものになることを心から応援しています！