View 設計と標準 View¶

10. View 設計方針¶

複数プロダクトを扱う場合、全員が同じ一覧を見る必要はありません。役割ごとに必要な情報が違うからです。経営は全社の投資配分を、開発チームは今サイクルの Issue を、CS は顧客要望を見たい——同じ生データでも、見たい切り口は異なります。

そこで、Linear の Custom View を使い、Issue / Project / Initiative をフィルタして目的別の View を作ります。プロダクト軸も、Team を分けるのではなく View（＋ Project Label）で表現します。

View は次の方針で作成・共有します。

経営・PdM・EM 向け：全社横断の状況を見る
各プロダクトチーム向け：自分たちのプロダクトを見る
PM 向け：要望や優先度を整理する
開発チーム向け：今やる Issue を見る
GTM・CS 向け：顧客要望やリリース予定を見る

11. 作成する標準 View（6 種）¶

以下の 6 つを標準 View として用意します。View 名は「対象者と用途が分かる名前」にします（→ operating-rules.md の命名ルール）。

1. 全社プロダクトポートフォリオ¶

全社の Project を横断的に確認するための、最上位の俯瞰 View です。

目的：全社の Project を横断的に確認する
対象：Projects
Filter：Status = Active / Planned
Group by：Product（Project Label）
Display：Timeline
主な利用者：経営 / PdM / EM / 事業責任者
用途：
- 全プロダクトの進行状況を確認する
- 四半期の投資配分を見る
- 進行中・計画中の Project を一覧する
- プロダクト間の優先度を調整する

2. Product 別 Roadmap¶

特定プロダクトの Project だけを見る View です。プロダクトごとに 1 つ作成します（Product A / B / C …）。

目的：特定プロダクトの Project だけを確認する（例：Product A Roadmap）
対象：Projects
Filter：Project Label: Product = Product A
Display：Timeline
主な利用者：当該プロダクトの PM / デザイナー / 開発チーム / GTM / CS
用途：
- そのプロダクトのロードマップを見る
- 今後のリリース予定を確認する
- 進行中 Project のフェーズ（Milestone）を確認する
- 関係者間で優先順位を揃える

Product B・Product C についても、同じ要領で Product B - Roadmap / Product C - Roadmap を作成します。

3. Initiative 別ロードマップ¶

戦略テーマ・OKR の単位で Project を確認する View です。Initiative ごとに作成します。

目的：戦略テーマや OKR 単位で Project を確認する
対象：Projects
Filter：Initiative = 任意の Initiative
Display：Timeline
Initiative 例：Activation 改善 / Enterprise readiness / コスト削減 / 解約率低下 / 新規収益源の立ち上げ
主な利用者：経営 / PdM / EM / 事業責任者 / OKR オーナー
用途：
- OKR に紐づく Project を確認する
- 四半期計画の進捗を見る
- 戦略テーマごとの投資状況を把握する
- Project の継続・延期・中止を判断する

4. PM Triage / Intake¶

新規要望やフィードバックを受け付け、整理する入口の View です。

目的：新規要望・フィードバックを受け付け、整理する
対象：新規要望 / 顧客要望 / 営業要望 / CS フィードバック / 社内改善要望 / 未分類の Issue
主な利用者：PM / PdM / EM / CS / Sales / Support
用途：新規 Issue の確認 / 要望の分類 / 重複の整理 / Backlog 入りの判断 / Project 化の判断 / 優先度付け

運用ルール：Triage に入った Issue は、PM または担当者が確認し、次のいずれかに分類します。

分類	意味
Accept	対応対象にする
Duplicate	既存 Issue に統合する
Decline	対応しない
Snooze	後で再確認する
Backlog	将来対応候補にする
Project 化	大きな成果物として管理する

Triage 未通過の Issue は Cycle に入れない

Triage を通過していない Issue は、原則として Cycle に入れません。未整理の要望がそのまま実装サイクルに紛れ込むのを防ぎます。

5. Blocked / At risk¶

進行リスクのある Issue / Project を横断的に確認する View です。

目的：進行リスクのある Issue / Project を横断的に確認する
対象：Issues / Projects
Filter 例：Blocked / High priority / Urgent / Due soon / At risk
主な利用者：PM / EM / Tech Lead / PdM / 経営
用途：詰まっている作業の確認 / リリース遅延リスクの把握 / 優先度の高い問題の早期発見 / 週次プロダクト会議での確認

運用ルール：週次のプロダクト会議では、必ずこの View を確認します。Blocked または At risk の Project については、次を明確にします。

何が原因か
誰が解消するか
いつまでに判断するか
スコープ調整が必要か
リリース時期に影響があるか

6. Customer-backed work¶

顧客要望に紐づいた Issue / Project を確認する View です。B2B では優先度判断の重要材料になります。

目的：顧客要望に紐づいた Issue / Project を確認する
対象：顧客要望が紐づいた Issue / 顧客要望から作成された Project / 売上影響のある要望 / Enterprise 顧客からの要望 / 複数顧客から繰り返し出ている要望
主な利用者：PM / CS / Sales / GTM / 経営
用途：顧客要望に基づく開発の確認 / 売上・契約更新に影響する要望の把握 / Enterprise 顧客向け対応の管理 / 同一要望が複数顧客から出ていないかの確認

運用ルール：顧客要望に紐づく Issue / Project には、可能な限り次の情報を付与します。

顧客名
顧客 Tier
契約規模
要望の背景
業務上の困りごと
関連する商談または更新タイミング
対象プロダクト
関連 Project

B2B では優先度判断の重要材料

B2B プロダクトでは、この View を優先度判断の重要な材料として使います。「売上・更新に効く要望か」「複数顧客に共通か」を、ここで定量的に見えるようにします。

12. Timeline View の使い方¶

Timeline View は、高レベルな Project 計画・ロードマップを可視化する場所です。細かい Issue の実装状況を見る場所ではありません。Project 単位で、次を確認します。

いつ開始するか
いつ完了予定か
現在どのフェーズか（Milestone）
他 Project と時期が重なっていないか
重要リリースがいつあるか
四半期内に収まっているか

複数プロダクトを扱う場合、Timeline View は次の用途で使います。

全社ロードマップ
プロダクト別ロードマップ
Initiative 別ロードマップ
四半期計画
経営向け進捗確認

細かい進捗は Cycle / Backlog で

Issue の細かい進捗確認は Timeline ではなく、各 Team の Cycle / Backlog で行います。 Timeline は「Project がいつ・どの段階か」、Cycle は「今サイクルで誰が何をやるか」と役割を分けます。