Linear 運用ハンドブック¶
複数プロダクトを扱う組織で Linear を正しく・一貫して運用するための社内ハンドブックです。 チームメンバー（経営・PdM・EM・開発・Design・GTM・CS）が読んで、そのまま実行できることを目的にしています。 Linear に詳しくない方でも、「なぜこの使い分けをするのか」が分かるように書いています。
なぜこのルールが必要か¶
私たちは Linear を次の目的で使います。
- 複数プロダクトのロードマップ管理
- 開発タスク・バグ・調査・実装作業の管理
- 顧客要望・営業要望・社内要望の整理
- 四半期目標・戦略テーマ・OKR との紐づけ
- 経営・PdM・EM・開発・Design・GTM・CS がそれぞれ必要な情報を見るための View 設計
複数プロダクトを 1 つの Linear で扱うと、各要素を「なんとなく」使い始めた瞬間に破綻します。 そこで、各要素の役割を 1 つに固定することを最重要原則とします。
最重要原則（迷ったらここに戻る）
| 要素 | 役割（これだけを表す） |
|---|---|
| Team | 誰がやるか（実働チーム） |
| Project | 何を出すか（リリース・機能・大きな成果物） |
| Initiative | なぜやるか（四半期目標・戦略テーマ・OKR） |
| Project Label | どのプロダクト・領域か |
| Timeline / Milestone | いつ・どの段階か |
| Issue | 具体的な作業 |
| Cycle | 今やる作業 |
| View | 誰が何を見るか |
最重要の注意：プロダクトを Team で表現しない
複数プロダクトを扱う場合、プロダクト軸は Team ではなく、原則として Project Label と View で表現します。 Team を「プロダクト」にしてしまうと、横断ロードマップ・共通基盤・チーム異動の管理がすぐ破綻します。 Team はあくまで「誰が実行するか」です（→ structure.md の Teams / Project Labels）。
全体構造¶
Workspace（組織全体で 1 つ）
└── Teams：実働チーム
└── Issues：個別タスク・バグ・調査・実装
Projects：リリース・機能・大きな成果物
└── Milestones：Discovery / Design / Build / Beta / GA など
Initiatives：四半期目標・戦略テーマ・OKR
Project Labels：Product / Area / Work type / Stage / Market などの分類
Views：プロダクト別ロードマップ・経営向け一覧・PM 用トリアージ など
- Workspace は組織で 1 つ。プロダクトごとに分けません。
- Team は実働チーム（Frontend / Backend / Design など）。「誰がやるか」。
- Issue は Team の中の具体的な作業。
- Project は「何を出すか」。複数 Issue・複数 Team にまたがる成果物。
- Milestone は Project の進行フェーズ（Discovery→GA）。
- Initiative は「なぜやるか」。Project を戦略目的に束ねる。
- Project Label は Project の分類（特に どのプロダクトか）。
- View は「誰が何を見るか」。役割別に必要な情報だけを抽出する。
このハンドブックの構成¶
| ドキュメント | 内容 |
|---|---|
| structure.md | Linear の各要素（Workspace / Team / Issue / Project / Milestone / Initiative / Project Label）の役割と使い分け |
| operating-rules.md | 迷ったときの判断ルール・命名ルール・最重要ルールの再掲 |
| views.md | View 設計方針と、作成する 6 つの標準 View・Timeline View の使い方 |
| routines.md | Triage / Product Review / Engineering Planning / Portfolio Review などの定例運用 |
迷ったら、まず operating-rules.md の「判断ルール」を見てください。 ほとんどの「これは Issue？ Project？」「Team？ Label？」はそこで解決できます。