Linear の構造と各要素の役割¶

このページでは、Linear の各要素を「何のために使うか」を 1 つずつ定義します。各要素の役割を固定することが、複数プロダクト運用を破綻させないための土台です。

1. 全体方針¶

Linear は次の構造で使います。各要素は役割を 1 つだけ持ちます。

Workspace
└── Teams：実働チーム
    └── Issues：個別タスク・バグ・調査・実装

Projects：リリース・機能・大きな成果物
└── Milestones：Discovery / Design / Build / Beta / GA など

Initiatives：四半期目標・戦略テーマ・OKR

Project Labels：Product / Area / Work type などの分類

Views：プロダクト別ロードマップ・経営向け一覧・PM 用トリアージ など

要素	役割	一言でいうと
Workspace	組織全体の入れ物	組織で 1 つ
Team	実働チーム	誰がやるか
Issue	個別の作業	具体的な作業
Project	リリース・機能・大きな成果物	何を出すか
Milestone	Project 内の進行フェーズ	どの段階か
Initiative	四半期目標・戦略テーマ・OKR	なぜやるか
Project Label	Project の分類（特にプロダクト）	どのプロダクト・領域か
View	役割別の情報抽出	誰が何を見るか

2. Workspace¶

Workspace は、原則として組織全体で 1 つとします。複数プロダクトを扱う場合でも、プロダクトごとに Workspace を分けません。

分けてしまうと、次の問題が起きます。

横断ロードマップが見づらくなる：全プロダクトを 1 枚で俯瞰できなくなる。
共通基盤・横断 Project を管理しづらくなる：認証基盤やデザインシステムなど、複数プロダクトに跨る取り組みの置き場が定まらない。
顧客要望・経営向けレポートが分断される：同じ顧客の要望が Workspace ごとにバラバラになる。
メンバー・権限・課金・通知が分散する：管理コストが増え、見落としが発生する。

プロダクトの違いは Workspace ではなく、Project Label と View（→ views.md）で表現します。

3. Teams¶

Team は、実際に作業を行う実働チーム単位で作成します。Team は「どのプロダクトか」ではなく、「誰が実行するか」を表します。

例：

Frontend
Backend
Mobile
Platform
Design
Growth
Data
QA

プロダクト A も B も、同じ Frontend / Backend チームが横断して関わることが普通です。そのため Team をプロダクト名にすると、1 人が複数 Team に分散したり、共通作業の置き場が決まらなかったりして破綻します。プロダクト軸は Project Label と View で表現してください。

例外：完全専任チームがある場合

あるプロダクトに 完全に専任の開発チームが存在する場合に限り、プロダクト名を Team 名にしても構いません。ただしこれは例外です。チームがプロダクトを跨いで動く可能性が少しでもあるなら、機能別 Team（Frontend / Backend …）にしてください。

4. Issues¶

Issue は、具体的な作業単位です。1 つの実行可能な作業を表します。

Issue に含めるものの例：

個別タスク
バグ修正
調査
実装
デザイン作業
レビュー
計測設定
ドキュメント更新

Issue には、可能な限り次の情報を設定します（後から View で正しく抽出するために重要です）。

項目	目的
Team	誰がやるか
Project	どの成果物の一部か
Priority	優先度
Status	進行状態
Assignee	担当者
Label	分類（プロダクト・領域・種別など）
Cycle	今サイクルで取り組むか
Due date	期限

Project 紐づけのルール

Project に関連する Issue は、必ず該当 Project に紐づけます。 紐づいていない Issue は、ロードマップや進捗 View に現れず「見えない作業」になります。

5. Projects¶

Project は、リリース・機能開発・大きな成果物を管理する単位です。Project は 「何を出すのか」を表します。

Project にするものの例：

新機能
大きな改善
リリース単位の取り組み
複数 Issue を含む開発
複数 Team にまたがる取り組み
移行作業
実験施策

Issue で十分なもの（Project にしない）の例：

軽微な修正
単発バグ
小さな調査
文言修正
1 人で完結する小タスク

判断に迷ったら：複数 Issue・複数 Team にまたがる／リリースの単位になるなら Project、1 つの作業で完結するなら Issue です。

Project 名の命名ルール¶

推奨形式は [Product名] - [成果物名] です。先頭にプロダクト名を置くことで、一覧や検索で「どのプロダクトか」が一目で分かります。

Product A - 新オンボーディング
Product B - 請求画面リニューアル
Admin - 権限管理 v2
Common - 認証基盤移行

（共通基盤・横断的な取り組みは Common - …、社内管理系は Admin - … のように、プロダクトに準じた接頭辞を付けます。）

6. Milestones¶

Milestone は、Project 内の進行フェーズを管理するために使います。Project 全体を細かい実行段階に分解し、「今どの段階か」「どこで止まっているか」を把握するためのものです。

標準 Milestone：

Discovery（課題・要件の探索）
Design（設計）
Build（実装）
Beta（限定公開・検証）
GA（一般提供）

必要に応じて、次も使えます。

Research（調査）
Validation（仮説検証）
Internal Test（社内テスト）
Launch（ローンチ）
Post Launch Review（ローンチ後の振り返り）

Milestone は「いつ・どの段階か」を表すものであり、個別 Issue の細かい実装状況を追う場所ではありません（それは Cycle / Backlog の役割です）。

7. Initiatives¶

Initiative は、四半期目標・戦略テーマ・OKR を管理する単位です。Initiative は 「なぜ今やるのか」を表します。複数の Project を、事業・プロダクト上の目的のもとに束ねます。

良い例（目的・成果を表す）：

Activation 改善
Enterprise readiness
解約率低下
Support cost reduction
新規収益源の立ち上げ

避ける例（プロダクト名・機能名そのもの）：

~~Product A~~
~~管理画面~~
~~検索機能~~

プロダクト名や機能名は Initiative ではありません。それらは Project（何を出すか）や Project Label（どのプロダクトか）で表します。 Initiative には 事業上・プロダクト上の目的を置いてください。

Initiative 名の命名ルール¶

形式は [年度・四半期] - [目的・戦略テーマ] です。

FY26 Q3 - Activation 改善
FY26 Q3 - Enterprise readiness
FY26 Q3 - Support cost reduction

8. Project Labels¶

Project Label は、Project を分類するために使います。特に 「どのプロダクトか」は Label で表現するのが本ハンドブックの中心方針です。

主に次の分類軸を用意します。

分類軸	目的	例
Product	どのプロダクトか	Product A / Product B / Product C
Area	どの機能領域か	Billing / Onboarding / Search / Permissions / Notification
Work type	どんな種類の仕事か	Feature / Experiment / Tech debt / Compliance / Migration
Stage	どの段階か	Discovery / Build / Beta / GA
Market	どの市場・対象か	SMB / Enterprise / Internal

プロダクト横断で見たいときは Label で抽出する

複数プロダクトを扱う場合、プロダクト軸は Project Label Product で表現します。「Product A のロードマップだけ見たい」「全プロダクトを横断で見たい」は、Team を分けるのではなく、 Product Label で Project をフィルタ・グループ化した View（→ views.md）で実現します。

次に読むべきページ：迷ったときの判断は operating-rules.md、見る仕組みは views.md です。