MENU

前提を設計する際に最重要なのは、定義である

結論：前提を設計するときに最重要な作業は「用語の定義」を固定することです。定義が曖昧なまま前提を積み上げると、どれだけ精緻に議論しても土台ごとズレます。

前提をどう設計するか？
このテーマを突き詰めていくと、必ずぶつかる壁があります。

「そもそも、その言葉はどういう意味で使っているのか？」

ここを曖昧にしたまま、「前提」を語ることはできません。
前提は、必ず「定義」に乗るからです。

  • 前提：ある議論・判断を成り立たせるための条件・仮定
  • 定義：その議論で使う用語の意味・範囲を決める取り決め

主語 S と 述語 P のあいだに橋をかけるのが前提 A だとすれば、
その前に、S と P に使う言葉の意味を固めるのが定義です。

定義が揺れている限り、前提はどれだけ設計しても足場がスライドし続ける。
だからこそ、前提設計の「最優先タスク」は定義だと考えます。

1. 「定義抜きの前提」は、必ずどこかで破綻する

典型的な例で考えます。

命題：
「この政策は 成長 に資する」

ここで使われている要素を分解すると：

  • S（主語）：この政策
  • P（述語）：成長に資する
  • A（前提）：
    • 「成長」は良いことである
    • 「成長」はこの政策の評価基準として採用できる

…といったものが暗黙に乗っています。

しかし、もっと根本的な問題があります。

「そもそも、成長 とは何を指しているのか？」

  • GDP 成長率か
  • ひとり当たり所得か
  • 企業利益か
  • 雇用者数か
  • 生活満足度か

定義が違えば、「成長に資するかどうか」の判定結果はまったく変わります。

  • 定義1：成長＝GDP 増加
  • 定義2：成長＝一人あたり可処分所得の増加
  • 定義3：成長＝生活満足度の向上

同じ「この政策」でも、定義1では「成長に資する」、定義2・3では「むしろ損なう」となることは普通に起こります。

結論：

  • 定義が変われば、
  • 同じ前提・同じデータでも、
  • 結論 C が変わってしまう。

つまり、

「前提が大事だ」と言いながら、
定義を固めていない議論は、
地盤がスライドする上に家を建てている のと同じ

だということです（妥当性 80％）。

2. 「定義 → 前提 → 結論」の順序を守る

前提設計を行うときの、正しい「施工手順」はこうです。

  1. 定義を決める（用語とメトリクス）
  2. その定義のもとで 前提を設計する
  3. 前提から 結論を導く

逆順でやると危険です。

  • 先に結論を決める
  • それに合わせて前提を集める
  • 都合の良いように定義をいじる

これは、結論 C を正当化するために
A（前提）と D（定義）を後付けでねじ曲げる操作になりがちです。

このような操作は短期的には「勝てる議論」に見えても、
長期的には OS が壊れます。

3. 良い前提は「良い定義」からしか生まれない

3-1. 定義が前提の「型」を決める

例題：

テーマ：「この企業は投資に値するか？」

ここで最低限、定義しなければならない用語は：

  • 「投資に値する」とは何か
    • リターンが一定水準を超えること？
    • ボラティリティが一定水準以下であること？
    • ESG 評価も含めた総合判断？

この定義によって、前提の「型」が変わります。

  • 定義1：
    • 投資に値する ＝ 期待リターンが年率5％超
      → 前提：
      • 将来収益の前提（売上・利益成長率）
      • 割引率の前提
  • 定義2：
    • 投資に値する ＝ 元本毀損リスクが一定水準以下
      → 前提：
      • 財務健全性の前提
      • 業界構造の安定性の前提

このように、

定義が、必要な前提の種類と構造を決める

のであり、
「良い前提」は 「良い定義」からの派生物 にすぎません。

3-2. 定義・前提・結論の依存関係

整理し直すと：

  • 定義 D：用語の意味と測り方を決める
  • 前提 A：D のもとで、世界の状態についての仮定を置く
  • 結論 C：D と A のもとで「どうするか」を決める

この依存関係を意識することで、

  • 結論 C が変わったのは 前提 A のせいか
  • そもそも 定義 D を変えたからか

を切り分けられるようになります。

4. 実務で使える「定義設計」の３ステップ

前提を設計するときに、実務でそのまま使える手順に落とします。

ステップ1：キーワードを丸で囲む

検討テーマの文章から、キーワードを抜き出し、丸で囲みます。

  • 成長
  • リスク
  • 安全
  • 効率
  • 採算
  • 妥当

これらはすべて、何も定義しないといくらでも意味をすり替えられる言葉です。

ステップ2：「この文脈での定義」を日本語で書く

例：

  • 「この文脈での『成長』＝日本円ベースの売上高が年率3％以上増えること」
  • 「この文脈での『リスク』＝営業利益が赤字になる可能性」
  • 「この文脈での『採算が合う』＝3年以内に累積営業キャッシュフローがプラス転換すること」

ここで重要なのは、

  • 辞書的な定義ではなく、
  • 「この議論で、何をもってそう呼ぶか」 を決めることです。

ステップ3：定義を数字か観測条件に落とす

可能な限り、定義を数値や観測条件に紐づけます。

  • 年率○％
  • 3年以内
  • 元本毀損確率○％未満
  • 顧客満足度調査で○点以上

これによって、前提 A は「測れない抽象論」から「検証可能な仮説」に変わります。

  • 前提例：
    • 「この事業は、今後3年、売上が年率3％以上で成長する」

→ この前提が現実に合っているかどうかは、
数年後に検証可能です。

5. 定義を変えれば、前提も結論も再設計される

最後に、もう一歩踏み込みます。

定義を変えることは、世界の切り方を変えることです。

  • 成長の定義を「売上」から「一人当たり可処分時間の増加」に変えれば、
    成長企業の顔ぶれは一変します。
  • リスクの定義を「赤字になる可能性」から
    「社会的信頼を失う可能性」に変えれば、
    企業行動の最適解も変わります。

このように、

D（定義）を変える
→ A（前提）の設計が変わる
→ C（結論）も変わる

という構造が意識できているかどうかが、
思考の質を大きく分けます。

6. まとめ：前提の前に、定義を疑う癖をつける

前提を設計するとき、ついこう考えがちです。

  • 「どんな前提を置けば、この問題をうまく処理できるか？」

しかし、その前に問うべきは、こちらです。

「そもそも、ここで使っている言葉を、
　自分はどういう意味で定義するのか？」

  • 定義が曖昧な前提 → いくら精緻でも、土台からズレる
  • 定義が明確な前提 → 多少ラフでも、ズレの場所が特定できる

前提を設計する際に最重要なのは、
用語の定義を固定し、その定義に責任を持つことです。

前提を疑う前に、まず定義を疑う。
この順序を OS に刻み込むことが、
思考の精度を上げるいちばん地味で、いちばん効く習慣だと考えます。

コラム