速度を最優先し、失敗や破壊（仕様破壊・既存ルール破り）を許容して前進する、という開発文化の合言葉

Facebook（初期）の有名なモットーとして広まった

後に「Move fast with stable infrastructure」的な方向へ調整された、という“成長後の揺り戻し”もセットで語られがち

何を“break”するのか

仕様（互換性）を壊す

既存の合意形成プロセスを壊す

既存顧客の期待を壊す

信頼（セキュリティ/プライバシー/法令順守）を壊す

→ 「壊してよいもの」と「壊すと取り返しがつかないもの」が混ざるのが問題

この言葉が刺さる局面

競争が激しく、学習速度が勝敗を決める

まだ“何が価値か”が不確実で、試行回数が正義

小さく出して小さく壊れる（被害半径が小さい）設計ができる

刺さらない/危険な局面

社会インフラ・医療・金融・行政など、失敗コストが高い領域

個人情報・安全保障・差別/炎上リスクなど、外部不利益が大きい領域

「壊れた後に直す」より「壊さない設計」の方が安い領域

“Break”の被害半径（blast radius）で考える

壊れてもいい: 内部ツール / 検証用プロト / 一部ユーザへの限定公開

壊れにくい方がいい: 認証 / 課金 / データ消失 / 個人情報 / セキュリティ

壊してはいけない: 生命・法令・信頼・不可逆なデータ

よくある誤解

「雑にやれ」ではない

「責任を負わない」でもない

本質は “学習速度を最大化する設計”（失敗を前提にした安全装置込み）