【実務・中級編】Linearでのイシュー階層管理：Projects、Milestones、Sub-issuesを正しく使い分ける設計思想 – プロジェクト・ナレッジ管理活用バイブル

【Linear極意】Projects、Milestones、Sub-issuesを極めろ：大規模開発を高速化する階層設計のアンチパターンと正解

プロダクト開発の現場において、ツールの選定以上に重要なのは「情報の構造化と認知負荷の最小化」だ。

Jiraの重厚長大なワークフローに疲弊したチームがLinearに移行したとき、その圧倒的な速度感と洗練されたUIに魅了される。しかし、プロダクトがスケールし、開発チームが拡大するにつれて、次のようなカオスに直面する。

「この巨大な機能開発、どこからどこまでが1つのイシューなんだ？」
「Projectsの中にMilestonesを入れたはいいが、進捗が全く見えない」
「Sub-issuesを切ったはいいが、親タスクのステータスと連動せず、誰も進捗を把握できない」

これらはツール側の問題ではない。Linearが持つ強力な階層概念（Projects、Milestones、Sub-issues）の「設計思想」を誤解していることによる構造的敗北だ。

今回は、数々の修羅場を潜り抜けてきたテックリードの視点から、Linearの真の実力を引き出し、チームのベロシティを限界突破させるための「イシュー階層管理の極意」を伝授する。

—

1. 階層の思想：何がどこに属すべきか

Linearにおけるオブジェクトの粒度を間違えると、途端に管理コストが跳ね上がる。まず、各レイヤーの「責務」を正確に定義しよう。

[ Projects ] -> 3ヶ月〜半年のビジネス目標・大型機能（例: 「Q3 決済基盤リプレイス」）
└── [ Milestones ] -> リリース可能なマイルストーン・フェーズ（例: 「Phase 1: DB移行」）
└── [ Issues ] -> 1人〜数人で数日〜1週間で完了する単位（例: 「ユーザーテーブルのマイグレーション」）
└── [ Sub-issues ] -> 1人が1日で終わらせる実装の細分化（例: 「カラムの型定義追加」）

Projects（プロジェクト）

責務: 期限（Target Date）とオーナー（Lead）を持ち、ビジネス上の価値単位でスコープを区切る。
アンチパターン: 「バグ修正全般」や「日常的な保守タスク」をProjectsにする。Projectsは原則として「終わりがあるもの」に限定する。

Milestones（マイルストーン）

責務: Project内部を時系列、あるいは機能単位で分割するための「中間ゴール」。
アンチパターン: すべてのイシューにMilestonesを紐付けようとする。単体のProjectが小さい場合、Milestonesは不要だ。大規模なProjectの「見通しを良くする」ためにのみ使う。

Sub-issues（サブイシュー）

責務: 1つのイシューを複数の担当者で分割する場合や、PR（プルリクエスト）を細かく分けたい場合の「チェックリスト以上の構造化」。
アンチパターン: 「とりあえず細かく切りたいから」と何でもかんでもSub-issuesにする。親イシューのステータス管理が複雑化し、かえって認知負荷が上がる。

—

2. ベロシティを劇的に高めるLinearの裏技（ショートカット & 設定）

ツールを使いこなすエンジニアは、マウスをほぼ触らない。Linearのポテンシャルを極限まで引き出すキーボードショートカットと、チーム全体で共有すべき設定ルールを紹介する。

爆速操作を実現する神ショートカット

`C` : どこからでも新規イシュー作成 (Create)
`G` -> `P` : Projects画面へ一瞬でジャンプ
`Cmd + K` (Mac) / `Ctrl + K` (Win) : コマンドパレット。ここに「Assign to me」「Change project」などを打ち込めば秒で処理が完了する。
`O` ➔ `I` : リスト表示からインラインでイシューを開く

チーム開発で絶対入れるべき「規約設定」

1. Parent Issueの自動ステータス連動ルール

Sub-issuesがすべて「Done」になったら、自動的に親イシューも「Done」にする、あるいはその逆のワークフローをチーム内で厳格化する。Linearの標準機能やAPI連携を使い、手動のステータス同期コストをゼロにする。

2. Project Updatesの定例化

Projectsには「Weekly Update」の機能がある。毎週金曜の終わりに、Project Leadが「On Track / At Risk / Off Track」のステータスと所感を必ず1行でも記載する文化を作る。これだけで、無駄な進捗確認ミーティングが消滅する。

—

3. 【実務設計】Linearをコードのように扱う設定ファイル・自動化のベストプラクティส

LinearはAPIや外部連携（GitHub, Slack等）が非常に強力だ。ここでは、チームの運用をコード化・自動化するための実践的な設定・構成例を提示する。

① GitHub Actions連携によるイシュー自動紐付けルール (`.github/workflows/linear-link.yml`)

コミットメッセージやPRのタイトルから、LinearのイシューID（例: `ENG-123`）を自動検出し、ステータスを連動させるためのベストプラクティス設定。

name: Linear Issue Linker & Validator

on:
pull_request:
types: [opened, edited, synchronize, closed]

jobs:
linear-sync:
runs-on: ubuntu-latest
steps:

name: Check PR Title for Linear Issue ID

uses: actions/github-script@v6
with:
script: |
const prTitle = context.payload.pull_request.title;
// ENG-123 のようなフォーマットを正規表現で検知
const linearIdRegex = /^[A-Z]+-\d+/;

if (!linearIdRegex.test(prTitle)) {
core.setFailed(“PRタイトルには必ずLinearのイシューID（例: ENG-123）を先頭に含めてください。”);
}

name: Update Linear Status on PR Merge

if: github.event.pull_request.merged == true
run: |
echo “PRがマージされました。Linear側のステータスを ‘In Review’ から ‘Done’ へ移行するAPIを叩きます。”
# ここにLinear GraphQL APIを叩くスクリプトや公式連携アクションを記述
# curl -X POST https://api.linear.app/graphql …

② チームのカスタムビュー設計（JSON構成概念）

Linearの「Custom Views」を活用し、テックリードやエンジニアが見るべきフォーカスを絞る。以下の条件をチーム共通のビューとして保存せよ。

「Blocking My Team」ビューの作り方
Filter: `Status` = `In Progress` AND `Blocked` = `true` AND `Team` = `Current Team`
意図: どこで開発が詰まっているかを朝会で真っ先に確認するためのビュー。
「Stale Issues」ビューの作り方
Filter: `Updated` > `14 days ago` AND `Status` NOT IN (`Done`, `Canceled`)
意図: 放置されたゾンビタスクを定期的に成仏させるためのビュー。

—

4. テックリードが守るべき「Linear運用の鉄則」

ツールは鏡だ。チームのコミュニケーション不全や設計の甘さは、そのままLinearのカオスとして現れる。

1. 「チケットがない仕事は存在しない」原則

口頭の雑談やSlackのDMで発生したタスクも、必ず数秒でLinearのインボックス（Triage）に放り込む。アジリティの源泉は「情報の集約」だ。

2. Sub-issuesは「他人に委譲できる粒度」で切れ

自分しか分からないサブタスクは、それはタスクではなく単なる「個人のメモ」だ。チーム全員が認知でき、誰にでもアサイン可能な粒度に昇華させよ。

3. Projectsのスコープクリープ（仕様肥大化）を防ぐ

途中から湧いて出た要件は、既存のProjectに安易にねじ込まず、「別Projects」として切り出すか、「次のMilestone」へ送る勇気を持つ。

Linearの階層設計を正しく行えば、プロダクトの現在地、ボトルネック、そして未来のロードマップが、ひと目でチーム全員の脳内に同期される。

今すぐチームのLinearを開き、カオスになっているProjectsやSub-issuesの棚卸しを行ってほしい。その数時間の整理が、数ヶ月後の開発スピードを何倍にも跳ね上げるはずだ。