> ## Documentation Index > Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt > Use this file to discover all available pages before exploring further. # マーフィーの法則 > マーフィーの法則は、失敗しうるものは失敗すると述べています。その起源、心理学、そして失敗を防ぐための防御的思考の使い方を学びましょう。 **Category**: 法則
**Type**: システム思考の法則
**Origin**: 工学、1949年、エドワード・A・マーフィー・ジュニア
**Also known as**: マーフィーの公理、ソッズ・ロー（英国） **先に答えると** — マーフィーの法則は「失敗しうるものは、失敗する」と述べています。1949年に航空宇宙エンジニアのエドワード・A・マーフィー・ジュニアが定式化したこの原則は、工学と日常生活において最も広く知られた格言の一つとなりました。単なる悲観主義として扱われがちですが、マーフィーの法則は価値ある工学的原則を反映しています。つまり、失敗しうるものは何でも失敗すると仮定してシステムを設計すべきだということです。この防御的な考え方は、安全工学、ソフトウェア開発、リスク管理など、幅広い業界の形成に影響を与えてきました。 ## マーフィーの法則（Murphy's Law）とは マーフィーの法則は、複雑なシステムにおける失敗の不可避性を表す格言です。その核心には、宇宙に関する根本的な真実が示されています。十分な機会があれば、失敗しうることは最終的に失敗するということです。この法則の力は、神秘的な予知にあるのではなく、潜在的な失敗を想定し、それに耐えたり回復したりするシステムを設計するよう促す心理的転換にあります。 > 「物事を行う方法が複数あり、そのうちのひとつが災難をもたらす場合、誰かがその方法で行うだろう。」 この法則は航空宇宙工学から有名になりましたが、普遍的に適用されます。家具の組み立てであれ、ソフトウェアのリリースであれ、大規模プロジェクトの計画であれ、複雑さは失敗の機会を生み出すということをこの原則は思い出させてくれます。システムに関わるコンポーネント、相互作用、人間の意思決定が多ければ多いほど、何かが最終的に失敗する可能性は高まります。 ### マーフィーの法則を3つの深さで理解する * **初心者**: 複数ステップの計画を立てる際、各段階で「何が失敗しうるか？」を明示的に問いましょう。このシンプルな習慣が、潜在的な失敗を実際の失敗になる前に表面化させます。 * **実践者**: 重要なシステムに冗長性を組み込みましょう——予備電源、バージョン管理されたバックアップ、自動テスト。成功パスが機能すると仮定するのではなく、失敗モードに対して設計しましょう。 * **上級者**: マーフィーの法則が統計的不可避性と人間の心理学から生まれることを理解しましょう。大規模システムにおいて、失敗は例外ではなく特徴です。カオスエンジニアングを取り入れ、ユーザーが気づく前にシステムの弱点を発見しましょう。 ## 起源 この法則は、アメリカの航空宇宙エンジニアである**エドワード・A・マーフィー・ジュニア**（1918年–1990年）に帰せられます。1949年、マーフィーはカリフォルニア州エドワーズ空軍基地で、人間が極限加速度にどこまで耐えられるかをテストするロケットスレッド実験の一連のプロジェクトに関わっていました。 これらの実験中、センサーが逆向きに取り付けられ、データを記録できませんでした。マーフィーの苛立ちが、後に有名な原則となる発言につながりました。「彼らにやり方があるなら、彼らはそうするだろう。」同僚のフライトサージョン、ジョン・スタップ博士がこの本質を捉え、現在知られる定式化に洗練させました。 この原則は工学界で急速に広まり、その外にも波及しました。マーフィー自身はこの名声にやや戸惑い、実際の工学的貢献で覚えられたいと思っていました。しかし、この法則のシンプルさと真実性は、ポピュラーカルチャーと専門的実践における永続的な地位を保証しました。 ## 要点 マーフィーの法則は魔法ではなく数学です。十分な変数と十分な時間があれば、あらゆる失敗モードはいずれ現れます。この法則は、それが起こらないふりをするのではなく、この不可避性を認めているだけです。 人がミスをするとき、彼らは繰り返し同じ種類のミスを犯す傾向があります。一般的なエラーパターンを理解することで、それらを防止または捕捉するシステムを設計できます。 システムのコンポーネント、接続、相互作用が追加されるごとに、新たな潜在的な失敗ポイントが生まれます。単純なシステムがより信頼できるのは偶然ではなく、設計によるものです。 マーフィーの法則に対する正しい対応は悲観主義ではなく防御的設計です——失敗を前提とし、それでも機能し続けるシステムを構築することです。 ## 応用場面 開発者はマーフィーの法則を、包括的なテスト、バージョン管理、自動バックアップ、グレースフルなエラーハンドリングを通じて適用します。この原則は、予期しない状況が発生したときにユーザーを保護する防御的コーディングプラクティスを動機づけます。 航空宇宙から医療まで、さまざまな業界で冗長性、フェイルセーフ、包括的なチェックリストを使用して、「失敗しうるもの」のシナリオが災難を引き起こすのを防いでいます。 効果的なプロジェクトマネージャーは、コンティンジェンシーバッファーを構築し、リスクを明示的に特定し、物事が失敗する計画を立てます。これは悲観主義ではなく、プロフェッショナルなリスク管理です。 コンピュータのバックアップを取り、ドキュメントを頻繁に保存し、重要な会議には早めに到着する。マーフィーの法則の個人的な適用は、回避可能な失敗がキャリアを制限する出来事になるのを防ぎます。 ## 事例 ### マーズ・クライメイト・オービターの災害（1999年） NASAのマーズ・クライメイト・オービターは、マーフィーの法則の実例——そしてそれを無視することのコスト——を示す戒めの例となっています。1999年9月、3億2,700万ドルの宇宙機は軌道に入る代わりに火星大気圏で燃え尽き、ミッション全体が失われました。 根本原因は驚くほど単純でした。あるエンジニアチームは力の計算にメートル法（ニュートン）を使用し、別のチームはヤード・ポンド法（ポンドフォース）を使用していました。マーフィーの法則に慣れた人々が予測していたこの単位の不一致は、打ち上げ前のチェックで捕捉されませんでした。 宇宙機は火星に近づきすぎて大気摩擦によって破壊されました。この損失は、単一のシンプルな検証ステップで防げたはずです。それどころか、コミュニケーションと相互チェックの根本的な失敗が、計算可能なリスクを壊滅的な失敗に変えてしまいました。 ### 教訓 教訓は、失敗が不可避だということではなく、重要なシステムには予測可能な失敗モードに対する明示的で体系的なチェックが必要だということです。マーフィーの法則は、単純なエラーが発生するということを教えてくれます。それに対する対応は、エラーが災難に連鎖する前に捕捉するシステムを設計することです。 ## 限界と失敗パターン マーフィーの法則は、「すべてが常に失敗する」という意味だと誤解されることがあります。これは誤りです。この法則は、失敗が*可能*な状況にのみ適用されます——不可避ではありません。適切な保護措置を備えたうまく設計されたシステムは、極めて低い失敗確率を持つかもしれませんが、その確率がゼロになることはありません。 また、この法則は**挑戦しない**ことや**不運のせいにする**言い訳として使われるべきではありません。マーフィーの法則はより良い設計への呼びかけであって、諦めではありません。失敗が発生したとき、正しい対応は「これをどう防ぐか？」を問うことであり、「どうしようもない」と言うことではありません。 さらに、マーフィーの法則の過度な適用は**分析麻痺**につながる可能性があります——あらゆる可能な失敗に備えることに時間を費やしすぎて、何も達成できなくなるのです。目標は合理的な予防であって、偏執症ではありません。 ## よくある誤解 **訂正**: この法則は、失敗しうる*もの*に適用されるのであって、すべてに適用されるわけではありません。フェイルセーフに設計されており、危険な方法で失敗できないものも多くあります。重要なのは、どのコンポーネントやプロセスが脆弱かを特定することです。 **訂正**: しばしばユーモアとして使われますが、マーフィーの法則は深刻な工学的原則です。防御的設計、冗長性、体系的なリスク評価を動機づけます。航空宇宙、医療、その他の安全クリティカルな分野で数え切れないほどの命を救ってきました。 **訂正**: どれほど注意してもヒューマンエラーはなくなりません——マーフィーの法則は、ミスを犯す方法があれば、誰かがそれを犯すと明示的に述べています。解決策は、エラーを捕捉する、あるいはエラーが発生しても機能し続けるシステムを設計することです。 ## 関連概念 マーフィーの法則は、工学、心理学、リスク管理におけるいくつかの関連するアイデアにつながっています。 * **防御的設計（Defensive Design）**: コンポーネントの失敗が発生しても機能し続けるシステムを作成すること * **冗長性（Redundancy）**: 単一障害点が連鎖しないようにバックアップシステムを構築すること * **[ホフスタッターの法則](/ja/laws/hofstadters-law)**: プロジェクトは常に予想以上に時間がかかるという関連する観察——複雑さを過小評価する体系的な楽観主義の別の例 * **リスク管理（Risk Management）**: 潜在的な失敗を特定、評価、軽減する専門分野 * **スイスチーズモデル（Swiss Cheese Model）**: 失敗が整列したときに複数の防御層がどのように突破されるか ## 一言で言うと 何が失敗しうるかを計画し、何がうまくいくべきかを計画しない——マーフィーの法則は、失敗を前提とすることが、失敗しないシステムを構築するための第一歩であることを思い出させてくれます。