scoping-cutting について
プロジェクトの範囲を決め、機能を絞るためのプロダクト計画スキルです。固定の時間枠、仮説検証、小さく完結した初期スコープを扱います。
主な機能
- 01検証する仮説の明確化
- 02固定した時間枠の設定
- 03初期版に必要な要素の特定
- 04開発前の手動検証
- 05方向転換や中止の選択肢
活用シーン
- 01製品の初期版の範囲決め
- 02時間枠に合わせた機能削減
- 03自動化せずに需要を検証
- 04遅延した作業の中止判断
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/scoping-cuttingを入力して読み込まれたか確認します。
同梱ファイルreferences/guest-insights.md
詳細
スコープ設定と機能の削減
15人のプロダクトリーダーが用いるフレームワークを活用し、ユーザーがプロジェクトのスコープを設定し、効果的に機能を削減できるよう支援します。
支援の進め方
ユーザーからスコープ設定の相談を受けたら、次のように進めます。
- 仮説を理解する - 何を学ぼうとしているのか、何を検証したいのかを尋ねます
- 投入できる時間を把握する - どれだけの時間やリソースを投入する意思があるのかを見極めます
- 不可欠なコアを見つける - 初回バージョンに必ず含めるべきものを特定できるよう支援します
- 学びにつながる設計にする - ただ迅速にリリースするだけでなく、すばやくフィードバックを得られるスコープにします
基本原則
見積もりではなく、投入できる時間を基準にする
Ryan Singer：「逆の方向から考えて、何かを実際に完成させるまでに許容できる最大の時間はどれくらいか、と問いかけます。」固定の時間枠（投入できる時間）を設定し、その範囲に収まる解決策のバージョンを設計します。期限ではなく、スコープを調整します。
MVPは検証のためのツール
Eric Ries：「MVPとは、検証しようとしている仮説が何であれ、その仮説が正しいかどうかを確かめるために必要な検証を、最も効率的に得る方法にすぎません。」MVPは低品質な製品ではなく、特定の仮説を検証する最も効率的な方法です。
リストを半分にし、さらに半分にする
Eric Ries：「MVPに必要な機能のリストを書き出してください。それを半分にし、さらに半分にして、そこから作り始めます。」創業者は「最小限」に必要なものを一貫して過大評価します。本当の最低ラインにたどり着くには、大胆な削減が必要です。
固定された期間と少人数のチーム
Jason Fried：「個々の機能にかける期間は、どれも最長で6週間です……だから、6週間以内に2人で完成させるために、最もシンプルで効果的なバージョンを考えなければなりません。」制約が創造的な解決策を促します。集中を保つため、チームの人数を制限します。
車軸ではなく、スクーターを作る
Eeke de Milliano：「車のMVPを作ろうとしているなら、車輪と車軸だけを作るのではなく、まずスクーターを作ってください。」MVPは、より大きな価値提案の未完成な一部分ではなく、より小さな価値提案をエンドツーエンドで実現する、機能するバージョンであるべきです。
ウィザード・オブ・オズ方式でテストする
Crystal W：「まさにウィザード・オブ・オズのような体験です。何も作る必要はありません。インターン何人かと協力し、価値提案を検証できました。」エンジニアリングに投資する前に、手作業で価値提案を検証します。自動化された機能を人間が再現します。
期限内に完成しないプロジェクトは終了する
Jason Fried：「丘の左側に残っている作業、つまり、まだ押し上げている途中で、どう進めるか分からず、期限を迎えてしまった作業があれば、そのプロジェクトはほぼ確実に終了です。」終わりのない作業を防ぐため、割り当てられた期間内に完成しなかったプロジェクトは終了させます。
ピボットの選択肢をプロセスに組み込む
Paige Costello：「ロードマップに載せたら必ず実行しなければならないように感じていたので、ロードマップに載せたものでも、ピボットしたり削除したりする可能性をプロダクトのプロセスに加えました。」ロードマップ上の項目を削除したり、方向転換したりできる仕組みを正式に設け、サンクコストの誤謬を避けます。
ユーザーを支援するための質問
- 「このバージョンで検証しようとしている、唯一の仮説は何ですか？」
- 「何かをリリースするまでに、最大でどれくらいの時間を投入できますか？」
- 「半分の期間でリリースしなければならないとしたら、何を削りますか？」
- 「自動化を構築する前に、手作業でテストする方法はありますか？」
- 「この機能が期限内にリリースできなかったら、終了しますか、それとも延長しますか？」
- 「完全な価値を届けられる、最小のものは何ですか？」
よくある、注意すべき間違い
- 見積もるだけで、期間を区切らない - 「X 週間で何ができるか？」ではなく、「どれくらいかかるか？」と尋ねること
- 車軸を作る - より大きな機能の未完成な部分をリリースするのではなく、小さな機能を完成させてリリースすること
- プロジェクトを決して打ち切らない - 範囲を縮小したり中止したりせず、期限を延長すること
- MVP を過剰に作り込む - 中心となる仮説を検証する前に、作り込みすぎること
- オズの魔法使いの手法を無視する - 手作業で検証したほうが早い場合でも、常に開発を選ぶこと
詳細
15 人のゲストから得た 19 の知見については、references/guest-insights.md をご覧ください。
関連スキル
- ロードマップの優先順位付け
- 不確実性を考慮した計画
- 問題の定義