【実務・中級編】Figma、Sentry、Notion…Linearと周辺ツールを連携させて開発エコシステムを統一する方法 – プロジェクト・ナレッジ管理活用バイブル

【Linear超連携】Figma・Sentry・Notionを束ね、開発エコシステムを極限まで加速させる「真の自動化」

優秀なエンジニアリングチームと、そうでないチームの決定的な違いは何か？
コードを書くスピードか？優れたアーキテクチャか？

答えは「文脈のスイッチングコスト（Context Switching Cost）」の総量にある。

Slackを行き交う「デザイン変わりました」「Sentryでエラー起きてます」「Notionの仕様書どこだっけ？」という雑音の海で、開発者は一日に何時間もの集中力を削り取られている。ツール間の連携が断絶しているとき、チームのベロシティは確実に死に向かう。

私はこれまで数々のアジャイルチームの生産性を診断・改善してきたが、Linearを中心に据えたエコシステムを構築した瞬間から、チームの熱量とスループットが劇的に変わるのを何度も目撃してきた。

今回は、LinearをハブとしてFigma、Sentry、Notionを完全に統合し、開発スピードを極限まで高めるための「プロの実践テクニック」をすべて公開しよう。

—

1. 開発エコシステムの設計思想：なぜLinearを「中心」に据えるのか？

Jiraの重厚長大さに疲弊したチームがLinearに移行する理由は、単にUIが軽快だからではない。「エンジニアの認知負荷を最小化し、フロー状態を維持する」という徹底した設計思想に共鳴しているからだ。

Linearを中心にしたエコシステムでは、すべての外部イベント（デザイン変更、エラー検知、仕様策定）が「アクション可能なイシュー」として一元化されなければならない。

[Figma] ──(デザイン確定)──┐
│
[Sentry] ──(エラー検知)──┼──> [ Linear (Hub) ] ──> [ 開発者のフロー状態 ]
│ │
[Notion] ──(要件定義)────┘ └─────> [Slack (双方向同期)]

情報がプッシュ型で流れてくるだけのSlack通知は「騒音」にすぎない。ツール間をシームレスに繋ぎ、「知るべき人が、知るべきタイミングで、文脈を失わずにイシューにアクセスできる状態」を作るのが本稿の目的だ。

—

2. Figma × Linear：デザインとコードの断絶を消し去る

「デザインのどこが変わったのか分からない」「Figmaのコメント欄で議論が分散する」。この非効率を根絶する。

公式インテグレーションの活用

LinearのFigma連携を有効にすると、イシューにFigmaのURLを貼り付けるだけで、プレビュー表示と最新のステータス（In progress, Ready for devなど）がリアルタイム同期される。

プロが実践するワークフロー

1. デザイナーがFigma上でセクションを「Ready for dev」に変更。
2. LinearのAutomation機能を用い、Figmaリンクが含まれるイシューのステータスを自動で `In Review` や `Ready` に移行。
3. エンジニアはLinear上でFigmaのサムネイルを確認し、ワンクリックで該当フレームへジャンプ。

> 💡 テックリードの知見:
> Figmaのコメントで仕様の議論を完結させてはならない。「デザインに関する意思決定のログ」は必ずLinearのコメントに残す。FigmaはあくまでUIの表現媒体であり、真実のソース（Source of Truth）は常にLinearのイシューにあるべきだ。

—

3. Sentry × Linear：エラーを「見なかったこと」にさせない自動起票

プロダクション環境のエラー（Sentry）をSlackに流し込んで放置していませんか？「あとで対応する」と言って流れていったエラーは、二度と日の目を見ない。

SentryとLinearを直結させ、「未対応のエラー＝必ずLinearのバックログにある状態」を強制する。

Sentry側の設定とベストプラクティス

Sentryの「Alerts」機能から、Linearへの自動連携ルールを設定する。すべてのエラーで起票するとノイズになるため、以下のフィルタリングを必ず入れる。

発生頻度（1時間に10回以上） または 影響を受けるユーザー数 が閾値を超えた場合のみ起票。
環境（Environment）が `production` のものに限定。

チーム開発で役立つ「Sentry → Linear」マッピング設定例

Sentryのインテグレーション設定における、最適なイシュー自動生成のメンタルモデル：

Team / Project: バックエンドチームなら `Backend` プロジェクトへ直行。
Label: 自動で `bug` および `sentry` タグを付与。
Priority: スタックトレースの重要度やSentryのLevel（Error / Fatal）に応じて、Linearの `Urgent` または `High` を動的割り当て。

これで、朝会での「このエラー何でしたっけ？」という不毛な確認時間がゼロになる。

—

4. Notion × Linear：ドキュメントのサイロ化を防ぐ双方向リンク

「Notionに仕様書を書いたが、開発者は誰も読んでいない」「Linearのイシューを見ても、前提となる要件定義の背景（Why）が分からない」。これを解決するのがNotionとLinearの有機的結合だ。

理想的なドキュメント・イシュー構造

1. Notion: プロダクトの要件定義書（PRD）、デザインドキュメント、アーキテクチャ決定レコード（ADR）を格納。
2. Linear: PRDをベースにブレイクダウンされた具体的なタスク（実装、テスト、マイグレーション）を切る。

NotionのデータベースからLinearイシューを直接生み出す

Notion側のインテグレーションを使い、要件定義書のページ内にLinearのウィジェットを埋め込む、あるいはNotionのデータベースのプロパティからLinearのイシューを直接作成・リンクする。

これにより、「なぜこのコードを書いているのか（NotionのPRD）」と「何をすればいいのか（Linearのイシュー）」が双方向で完全にリンクする。新メンバーがアサインされた際も、Notionの親ページからLinearのタスク群を辿るだけで、開発文脈のすべてを数分でキャッチアップできるようになる。

—

5. 開発スピードを極限まで高める：Linearの神機能とショートカット

ツール連携の土台ができたら次は個人の速度、すなわち「指をキーボードから離さないこと」だ。マウスに手を伸ばした瞬間、エンジニアの集中力は途切れる。

現場で即座に使うべき「神」キーボードショートカット

今すぐ覚えるべきショートカットを厳選した。

チームの規律を生む「設定の共有化ルール」

個人の好みに委ねてはならない。チームとしてベロシティを最大化するためのLinear設定ルールを策定せよ。

1. カスタムステータスの最小化: `Backlog`, `Todo`, `In Progress`, `In Review`, `Done`, `Canceled` の基本6つ以外は原則作らない。複雑なステータスは「プロセスが機能していない」証拠。
2. サイクルの厳守: 1週間または2週間の「Cycle（スプリント）」を必ず回し、未完了のイシューは自動的に次サイクルへ持ち越す（Rollover機能の活用）。
3. Labelsの統一: `bug`, `enhancement`, `tech-debt`, `security` などのグローバルラベルの色と定義をチーム間でドキュメント化し、完全統一する。

—

6. 実戦投入：今すぐ使える設定ファイル・自動化レシピ

理論はここまでだ。最後に、あなたのチームの開発エコシステムを今すぐ実戦レベルに引き上げるための設定ファイル群を贈る。

1. GitHub Actions: PRとLinearイシューの完全同期

プルリクエストが作成されたらLinearのステータスを自動で `In Review` にし、マージされたら `Done` にするワークフロー（`.github/workflows/linear-sync.yml`）。これぞ自動化の真骨頂だ。

name: Sync Linear Issue Status

on:
pull_request:
types: [opened, closed, reopened]

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

name: Extract Linear Issue ID from Branch Name

id: extract_issue
uses: actions/github-script@v7
with:
script: |
const branch = context.payload.pull_request.head.ref;
// ブランチ名が feature/ENG-123-add-login のような形式であることを想定
const match = branch.match(/([A-Z]+-[0-9]+)/);
if (match) {
core.info(`Found Linear Issue ID: ${match[1]}`);
core.exportVariable(‘LINEAR_ISSUE_ID’, match[1]);
} else {
core.setFailed(‘No Linear Issue ID found in branch name.’);
}

name: Update Linear Issue Status (In Review)

if: github.event.action == ‘opened’
uses: linear-app/linear-action-update-status@v1 # ※概念的なアクション表現
with:
api-key: ${{ secrets.LINEAR_API_KEY }}
issue-id: ${{ env.LINEAR_ISSUE_ID }}
status: ‘In Review’

name: Update Linear Issue Status (Done)

if: github.event.action == ‘closed’ && github.event.pull_request.merged == true
uses: linear-app/linear-action-update-status@v1
with:
api-key: ${{ secrets.LINEAR_API_KEY }}
issue-id: ${{ env.LINEAR_ISSUE_ID }}
status: ‘Done’

※注: 実際のAPI連携にはLinearのGraphQL APIを叩くカスタムスクリプトやサードパーティ製Actionを使用してください。ブランチ名にイシューIDを含める命名規則（例: `feature/ENG-123-fix-bug`）の徹底が前提条件となります。

2. Linear Webhook (JSON): Slackへの高度な通知フィルタリング

LinearのイベントをカスタムWebhookで受け取り、特定の重要度（Urgent等）のみを専用のSlackチャンネルに飛ばすためのペイロード構成例。

{
“action”: “create”,
“type”: “Issue”,
“createdAt”: “2023-10-25T10:00:00.000Z”,
“data”: {
“id”: “uuid-string-here”,
“identifier”: “ENG-456”,
“title”: “決済APIでタイムアウト頻発”,
“priority”: 1,
“priorityLabel”: “Urgent”,
“state”: {
“name”: “Todo”,
“type”: “unstarted”
},
“assignee”: {
“name”: “Taro Engineer”
},
“url”: “https://linear.app/your-team/issue/ENG-456”
},
“url”: “https://linear.app/your-team/issue/ENG-456”
}

テックリードの解説: `priority: 1`（Urgent）のイベント検知時のみ、このJSONペイロードをAWS LambdaやZapier等を経由してSlackの `#alert-critical` に直撃させ、オンコールメンバーのスマホを鳴らす仕組みを構築せよ。

—

結び：ツールに踊らされるな、ツールを統べれ

Linear、Figma、Sentry、Notion。これらは単なる「便利なSaaSの寄せ集め」ではない。

正しく結合されたとき、これらはチームの脳みそを拡張する「一つの巨大な神経系」として機能する。デザインの変更が瞬時にタスクになり、本番のエラーがエンジニアのバックログを叩き、要件定義の文脈がコードの隅々にまで行き渡る。

無駄な会議や、ツールの海を泳ぐためのサーフィンはもう終わりにしよう。
今日からこのエコシステムを構築し、チームのベロシティを「限界突破」させてほしい。