principle-attack-the-premise

前提を疑う

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

理由： 共通の前提のもとで発生した失敗は、それぞれが前提についての証拠になります。

パターン：

• 前提を書き出します。 前提とは、失敗したすべての修正が仮定していた1つの文です。
• 次の修正に取りかかる前に、実態を数えます。 アクターごとの偏りを数えます。この調査で分かるのは、どのアクターが偏りを抱えているかであり、その偏りの大きさではありません。Build the Leverに従って、再実行可能なスクリプトとして調査を記述します。
• 偏りを読み取ります。 実行のたびに同じ少数のアクターが偏りの大半を抱えているなら、何かがその役割を割り当てています。役割を割り当てるものを見つけます。それが、Fix Root Causesに従う次の「なぜ」です。
• Laziness Protocolに従い、埋め合わせるのではなく、非対称性を取り除きます。実行のたびに同じアクターが役割を担わないよう、アクター間で役割を交代させるか、割り当てをランダム化するか、役割を移します。戻しの経路、共有プール、まとめて引き渡す方法、定期的な再均衡では、割り当てをそのまま残したうえで、実行のたびに作業を増やします。

停止条件：

• 前提を書き出し、調査ができるまで、次の修正を始めないでください。
• アクター間で調査結果が均等なら、前提が原因ではありません。証拠として調査結果を残し、別の原因を探してください。

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