前提設計：成果を出す前に、判断を壊さない"土台"を作る

前提設計とは、施策を選ぶ前に「何を良くしたいか」「どの条件で判断するか」を揃えることです。 同じ売上の数字を見ても、短期の受注を優先するのか、現場の負担を減らすのかで、選ぶ案は変わります。

本記事では、目的・制約・現状・判断基準の4枠と、確認に使う15の質問を示します。これはFirst byteが実務を整理するための形式です。失敗のすべてが前提不足で起きるわけではなく、項目を埋めるだけで成果や判断の正しさが保証されるわけでもありません。

30秒で要点

• 目的、制約、現状、判断基準を分けて書きます。
• 「確認した事実」「仮説」「希望する状態」「不明なこと」を混ぜません。
• 分からない項目を無理に埋めず、結論が変わるものから確かめます。
• 前提は固定する約束ではありません。変化を検知したら、理由と日付を残して更新します。
• 調査、AI、投資などの個別の妥当性は、前提を揃えた後にも別途確認が必要です。

どこから読むか — 自分の状況から選ぶ

この記事は前提設計の土台を扱います。具体的な設計対象はそれぞれ別の記事にあります。

前提設計そのものを確認したい。 定義とチェックリストは前提設計とは何か、改善の進め方は「改善の正解探し」をやめる、予算の決め方は上限予算は「失敗耐性」から決める。

AIに任せる範囲を決めたい。 権限の線引きはAIに任せる範囲の決め方、人の扱いに近い見立てはAIは優秀な新人、確認の設計はAIレビューの設計、例外の集め方は例外集の作り方、問いの立て方はAIの質問力を設計する。

AIの効果を測りたい。 指標の設計はAI運用のKPI設計、投資対効果はAI導入の投資対効果、品質の管理はAI時代の文章品質管理、体感より遅れて出る効果はCFO734人調査に見るAI生産性の実態。

場所や人数の設計をしたい。 定員の出し方は定員数の算出、収益との関係は定員＝収益上限ではない、距離の設計値化はパーソナルスペースを"設計値"にする、混雑への対処は混雑を増やす前にやること、環境の測定は施設のストレスを測る。

アンケートの数字を疑いたい。 状況による歪みはアンケートは内容より"状況"で歪む、満足度と離脱のずれは満足度は高いのに離脱が減らない理由。

前提が揃っていないと、何が起きるか

架空の会社で、営業は問い合わせ数を増やしたい、現場は対応できない相談を減らしたい、経営は利益の残る受注を増やしたいと考えているとします。この状態で「問い合わせ数を増やす施策」を採用しても、全員の目的が満たされるとは限りません。

これは誰かが間違っているというより、目的と制約が別々のまま議論されている状態です。何を増やし、何を増やしたくないかを共有すると、比較する案が変わります。たとえば、広告を広げる案と、依頼条件を明確にする案では、評価すべき指標も異なります。

一方、目的が一致していても、実装の不具合や外部環境の変化で失敗することはあります。前提設計は、問題の原因を一つに決める説明ではなく、今回どの条件で判断したかを後から確認する準備です。

4つの枠で、決めることと不明点を分ける

表が収まらない場合は、横にスクロールできます

すべてを同じ精度で調べる必要はありません。後から戻せる小さな変更と、長期契約や広い公開を伴う変更では、確認の負担を変えます。ただし、曖昧さが残るなら、その分だけ判断の適用範囲も狭くします。

そのまま使える15の質問

A. 目的を揃える3問

1. 何を増やしたいか。 売上、利益、利用継続、作業の余裕など、今回の中心を選びます。
2. 何を減らしたいか。 誤解、不要な問い合わせ、手戻り、利用者や担当者の負担などを挙げます。
3. 達成した状態を一文で言えるか。 対象、期間、観察方法を含めます。測れない部分も明記します。

「サイトを良くする」なら、「初めて検討する人が、依頼できる条件と費用の考え方を理解できる」のように分けられます。ここで具体化した目標が本当に重要かは、利用者と業務の両方から確認します。

B. 制約を揃える4問

1. いつまでに、何を決める必要があるか。 実施期限と、判断する期限を分けます。
2. 社内で合計どれだけの時間を使えるか。 制作だけでなく、承認、確認、問い合わせ対応、保守を含めます。
3. どこまでの費用と負担を引き受けられるか。 支払額、継続費、やり直しや撤退の費用も確認します。
4. 誰が決め、誰が止められるか。 実行担当と最終判断者が違う場合は、境界を明記します。

予算が大きいほど良い確認ができるとは限りません。限られた予算で何を知る必要があるかを決め、確認に使う費用と本番実施の費用を分けます。負担上限を決めても、その額を使い切る理由にはなりません。

C. 現状を揃える5問

1. いま信用して使える数字は何か。 期間、対象、分母、収集方法まで確認します。
2. 不明、古い、信頼しにくい情報は何か。 ゼロと欠損、事実と予想を分けます。
3. 利用者は、ここへ来る前に何を見聞きしているか。 広告、紹介、検索、前の接点を調べます。
4. 現場のどこで困りごとや手戻りが起きているか。 印象だけでなく、観察できる場面を挙げます。
5. すでに使えるログ、観察記録、問い合わせ、調査はあるか。 新たに集める前に、利用可能な範囲と品質を確認します。

英国政府のデータ品質フレームワークは、用途に合う品質かを考え、完全性、重複、鮮度、形式上の妥当性、実際の正確さなどを区別しています。欠損がない表でも、値そのものが正しいとは限りません。

また、観察したことと意味づけを分けます。GOV.UKの調査分析ガイドでも、観察・解釈・次の行動を区別しています。「条件説明を読み直した」は観察、「説明に不信感を持った」は追加確認が必要な解釈です。

D. 判断基準を揃える3問

1. 今回は何をしないか。 対象外の顧客、ページ、業務、変更を明記します。
2. 何が起きたら止める、戻す、保留するか。 費用、時間、誤案内、利用者への影響などを具体化します。
3. どんな根拠が揃えば採用するか。 主な指標と、悪化させたくない条件、不確実性の扱いを先に決めます。

採用基準は、結果を見て都合よく変えるためのものではありません。事業条件が変わり基準を見直す必要があれば、変更理由と時点を残し、それまでの結果を当初の基準でも確認できるようにします。

回答に、情報の状態と担当者を付ける

15問への回答は、もっともらしい文章を作ることより、情報の状態を区別することが大切です。次の表は架空の問い合わせ改善での記入例です。

表が収まらない場合は、横にスクロールできます

「不明」は記録の不備とは限りません。必要な費用や時間が大きく、今は調べないという判断もできます。その場合は、何を確定できないまま進めるのかを書きます。更新日、記入者、次に確認する人を添えれば、古い推測がいつの間にか合意済みの事実になるのを見つけやすくなります。

アンケートでは、回答が生まれる条件を残す

同じ質問でも、どの人に届いたか、いつ答えたか、誰が目の前にいたか、謝礼や特典があったかで、集まる回答は変わり得ます。ただし「店内なら好意的」「Webなら本音」と方向を決めつけることはできません。

AAPORの調査実務指針は、対象者の選び方、回答方法、誘導を避けた質問、事前テスト、継続調査で測り方を揃えることを扱っています。回答方法を変えた前後で評価が上がっても、顧客の気持ちが変わったのか、回答者や質問の条件が変わったのかを分ける必要があります。

前提欄には、調べたい母集団、募集方法、回答した人数と回答しなかった範囲、質問文、実施時期を残します。特典を付けるなら、その有無も記録します。詳しく考えるときはアンケート回答を左右する状況を参照し、自分の調査条件と照合してください。

店舗や空間では、快適さを売上の原因と決めない

席間や動線を変える検討では、受け入れられる人数、滞在のしやすさ、スタッフの作業、安全、利用目的が関係します。最大の席数と望ましい運用が一致しない場合はありますが、「席を減らせば満足度も売上も上がる」という一方向の関係ではありません。

前提として、混む時間帯、利用者の目的、待ち時間、スタッフの移動、利用者が実際に困った場面を確認します。「落ち着かない」という声があっても、原因は席間だけでなく音や待ち時間かもしれません。試す場合は変更条件を記録し、曜日や客層などの違いを残します。

観察できた困りごとの解消と、利益や再来店への因果効果は区別します。空間の距離感と価値を読むときも、心理の説明をそのまま自店の成果予測に変えないことが大切です。

AIには前提を渡し、出力は別に確かめる

AIへ依頼するときは、対象業務、入力してよい情報、出力の用途、確認者、やってはいけないことを先に書きます。顧客向けに送る文章なのか、社内で案を比較する下書きなのかでも、確認すべき範囲が違います。

前提が足りないことで用途に合わない回答が出る場合はあります。しかし、それをAIの誤りの唯一の原因にはできません。NISTの生成AIリスク管理プロフィールが扱うように、生成AIは誤った事実や出典を示すことがあります。入力が具体的でも、根拠や計算の検証は必要です。

前提を整理する発想はAIに伝える業務条件でも扱っています。人間にたとえる説明を使う場合も、AIが責任を引き受ける、経験から必ず正しく判断するという意味にはしません。出力の修正時間や確認漏れも含めて、実際の業務に合うかを確かめます。

投資判断では、回収の見込みと負担の上限を分ける

費用を払えることと、払う価値があることは別です。実施費、継続費、社内時間、撤退費用に加え、実施しない場合や別案に使う場合も比較します。利益の見込みを置くなら、どの仮定に依存するかを示します。

小さな検証から得る情報にも価値はありますが、「学びがあるから損失は問題ない」とはしません。何が分かれば、次の大きな支出や不適切な施策を避けられるかを先に考えます。学びを得るための負担が大きすぎれば、他の確認方法を選ぶ余地があります。

投資と回収の前提やAI投資のROIへ進むときも、示された数字を自社の予測として借りず、自分の費用、対象業務、確認時間から組み立てます。本記事の15問だけで、投資の専門的な妥当性が確定するわけではありません。

最小の検証：使える時間と、知りたいことを合わせる

仮想の検証で、今週使える時間が6時間、準備に2時間、1件の確認に30分かかるとします。確認に使えるのは4時間なので、上限は8件です。これは作業量の計算であり、8件で顧客全体の傾向や施策効果が分かるという意味ではありません。

この条件なら、特定の説明が読めるか、計測が動くか、確認手順に抜けがないかなど、少数でも具体的に観察できる問いを選びます。小さな売上差を統計的に検出したいなら、その目的に必要な件数と期間を別途設計し、今週の8件とは切り離します。

最初の検証を始める前に、次の4点を一文ずつ書ければ、確認の範囲を共有できます。

1. 今回の判断：何を採用・保留するための確認か。
2. 結果で変わること：どの観察なら別の案に進むか。
3. 答えられないこと：今回は何の効果や割合を推定しないか。
4. 記録と見直し：誰が何を残し、いつ次の判断をするか。

前提を更新するときは、判断が変わる理由を残す

対象顧客が変わった、費用が増えた、担当者が減った、計測定義が変わった、想定と違う観察が出た。こうした変化は、前提を見直すきっかけです。予定した確認日が来たときだけでなく、判断を支える条件が動いたときに戻ります。

更新前の記録を消さず、変更した項目、理由、判断への影響を残します。「新しいデータで仮説を変えた」のか、「目標や制約そのものを変えた」のかが分かれば、次の担当者も経緯を追えます。途中で結果が良かったから目標を下げた場合などは、当初の基準での評価も失わないようにします。

短い点検から始めたい場合は前提設計のチェックリスト、次の施策を比較したい場合は改善仮説の組み立て方へ進めます。前提・仮説・予算・ログ・判断理由を一続きで扱う流れは、First byte Method完全ガイドとMethod Runの公開説明で確認できます。