仮説を分けろと書いておきながら、自社の台帳には成功基準が1行もありませんでした

私たちはプロジェクトを始めるとき、仮説を3つの層に分けるよう書いています。

大仮説  1つ        問題の根本原因
  └ 中仮説 2〜4つ    大仮説が正しければ必ず成り立つべきこと
      └ 小仮説 1つずつ  2週間以内に実際に判定すること

これが自社の文書に実際に適用されているか、確認してみることにしました。その過程で2つのことがわかりました。1つは私たちの欠陥で、もう1つは私たちの測定方法の欠陥でした。より重要だったのは2つ目です。

まず、測定が間違っていました

作業文書全体を調べて、"大仮説"という語を含む文書を数えました。3件が出てきました。低い数字だったので、そのまま使うつもりでした。

ところが、その3件を開いてみました。

すべて、大仮説という概念を説明した文書でした。ルールを定義した文書、そのルールを監査した文書、コンテンツのネタを書き留めた文書。大仮説を実際に立てたプロジェクト文書は1件もありませんでした。

"3件"とは、その語が出てくるファイルが3つあるという意味であって、その層を立てたプロジェクトが3つあるという意味ではありませんでした。私たちは文字列を数えていたのです。

もう一度確認すると、さらにはっきりしました。この記事を準備する中で関連文書をいくつか書いたところ、同じ数字が6件に増えました。大仮説を立てたからではなく、大仮説という語を使った文書が増えたからです。いまお読みのこの記事も、公開されればその数字をもう1つ押し上げます。

単語を数えることと、実際にやっているかを見ることは違います。そのため、この数字はこの記事では証拠として使っていません。

文字列の罠がない数字を1つ

代わりに別のものを見ました。私たちはすべての判断を決定台帳に記録しています。この記事を書き始めた時点で985件でした。

これは文書本文ではなく記録の欄なので、単語ではなく欄が埋まっているかを見ます。

• この決定が成功したとみなす基準 — 0件
• 何が見えたら撤退するか — 0件
• いつ見直すか — 0件

985件中0件でした。ここに解釈の余地はありません。

並べてみると、こうなります。

決定      985件
実行    2,825件
結果       66件

決定と実行は積み上がるのに、結果がそこにありません。判定基準を書いていなかったので、後から判定しようがなかったのです。

そして今日

この数字を数える過程で、私たちはその日の決定3件を新たに台帳に入れました。

その3件にも、成功基準を書いていませんでした。

数えていた欠陥を、数えている最中にさらに3回つくってしまいました。ルールを知らなかったからではありません。そのルールを書いたのは私たち自身です。

なぜこうなるのか

理由は単純でした。決定する時点と判定する時点が違うからです。

決定するときは、何をするかがはっきりしています。だからそれだけを書きます。"何が見えたらこれが間違いだったと認めるか"は、その瞬間に書かなくても仕事は進みます。当面は何の問題もありません。

問題は数か月後です。その決定を開き直したとき、何を基準にうまくいった／いかなかったと言うのか、誰にもわかりません。すると多くの場合、"あのときはそれが正しかった"で終わります。判定ではなく、振り返りになってしまうのです。

層を分けることがなぜ必要か

• 大仮説は、プロジェクトが立っている前提です。これが間違っていればすべてを開き直すことになるので、頻繁には触りません。
• 中仮説は、大仮説が正しければ必ずついてくるべきものです。棄却されてもプロジェクトは生き残ります。
• 小仮説は、短いサイクルの中で判定できる大きさに切ったものです。私たちは2週間としています。

核心は、棄却が正常な状態になるという点です。中仮説が1つ間違っていてもプロジェクトは崩れないので、間違っていたと言えるようになります。層が1つしかなければ、仮説を否定することがプロジェクトを否定することになり、誰も間違っていたと言わなくなります。

ちなみに、よく設計された実験でも目標指標が改善するのは3分の1です。残りの3分の1は変化がなく、3分の1はむしろ悪化します。棄却は例外ではなく、デフォルトです。

今日1つだけやるとしたら

いま進行中の仕事を1つだけ選んで、1行書いてみてください。

何が見えたら、これが間違いだと認めるか

この1行が書けなければ、その仕事はまだ仮説ではなく計画です。計画は終わらせることはできても、判定することはできません。

そして私たちの経験から1つ付け加えるなら — その1行を書いたかを確認するとき、文書にその単語があるかどうかで数えないでください。私たちはそうして3という数字を得て、開いてみたら0でした。

この記事を書きながら変わったこと

過去の985件は遡って埋めることができません。その代わり、この記事を書いている間にその日の決定3件に3つの欄を埋めました — 成功基準、撤退基準、見直し日。

989件中3件です。誇れる数字ではありません。ただ、0ではない最初の数字であり、これから記録する決定がどこから始まるのかは、これで決まりました。

---

進行中の仕事が判定できる状態なのかわからない場合は
2分の診断で、いま最初に手をつけるべき課題1つと2週間パイロットの開始案、人が必ず確認すべきリスクを整理してご覧いただけます。答えられる範囲だけでも大丈夫です。

STAR-T AI事業運営診断 →

---

脚注

① 参考資料・確認日（測定時刻 2026-08-12 14:04 · 再測定 15:37）

• 決定台帳 985件 → 989件（測定中に増加）· 台帳を直接照会
• 成功基準 / 撤退基準 / 見直し日 各0件 → 3件 — フィールドの有無を照会。3件はこの記事を書きながら埋めたもの
• 実行 / 結果 2,825 → 2,841 / 66（本文のブロックは985件と同じ時点のセットなので2,825のまま）
• "大仮説"の文字列検索 3件（8/10）→ 6件（8/12）— ⚠️ 証拠ではありません。本文では反例としてのみ使用

⚠️ 決定台帳は毎日積み上がる記録です。上記の総件数は測定時刻時点の値で、お読みのいまはさらに増えています。検収している間も変わり続けました（983 → 984 → 985 → 989）。変わらなかったのは"0件"のほうです — この記事の主張は総件数ではなく、その0にかかっています。

実験結果が改善・無効・悪化でそれぞれ3分の1ずつに分かれるというのは、マイクロソフトが12年間のオンライン対照実験をまとめ、2015年に学会で発表した資料によるものです。

② この記事で使わなかった数値

• "大仮説がある文書3件"を欠陥の根拠として使いませんでした。草稿ではこれをタイトルに入れていましたが、検収で文字列カウントなので自己言及的に汚染されるという指摘を受け、確認したところ事実でした（3 → 6に増加）。数字を差し替える代わりに、その失敗自体を本文に残しました。
• 比率（%）表記 — 分母にはログや議事録のように仮説が不要な文書が大半を占めるため、比率にすると実際より悪く読めてしまいます。
• "的中率3分の1" — 社内文書ではこのように略されていますが、原典は改善／無効／悪化 各3分の1です。原典のほうに合わせて書きました。
• 2週間という基準の外部根拠 — 短いサイクルを勧める外部レポートはありますが、そちらの基準は1週間です。私たちの2週間はそれより緩いため、他者の数字を根拠として借りませんでした。
• トラック別の詳細数値 · 私たちの講義・コンサルティングの満足度や実績の数値 — 主張と無関係なので外しました。

③ 作り方
AIで草稿をつくり、人が検証・編集しました。草稿は事実検収で一度差し戻されました — 核心の数値が測定方法上成り立たないという指摘で、確認した結果その通りだったため、タイトルと論旨を変えて書き直しました。生成AIによる画像・音声は使用していません。