ランスの法則(Lance's Law)とは?

こんにちは。ゆうせいです。

「うまくいっているなら、いじるな」が教えてくれる安定の哲学

「今の仕組み、完璧じゃないけどとりあえず動いてる」
「もっと改善できそうだけど…これって手を加えるべき?」

そんなときに思い出したいのが――ランスの法則(Lance's Law)

これはとてもシンプルでありながら、実は現場で頻繁に無視されている重要な原則です。


ランスの法則とは?

物事がうまく進んでいるなら、余計な手を加えるべきではない。

英語ではよく次のように表現されます:

"If it ain’t broke, don’t fix it."
(壊れていないなら直すな)

つまり、正常に機能しているものに無理やり手を加えると、逆に悪化する可能性があるという教訓です。


エンジニアリングの現場でよくある「違反」例

シーンありがちなこと結果
安定稼働中の本番コード「リファクタリングしとこうかな」うっかりバグ発生→障害対応に追われる
動いているCI/CD設定「ちょっとモダンな構文に変更したい」ビルド失敗→デプロイ不能に
安定しているチーム運用「ルール増やしたらもっと効率よくなるかも」混乱・反発・逆に非効率に

数式で表してみると?

\text{Risk}_{\text{Change}} = f(\text{System Stability}, \text{Change Complexity})

  • 変更のリスクは、現在の安定度が高ければ高いほど、変化によるダメージが大きくなるということ。

なぜ「動いているものを触りたくなる」のか?

人は、完璧を求めるあまり、「今よりもっとよくしたい」という誘惑にかられがちです。
特にエンジニアは、技術的な美しさや効率を追求する性質が強いため、「今は正しくても、もっと最適化できるのでは?」と思いがち。

しかしそれが裏目に出ると、本来なら起きなかったトラブルを、自ら引き起こすことになるのです。


ランスの法則を活かすには?

✅ 1. 「目的」が明確か確認せよ

  • 「なんとなく不満だから直したい」は目的が曖昧
  • 「パフォーマンス改善」「保守性向上」など具体的な成果が期待できる場合のみ着手

✅ 2. 「安定している」こと自体を評価せよ

  • 変更がない=怠慢 ではない!
  • 安定していることは技術的にも組織的にも“価値”がある

✅ 3. テストとロールバックができる状態で触れ

  • 「万が一」を想定して動く
  • 「壊れたら戻せる」がないなら、ランスの法則を守るべきとき

似ている考え方:ヤグニの原則(YAGNI)

You Aren’t Gonna Need It(それ、本当に必要?)

不要な機能追加や先回りの設計は、かえってシステムを不安定にするという思想で、ランスの法則と親和性が高いです。


まとめ:「触らない勇気」もエンジニアの技術

ランスの法則は、変えることよりも、“今ある安定”をどう守るかという視点をくれます。
理想を追うのではなく、現実の成果とバランスを取ることこそプロの仕事。

「いじりたい」なら、その理由を言語化してみよう。
言語化できないなら、それは“気分”であり、“根拠”ではないかもしれません。


次に学んでおきたいこと

  • ヤグニの原則(YAGNI):将来必要になるかもしれない、は幻想
  • コンウェイの法則:組織構造がシステム構造に影響する
  • 技術的負債:むやみに手を入れると、返済額が膨らむリスク

最善を目指す前に、「最悪を避ける」判断力を身につけよう!
それが、安定したチームとシステムを支える“見えない技術”になります。

セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク

投稿者プロフィール

山崎講師
山崎講師代表取締役
セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します!
この記事に間違い等ありましたらぜひお知らせください。