「改善の正解探し」をやめる

"改善の正解探し"をやめる

仮説→検証を回すための意思決定プロトコル（First byte Method 中核）

この記事が想定する読者：改善会議が長引き「正解」を探しがちだが、仮説と検証で前に進めたい担当者。

判断を誤るとどうなるか：正解を探し続けると、前提が曖昧・検証が設計されず・撤退条件がなく、決められないまま時間だけ消える。先に「反証可能な仮説」と「指標・最小変更・撤退条件」を決めてから動くと失敗しにくい。

改善が止まる瞬間には、共通パターンがあります。

• 何が正解か分からない
• 失敗したくない
• だから調べ続ける
• いろんな意見が出る
• 結局、決められない

ここで多くの人は「正解」を探します。

でも現実はこうです。

改善に"正解"はない。

あるのは「今の前提で、確からしい仮説」と「検証の結果」だけ。

だからFirst byte Methodは、正解探しではなく、

仮説→検証を回すための意思決定プロトコルを用意します。

1. 結論：意思決定は「当てる」ではなく「壊れない形で進める」

改善における意思決定の目的は、成功を断定することではありません。

• 失敗をゼロにすることでもない
• 一発で当てることでもない

目的はこれです。

壊れない条件の中で、前進を積み上げること

つまり「進め方」を設計する。

不確実性の中で判断する考え方は、正解が分からない状態で、意思決定をするということと不確実性を前提に、仮説と検証を回し続けるということで扱っています。

2. 改善が止まる原因は3つ（ほぼこれ）

① 前提が曖昧

目的、対象、制約が曖昧だと、意見が散らかります。

② 検証が設計されていない

やってみる前に結論を出そうとすると、永久に決まりません。

③ 撤退条件がない

「戻せない」改善は怖い。だから決められない。

改善が止まるのは、能力ではなく設計の問題です。

前提の揃え方は、前提設計：成果を出す前に、判断を壊さない土台を作るで解説しています。

3. First byte式：意思決定プロトコル（最小で回る）

ここからが実務で使える"型"です。

この順に書けば、議論は止まりにくくなります。

STEP0：目的を1行にする（ブレ防止）

何を増やす / 減らすのかで定義する

例：離脱を減らす／待ち上位10%を下げる／再訪率を上げる

STEP1：前提を固定する（条件の明文化）

• 対象（誰/どこ）
• 期間（いつまで）
• 制約（やらないこと）
• 参照情報（一次情報）

STEP2：仮説を1つに絞る（一点突破）

「これが原因で、この結果が起きている」

例：受付の迷いが滞留を生み、待ち上位10%が伸びている

STEP3：検証方法を決める（観察指標）

• 何がどう変わったら"支持"か
• 変わらなかったら"棄却"か

例：待ち上位10%、滞留地点数、予約完了率

観察指標の設計は、施設のストレスを測ると定員数の算出で扱っています。

STEP4：最小変更で試す（可逆性）

• まずは戻せる変更だけやる
• いきなり大改修しない

改善の順番（情報→工程→配置→稼働）は、混雑を増やす前にやることで解説しています。

STEP5：撤退条件を先に決める（恐怖を消す）

悪化したら戻す条件

例：離脱が増えたら中止／待ちが悪化したら戻す

STEP6：結果を"例外集"に変える（学習）

• 何が効いた/効かなかった
• どの前提で再現するか
• 次回の判断材料として残す

例外を資産にする運用は、例外集の作り方（AI運用向け）でも同様の考え方で扱っています。

4. 重要：仮説は「正しさ」より「反証可能性」で評価する

良い仮説とは、当たりそうな仮説ではありません。

外れたときに学びが残る仮説

つまり、反証可能であること。

• 何を見れば外れたと言えるか
• どの指標が動かなかったら棄却か

これを決めると、議論が終わります。

5. "正解探し"に戻らないためのルール（運用のGate）

改善会議や検討が「無限」に伸びるのを止めるためのGateです。

Gateルール（最小）

• 仮説は同時に1つ
• 期間は2週間〜1ヶ月で区切る
• 指標が決まらない改善は実施しない
• 撤退条件がない改善は実施しない
• 例外集に残せない改善は繰り返す（＝学習してない）

6. 施設・サービス改善に当てはめる（具体例）

例：待ちが発生し、離脱が増えている

この形式なら、改善は止まりません。

本記事は改善が止まる原因と仮説→検証のプロトコル（6ステップ・Gateルール）に特化しています。実際の運用の優先順位や成果は目的・組織・領域により異なるため、前提設計の土台やMethod完全ガイドとあわせて自社の前提に合わせた判断をおすすめします。

判断の土台として押さえておくこと

• 改善の目的は正解を当てることではない：壊れない条件で仮説→検証を回し、外れたときに学びが残る形にする。
• 前提固定・一点突破・指標・最小変更・撤退条件・学習の6つを揃える：仮説は同時に1つ、期間で区切る、指標と撤退条件がない改善は実施しない。
• Gateルールで「正解探し」に戻らない：例外集に残せない改善は繰り返す＝学習していない、とみなす。

次の一手：前提設計の基礎／施設のストレスを測る／First byte Method 完全ガイド

7. 意思決定を"設計"すると前に進む

• 改善の目的は正解を当てることではない
• 壊れない条件で、仮説→検証を回すこと
• 前提固定→一点突破→指標→最小変更→撤退条件→学習

これがFirst byte Methodの中核プロトコルになります。

前提の4ブロック（目的・制約・現状・判断基準）は前提設計：成果を出す前に、判断を壊さない土台を作るで解説しています。観察指標と閾値は施設のストレスを測ると定員数の算出、改善の優先順位（情報→工程→配置→稼働）は混雑を増やす前にやることで扱っています。不確実性と意思決定は正解が分からない状態で、意思決定をするということと不確実性を前提に、仮説と検証を回し続けるということで、Method全体はFirst byte Method 完全ガイドをご覧ください。