principle-attack-the-premise

前提を疑う

同じ前提に基づく 2 つ以上の修正が同じゲートで失敗した場合、修正ではなく前提を疑ってください。

理由： 修正が失敗するたびに、その修正が前提としていた考えに反する証拠が得られます。同じ前提に基づく 3 つ目の修正に取り組むのは、原因ではないとすでに証拠が示している箇所に労力を費やすことになります。

パターン：

• 前提を書き出します。 前提とは、失敗したすべての修正が共通して仮定していた一文です。
• 次の修正に着手する前に、前提を検証します。 前提が誤っていれば結果が異なるはずの観察項目を見つけて、実際に確認します。失敗の規模だけでなく、失敗がどのように分布しているかを見ます。Build the Lever に従って、確認を再実行できるようにします。
• 証拠に従います。 証拠が前提と矛盾する場合、原因は別のところにあります。前提では予測できなかった、失敗に共通する点を探します。証拠が前提を裏付ける場合は、Fix Root Causes に従って次の「なぜ」を問いかけます。それまでの修正は、原因ではなく結果に対処していた可能性があります。
• Laziness Protocol に従い、条件を補うのではなく、取り除きます。ある部分が常に不利な側に回ると証拠が示しているなら、そうなる原因を変えます。後から片付ける仕組みでは原因が残り、実行のたびに作業が増えます。

停止条件： 前提を書き出して検証するまで、次の修正に着手しないでください。

この原則は、新しい要件に合わせて設計を作り直す Redesign from First Principles とは異なります。こちらは、現在の設計が前提としている事実を問い直します。