前提設計とは何か
判断が壊れない条件を先に作る（チェックリスト付き）｜First byte Method
施策が失敗する原因は、手法不足ではありません。
ほとんどは、もっと手前で壊れています。
- 何を目指しているのか曖昧
- 何が制約なのか曖昧
- どこまでが確定で、どこからが推測か曖昧
- 成功の定義が曖昧
この状態で施策に入ると、現場はこうなります。
- 意見が散らかる
- 施策が増える
- 検証が弱い
- 結果が出ない
- 「結局なにが効いたの？」が残る
だからFirst byte Methodは、最初にこうします。
施策の前に、判断が壊れない条件を作る。
これが「前提設計」です。
この記事が想定する読者：施策・施設・AI・アンケートなどで前提が曖昧になりがちで、最小セットとチェックリストで揃えたい担当者。
判断を誤るとどうなるか：前提が曖昧なまま進めると、同じ会議で別のゲームを追い、結論が出ない・検証が弱い・「何が効いたか」が残らない。先に7点最小セット（目的・対象・制約・成功・参照・指標・撤退）を埋めてから施策を開始すると失敗しにくい。
1. 結論：前提設計は「地図」と「ルール」を作る作業
前提設計は、思考の準備運動ではありません。
実務上の成果物です。
| 種類 | 内容 |
|---|---|
| 地図 | 何をどこまで見るか（範囲・対象） |
| ルール | 何を根拠に決めるか（判断基準・制約） |
この2つが揃うと、議論は早くなり、検証は強くなります。
前提設計の4ブロックと15問シートは、前提設計：成果を出す前に、判断を壊さない土台を作るで解説しています。
2. なぜ前提がないと壊れるのか：判断が"別のゲーム"になる
前提が曖昧だと、人は無意識に違うゲームを始めます。
- 売上最大化ゲーム
- リスク回避ゲーム
- 体験品質ゲーム
- 自分の正しさゲーム
- 説得ゲーム
すると、同じ会議で別の目的を追い始める。
当然、結論は出ません。
前提設計は、こう言い換えられます。
全員が同じゲームをするための「ルールブック」
3. 前提設計の成果物（最小セット）
前提設計は、長文にしなくていい。
最小はこれだけで回ります。
- 目的（増やす/減らす）
- 対象（誰/どこ/いつ）
- 制約（やらないこと）
- 成功条件（合格ライン）
- 参照元（一次情報）
- 検証指標（観察項目）
- 撤退条件（戻す条件）
この7点が揃えば、判断は壊れにくい。
4. First byte式：前提設計チェックリスト（そのまま使える）
ここからが実務用です。
そのままコピペして使える形にします。
A. 目的（Purpose）
- [ ] 何を「増やす/減らす」かが1行で言える
- [ ] 優先順位がある（複数目的なら順位を付けた）
- [ ] "やらない目的"も明記した（例：短期売上最優先はしない）
B. 対象（Scope）
- [ ] 対象ユーザー/顧客は誰か
- [ ] 対象の場所/ページ/工程はどこか
- [ ] 期間（いつからいつまで）を決めた
- [ ] 対象外を決めた（範囲の固定）
C. 制約（Constraints）
- [ ] 法務/規約/ブランド上の禁止事項がある
- [ ] 予算・工数の上限がある
- [ ] 変更できない条件（固定資産/契約/構造）を列挙した
- [ ] 可逆性（戻せる改善）を優先する
D. 成功条件（Success）
- [ ] どの状態なら「成功」と言えるか
- [ ] 最低合格ライン（Must）と理想（Nice）を分けた
- [ ] "悪化したら失敗"の指標もある
E. 参照元（Source of Truth）
- [ ] 一次情報はどこか（URL/資料/責任者）
- [ ] 情報の更新日を把握している
- [ ] 矛盾がある場合の優先順位が決まっている
- [ ] 推測は禁止、要確認タグ運用をする
F. 検証指標（Metrics）
- [ ] 観察指標が決まっている（待ち上位10%、離脱率など）
- [ ] 「変わったら支持/変わらなかったら棄却」が言える
- [ ] 計測の頻度と期間が決まっている
- [ ] ノイズ（季節性/曜日/キャンペーン）の扱いを決めた
観察指標の設計は、施設のストレスを測ると定員数の算出で扱っています。
G. 撤退条件（Exit）
- [ ] 何が起きたら戻すかを先に決めた
- [ ] 期間の上限（2週間/1ヶ月など）が決まっている
- [ ] 負担が増えた場合の停止条件がある
- [ ] "学習として残す項目"が決まっている（例外集）
仮説→検証の進め方と撤退条件の置き方は、"改善の正解探し"をやめるで解説しています。
5. 前提設計が効く場面：全部に効く（だから"万物の土台"）
「万物の土台」は誇張ではありません。
前提設計は、領域を問わず効きます。
- 施策（SEO/広告/UX/導線改善）
- 施設設計（定員・快適域・動線）
- AI運用（質問テンプレ・レビュー・KPI）
- サービス設計（投資と回収・上限予算）
- アンケート（取得→解釈→運用）
全部、前提が薄いと壊れます。
施設の定員と快適域はパーソナルスペースを"設計値"にすると混雑を増やす前にやること、投資と回収の前提設計は上限予算は失敗耐性から決める、AI運用の前提はAIは優秀な新人とAI時代の文章品質管理で扱っています。
6. 使い方：会議や制作の"開始条件"にする
最も強い運用はこれです。
前提設計が埋まっていない施策は開始しない
厳しそうに見えますが、実際は逆です。
無駄が減って、前に進みます。
本記事は前提設計の定義・7点最小セット・チェックリストに特化しています。実際の運用の優先順位や成果は目的・組織・領域により異なるため、前提設計の土台や改善プロトコル・Method完全ガイドとあわせて自社の前提に合わせた判断をおすすめします。
判断の土台として押さえておくこと
- 前提設計の成果物は「地図」と「ルール」：何をどこまで見るか（範囲・対象）と、何を根拠に決めるか（判断基準・制約）を書く。
- 7点最小セットを揃える：目的・対象・制約・成功条件・参照元・検証指標・撤退条件。揃うと判断は壊れにくくなる。
- 前提が埋まっていない施策は開始しない：運用の開始条件にすると、無駄が減り前に進む。
次の一手：前提設計の基礎（4ブロック・15問）／改善の正解探しをやめる／First byte Method 完全ガイド
前提設計は「判断の品質」を守る技術
- 手法より先に、条件を揃える
- 地図（範囲）とルール（基準）を作る
- 7点セット（目的/対象/制約/成功/参照/指標/撤退）が最小
これがFirst byte Methodの土台になります。
前提設計の4ブロックと15問シートは前提設計：成果を出す前に、判断を壊さない土台を作るで解説しています。仮説→検証の進め方は"改善の正解探し"をやめる、観察指標と閾値は施設のストレスを測ると定員数の算出、改善の優先順位は混雑を増やす前にやることで扱っています。Method全体はFirst byte Method 完全ガイドをご覧ください。