前提設計：成果を出す前に、判断を壊さない"土台"を作る
「何をやるべきか分からない」
この状態は、能力不足でも、情報不足でもありません。
多くの場合、前提が揃っていないだけです。
前提が揃っていないまま施策を足すと、起きることはだいたい決まっています。
- 会議で合意したはずなのに、実行がズレる
- データを見ても結論が割れる
- 頑張っているのに成果が薄い
- 改善が「感想戦」になる
私たちは、正解を当てる方法を売りません。
不確実な現場で、判断が壊れない条件を揃えることを重視します。
そのための最初の仕事が、前提設計です。
この記事が想定する読者：「何をやるべきか」が定まらないが、前提のズレが原因だと感じている担当者。
判断を誤るとどうなるか：前提を揃えずに施策を足すと、合意したのに実行がズレる・データで結論が割れる・改善が感想戦になる。先に目的・制約・現状・判断基準の4ブロックを言葉にしてから施策を選ぶと失敗しにくい。
前提設計とは何か
前提設計とは、答えを出す技術ではありません。
答えが壊れない条件を揃える技術です。
「施策」や「手法」を選ぶ前に、
- 何のために
- どこまでなら許容できて
- 何が分かっていて
- どうなったら成功（または撤退）なのか
を、判断可能な言葉にします。
ここが曖昧だと、どれだけ正しい施策でも、噛み合いません。
前提がズレると起きる典型症状
以下に当てはまるほど、前提設計の優先度が上がります。
- 施策が増えるほど成果が出なくなってきた
- 「まず何をすべきか」で意見が割れる
- レポートは見ているのに意思決定が進まない
- “改善”が、良かった/悪かったの言い合いになっている
- 外注しても内製しても、結果が安定しない
これは、担当者の問題ではありません。
前提が共有されていない状態で最適化しようとしているのが原因です。
前提設計の4ブロック（これが核）
前提設計は、4つのブロックで整理します。
| ブロック | 内容 |
|---|---|
| A：目的 | 何を増やす/減らす |
| B：制約 | 時間・予算・権限・リスク耐性 |
| C：現状 | データ・現場・顧客理解 |
| D：判断基準 | やる/やらない・続ける/止める |
この4つが揃うと、施策は迷いにくくなります。
逆に、1つでも欠けると、判断はすぐに歪みます。
A：目的（何を増やす/減らす）
目的は「売上」だけではありません。
本当に増やしたいのは、例えばこういうものかもしれません。
- 指名の問い合わせ
- 継続率
- 予約の質（キャンセル率低下）
- 紹介率
- 工数削減
- クレーム減少
重要なのは、目的を数値にすることではなく、
判断できる言葉にすることです。
例：
「問い合わせを増やす」ではなく
「比較検討が進んだ状態の指名問い合わせを増やす」
B：制約（壊れない範囲を決める）
ここが曖昧なままだと、プロジェクトは壊れやすくなります。
制約は「できる/できない」の話ではなく、
壊れない範囲（失敗耐性）の話です。
- いつまでに何を確認したいのか
- 使える工数はどれくらいか
- 失敗しても許容できるコストはどこまでか
- 誰が決めるのか（権限）
制約を決めるのは、ブレーキではありません。
前に進むための路面を作る作業です。
C：現状（データは"取得方法"で歪む）
現状把握で最も多い誤解があります。
それは、
「データは中立である」という思い込みです。
実際は逆です。
データは、取得方法が結論を作ります。
アンケートを例にすると分かりやすいです。
| 取得方法 | 起きやすい歪み |
|---|---|
| 手渡し | 悪いことが書けない |
| 店内の投函BOX | スタッフの視線が気になる |
| Web | 回答の温度感が変わる |
| クーポン配布 | 批判が沈黙しやすい |
つまり、アンケートは「質問内容」だけでなく、
状況設計（回収導線・匿名性・特典）で回答が誘導されます。
この話は別記事で詳しく扱います。
アンケートは内容より"状況"で歪むD：判断基準（やる/やらない・続ける/止める）
ここがないと、プロジェクトは"やりっぱなし"になります。
判断基準は2つです。
- 採用基準（次の一手に進む条件）
- 撤退基準（途中で止める条件）
撤退基準があると、失敗が怖くなくなります。
怖くなくなると、小さく試せます。
試せると、検証が回ります。
結果として、前進が速くなります。
前提は「環境」の質も決める（パーソナルスペース）
前提設計は、数字や文章だけの話ではありません。
環境も前提です。
例えば店舗や施設なら、
- 人が多すぎるとストレスが増える
- ストレスが増えると滞在が短くなる
- 滞在が短いと満足度と継続率が落ちる
ここで重要なのは、
定員は「最大収容人数」ではなく、
快適人数（心理的に壊れない上限）で決めることです。
快適人数が決まると、
- 回転率
- スタッフ負荷
- 体験品質
- 収益上限
- 投資上限
まで逆算できます。
この話は別記事で扱います。
パーソナルスペースを設計値にする：快適定員→収益上限前提は「AI」の性能も決める（AIは優秀な新人）
AI活用も同じです。
AIは魔法ではありません。
優秀な新人に近い存在です。
新人が能力を発揮できる条件は、だいたい同じです。
- 栄養（良いデータ）がある
- 規律（前提・評価基準）がある
- 禁止事項が明確
- 目的が共有されている
逆に言うと、AI活用の失敗原因は
AIの性能よりも、前提の未整理であることが多いです。
この話は別記事で詳しく扱います。
AIは優秀な新人：栄養と規律で性能が決まる前提は「投資と回収」も決める（上限予算は失敗耐性から）
制作やコンサルの見積もりで、最も多い悩みはこれです。
「いくらまで出していいのか分からない」
ここでFirst byteは、費用対効果を断定しません。
不確実性があるからです。
代わりに、先に決めるべきものがあります。
上限予算は"失敗耐性"から決める
- 失敗しても撤退できる金額
- 失敗しても資金繰りが壊れない金額
- 失敗しても人が疲弊しない金額
そして回収は、売上だけではありません。
- 学習（何が分かったか）
- 再現性（次に活かせるか）
- 内製化（自社の力が増えたか）
この話も別記事で扱います。
上限予算は失敗耐性から決める：投資と回収の前提設計（制作・コンサル・施策全般に効く型）。AI導入に特化した応用はAI導入の投資対効果で解説しています。前提設計シート（15問）｜まずこれだけ埋めてください
完璧に書く必要はありません。
未完成でもいいので、一度"言葉にする"のが重要です。
前提は、仮説として置いて、更新していけばいい。
A 目的（3問）
- この取り組みで「増やしたいもの」は何ですか？（例：指名問い合わせ／継続率）
- 「減らしたいもの」は何ですか？（例：離脱／不安／工数／クレーム）
- それが達成されたと判断できる"1行定義"は？
B 制約（4問）
- 期限はいつですか？（いつまでに何を確認したい？）
- 使える総工数（社内含む）はどれくらいですか？
- 失敗しても許容できるコスト（失敗耐性）はどこまでですか？
- 意思決定者と、決定できる範囲（権限）は？
C 現状（5問）
- 現状の数字で"信頼できるもの"は何ですか？（GA4/売上/来店など）
- 逆に"信頼できない/欠けている"データは何ですか？
- 顧客が来る直前の動きは、どこまで分かっていますか？（検索/紹介/地図など）
- 現場で起きている"違和感"は何ですか？（摩擦・詰まり）
- 現時点で観察/取得できるデータは何ですか？（ログ/観察/簡易アンケ）
D 判断基準（3問）
- 今回「やらない」と決めることは何ですか？（除外ルール）
- 途中で止める条件（撤退基準）は何ですか？
- 次の一手に進む条件（採用基準）は何ですか？
本記事は前提設計の4ブロック・15問チェックリストに特化しています。実際の運用の優先順位や成果は目的・組織・領域により異なるため、前提設計とは何か（7点セット）や改善プロトコル・Method完全ガイドとあわせて自社の前提に合わせた判断をおすすめします。
判断の土台として押さえておくこと
- 前提設計は「正解を出す」ではなく「答えが壊れない条件を揃える」：目的・制約・現状・判断基準を判断可能な言葉にしておく。
- 4ブロック・15問を一度で完璧にしなくていい：未完成でもいいので、揃っていない前提を明示し、揃うところから判断する。
- 前提が揃うほど施策は速く回る：迷いが減り、検証が回り、意思決定が速くなる。ここが揃うまで施策を足さない運用も有効。
次の一手：前提設計とは何か（チェックリスト）／改善の正解探しをやめる／First byte Method 完全ガイド
前提が揃うと施策は速く回る
前提設計は、遠回りに見えるかもしれません。
でも実務では、ここが揃うほど
- 迷いが減り
- 検証が回り
- 意思決定が速くなり
- 成果が安定します
First byte Method は、
不確実性の中で、判断を壊さないためのプロトコルです。
前提設計の7点セットとそのまま使えるチェックリスト（A〜G）は前提設計とは何かで、「改善を止めない進め方（仮説→検証）」は"改善の正解探し"をやめるで、「何をどこから手をつけるか」の全体像はFirst byte Method 完全ガイドで解説しています。