scope-cutting

問いを反転させてスコープを絞ります。「どれくらい時間がかかるか？」ではなく、「この問題にはどれだけの時間をかける価値があるか？」と尋ねましょう。まず時間の枠を決め、それに合うようにソリューションを形作ります。これが Shape Up の核心となる考え方です。時間は固定し、スコープは変動させます。

時間の枠を決める

スコープに手をつける前に、時間の予算を決めます。

• スモールバッチ： 1〜2人で1〜2週間
• ビッグバッチ： 少人数チームで最長6週間

プロジェクトに6週間以上（または Linear の手法で1〜3人の場合に3週間以上）かかるなら、大きすぎます。分割するか、手を引きましょう。

時間の枠は見積もりではありません。見積もりは「これには X かかる」と言います。時間の枠は「これには X の価値がある」と言います。形作ったソリューションが時間の枠に収まらない場合は、収まるまでスコープを削るか、プロジェクトを中止しましょう。

スコープを徹底的に絞る

仕様書の各項目について、次の質問を順番に確認します。

1. 必須か、あるとよいものか？ その機能がなくてもリリースでき、ユーザーが価値を得られるなら、あるとよいものです。削りましょう。
2. なくてもリリースできるか？ これを含めずに、動作するバージョンをデプロイできますか？ できるなら、v1 から削りましょう。
3. エッジケースか、主要な利用経路か？ この状況に遭遇するユーザーが20％未満なら、後回しにしましょう。
4. ベースラインと比較する。 ベースラインは機能がまったくない状態であり、理想的なバージョンではありません。「ないよりはよいか？」は、常に「これ以上よくできるか？」より優先されます。

ソリューションをさらに絞る

徹底的に絞ってもスコープが大きすぎる場合は、次のようにします。

• 品質ではなく、幅を削ります。 3つの認証プロバイダーを中途半端にサポートするより、1つをしっかりサポートしましょう。あらゆるエラー状態に対応するより、正常系を完全にカバーしましょう。
• 機能面を丸ごと取り除きます。 設定ページをなくします。ダッシュボードを削除します。設定可能にするのではなく、妥当なデフォルト値を用意してリリースしましょう。
• エッジケースに時間の上限を設けます。 「CSV のインポートは最大1,000行まで対応します。それを超える場合はメールでご連絡ください。」自動化が必要な規模になるまでは、手作業で対応しましょう。
• 「お客様に感謝される、最もシンプルなバージョンは何か？」と尋ねます。 それがスコープです。

サーキットブレーカー（Shape Up）

1サイクルでリリースできなければ、デフォルトで中止します。自動的な持ち越しはありません。チームは次のサイクルに向けて、あらためて提案する必要があります。これにより、いつまでも続くゾンビプロジェクトを防ぎます。

ガイドライン

• 重要：品質を削るのは絶対に避け、幅を削ります。5つのことをするバグだらけの機能より、1つのことをきちんと行う洗練された機能を優先します。
• 見積もりは絶対にしません。時間の枠を決めます。「2週間かける価値がある」であって、「完了まで2週間かかる」ではありません。
• v1 の必須項目は5つを超えないようにします。超えているなら、スコープを十分に絞れていません。
• 理想的な実装ではなく、ベースライン（機能がまったくない状態）と必ず比較します。
• 「すべてをリリースするまでどれくらいかかるか？」ではなく、「［時間の枠］内で何をリリースできるか？」と必ず尋ねます。
• 作業を自動的に持ち越すことは絶対に避けます。未完了の作業は、あらためて提案する必要があります。

---

Shape Up（Basecamp）と Linear Method に基づいています。スキルは productskills より。