前提を疑う

同じ前提に立つ修正が 2 回以上同じ検査で落ちたら、修正でなく前提を疑う。前提を書き出して確かめるまで、次の修正を始めない。

なぜ: 落ちた修正は、それが仮定した考えへの反証になる。同じ前提で 3 つ目の修正を書くと、原因が無いと証拠が示す場所に労力を使う。審査の周では、どの周も「直しが正しいか」を問い、直している仕組みが目的に要るかは誰も問わない。仕組みに直しを足すたびに攻める所が増え、周が止まらない。

適用する場面:

• 2 回続けて同じ受入条件・同じ試験が落ち、また似た修正を足そうとしているとき。
• 「今度こそ」と、閾値・待ち時間・再試行の回数を変えようとしたとき。
• 修正のたびに失敗の形は少し変わるが、落ちる検査は同じとき。
• 審査で、前の直しで足した部分に次の穴が見つかったとき（落ちる検査が周ごとに違っても、前提は「足せば閉じる」で同じ）。

やること:

• 落ちた修正のすべてが仮定していた 1 文を、前提として書き出す。
• 直しが同じ仕組み（足した処理・分岐・試験の土台）に重なっているなら、その仕組みの前提も書き出す。「この仕組みは依頼の目的（測れる値）に要り、仕組みの無い別の形より良い」。目的の値を、仕組みあり・仕組みなし・仕組みの無い別の形（処理を別の単位に分ける、既存の機構に任せるなど）の 3 つで比べる。手元の記録やログから値を出せるなら、それを使う。前提が崩れていれば、仕組みに直しを足さず、別の形に替えるか、仕組みを外す。
• 別の形を否定する文（「〜しても縮まない」「〜では足りない」）は、その形を試すか、手元のデータから値を出してから書く。試さずに書いた否定は、後の審査でも試されず、選択肢を閉じたまま残る。
• 主張が強制の形（「避けられない」「免除できない」「常に」）なら、前提を「結果を変えられる入力の集合は ___ だけである」と書き、データファイル・登録の一覧・設定・fixture・環境・基準の版を 1 つずつ書き換えて確かめる。判定の順序のような局所の前提だけを疑うと、列挙しなかった入力から次の穴が出る。
• 前提が偽なら結果が変わる観察を決めて、行う。失敗の大きさだけでなく、どこに偏って落ちるか（どの対象・どの入力・どの回）を見る。確かめは再実行できるスクリプトにする。
• 証拠が前提に反すれば、前提が予想しなかった失敗の共通点を探す。前提が正しければ、さらに「なぜ」を問う（principle-fix-root-causes）。どちらでも、条件を後から補う仕組みを足さず、条件を生む原因を取り除く。

使わないとき: 初めて落ちた修正、または落ちた修正がそれぞれ別の前提に立っている場合。新しい要件に合わせて設計を作り直す話でもない。これは、今の設計が仮定している事実を疑う原則。

確かめる例: 2 回目の失敗の後の記録に、前提の 1 文と、それを確かめた観察と結果がある。3 つ目の修正が、同じ前提のまま出ていない。仕組みに直しが重なった後の記録に、目的の値での仕組みあり・なし・別の形の比較がある。