Issue管理、後回しになっていませんか
開発に集中していると、Linearのステータス更新やPRの紐付けはどうしても後回しになりがちです。「今どのIssueが進行中か分からない」「マージしたのにステータスが未更新のまま」といった状態、心当たりがある方も多いのではないでしょうか。
この記事でできるようになること
Linear・Claude Code・GitHubを連携させることで、コードを書いてPRをマージするという普段の作業だけで、Issueの進捗が自動的に更新される環境を作れます。手作業でのステータス変更をほぼなくし、開発に集中できる状態を目指す構成です。
ポイントは「Issue ID」を軸にLinear・ブランチ・PRをつなげることです。
手順1：Linearでプロジェクトとイシューを整備する
まずはLinear側の準備からです。プロジェクトを作成し、着手する作業をIssue単位で登録します。このとき自動採番される「ENG-123」のようなIssue IDを意識しておいてください。このIDが後の連携すべての起点になります。
粒度は「1PRで完結する作業」くらいが扱いやすいです。大きすぎるIssueだとブランチが長生きしてしまい、進捗更新の恩恵も薄れます。
手順2：GitHubリポジトリとLinearを連携する
Linearの設定画面からGitHub連携を有効にし、対象リポジトリを紐付けます。連携が済むと、ブランチ名やPRタイトル・コミットメッセージにIssue IDを含めるだけで、LinearがそのPRを該当Issueに自動でリンクしてくれるようになります。
さらにPRがマージされたタイミングで、Issueのステータスが「進行中」から「完了」などへ自動的に切り替わる仕組みも用意されています。ここまで設定できれば、手作業でのステータス変更はほぼ不要になります。
ブランチ命名のルールを決めておく
feature/eng-123-add-login-form
のように、Issue IDを含んだ命名規則をチームで統一しておきましょう。ここを曖昧にすると連携がうまく働かないので、最初にルール化しておくのが結局一番早いです。
手順3：Claude Codeを導入し、ブランチ内で作業する
ターミナルからClaude Codeを起動し、先ほど作成したブランチ上でコーディングを進めます。Issueの内容をそのまま指示文としてClaude Codeに渡し、実装・修正・テストコード作成まで任せる、という流れが基本になります。
Issueの説明文をそのままコピーして指示に使うと、意図がずれにくくおすすめです。個人的には、Issue本文に受け入れ条件まで書いておくと、Claude Codeへの指示がぐっと楽になりました。
作業が一区切りついたら、コミットメッセージにもIssue IDを含めておきます。これでコミット単位でもLinear側にログが残るようになります。
手順4：PRを作成し、GitHub Actionsでチェックを回す
ブランチでの作業が終わったらPRを作成します。PRタイトルにもIssue IDを含めるのを忘れずに。GitHub Actions上でテストやビルドチェックを走らせるワークフローを組んでおけば、レビュー前の一次チェックまで自動化できます。
ポイント：Issue ID・ブランチ名・PRタイトル・コミットメッセージ、この4か所でIDの表記を統一することが、連携を安定させる一番の近道です。
PRがマージされれば、Linear側のIssueステータスも自動で更新されます。ここまで来ると、「開発している」という行為そのものが、そのままプロジェクト管理の更新作業になっている感覚を得られるはずです。
つまずきやすいポイントと対処
最初に戸惑いやすいのは、ブランチ名やPRタイトルの表記ゆれです。Issue IDの大文字小文字やハイフンの位置が少しでもずれると、Linearが自動で紐付けてくれません。正直ここは少し面倒に感じるところですが、テンプレート化してしまえば一度きりの手間で済みます。
PRテンプレートやコミットメッセージのひな形をリポジトリに用意しておくと、表記ゆれによる連携漏れをかなり減らせます。
もう一つは、Issueの粒度が大きすぎるケースです。1つのIssueに複数の作業がぶら下がっていると、どのPRでステータスが更新されるべきか曖昧になります。Issueを小さく切る習慣は、地味ですがこの仕組み全体の土台になります。
まとめ
LinearのGitHub連携とClaude Codeを組み合わせることで、コーディングと進捗管理の間にあった手作業を大きく減らせます。ルールさえ決めてしまえば、あとは普段通りに開発を進めるだけです。まずはブランチ命名規則の統一から、今日試してみてはいかがでしょうか。
コメント