LinearのCyclesとCapacity Planningで実現する、燃え尽き症候群ゼロの持続可能なアジャイル開発
こんにちは。テックリードとして日々チームのベロシティとコード品質に向き合っているあなたなら、こんな悪夢のような光景に見覚えがあるはずだ。
「今スプリントも気合でストーリーポイントを積み増したが、案の定クランチモードに突入し、テストはスキップ、技術負債の山がまた一つ築かれた……」
多くのチームが「アジャイル」という名の元に、ベロシティの最大化＝労働密度の極限化を履き違えている。結果として待っているのは、メンバーの疲弊、離職、そしてプロダクトの停滞だ。
アジャイルの本質は「持続可能なペース（Sustainable Pace）」の維持にある。それをLinearのCycles（サイクル）とCapacity Planning（稼働容量計画）の機能を徹底的にハックすることで、チームを燃え尽きから守りつつ、予測可能性（Predictability）の極めて高い開発組織へと生まれ変わらせる手法を伝授しよう。
—
1. なぜ「ベロシティの最大化」はチームを殺すのか？
ベロシティは「チームの生産性」を測る絶対的な指標ではない。それは「一定期間内にチームがどれだけの不確実性を消化できたか」の計測値に過ぎない。
これを「今期は20ポイントだったから、来期は25ポイントを目指そう」というゲーム感覚でオーバコミットを繰り返すと、WIP（Work in Progress）が増大し、コンテキストスイッチの嵐によって実際のスループットは低下する。
LinearのCycles機能は、単なるスプリント管理ツールではない。「チームが絶対に超えてはならない物理的な境界線」を引くための防波堤なのだ。
—
2. Linear Cycles × Capacity Planning の実戦投入
リソース管理を感覚で行うのを今日で終わりにしよう。Linearのネイティブ機能とメタ認知を組み合わせた、実践的なステップを解説する。
ステップ①：真のキャパシティ（Capacity）の算出法
「1人あたり週40時間＝40ポイント」などと考えてはいけない。会議、コードレビュー、突発的な障害対応、そして人間の脳の限界を考慮せよ。
- フォーミュラ:
$$\text{実効キャパシティ} = (\text{総稼働時間} – \text{Mtg/サポート対応}) \times \text{フォーカス係数（推奨: 0.7）}$$
LinearのCyclesでは、メンバーごとのアサインに対して「推定工数（Estimate）」を比較できる。この数値が実効キャパシティの80%を超えた瞬間、そのサイクルは「危険信号（Over-committed）」とみなすルールをチームで徹底する。
ステップ②：Linearの隠しコマンドでバックログを秒速制圧する
プロのテックリードはマウスに手を伸ばさない。Linearの真骨頂は、キーボードだけで完結する圧倒的な操作スピードにある。Cycles運用で必須のショートカットを体に叩き込んておけ。
| ショートカット (Mac / Windows) | 実行アクション | 現場での活用文脈 |
| :— | :— | :— |
| `G` → `C` | Cyclesビューへの即時移動 | 現在のサイクスの進捗をミリ秒単位で確認 |
| `P` | Issueの担当者（Assignee）変更 | 朝会でのリソース再配分をノータイムで行う |
| `Shift` + `C` | Cyclesの新規作成・編集モーダル | 次期サイクルのスコープ調整を素早く起動 |
| `Cmd` + `K` / `Ctrl` + `K` | コマンドパレットの呼び出し | あらゆる操作のハブとして機能させる |
| `O` then `I` | 自分の課題（Assigned to me）に絞り込み | ノイズを消し去り、目の前のタスクに集中する |
—
3. 開発スピードを加速させる「神プラグイン」＆連携
Linear単体でも強力だが、外部ツールと連携させることで、キャパシティプランニングの精度は次元が変わる。
1. Linear ＋ GitHub / GitLab Integration (必須)
PRのステータスとLinearのIssueを完全に同期させよ。「Draft状態」「Review中」「Merged」のライフサイクルを自動化し、エンジニアが手動でステータスを動かす手間をゼロにする。これにより、Cycle途中の「見えないボトルネック（レビュー待ちの放置）」がリアルタイムで可視化される。
2. Clockify または Toggl Track 連携 (実工数トラッキング)
「見積もり（Estimate）」と「実績（Time Spent）」の乖離を測るためのプラグイン。これをLinear上のIssueに紐付けることで、次回のCapacity Planningの精度（予測力）が劇的に向上する。
—
4. チームで共有すべき「Linear運用ルール」のコード化
ツールの設定はチームの共通認識であってこそ意味を持つ。GitHubリポジトリの `.github/` やドキュメントスペースに、以下の設定・運用ルールをコード・ドキュメントとして共有せよ。
以下は、チームのLinear運用ガイドラインを定義した YAML のベストプラクティス構成例だ。これをチームの憲法として掲げよ。
.linear/governance-rules.yml
Linear運用ガバナンスとキャパシティプランニングの基準
version: “2.1”
team: “Core Engineering”
cycle_policy:
duration_weeks: 2
planning_day: “Monday 10:00 AM”
review_day: “Friday 4:00 PM”
# オーバコミットを防ぐためのハードリミット
capacity_guardrails:
max_load_factor: 0.80 # 実効キャパシティの80%を超えたら追加投入禁止
buffer_for_bugs_percent: 20 # 予期せぬバグ・負債対応へのバッファ
max_wip_per_engineer: 2 # 同時並行タスクの最大数（Context Switch防止）
estimation_scale:
type: “fibonacci”
values: [1, 2, 3, 5, 8, 13]
definitions:
1: “軽微な文言修正、設定変更（< 2h）"
3: "単体のコンポーネント実装、ユニットテスト追加（< 0.5d）"
5: "標準的な機能開発、APIエンドポイント追加（1d - 2d）"
8: "複雑なロジック、複数ドメインにまたがる改修（3d）"
13: "要件定義・設計から伴う巨大なエピック（※原則分割対象）"
automation_rules:
- trigger: “PR_OPENED”
action: “Move Issue to ‘In Review'”
- trigger: “PR_MERGED”
action: “Move Issue to ‘Done’ & Prompt for Release Note”
- trigger: “CYCLE_CLOSED”
action: “Auto-roll-over uncompleted ‘In Progress’ items to backlog”
—
5. テックリードが実践すべき「燃え尽き防止」のオペレーション
最後に、このシステムを現場でどう回すかという「運用論」を授ける。
1. 「Carry Over（持ち越し）」を悪としない
サイクル終了時に未完了だったIssueを無理やり残業して終わらせる文化を破壊せよ。未完了タスクは一旦バックログへ戻し、なぜ容量を超過したのか（見積もりが甘かったのか、割り込みタスクが多すぎたのか）をレトロスペクティブで冷静に分析する。
2. ベロシティの「ブレ」を愛せよ
人間の開発速度は一定ではない。ベロシティが下がった時は、チームを責めるのではなく「何が心理的安全性や開発効率を阻害したか？」のシグナルとしてLinearのグラフを読み解くのだ。
—
結びにかえて
LinearのCyclesとCapacity Planningは、あなたを冷酷な管理職にするためのものではない。むしろ逆だ。エンジニアが過重労働のプレッシャーから解放され、純粋に優れたコードを書くことだけに熱中できる環境を作るための「盾」なのだ。
今日からチームのキャパシティに上限を設け、オーバコミットを拒絶する勇気を持とう。それこそが、持続可能で圧倒的な成果を生むアジャイル・エンジニアリングの真髄である。