ランスの法則（Lance's Law）とは？
山崎講師こんにちは。ゆうせいです。
「うまくいっているなら、いじるな」が教えてくれる安定の哲学
「今の仕組み、完璧じゃないけどとりあえず動いてる」
「もっと改善できそうだけど…これって手を加えるべき？」
そんなときに思い出したいのが――ランスの法則（Lance's Law）。
これはとてもシンプルでありながら、実は現場で頻繁に無視されている重要な原則です。
ランスの法則とは？
物事がうまく進んでいるなら、余計な手を加えるべきではない。
英語ではよく次のように表現されます：
"If it ain’t broke, don’t fix it."
（壊れていないなら直すな）
つまり、正常に機能しているものに無理やり手を加えると、逆に悪化する可能性があるという教訓です。
エンジニアリングの現場でよくある「違反」例
| シーン | ありがちなこと | 結果 |
|---|---|---|
| 安定稼働中の本番コード | 「リファクタリングしとこうかな」 | うっかりバグ発生→障害対応に追われる |
| 動いているCI/CD設定 | 「ちょっとモダンな構文に変更したい」 | ビルド失敗→デプロイ不能に |
| 安定しているチーム運用 | 「ルール増やしたらもっと効率よくなるかも」 | 混乱・反発・逆に非効率に |
数式で表してみると？
- 変更のリスクは、現在の安定度が高ければ高いほど、変化によるダメージが大きくなるということ。
なぜ「動いているものを触りたくなる」のか？
人は、完璧を求めるあまり、「今よりもっとよくしたい」という誘惑にかられがちです。
特にエンジニアは、技術的な美しさや効率を追求する性質が強いため、「今は正しくても、もっと最適化できるのでは？」と思いがち。
しかしそれが裏目に出ると、本来なら起きなかったトラブルを、自ら引き起こすことになるのです。
ランスの法則を活かすには？
✅ 1. 「目的」が明確か確認せよ
- 「なんとなく不満だから直したい」は目的が曖昧
- 「パフォーマンス改善」「保守性向上」など具体的な成果が期待できる場合のみ着手
✅ 2. 「安定している」こと自体を評価せよ
- 変更がない＝怠慢 ではない！
- 安定していることは技術的にも組織的にも“価値”がある
✅ 3. テストとロールバックができる状態で触れ
- 「万が一」を想定して動く
- 「壊れたら戻せる」がないなら、ランスの法則を守るべきとき
似ている考え方：ヤグニの原則（YAGNI）
You Aren’t Gonna Need It（それ、本当に必要？）
不要な機能追加や先回りの設計は、かえってシステムを不安定にするという思想で、ランスの法則と親和性が高いです。
まとめ：「触らない勇気」もエンジニアの技術
ランスの法則は、変えることよりも、“今ある安定”をどう守るかという視点をくれます。
理想を追うのではなく、現実の成果とバランスを取ることこそプロの仕事。
「いじりたい」なら、その理由を言語化してみよう。
言語化できないなら、それは“気分”であり、“根拠”ではないかもしれません。
次に学んでおきたいこと
- ヤグニの原則（YAGNI）：将来必要になるかもしれない、は幻想
- コンウェイの法則：組織構造がシステム構造に影響する
- 技術的負債：むやみに手を入れると、返済額が膨らむリスク
最善を目指す前に、「最悪を避ける」判断力を身につけよう！
それが、安定したチームとシステムを支える“見えない技術”になります。
セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク
投稿者プロフィール
