Linear無料プランの限界突破：小規模チームのベロシティを極限まで高めるアップグレード戦略
こんにちは。数々の修羅場をくぐり抜けてきたテックリードの私だ。
開発チームの生産性を語る時、ツールの選定はエンジニアリングそのものと同義である。Jiraの重さに殺され、GitHub Issuesの単機能さに泣かされていた我々の救世主、それが「Linear」だ。
「モダンで、圧倒的に速い」。その評判を聞きつけ、まずは無料プラン（Free Plan）から導入を検討するチームは多いだろう。しかし、コストパフォーマンスを気にするあまり、「無料の限界を知らずにスケールさせ、気づいた時には技術的負債ならぬ管理の負債に溺れている」チームを私は数多く見てきた。
結論から言おう。Linearの無料プランは、単なる「お試し版」ではない。正しく使い倒せば、3〜5人の精鋭チームで数ヶ月間、プロダクトを高速で市場に送り出すための十分すぎる武器になる。
今回は、Linearの無料プランのリアルな限界値を見極めつつ、開発スピードを極限まで高めるためのキーボードショートカット、神インテグレーション、そしてチームのサイロ化を防ぐ設定の極意を、プロの実践知見として余すことなく伝授する。
—
1. Freeプランの全仕様と「見落としがちな罠」
まずは現実を直視しよう。LinearのFreeプランで何ができて、何ができないのか。表面的な機能一覧ではなく、実際の開発現場でどこにボトルネックが生まれるのかを解説する。
Freeプランの主要制限事項
1. メンバー数: 無制限（ただし、アクティブなコントリビューター数ではなく、チーム全体の規模感として小規模なうちは問題にならない）
2. ストレージ容量: 合計 250MB（1ファイルあたりの上限も設定される）
3. ワークフローとラベル: カスタマイズ可能だが、一部高度な自動化（Workflow Automation）に制限あり
4. ゲスト（Guest）アカウント: 基本的に利用不可（外部ステークホルダーの招待制限）
5. インサイト（Analytics）: 基本的なバーンダウンチャートやサイクルタイムはあるが、高度なクロスチーム分析やエクスポート機能は制限される
「250MBのストレージ制限」という最大のトラップ
「テキストベースのタスク管理に250MBもあれば十分だろ」と思ったそこのあなた。甘い。
現代の開発において、Issueへのスクショ、エラーログのGIFアニメ、Figmaの切り抜き、コンパイルエラーのスタックトレース画像などの添付は、仕様共有の生命線だ。
これをそのままLinearに貼り付けていると、数ヶ月でストレージ上限（250MB）に到達し、新しい画像をアップロードできなくなる。
対策：
- 画像は外部CDNやGyazo/CloudApp等に逃がす、あるいはマークダウンのリンクで貼る癖をつける。
- 定期的に古いIssueの添付ファイルを精査する（が、ぶっちゃけ面倒なので、有料プランへの移行シグナルと捉えるべきだ）。
—
2. ベロシティを劇的に高める！プロのLinear操作術
ツールがどれだけ軽快でも、マウスに手を伸ばしている時点でエンジニアの思考のフロー状態（ゾーン）は途切れる。Linearの真骨頂は、「マウスを一切触らずに完結するキーバインド」にある。これらをチーム全員の共通言語にしろ。
開発スピードを3倍にする隠れたキーボードショートカット
| アクション | ショートカット (Mac / Windows) | プロの解説 |
| :— | :— | :— |
| クイック追加 | `C` | どこにいても一瞬でIssue作成モーダルを開く。思考を止めずにタスク化。 |
| コマンドメニュー | `Cmd + K` / `Ctrl + K` | 全機能へのアクセスハブ。迷ったらこれを開いてインクリメンタルサーチ。 |
| 担当者のアサイン | `I` | Issue詳細画面で自分をアサインする最速のキー。 |
| ステータス変更 | `S` | Backlog → In Progress → Done への遷移をキーボードだけで完結。 |
| ラベルの付与 | `L` | バグ、機能追加などのコンテキストを瞬時に付与。 |
| ビューの切り替え | `G` then `I` (Issues) / `G` then `V` (Views) | リスト、ボード、ロードマップ間の移動。`G`（Go to）プレフィックスを覚えろ。 |
—
3. 絶対に入れるべき「神プラグイン」と連携術
Linear単体でも強力だが、外部ツールとエコシステムを構築することで、情報のサイロ化を完全に破壊できる。
1. GitHub / GitLabインテグレーション
これなしにLinearを使う意味はない。
- PR連携: ブランチ名に `ENG-123`（Issue ID）を含めてコミット・PRを作成するだけで、Linear側のステータスが自動で「In Review」や「Done」に遷移する。
- メリット: 「誰がどのコードを書いて、どのタスクに紐づいているか」のトレーサビリティが100%担保される。
2. Slackインテグレーション
- 通知の双方向制御: Slackのチャンネルから直接Issueを作成したり、ステータス変更を通知・スレッドで議論できる。
- Triage（トリアージ）の徹底: サポートや他部署から降ってきた雑多な要望をSlack経由でLinearのTriageキューに放り込み、スプリントプランニングで精査するフローを確立する。
—
4. チーム開発で役立つ「設定の共有化ルール」
小規模チームであっても、ルールの明文化とシステムの共通化を怠ると、すぐにカオスと化す。以下のルールをチームの憲法として設定せよ。
1. Issueの粒度（Sizing）の統一
- ストーリーポイント（Fibonacci: 1, 2, 3, 5, 8）を必ず設定する。
- 「1人称で1〜2日で終わる粒度（最大でも5）」に分割する。それ以上はEpicか親タスクにぶら下げる。
2. Triage（要仕分け）プロセスの義務化
- 外部からの起票はすべて「Triage」に入るように設定し、テックリードまたはプロダクトオーナーが毎日15分、適切なサイクル（Cycle）に振り分ける。
3. サイクル（スプリント）の期間固定
- 1週間または2週間の固定サイクルを回す。金曜の夕方に振り返り（Retro）を行い、未完了タスクの次サイクルへの持ち越しを機械的に行う。
—
5. 実用的な設定ファイル（YAML/JSON）のベストプラクティス構成例
Linear自体はWeb UI中心のSaaSだが、開発プロジェクト全体のメタデータ管理や、GitHub ActionsなどのCI/CD、issueテンプレートとの連携において、設定のコード化（GitOps的アプローチ）は極めて有効だ。
以下に、チームでLinear運用を標準化するための GitHub Issue Template (`ISSUE_TEMPLATE.yml`) と、プロジェクト管理をコード管理するための設定例を提示する。これによって、ユーザーがGitHubでIssueを切った際にもLinearの規則に強制的に従わせることができる。
`/.github/ISSUE_TEMPLATE/bug_report.yml`
（Linearとの連携をスムーズにするための、構造化バグ報告テンプレート）
name: 🐛 バグ報告 (Bug Report)
description: プロダクトの不具合を報告し、Linearへ正確に同期させます。
title: “[Bug]: ”
labels: [“bug”, “triage”]
body:
- type: markdown
attributes:
value: |
日々の品質向上のご協力ありがとうございます。以下の項目を埋めて起票してください。
このテンプレートは自動的にLinearのTriageキューに同期されます。
- type: textarea
id: what-happened
attributes:
label: 不具合の状況 (What happened?)
description: 何が起きたのか、簡潔に記述してください。
placeholder: 例: ログイン画面でエンターキーを押すと、ローディングが無限ループする。
validations:
required: true
- type: textarea
id: reproduction
attributes:
label: 再現手順 (Steps to Reproduce)
description: バグを再現するための手順をステップバイステップで。
placeholder: |
1. ログイン画面（ /login ）を開く
2. メールアドレスとパスワードを入力
3. キーボードの「Enter」を押下
validations:
required: true
- type: dropdown
id: environment
attributes:
label: 発生環境 (Environment)
options:
- Production (本番環境)
- Staging (ステージング環境)
- Development (ローカル/開発環境)
validations:
required: true
- type: textarea
id: logs
attributes:
label: エラーログ・コンソール出力 (Logs / Screenshots)
description: 可能な限り、スクリーンショットやコンソールエラーを貼り付けてください（※Linearのストレージ制限に注意し、URLを推奨）。
placeholder: “Paste any relevant logs here.”
validations:
required: false
—
6. 有料プラン（Standard / Plus）へアップグレードすべき「明確なタイミング」
では、無料プランから有料プラン（Standard: 月額$8〜/ユーザー、Plus: 月額$14〜/ユーザー等）へ移行すべきシグナルはどこにあるのか。経営陣やチームメンバーを納得させるための具体的な判断基準を授けよう。
1. ストレージの壁にぶつかった時（250MBの突破）
先述の通り、添付ファイルの容量制限（250MB）に達し、毎回のスクショ共有にストレスを感じ始めた瞬間が、最初の経済合理的な移行タイミングである。開発者の手戻り時間（時給換算）コストを考えれば、月額数ドルなど秒で回収できる。
2. 外部ステークホルダー（顧客・外部パートナー）との協業が必要になった時
Freeプランには「ゲストアカウント」の概念がない。クライアントや外部の業務委託（業務パートナー）にプロジェクトを見せたい、または一部のタスクだけアサインしたい場合、メンバーとしてフル権限で招待するしかなく、セキュリティ上またはライセンス上のリスクになる。
- Standardプラン以上のメリット: 閲覧専用のゲスト（Guest）を無料で無制限（または一定枠）招待できるようになり、セキュリティ境界を綺麗に引ける。
3. 高度なワークフロー自動化とサイクル分析が欲しくなった時
チームが10人を超え、複数のサブチームに分かれた瞬間、デフォルトのビューだけでは全体像が見えなくなる。
- Cross-team Initiatives（イニシアチブ）: 複数チームにまたがる大型プロジェクトの進捗管理。
- Advanced Insights: サイクルタイム（Cycle Time）、リードタイム（Lead Time）、スコープクリープ（Scope Creep）の高度なメトリクス分析。
- これらが経営層やEM（エンジニアリングマネージャー）から求められた時が、迷わずPlusプラン（またはStandard）へスケールアップするべきタイミングだ。
—
まとめ：小さく産んで、高速でスケールせよ
Linearの無料プランは、小規模チームにとって最高のスタートダッシュを切るためのエンジンである。
しかし、ツールはあくまで手段。重要なのは、「キーボードショートカットを身体に叩き込み、GitHub/Slackと緻密に連携させ、無駄なコンテキストスイッチをゼロにする」という開発文化そのものだ。
無料プランの制限（250MBのストレージやゲスト権限など）を逆手に取り、情報の密度を高め、本当に有料プランが必要になった時（＝チームとプロダクトが急成長した証明）に、迷わず投資を決断せよ。
あなたのチームのベロシティが、今日から劇的に跳ね上がることを期待している。