開発フローの聖域を守れ：Linear CLIとTerminalがもたらす「コンテキストスイッチ絶滅計画」
優秀なエンジニアにとって、最大の敵はコードのバグではない。「コンテキストスイッチ（文脈の切り替え）」だ。
エディタでディープなアルゴリズムを構築し、脳内が最高潮に達しているまさにその瞬間、「おい、次のチケットのステータス更新して」「このバグ、どのブランチで直すんだっけ」という割り込みが入る。ブラウザを開き、Linearのボードを探し、マウスでドラッグ＆ドロップし、ブランチ名を手動でコピーする――。
この数秒の無駄なスイッチングが、あなたのフロー状態を粉々に砕き、脳のRAMを無駄に消費している。
ベロシティが高いチームは、ツールの間を行き来しない。彼らは「黒い画面（Terminal）」から一歩も出ない。
今回は、公式Linear CLIとTerminalを極限まで連携させ、開発フローを完全にシームレス化する「裏技」と実践知を授けよう。
—
1. なぜLinear CLIなのか？ GUIの呪縛からの解放
世の中には多くのタスク管理ツールがあるが、多くは「マウス操作」を前提としており、キーボードから手を離さなければならない。エンジニアのホームポジションはキーボードの上だ。マウスに手を伸ばした時点で、生産性は低下している。
公式の `linear-cli` やコミュニティ製の強力なCLIツールを導入することで、以下のメリットがもたらされる。
- 指先からゼロレイテンシでイシュー生成：ブレインストーミングの勢いそのままにタスク化。
- Git連携の自動化：イシューキーに基づいたブランチ作成とコミットの紐付け。
- 脳内メモリの節約：ターミナルを閉じずに「今、何をすべきか」を即座にフェッチ。
まずは、この環境を構築するための必須ツールと設定から見ていこう。
—
2. 導入と環境構築：神速のセットアップ
インストールと認証
Node.js環境があれば、公式またはエコシステムのCLIは一瞬で導入できる。ここでは広く使われている `linear-cli` をベースに話を進める。
グローバルインストール（または npx で都度実行）
npm install -g @linear/cli
認証の実行（Personal Access Tokenが必要）
linear auth
Tip: Linearの Settings > API から Personal Access Token を発行し、環境変数 `LINEAR_API_KEY` として `.zshrc` や `.bashrc` に仕込んでおくのがプロの作法だ。
—
3. 実践！Terminalから離れないためのワークフロー
ここからが本題だ。日々の開発でどのようにCLIを組み込み、コンテキストスイッチをゼロにするのか、具体的なユースケースを紹介する。
① 思考を止めずにイシューを切る
コードを書いていて「あ、ここリファクタリングが必要だけど今はスコープ外だな」と思った瞬間、ターミナルにこう叩く。
linear issue create \
-t “Refactor UserRepository error handling” \
-d “Provide custom exception types for database timeouts” \
-p “High” \
–team “ENG”
ブラウザを開く必要すらない。3秒でバックログに積まれ、あなたは元のコードに戻れる。
② イシューから瞬時にブランチを生やす
GitのワークフローとLinearは完全に同期していなければならない。イシュー番号を入れたブランチ名を考える時間は無駄だ。
自分のアサインされているイシューを選択してインタラクティブにブランチを作成する
linear issue checkout
裏側で `git checkout -b eng-123-refactor-user-repository` が実行される。コミットメッセージにも自動でイシューIDが付与されるため、トレーサビリティも完璧だ。
—
4. チーム開発の生産性を爆発させる設定共有とベストプラクティス
個人の効率化にとどまらず、チーム全体でこの思想を共有するための設定ファイル（Dotfiles管理）のベストプラクティスを公開する。
プロジェクトルートに `.linear.yml` を配置し、チーム全体でCLIの挙動を統一せよ。これにより、新規参画者も初日から「黒い画面だけの最速開発フロー」を手に入れられる。
実用的な設定ファイル：`.linear.yml`
.linear.yml
Linear CLI Team Configuration
チーム全体のタスク管理・ブランチ命名規則をコードとして定義する
version: “1.0”
デフォルトのチーム設定
default_team: “ENG”
ブランチ命名規則のテンプレート
例: feature/ENG-123-short-title
branch:
format: “{type}/{issueKey}-{slug}”
types:
- feature
- bugfix
- refactor
- hotfix
イシュー作成時のデフォルト値
defaults:
project: “Core API Modernization”
estimate: 2 # アジャイルのストーリーポイント
labels:
- “Backend”
- “Needs Review”
ワークフローのエイリアス定義（よく使うクエリのショートカット）
aliases:
my-tasks: “issue list –assignee=@me –state=in-progress”
triage: “issue list –state=triage”
この設定ファイルをプロジェクトに含め、チームメンバー全員が共有することで、「誰がタスクを切っても同じ命名規則、同じラベル、同じプロジェクト紐付け」が担保される。情報のサイロ化は、こうした細部の自動化から防がれるのだ。
—
5. 究極の裏技：Zsh/Bashファンクションによる「秒速ステータス変更」
CLIをさらにハックする。毎度 `linear issue update …` と打つのは面倒だ。シェルのカスタム関数（あるいはエイリアス）を `.zshrc` に仕込み、コマンド一発で現在のイシューを「Done」にする魔改造を施そう。
以下のスニペットをあなたの `.zshrc` に追加してほしい。
~/.zshrc に追加する神スニペット
現在のGitブランチ名（例: feature/ENG-123-fix）からイシューキーを自動抽出してDoneにする
f_done() {
local branch=$(git branch –show-current)
# 正規表現で ENG-123 のようなパターンを抽出
if [[ $branch =~ ([A-Z]+-[0-9]+) ]]; then
local issue_key=$match[1]
echo “Marking Linear Issue $issue_key as Done…”
linear issue update $issue_key –state “Done”
echo “✨ Done! Keep shipping.”
else
echo “❌ Error: Current branch does not contain a valid Linear issue key.”
fi
}
エイリアス登録
alias ldone=”f_done”
使い方：
開発が終わったら、ターミナルでこう叩くだけだ。
ldone
たったこれだけで、Gitブランチ名から自動でイシューを特定し、Linear側のステータスが「Done」に変わる。ブラウザを開く必要は、もはや一生ない。
—
最後に：ツールに使われるな、ツールを飼いならせ
アジャイル開発の本質は「価値の早期deliver」であり、ツールへのデータ入力作業ではない。
GUIの画面遷移、マウスのドラッグ＆ドロップ、無駄なタブの切り替え――これらはすべて、エンジニアの認知負荷を高める「ノイズ」にすぎない。
Linear CLIとTerminalを連携させ、自分だけの最適化されたワークフローを構築せよ。
コンテキストスイッチを極限まで排除した先にある、「ゾーンに入った圧倒的なコーディングスピード」を、ぜひあなたのチームで体感してほしい。