shape-up

ドメインのコンテキスト

このスキルは、実績のあるプロダクトマネジメントのフレームワークを実装しています。このアプローチは業界をリードする企業のベストプラクティスを組み合わせ、日々のPM業務で実践できるよう設計されています。

入力要件

• プロダクト、機能、または課題に関するコンテキスト
• 関連データ、調査結果、または制約（推奨ですが任意です）
• 達成しようとしていることを明確に説明したもの

Shape Up

概要

Shape Upは、ひとつの重要な洞察に基づくプロダクト開発手法です。リリースまでの期間を見積もるだけでは、リリースにはたどり着けません。解決策を形作ることで、そこにたどり着く必要があります。

従来のアプローチでは、「これにはどれくらい時間がかかりますか？」と尋ね、その見積もりどおりに進めようとします。Shape Upでは、これを逆転させます。まず、どれだけの時間を費やす意思があるか（アペタイト）をあらかじめ決め、その制約内に収まる解決策を形作ります。

この手法は、Basecampの構築に取り組んだ17年間の中で生まれました。創業チームは、唯一のエンジニア（DHH）が週にわずか10時間しか働けないという特殊な制約に直面していました。そのため、何を作るかを極めて明確にし、1時間たりとも無駄にしないよう、範囲を徹底的に絞り込む必要がありました。

重要な転換点：「これはどれくらいの見積もりですか？」から、「費やす意思のある期間内に、自信を持ってリリースできるのはどのバージョンですか？」へと考え方を変えます。

使用する場面

次のような場合にShape Upを使用します。

• プロジェクトの長期化を防ぐ — 数週間で終わるはずの作業に数か月かかっている
• 見積もりの罠から抜け出す — いつも外れる見積もりにうんざりしている
• チームに真の自律性を与える — チケットをこなすだけではない
• 会議の負担を減らす — Scrumの儀式に時間を取られている
• 意味のあるまとまりでリリースする — 細かなチケットを積み上げるだけではない
• プロダクトとエンジニアリングの連携を図る — 現状では両者の間に壁がある
• スタートアップのスピードを維持する — 30～50人を超える規模へ拡大していく

使用しない場面

• 3人以下のチームの場合 — お互いに話し合えば十分です
• 実質的な複雑さがない場合
• エンジニアリングチームをシェーピングに参加させられない場合
• 経営陣の賛同が得られていない場合
• 純粋な保守作業を行っている場合

リソース

書籍：

• Ryan Singer著『Shape Up』（basecamp.com/shapeupで無料公開）
• Bob Moesta著『Demand-Side Sales 101』

さらに読む

• Shape Up