shape-up

Shape Up

ビルドの罠と終わりのないバックログから抜け出しましょう。Basecamp の方法論を使い、期間を固定し、スコープを柔軟にしながら、6 週間のサイクルで意義のある成果を届けます。

このスキルを使う場面

• プロダクト計画で終わりのないバックログを置き換える
• 機能開発で明確な期間を設定する
• チームの自律性を高め、自主的に動くチームを目指す
• スコープ管理でプロジェクトが膨らみがちな場合に対応する
• スタートアップ開発で限られたリソースを活用する
• 代理店／コンサルティングプロジェクトで固定スケジュールに対応する

方法論の基盤

観点	詳細
出典	Ryan Singer 著『Shape Up』（2019 年）、Basecamp で開発
基本原則	「期間を固定し、スコープは柔軟に。見積もりではなく、投資する期間を決める。構築する前に形にする。」
重要な理由	従来の手法では、細かく管理しすぎる（ウォーターフォール）か、方向性がないまま多くを未確定にする（方向性のないアジャイルスプリント）かのどちらかになりがちです。Shape Up はチームに方向性と自律性の両方をもたらします。

Claude が行うことと、あなたが決めること

Claude が行うこと	あなたが決めること
制作ワークフローの構成	最終的なクリエイティブの方向性
技術的なアプローチの提案	機材とツールの選択
テンプレートとチェックリストの作成	品質基準
ベストプラクティスの特定	ブランド／トーンに関する判断
スクリプトの概要の生成	スクリプトの最終承認

このスキルでできること

1. シェイピングを導入 - 適切な抽象度で作業を定義します
2. 見積もりより投資期間を設定 - これにどれだけの時間をかける価値があるかを判断します
3. サイクルを実現 - 集中的な 6 週間の作業と 2 週間のクールダウンを設けます
4. チームに権限を与える - 境界の範囲内で自律的に進めます
5. ベッティングテーブルを提供 - 原則に基づいて優先順位を決めます
6. スコープを動的に管理 - 必須項目と、あると望ましい項目を分けます

使い方

機能のアイデアを形にする

I want to shape this feature idea: [description]
Apply Shape Up methodology to define it at the right level.
Appetite: [2 weeks / 6 weeks]

サイクルを計画する

We have these potential projects for the next cycle:
[List of ideas]
Help me run a betting table to decide what to build.

開発中にスコープを管理する

We're in week 3 of a 6-week cycle building [feature].
We're running behind. Help me apply Shape Up scope hammering.

手順

ステップ 1：Shape Up の原則を理解する

## The Shape Up Philosophy

### Fixed Time, Variable Scope

**Traditional approach:**
"How long will this take?" → Estimate → Build → Deadline slips

**Shape Up approach:**
"How much time is this worth?" → Appetite → Shape to fit → Ship on time

**The mindset shift:**
Instead of estimating how long a feature will take,
decide how much time you're willing to spend.
Then shape the work to fit that time.

### Appetite, Not Estimates

**Appetite:** How much time is this problem WORTH solving?

- Small batch: 2 weeks or less
- Big batch: 6 weeks max

**Key insight:**
A feature can be built in 2 weeks OR 6 months.
The question is: What version fits your appetite?

**Example:**
"Auto-complete for search"
- 6-month version: ML-powered, personalized, learns preferences
- 6-week version: Pre-populated common searches, basic matching
- 2-week version: Static list of top searches

All solve the problem. Choose based on appetite.

### Shaping vs. Building

**Shaping (Senior people):**
- Define the problem
- Set boundaries
- Identify risks
- Rough solution direction
- Leave room for builder creativity

**Building (Teams):**
- Detailed implementation
- Technical decisions
- UX specifics
- Scope management within boundaries

---

ステップ 2：シェイピングのプロセス

## How to Shape Work

### Step 1: Set the Appetite

Before anything else, decide:
- Is this a **small batch** (2 weeks) or **big batch** (6 weeks)?
- Is this worth doing at all at this appetite?

**Questions to ask:**
- What problem are we solving?
- How painful is this problem?
- What's the opportunity cost of not doing it?
- What's the opportunity cost of spending more time on it?

### Step 2: Narrow the Problem

Don't shape "improve search."
Shape "help new users find their first project template."

**Narrowing technique:**
1. Start with the raw idea
2. Ask: Who specifically has this problem?
3. Ask: In what specific situation?
4. Ask: What's the minimum viable solution?

### Step 3: Rough Out the Solution

**Fat marker sketches:**
Draw the solution with a thick marker (no detail).
You're defining spaces and flows, not buttons and fields.

**Breadboarding:**
For flows, use words not wireframes:

[検索ボックス] → [検索結果ページ] → [テンプレートの詳細] ↓ [結果なし] → [カテゴリーを提案]

**Key principle:**
Leave room for the builders to be creative.
Define WHAT, not exactly HOW.

### Step 4: Identify Risks and Rabbit Holes

**Rabbit holes:** Technical or design problems that could explode in scope.

**For each potential rabbit hole:**
- Name it
- Decide: Solve it in shaping? Or declare it out of scope?
- Document the boundary

**Example:**
"If we build template search, what about user-generated templates?"
Decision: Out of scope. Only show official templates.

### Step 5: Write the Pitch

**Pitch elements:**
1. **Problem:** What are we solving?
2. **Appetite:** How long is this worth?
3. **Solution:** Fat marker sketch / breadboard
4. **Rabbit holes:** What we're explicitly NOT doing
5. **No-gos:** Boundaries and constraints

---

ステップ 3：サイクル

## Six-Week Cycles

### The Rhythm

**6 weeks building:**
- Long enough for meaningful work
- Short enough to maintain urgency
- Teams own their projects completely

**2 weeks cooldown:**
- Bug fixes
- Technical debt
- Exploration
- Shaping for next cycle
- Recovery

### Why 6 Weeks?

**Shorter (2-week sprints):**
- Not enough time for real progress
- Constant planning overhead
- Work gets chopped up artificially

**Longer (quarters):**
- Deadlines feel far away
- Scope creeps
- No urgency until the end

**6 weeks:**
- Urgent from day one
- Room to figure things out
- Clean endpoint

### Team Structure

**Small teams:**
- 1-2 designers + 1-3 programmers
- Self-managed during the cycle
- No daily standups with managers
- Check-ins when THEY need help

**Circuit breaker:**
If work isn't done at 6 weeks, it doesn't automatically continue.
It goes back to the betting table. Maybe it gets another cycle.
Maybe it doesn't.

### What Teams Do in a Cycle

**Week 1-2: Figure it out**
- Understand the shaped work
- Spike on unknowns
- Get oriented
- Early integration

**Week 3-4: Build the core**
- Make vertical slices
- Connect the pieces
- Working software early

**Week 5-6: Polish and ship**
- Cut scope if needed
- Must-haves only
- Ship by end of cycle

---

ステップ 4：ベッティングテーブル

## Choosing What to Build

### The Betting Table

**Who:** Senior people who can make commitments
**When:** During cooldown, before next cycle
**Input:** Shaped pitches
**Output:** Cycle bets

### The Process

**1. Review pitches**
Each pitch should be complete:
- Clear problem
- Shaped solution
- Identified risks
- Appetite set

**2. Consider each bet**

For each pitch, ask:
- Is this the right time?
- Do we have the right team?
- Are there dependencies?
- What's the opportunity cost?

**3. Make decisions**

Options:
- **Bet:** Assign to next cycle
- **Park:** Good but not now
- **Kill:** Not worth doing

**No backlog:**
If you don't bet on something, it goes away.
Good ideas come back. Bad ideas don't.

### Betting Criteria

**1. Strategic fit**
Does this support current company goals?

**2. Problem significance**
How painful is this for customers?

**3. Appetite match**
Can this actually be done in the proposed time?

**4. Team availability**
Who would work on this?

**5. Dependencies**
What else needs to be true?

### Anti-Patterns

**Carry-over:**
"We didn't finish last cycle, so we'll continue."
No. Circuit breaker. Re-evaluate. Maybe it's not worth it.

**Backlog grooming:**
"Let's go through the 200 ideas and prioritize."
No. Only consider shaped pitches. Unshaped ideas aren't real options.

**Consensus:**
"Let's vote on what to build."
No. Decision-makers decide. Not democracy.

---

ステップ 5：スコープの管理

## Scope Hammering

### The Principle

Scope grows naturally. Left unchecked, projects expand to fill time.
Your job is to constantly hammer scope back to what matters.

### Must-Haves vs. Nice-to-Haves

**Must-haves:**
- Core value delivery
- Without this, the feature doesn't work
- Absolutely required for ship

**Nice-to-haves:**
- Polish
- Edge cases
- Delighters
- "While we're at it..."

**Rule:** Identify nice-to-haves early. Cut them first.

### The Scope Hammer

**When you're behind (week 3+):**

1. **List all remaining work**
2. **Classify each item:**
   - Must-have for THIS version
   - Nice-to-have (cut or defer)
3. **Cut aggressively:**
   - What's the smallest version that still delivers value?
   - What can be a follow-up?
   - What can we not do at all?

### Scope Hammering Questions

- "Is this necessary for launch, or is it polish?"
- "What's the simplest version that still solves the problem?"
- "Can this be a fast-follow?"
- "What would happen if we just... didn't do this?"
- "Are we building for the 80% case or the edge case?"

### Hill Charts

**Track progress visually:**

    ┌─────────────────────────────────┐
    │                 ↗ 機能 C     │
    │       ↗ 機能 B               │
    │ ↗ 機能 A            ↘ 機能 D
    └─────────────────────────────────┘
     試行錯誤する    実現する

- **Uphill:** Still figuring it out (risky)
- **Downhill:** Know what to do, just executing (safe)

**Use for:**
- Early warning when something is stuck uphill
- Identifying where help is needed
- Manager visibility without micromanagement

---

例

例 1：機能を形にする

入力：

「プロジェクト管理アプリに通知を追加したいと考えています。Shape Up を使ってアイデアを形にするのを手伝ってもらえますか？」

出力：

形にした提案：プロジェクト通知

問題

ユーザーはアプリを時々しか確認しないため、重要な更新を見逃します。 確認しても、膨大なアクティビティが表示され、何が重要なのかを 把握する方法がありません。

具体的な状況： プロジェクトマネージャーが 1 日不在にした後でログインしても、 何に注意を向ける必要があるのか、すぐには分かりません。

投資期間

6 週間（大規模バッチ）

通知は基盤となる機能なので、きちんと投資する価値があります。 ただし、3 か月かけるほどではありません。6 週間に収まる範囲にします。

ソリューション

ブレッドボード：

[Activity happens] → [Notification created] → [Notification center]
                                                       ↓
                                              [Settings: what to notify]

太いマーカーで描いたスケッチ：

┌─────────────────────────────────────┐
│ 🔔 (3)                              │  ← Bell in header with count
├─────────────────────────────────────┤
│ ┌─────────────────────────────────┐ │
│ │ ● @you in Project Alpha         │ │  ← Unread notifications
│ │   Sarah mentioned you in a...   │ │
│ │   2 hours ago                   │ │
│ ├─────────────────────────────────┤ │
│ │ ○ Task completed                │ │  ← Read notifications
│ │   Build specs was marked done   │ │
│ │   Yesterday                     │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────┘

構築するもの：

1. アプリ内通知センター（ベルアイコン、ドロップダウン）
2. 通知の対象：@メンション、タスクの割り当て、期限
3. 基本設定（種類ごとのオン／オフ）

スコープ外（明確に対象外）の項目

メール通知： 配信到達性、配信停止、フォーマットなど、まったく別のシステムが必要です。 対象外です。将来的に小規模なバッチで対応する可能性があります。

モバイルプッシュ通知： ネイティブアプリの開発が必要です。対象外です。

通知のグループ化： 通知を5件個別に表示する代わりに、「プロジェクト Alpha にコメントが5件」と表示します。 あると便利な機能です。時間が必要なら削ります。

リアルタイム更新： 即時通知のための WebSocket です。あると便利な機能です。 V1 では60秒ごとのポーリングで問題ありません。

プロジェクトごとのカスタマイズ： 「プロジェクト X についてのみ通知する」といった設定です。複雑すぎます。 まずは全体設定のみから始めます。

対応しない項目

• メール通知は対応しません
• モバイルプッシュ通知は対応しません
• 通知音は対応しません
• ダイジェスト／サマリービューは対応しません
• チーム単位の設定は対応しません

リスク

リスク 1：データベースの負荷 大量の通知が作成される可能性があります。効率的なクエリが必要です。 軽減策： サイクルの最初の2日間で、テックリードが通知の保存方法について調査します。

リスク 2：UX の複雑さ 設定はすぐに複雑になる可能性があります。 軽減策： まずは3つの切り替え項目だけにします。プロジェクトごとの設定は設けません。

---

例 2：サイクル途中のスコープ見直し

入力：

「6週間のサイクルの4週目で、レポートダッシュボードを構築中です。遅れています。現状は、（1）予定していた5種類のグラフのうち、2種類のみ完了、（2）PDF へのエクスポートは未着手、（3）日付フィルターはほぼ完了、（4）リアルタイム更新は未着手です。スコープを見直してください。」

出力：

スコープの見直し：レポートダッシュボード

現在の状況（全6週のうち4週目）

項目	状況	必要な時間
グラフの種類（5種類を予定）	2種類完了	残り3種類に1.5週間
PDF へのエクスポート	未着手	1週間
日付フィルター	80％完了	2日
リアルタイム更新	未着手	1週間

残作業の合計：約4週間 残り時間：約2週間

分類

必須（中核となる価値の提供）：

• 少なくとも3種類のグラフ（折れ線、棒、円）—最も一般的なユースケース
• 日付フィルター—フィルタリングできなければ役に立ちません
• レポートの表示／読み込み—基本機能

あると便利（削除または延期）：

• 4種類目と5種類目のグラフ（テーブル、面）
• PDF へのエクスポート
• リアルタイム更新

推奨事項

今すぐ削る項目：

1. リアルタイム更新 → V2 に延期します。手動更新ボタンで問題ありません。
2. 5種類目のグラフ（面グラフ） → V2 に延期します。使用頻度は低いです。
3. PDF へのエクスポート → V2 に延期します。ユーザーがスクリーンショットを撮るか、後続の小規模バッチですぐに対応できます。

維持する項目：

1. 日付フィルター（2日で完了）
2. 3種類のグラフ（折れ線、棒、円。残り1種類に3～4日）
3. 4種類目のグラフ（テーブル）—データの確認に役立ちます（3日）

見直し後のスコープ

5週目：

• 1～2日目：日付フィルターを完了
• 3～4日目：円グラフを作成（3種類目）
• 5日目：テーブルビューを作成（4種類目）

6週目：

• 1～3日目：仕上げ、バグ修正、エッジケース対応
• 4日目：内部テスト
• 5日目：リリース

ステークホルダーへの説明

「4種類のグラフ（折れ線、棒、円、テーブル）と日付フィルターを備えた、完全に機能するダッシュボードをリリースします。エクスポートとリアルタイム更新は、次回の小規模バッチサイクルで速やかに追加します。

これにより、ユーザーに価値の90％を届けられます。残りの機能は仕上げであり、中核機能ではありません。」

サイクル後の小規模バッチ候補

• PDF へのエクスポート（2週間のバッチ）
• リアルタイム更新（2週間のバッチ）
• 面グラフ（1週間の追加対応）

---

例 3：ベッティングテーブルの実施

入力：

「次のサイクルに向けて、以下の5つの提案があります。どのようにベッティングテーブルを実施して、決定すればよいでしょうか？（1）検索機能の改善、（2）チーム権限、（3）モバイルアプリの再設計、（4）連携用 API、（5）オンボーディングの改善」

出力：

ベッティングテーブル：次のサイクル

作業前：ピッチレビュー

各ピッチは、以下の項目を整えてください。

• 明確な問題の説明
• アペタイト（2週間または6週間）
• 大まかな解決策
• 迷い込む可能性のある課題を特定
• やらないことを定義

評価：

ピッチ	整理済み？	アペタイト	必要なチーム
検索機能の改善	✓ はい	6週間	1D + 2E
チームの権限設定	✓ はい	6週間	1D + 2E
モバイルアプリの再設計	✗ 曖昧すぎる	?	?
インテグレーション用 API	✓ はい	6週間	0D + 3E
オンボーディングの改善	✓ はい	2週間	1D + 1E

モバイルアプリの再設計： 賭けの対象にできる状態ではありません。整理が必要です。 差し戻してください。今後のサイクルで検討します。

賭けの基準による評価

1. 検索機能の改善（6週間）

基準	スコア	備考
戦略との適合性	4/5	成長とユーザーの要望を後押し
問題の重要性	3/5	主にパワーユーザーにとっての課題
アペタイトとの適合性	4/5	範囲が適切に定められている
チームの対応可否	✓	チーム A が対応可能
依存関係	なし

判定： 候補

2. チームの権限設定（6週間）

基準	スコア	備考
戦略との適合性	5/5	エンタープライズ契約に必要
問題の重要性	5/5	販売の妨げになっている
アペタイトとの適合性	3/5	拡張する可能性があるため、規律が必要
チームの対応可否	✓	チーム B が対応可能
依存関係	なし

判定： 有力候補

3. インテグレーション用 API（6週間）

基準	スコア	備考
戦略との適合性	4/5	パートナーエコシステムを開拓
問題の重要性	3/5	重要だが緊急ではない
アペタイトとの適合性	4/5	まずは読み取り専用に範囲を限定
チームの対応可否	✓	チーム C が対応可能
依存関係	なし

判定： 候補

4. オンボーディングの改善（2週間）

基準	スコア	備考
戦略との適合性	5/5	アクティベーションに直接影響
問題の重要性	4/5	オンボーディング中の離脱率が40%
アペタイトとの適合性	5/5	小規模で、範囲が絞られている
チームの対応可否	✓	どのチームのサイクルにも組み込める
依存関係	なし

判定： 有力候補（小規模）

賭けの対象

対応可能なキャパシティ：

• 6週間の賭けに対応できるチームが2つ
• 1チームは2週間の追加作業を受け入れる余裕がある

決定：

賭け	チーム	理由
チームの権限設定	チーム B	エンタープライズの障害要因で、最も緊急性が高い
インテグレーション用 API	チーム C	戦略的な機会を切り開く
オンボーディングの改善	チーム A（1～2週目）	影響が大きく、投資は小さい
検索機能の改善	保留	良いが、現時点で最優先ではない

賭けの対象としないもの：

• モバイルアプリの再設計：整理ができていません。さらなる作業が必要です。
• 検索機能の改善：良いピッチですが、タイミングが合いません。次のサイクルに回します。

賭けの決定後のコミュニケーション

「次のサイクル：

• チーム B：チームの権限設定（6週間）
• チーム C：API v1（6週間）
• チーム A：オンボーディングの改善（2週間）、その後クールダウンタスク

検索機能は有力なピッチです。次々回のサイクルまで保留します。 モバイルアプリの再設計は、賭けの対象にできる状態になる前に、さらに整理する必要があります。」

---

チェックリストとテンプレート

ピッチテンプレート

## Pitch: [Feature Name]

### Problem
[What problem are we solving? Who has it? When?]

### Appetite
[2 weeks / 6 weeks]

### Solution

**Breadboard:**
[Flow diagram with words]

**Fat Marker Sketch:**
[Rough visual layout - no details]

### Rabbit Holes
[What could explode in scope? How are we preventing it?]

### No-Gos
[What are we explicitly NOT building?]

### Risks
[What could go wrong? How will we mitigate?]

---

賭けのテーブルのチェックリスト

## Betting Table: [Cycle Name]

### Before the Meeting
□ All pitches reviewed for completeness
□ Incomplete pitches sent back for shaping
□ Team availability mapped
□ Strategic priorities clear

### During the Meeting
□ Review each complete pitch
□ Assess against betting criteria
□ Discuss dependencies and timing
□ Make binary decisions (bet / don't bet)
□ Assign teams to bets

### After the Meeting
□ Communicate decisions to teams
□ Archive or park unbetted pitches
□ Schedule cycle kickoffs
□ Clear any dependencies

---

スキルの範囲

このスキルが得意なこと

• オーディオ制作ワークフローの構成
• 技術的なガイダンスの提供
• 品質チェックリストの作成
• クリエイティブなアプローチの提案

このスキルではできないこと

• オーディオエンジニアリングの専門知識に取って代わること
• 主観的なクリエイティブ上の判断を下すこと
• オーディオファイルに直接アクセスまたは編集すること
• 商業的な成功を保証すること

参考資料

• Singer, Ryan. 『Shape Up: Stop Running in Circles and Ship Work that Matters』（2019年）
• Basecamp の方法論に関するドキュメント
• 37signals（Basecamp）のブログ記事
• Shape Up に関するポッドキャスト出演

Related Skills

• product-discovery - Discovery before shaping
• design-sprint - Alternative sprint format
• lean-canvas - Business model context
• first-principles - Problem definition

---

Skill Metadata

• Mode: cyborg

name: shape-up
category: product
subcategory: methodology
version: 1.0
author: MKTG Skills
source_expert: Ryan Singer
source_work: Shape Up
difficulty: intermediate
estimated_value: $5,000+ process consulting
tags: [product, process, Basecamp, cycles, shaping, scope, betting, development]
created: 2026-01-25
updated: 2026-01-25