フレームワーク活用ガイドひとことで言うと#
6週間の固定サイクルで開発を回し、「何をつくるか」の輪郭（Shape）を事前に整えてからチームに渡すプロジェクト管理手法。Basecampが自社の開発プロセスとして体系化し、スクラムに代わる選択肢として注目されている。
押さえておきたい用語#
- Shaping（シェイピング）
- 開発に着手する前に、アイデアの**輪郭（方向性と制約）**を決める工程。細かい仕様は書かず、解決すべき問題と大まかなアプローチを定義する。
- Appetite（アペタイト）
- あるプロジェクトに「どれだけの時間をかける価値があるか」という時間予算。見積もりではなく、ビジネス判断として先に決める。
- Betting Table（ベッティングテーブル）
- 次のサイクルで何に取り組むかを決める意思決定の場。経営層やシニアメンバーが集まり、Shapingされた提案に「賭ける」かどうかを判断する。
- Cooldown（クールダウン）
- 6週間サイクルの間に挟む2週間の自由期間。バグ修正・技術負債の解消・個人プロジェクトなどに使う。
- Hill Chart（ヒルチャート）
- 作業の進捗を「登り坂（不確実性の解消）」と「下り坂（実装）」で表す独自の可視化ツール。
Shape Upの全体像#
こんな悩みに効く#
- スプリントが短すぎて、意味のある機能を出し切れない
- 見積もりに時間をかけているのに、毎回スケジュールが遅れる
- バックログが肥大化して、何から手をつけるべきかわからない
基本の使い方#
シニアメンバー（PM・デザイナー・テックリード）が、開発チームに渡す前に「何を解くか」の輪郭を固める。
- 問題を明確にする: 「ユーザーが請求書をPDFで出力できない」など具体的に
- Appetiteを決める: この問題に6週間（Big Batch）か2週間（Small Batch）のどちらをかけるか
- 解決策のスケッチ: ワイヤーフレームほど詳細ではなく、ファットマーカーで描ける程度の粗さ
- ラビットホール（落とし穴）を特定: 「ここは想定外に時間がかかりそう」というリスクを先に洗い出す
Shapingされた提案を経営層が評価し、次の6週間で何に取り組むかを決定する。
- バックログは使わない。前回採用されなかった提案は自動的にリセットされる
- 「まだ重要なら、また誰かがShapingするはず」という考え方
- 1〜2個のBig Batch + 数個のSmall Batch が典型的な構成
採択されたプロジェクトを、デザイナー1名＋プログラマー1〜2名の小チームに渡す。
- タスクの分解はチーム自身が行う。マネージャーがタスクを割り振らない
- Hill Chartで進捗を可視化。「登り坂にいる」なら不確実性が残っている
- 6週間で終わらなければ打ち切り。延長はしない（Circuit Breaker）
具体例#
Basecamp（現37signals）は約50名の組織で、Shape Upを10年以上運用している。
典型的なサイクルの例：CEO ジェイソン・フリードが「メールの返信が面倒」という問題をShapingし、Appetiteを6週間に設定。デザイナー1名＋プログラマー2名のチームが、メールクライアント「HEY」のスクリーニング機能を開発した。
ポイントはスコープの柔軟な調整。開発中に「全メールのカテゴリ分けは6週間では無理」と判断し、「初回受信時の振り分けのみ」にスコープを縮小。結果、6週間以内にリリースでき、ユーザーの 72% が初週から利用した。
バックログを持たないことで、チームが「過去の未処理タスク」に心理的に圧迫されることがなくなったという。
福岡のHRテックSaaS企業（従業員30名、エンジニア12名）は、2週間スプリントで運用していたが、3つの問題を抱えていた。
| 問題 | 状況 |
|---|---|
| スプリント内で完了しない | 完了率 58%、毎回持ち越しが発生 |
| 見積もり会議が長い | 週2時間×12名 = 月96人時をプランニングに消費 |
| バックログが膨れる | 未着手チケット 340件、優先順位がつかない |
Shape Upに移行し、6週間サイクル＋2週間クールダウンで回した結果：
- サイクル内完了率が 58% → 91% に改善（スコープを柔軟に調整できるため）
- プランニング時間は月96人時 → 12人時 に削減（Betting Tableは経営層3名で1時間）
- バックログを全廃。340件のチケットを一度ゼロにして、本当に重要なものだけが再度Shapingされた
エンジニアからは「6週間あると、腰を据えて設計できる」という声が上がった。
東京のEdTechスタートアップ（5名）は、オンライン学習プラットフォームのMVPを開発するにあたり、Shape Upを採用。少人数ゆえに「全員がShapingにもBuildingにも関わる」体制で運用した。
| サイクル | Appetite | 成果 |
|---|---|---|
| 第1サイクル | 6週間 | 動画再生＋進捗管理の最低限MVP |
| 第2サイクル | 6週間 | クイズ機能＋受講証明書の自動発行 |
| 第3サイクル | 2週間×3本 | 決済連携・メール通知・管理画面改善 |
18週間（約4.5ヶ月）で有料版をローンチ。スクラムで進めた場合の見積もりは7ヶ月だったため、約35%の期間短縮を実現した。
「Appetiteを先に決めることで “これは2週間の問題か、6週間の問題か” という議論が自然に始まり、過剰な機能を入れずに済んだ」とCTOは振り返る。
やりがちな失敗パターン#
- Shapingが雑すぎる — 「ユーザー体験を改善する」のような抽象的なShapingでは、チームが何を作ればいいかわからない。問題・Appetite・大まかなアプローチの3点は必須
- 6週間を「締め切り」としてプレッシャーをかける — Shape Upのサイクルは「時間予算」であり、デスマーチの道具ではない。時間内に終わらない場合はスコープを削る、または次サイクルで再提案する
- バックログ廃止に踏み切れない — 「いつかやる」リストを温存すると、Shape Upの最大の利点である「毎サイクル白紙から始める」が機能しなくなる
- Cooldownを省略する — 技術負債が蓄積し、6週間の生産性が徐々に低下する。Cooldownは「サボり期間」ではなく投資期間
- 全員がShapingに参加しようとする — Shapingは少人数（2〜3名）で行うもの。全員参加にすると合意形成に時間がかかり、結局スクラムのプランニング地獄に逆戻りする
まとめ#
Shape Upは「見積もりではなくAppetite（時間予算）を先に決める」「バックログを持たない」「6週間で出し切れなければ打ち切る」という、従来のアジャイルとは異なる思想のプロジェクト管理手法。Basecampが自社で磨き上げたこの方法は、特に少人数チームで「意味のある単位の機能を出し切る」のに向いている。スクラムの2週間スプリントが合わないと感じたら、試す価値がある。