【Linear実践】バグ報告・機能要望の品質を均一化する！Issueテンプレート設計の極意
開発チームのベロシティを鈍化させる最大の癌（がん）、それは「情報の非対称性」と「チケットの品質のバラつき」だ。
「画面が壊れました」
「なんか重いです」
「ここ、いい感じにしておいてください」
――こんなチケットがバックログに積まれた瞬間、エンジニアの認知負荷は跳ね上がる。原因特定のためのヒアリング、再現手順の確認、仕様のすり合わせ。コードを書く時間よりも、チケットの行間を読み解く無駄な時間に開発リソースがすり潰されていく。
Jiraの重厚長大なカスタムフィールド地獄から脱却し、爆速のUXでエンジニアを魅了するLinear。しかし、ツールがどれほど洗練されていようとも、入力される情報の質が低ければ意味がない。
今回は、Linearの「Issue Templates（イシューテンプレート）」を徹底的にハックし、バグ報告や機能要望の粒度を完全に揃え、チームの生産性を限界突破させるための実践的な知見を伝授する。
—
1. なぜ「なんとなく書いたチケット」は地雷なのか？
優秀なアジャイルチームにとって、Issueは単なるタスク管理のカードではない。「未来の自分や仲間へのコンテキストの引き継ぎ書」である。
品質の揃ったIssueには、以下の要件が最初から構造化されている。
- 再現可能性: 誰がやっても同じ結果になる。
- 影響範囲の特定: どのレイヤー（DB, API, Frontend）の問題か一目でわかる。
- ゴール（Definition of Done）の合意: 何ができたらこのタスクは完了なのかが明確である。
Linearのテンプレート機能を使い倒すことで、この「質の高いインプット」を投稿者のリテラシーに依存せず、仕組みとして強制（あるいは誘導）する。
—
2. 実践！プロジェクト種別ごとのテンプレート設計
Linearでは、チームごとに、あるいはグローバルにIssueテンプレートを設定できる。ここでは、現場で即座に効果を発揮する「バグ報告」と「機能要望」のテンプレートの具体例をMarkdownで公開する。
A. バグ報告（Bug Report）テンプレート
エンジニアが即座にデバッグを開始できる情報（環境、再現手順、期待値）を強制的に引き出す。
🐛 概要
（問題の現象を1行で簡潔に記述してください。例: 決済画面で「確認」ボタンを連打すると二重決済が発生する）
📱 発生環境
- OS: [e.g. macOS Sonoma 14.2 / iOS 17.2 / Windows 11]
- ブラウザ / アプリ版本: [e.g. Chrome 120.0 / App v2.14.0]
- 環境: [e.g. Staging / Production]
🔄 再現手順
1. 〇〇画面にアクセスする
2. フォームに「△△」と入力する
3. 「送信」ボタンを押す（※ここでエラー発生）
👀 期待される動作
（本来どうあるべきか）
📷 スクリーンショット / ログ
（エラー画面のキャプチャや、Sentry/Consoleのログをここに貼る）
B. 機能要望（Feature Request）テンプレート
「なぜそれが必要なのか（Why）」と「ビジネス価値（Business Value）」を書き込ませ、安易な機能肥大化（スコープクリープ）を防ぐ。
💡 課題・背景（Why）
（現在、どのようなペインがありますか？ 誰が困っていますか？）
✨ 提案内容（What）
（どのような機能や改善を求めていますか？）
🎯 受け入れ基準（Definition of Done）
- [ ] 〇〇の条件を満たしていること
- [ ] エラー時にトースト通知が表示されること
- [ ] モバイル表示（レスポンシブ）に対応していること
🎨 参考デザイン / 類似機能
（Figmaのリンクや、他社サービスの参考になる挙動があれば記載）
—
3. Linearを極限まで加速させるプロの技
ここからは、UIをポチポチ触っているだけでは絶対に辿り着けない、Linearの真の実力を引き出すキラーテクニックを紹介する。
⌨️ 開発スピードを劇的に高めるキーボードショートカット
マウスに手を伸ばした時点でエンジニアのフロー状態は途切れる。Linearはキーボードオペレーションだけで完結するように設計されている。
- `C` : どこからでも新しいIssueを作成 (Create)
- `P` : コマンドパレットを開き、あらゆる操作・検索を秒速で行う
- `Shift + C` : 現在開いているIssueのURLをコピー
- `E` : Issueのアサインやステータス変更をインラインで瞬時に行う
- `~` (チルダ) : チームやビューの切り替え
テンプレートを適用する際も、`C` で作成モーダルを開き、テンプレート選択ショートカット（またはスラッシュコマンド）を使うことで、一瞬でフォームを呼び出せる。
🔌 絶対入れるべきインテグレーション（神プラグイン）
1. GitHub / GitLab連携
- PRのタイトルやブランチ名にIssue ID（例: `ENG-123`）を含めるだけで、Linear側のステータスが自動連動する。「PR出しました」のチャット報告すら不要になる。
2. Sentry連携
- エラーログから直接Linearのバグチケットを起こせる。スタックトレースが自動でテンプレートに流し込まれるため、エンジニアの初動調査時間がゼロになる。
3. Figma連携
- デザインファイルの変更がIssueに即座に同期され、デザインの差し戻しによる手戻りを防ぐ。
⚙️ チーム開発で役立つ設定の共有化ルール
テンプレートやラベル、ワークフローのステータスは、チームの成熟度に合わせて進化させるべきだ。
- ラベルの命名規則の統一: バグ（`bug`）、機能（`feature`）、技術負債（`tech-debt`）、改善（`enhancement`）の色と名前をチーム間で完全に統一し、フィルタリングの精度を上げる。
- Auto-closeの設定: `main` ブランチにPRがマージされたら、紐付くIssueが自動的に `Done` になるワークフローをチーム設定で必ず有効化する。人間の手でステータスを動かす手間を排除せよ。
—
4. チケット管理のパラダイムシフトを起こせ
ツールに振り回されてはならない。ツールに仕事をさせよ。
LinearのIssueテンプレートを導入し、情報の粒度を揃えることは、単なる「お片付け」ではない。チームメンバー全員の「仕様に対する共通言語」を構築する行為だ。
雑なチケットが消滅し、コンテキストが詰まった美しいIssueだけが並ぶバックログを見た時、あなたのチームのベロシティは、確実に次のステージへと加速しているはずだ。さあ、今すぐチームのLinearを開き、最初のテンプレートをブランチにブチ込め。