【実務・中級編】【完全版】Linearのキーボードショートカット一覧！マウス操作を無くして開発スピードを3倍にする方法 – プロジェクト・ナレッジ管理活用バイブル

【完全版】Linearのキーボードショートカット一覧：マウス操作を無くして開発スピードを3倍にする方法

テックリードの私たちが日々の開発において最も忌むべきもの、それは「マウスへの持ち替え」という致命的なコンテキストスイッチだ。

思考のフロー状態に入り込み、コードの迷宮を突き進んでいる最中に、「あ、このバグのチケット切っとかなきゃ」「ステータスをDoneに変えなきゃ」とマウスに手を伸ばす。あの瞬間、脳内で築き上げたアーキテクチャの構築は音を立てて崩れ去り、再び元の集中状態に戻るまでに膨大な cognitive load（認知負荷）を支払うことになる。

Jiraの重厚長大なUIに絶望し、GitHub Issuesの簡素さに物足りなさを感じていた我々の救世主、Linear。このツールの真の破壊力は、その圧倒的なレンダリング速度と、「指をホームポジションから一歩も離さずに完結するキーボード駆動型オペレーション（Keyboard-Driven Operations）」にある。

本記事では、Linearのポテンシャルを極限まで引き出し、開発チームのベロシティを物理的・精神的に3倍へと跳ね上げるための「究極のショートカット体系」と「現場で即効性のある実践知」を叩き込む。

—

1. 思考を止めない：指先で世界を操る基本ショートカット網羅

まずは、エディタからLinearへ、Linearからエディタへと、脳のスイッチングコストをゼロにするための基本コマンドだ。VimやVS Codeのキーバインドに慣れ親しんだエンジニアであれば、数時間で筋肉に刻み込まれるはずだ。

🧭 ナビゲーション（どこへでも一瞬で跳ぶ）

マウスでサイドバーのプロジェクトやチームを行き来しているようでは、プロとは言えない。`G`（Go）に続く2ストロークキーで、瞬時に目的地へワープしろ。

> 💡 テックリードの極意：`Cmd + K` は思考の拡張である
> すべてのショートカットを暗記する必要はない。迷ったら `Cmd + K`（Windowsは `Ctrl + K`）を叩き、曖昧な検索ワード（例：「auth refactor」など）を入力すればいい。検索、移動、作成、アサインのすべてがこのコマンドパレット内で完結する。

—

2. 爆速チケット起票・編集の裏技

バグを発見した瞬間、あるいはミーティング中にタスクが降ってきた瞬間、0.5秒でチケットを生み出すためのフローだ。

✍️ イシューの作成・操作

⚡️ インスタント・アクション（イシューを選択した状態で叩く）

リスト上でイシューにフォーカス（または選択）した状態で、以下のキーを押すだけで、モーダルすら開かずにメタデータを書き換えられる。

| ショートカット | 動作 |
| :— | :— |
| `A` | 担当者（Assignee）の変更 |
| `P` | 優先度（Priority: Urgent / High / Medium / Low）の変更 |
| `S` | ステータス（Todo / In Progress / Done等）の変更 |
| `L` | ラベル（Labels）の付与・剥奪 |
| `T` | 期限（Due date）の設定 |
| `I` | 親イシュー（Parent issue）やプロジェクトの紐付け |

【実践フロー例】
バグ修正のPRを出し終えた：
1. `G` → `A` で自分のタスク一覧へ。
2. 対象のイシューにカーソルを合わせ、`S` を押して `In Review`（または `Done`）へ変更。
3. `Space` で詳細を開き、PRのURLをサクッと貼り付けて `Esc`。
この一連の動作、マウスに一度も触れておらず、所要時間わずか2.5秒だ。

—

3. 開発スピードを3倍にする「神プラグイン・連携」の極意

ショートカットだけに頼るな。LinearはそのAPIエコシステムと外部ツール連携によって真価を発揮する。チーム全体のベロシティを底上げする、絶対に導入すべきインテグレーションと拡張機能を紹介する。

🔌 1. GitHub / GitLab 連携（双方向の完全同期）

これなしにLinearを使う意味はない。プルリクエストのタイトルやブランチ名にイシューID（例: `ENG-123`）を含めるだけで、以下の自動化が走る。

PR作成時にLinearのステータスが自動で `In Progress` になる。
PRがマージされたら、Linearのイシューが自動で `Done` にクローズされる。
Linearのイシュー画面から、紐づくPRのビルドステータス（CI/CDの成功・失敗）が一目でわかる。

設定ルール：
チーム全員のGitコミットメッセージやPR名に必ず `[ENG-XXX]` を含めるフック（GitHub ActionsやHusky等でのバリデーション）を義務付けろ。これにより、進捗更新の「人間による手作業」が完全に消滅する。

🧩 2. Raycast 連携（Macユーザー必携のランチャー拡張）

Macを使用しているエンジニアであれば、AlfredやSpotlightの代わりにRaycastを導入しているはずだ。Linear公式のRaycast拡張機能は、ブラウザを開くことすら面倒くさい我々のための最終兵器である。

コマンド例： `Raycast` から `Create Linear Issue` を呼び出し、デスクトップのどこにいても数キー入力するだけでバックログにタスクを放り込める。
メリット： ブラウザのタブをLinearに切り替える必要すらない。

🤖 3. Linear × Slack 連携（双方向メンションと簡易起票）

Slackのチャンネルで「これバグじゃない？」という議論になった時、わざわざLinearを開いて起票していませんか？

Slackのメッセージの「…」メニューから “Create Issue” を選択するだけで、その文脈（スレッドのURL等）を引き継いだままLinearのイシューが即座に生成される。
また、Linear側でメンションされたりステータスが動くと、Slackの専用チャンネル（またはDM）に通知が飛び、Slack上から直接コメントを返信できる。

—

4. チーム開発でナレッジを殺さない「設定共有化ルール」

どれだけ個人のショートカットスキルが高くても、チーム全体のチケットの切り方やワークフローがバラバラでは、情報のサイロ化が起き、ベロシティは落ちる。テックリードが主導してチームに強制すべき「Linearガバナンスのルール」を定義する。

📋 ワークフロー（Workflow）の厳格化

デフォルトのステータス（Backlog, Todo, In Progress, In Review, Done, Canceled）を勝手に増やすな。チームの認知負荷を下げるため、ステータスは以下の5段階に厳格に絞る。

1. Backlog / Triage: 未着手・要精査。プロダクトマネージャー（PM）やテックリードがトリアージする場所。
2. Todo: 今スプリントで着手するもの。
3. In Progress: 現在まさにコードを書いている状態（原則、1人につき同時に持てるのは最大2つまで）。
4. In Review: PRを出し、レビュアーをアサインしている状態。
5. Done: マージされ、検証環境（または本番）にデプロイされた状態。

🏷️ ラベル（Labels）とプロジェクト（Projects）の命名規則

カオスを防ぐため、ラベルは以下のプレフィックスルールを徹底する。

`bug` : 不具合修正
`refactor` : 技術的負債の返済・コード構造改善
`feature` : 新機能開発
`infra` : インフラストラクチャ・CI/CD関連
`spike` : 調査・検証タスク（タイムボックスを必ず設定すること）

—

5. 【実践】チーム標準化のための設定ファイル・ベストプラクティス

Linear自体はWebベースのSaaSであり、Kubernetesのようにリポジトリに直接YAMLを置くネイティブな設定ファイル機構はない。しかし、Linear API (GraphQL) や GitHub Actions / Linear CLI を用いることで、プロジェクトテンプレートやチーム設定をコードとして管理（As-Code）し、自動プロビジョニングすることが可能だ。

ここでは、チームの新プロジェクト立ち上げ時に、一貫したイシューテンプレートやマイルストーンを自動生成するための GitHub Actions ワークフロー（YAML） と、Linear APIに投げるための GraphQLクエリのサンプル を提示する。

🛠️ 1. 自動イシューテンプレート生成スクリプト（GitHub Actions / Node.js）

新プロジェクト発足時に、定型的なタスク（キックオフ、セキュリティレビュー、CI/CD構築など）をLinearへ自動投入するCI/CDパイプラインの構成例だ。

.github/workflows/bootstrap-linear-project.yml
name: Bootstrap Linear Project

on:
workflow_dispatch:
inputs:
projectName:
description: ‘New Project Name’
required: true
type: string
teamId:
description: ‘Linear Team ID (e.g., ENG)’
required: true
type: string

jobs:
create-project:
runs-on: ubuntu-latest
steps:

name: Checkout Repository

uses: actions/checkout@v4

name: Set up Node.js

uses: actions/setup-node@v4
with:
node-version: ’20’

name: Install Dependencies

run: npm install graphql-request

name: Execute Linear Project Scaffolding

env:
LINEAR_API_KEY: ${{ secrets.LINEAR_API_KEY }}
PROJECT_NAME: ${{ inputs.projectName }}
TEAM_ID: ${{ inputs.teamId }}
run: |
node -e ‘
const { request, gql } = require(“graphql-request”);

const endpoint = “https://api.linear.app/graphql”;
const apiKey = process.env.LINEAR_API_KEY;
const projectName = process.env.PROJECT_NAME;
const teamId = process.env.PROJECT_TEAM_ID; // 実際の実装に合わせて調整

async function main() {
// 1. プロジェクトの作成
const createProjectMutation = gql`
mutation CreateProject($name: String!, $teamIds: [String!]!) {
projectCreate(input: { name: $name, teamIds: $teamIds }) {
success
project {
id
name
}
}
}
`;

console.log(`Creating project: ${projectName}…`);
// ※ 実運用ではここにAPIリクエストを記述し、標準的な初期タスクを流し込む
}

main().catch(console.error);
‘

📝 2. イシュー記述の標準フォーマット（Markdownテンプレート）

Linearのプロジェクトやチーム設定にある「Default issue description」には、以下のMarkdownテンプレートを必ず設定させろ。これにより、開発者がチケットを切る際に「何を書くべきか」迷わなくなり、情報不足による手戻りを防ぐ。

🎯 概要 (Overview)

🛠️ 実装詳細 (Implementation Details)

[ ] データベーススキーマの変更 (Migrations)
[ ] ビジネスロジックの実装
[ ] 単体テスト・統合テストの追加
[ ] APIドキュメントの更新 (必要に応じて)

🧪 検証方法 (Verification Steps)

1. ローカル環境で `docker compose up` を実行
2. エンドポイント `POST /api/v1/…` へリクエストを送信
3. 期待されるレスポンスが返ることを確認

📸 スクリーンショット / ログ (Evidence)

—

結びにかえて：マウスを捨てよ、コードを書け

ツールに振り回されるな。ツールを指先の神経の延長線上にまで昇華させろ。

Linearのショートカットを体に覚え込ませ、インテグレーションを緻密に組み上げ、チーム全体でオペレーションの共通言語化をやり切ったとき、あなたのチームの開発ベロシティは文字通り「異次元」の領域に到達する。

コンテキストスイッチのノイズを消し去り、純粋に「良いコードを書くこと」だけに脳の全リソースをブーストさせろ。今日この瞬間から、あなたの机の上からマウスは不要になる。さあ、`Cmd + K` を叩いて、最初のタスクへダイブせよ。