こんにちは！開発現場の「燃え尽き症候群」や、終わらない「デスマーチ」に心を痛めていませんか？
「今スプリントも予定の7割しか終わらなかった……残業で何とかカバーしよう」
「ベロシティを上げろと言われるが、メンバーの疲弊感が限界にきている」
もしあなたがそんなモヤモヤを抱えているなら、朗報です。次世代の超高速Issueトラッカー「Linear」を正しく使いこなし、Cycles（サイクル）とCapacity Planning（稼働容量計画）を組み合わせれば、チームのベロシティを劇的に安定させつつ、誰も燃え尽きない「持続可能な開発体制」を手に入れることができます。
今回は、Linearをまだ触ったことのない初心者の方に向けて、その基礎から、チームを救うリソース管理の極意まで、優しく丁寧にお伝えしていきますね。これをマスターすれば、あなたのチームの毎日の開発が驚くほどスムーズになりますよ！
—
1. Linearとは何か？ なぜアジャイル開発の救世主なのか？
Jiraの重さに絶望したことはありませんか？ ページの読み込みを待つだけで、エンジニアの集中力は削がれてしまいますよね。
Linearは、「KILB (Keyboard Is Life / キーボードこそが命)」を体現するかのような、圧倒的なスピード感を誇るIssueトラッカーです。余計なローディングを排除し、ショートカットキー一つでタスクの作成・アサイン・ステータス変更が完結します。
アジャイル開発において、ツールは「監視の道具」ではなく「チームの鼓動を合わせる楽器」であるべきです。Linearはその楽器を最高チューニングで提供してくれます。特に、チームの時間単位の計画を支える「Cycles」機能は、アジャイルの真髄を最も美しく実装した機能と言えます。
—
2. 基礎セットアップ：CyclesとCapacityを有効化する
まずは、Linearで持続可能な計画を立てるための土台を作りましょう。設定は驚くほどシンプルです。
ステップ1: Team SettingsでCyclesを有効化する
Linearのワークスペース（プロジェクト）内で、特定のチームの設定を開きます。
1. 左下のチーム名をクリック ＞ Settings へ移動。
2. サイドメニューから Cycles を選択。
3. 機能トグルを On にし、サイクル期間（通常は1週間、または2週間）を決定します（※心理的安全性を保ち、変化に素早く適応するためには「2週間」がおすすめです）。
ステップ2: 稼働容量（Capacity）の概念をチームにインプットする
Linearでは、サイクルごとに「チーム全体でどれだけのストーリーポイント（またはIssue数）を消化できるか」を設定できます。
これがCapacity Planning（稼働容量計画）の核心です。
「人は機械ではない。常に100%のパフォーマンスでコードを書けるわけではない」という現実をデータとして受け入れます。
—
3. Hello World的な動作確認：初めてのサイクルとキャパシティ設定
では、実際にチームで最初のサイクルを回すための「最小にして最高の動作確認」をしてみましょう。
① メンバーの「実効稼働時間」を把握する
例えば、2週間（10営業日）のサイクルだとします。
- メンバーA：フル稼働（10日） ＝ 容量 100%
- メンバーB：途中2日間は他のプロジェクトやレビュー対応（8日） ＝ 容量 80%
- メンバーC：新メンバーのためキャッチアップ期間を考慮（5日） ＝ 容量 50%
このように、全員が「常時フルパワー」ではないことを前提にキャパシティを算出します。
② Linear上でCapacityを設定する
Linearの Cycles タブを開き、新しく作成するサイクル（例: `Cycle 1`）に対して、チームの許容量を設定します。
[Cycle 1: 2023.11.01 – 2023.11.14]
- チーム目標キャパシティ: 30ポイント（※後述のベロシティ測定に基づく）
- アサインされたIssueの合計: 28ポイント
=> オーバコミット回避！健全な状態 🟢
もし、ここに「50ポイント」分のタスクを詰め込もうとすると、Linearは警告を発してくれます。これが、あなたとチームの燃え尽きを防ぐ最初の防壁となります。
—
4. 現場で震えるほど役立つ：ベロシティ測定とオーバコミット防衛術
ここからが本題です。ツールを使っても、運用を誤ればただの形骸化します。持続可能な開発体制を作るための「3つの極意」を伝授します。
極意1: 「平均ベロシティの70%」を計画の基準にする
よくある失敗は、過去最高のベロシティ（例: 40ポイント）を基準に次のサイクルを組むことです。これは確実に破綻します。割り込みタスク、急なバグ対応、ミーティング、そして人間のバイオリズムを考慮してください。
- 実践ノウハウ: 直近3サイクルの「完了ポイントの平均値」を出し、その 70%〜80% を今回のキャパシティの限界値（上限）としてロックします。あえて余白（バッファ）を残すことが、チームの心理的安全性とコード品質を担保します。
極意2: メンバーごとの「Load（負荷）」を可視化する
Linearのサイクル画面では、各メンバーに何ポイントのタスクがアサインされているかが一目でわかります。
特定の誰か（例えばエースエンジニアのAさん）に負荷が偏っていないか（Loadが100%を超えていないか）を、スプリントプランニングの段階で必ずチェックしてください。
[負荷バランスのチェック例]
- 👨💻 メンバーA: Load 120% ⚠️ (赤信号！タスクを他のメンバーに逃がす)
- 👩💻 メンバーB: Load 60% 🟢 (まだ余裕あり。ヘルプに回ってもらう)
この「負荷の偏り」をリアルタイムで検知できるのが、LinearのCyclesの真価です。マネージャーやテックリードは、赤信号のメンバーが出たら即座にスコープの縮小（後述）を行います。
極意3: スコープの動的調整（Scope Creepの排除）
サイクル途中に「あれもこれも追加したい」という要望（Scope Creep）が降ってくることはありませんか？
ここで全てを受け入れていると、チームは確実に疲弊します。
- 厳格なルール: サイクルが始まったら、原則として新しいタスクの追加は禁止します。
- 例外処理: どうしても緊急のタスクを入れる必要がある場合は、「同等サイズの既存タスクを次のサイクルへ逃がす（トレードオフ）」ルールを徹底してください。キャパシティの総量は絶対に増やさないのが鉄則です。
—
5. まとめ：持続可能な開発こそが、最高のプロダクトを生む
いかがでしたでしょうか？
LinearのCyclesとCapacity Planningは、単なる「スケジュール管理ツール」ではありません。それは、「開発者の心身の健康を守り、長期的に最高のパフォーマンスを発揮するためのシールド（盾）」です。
- 過去の平均ベロシティの70%をキャパシティの上限にする。
- 個人の負荷（Load）の偏りを防ぐ。
- 始まったサイクルのキャパシティを死守する。
これを実践するだけで、あなたのチームから「デスマーチ」の二文字は消え去り、ワクワクしながら良いコードを書き続ける持続可能な環境が手に入ります。
今日からあなたのチームでも、LinearのCyclesを使って「無理のない美しいスプリント計画」を始めてみませんか？ きっと、チームの空気感がガラリと変わるのを実感できるはずですよ！