20世紀の重大事故から考える、ITエンジニアに必要なシステムズ・エンジニアリングとは？
はじめに
現代のITは、単に「便利なアプリ」や「業務効率化ツール」にとどまりません。
クラウドやソフトウェアはすでに、航空機の運航制御、金融取引システム、軍事防衛ネットワーク、原子力プラント制御といった、極めてクリティカルな領域に組み込まれています。
つまり、ITはITだけで独立した閉じた世界に存在しているのではなく、**他の技術領域と密接に結合した「社会的システムの一部」**として機能しています。
この状況においては、ITを「ソフトウェア工学」という枠組みだけで捉えるのは限界があります。
そこで重要になるのが、**システムズ・エンジニアリング（Systems Engineering）**です。
これは、機械・電気・制御・人間・運用・保守といった異なる領域を横断し、システム全体を最適化するための設計思想です。
システムズ・エンジニアリングとは？
システムズ・エンジニアリングは、NASAや軍事システム開発などで発展してきた領域で、特徴は以下のとおりです。
- 全体アーキテクチャ設計: 部品の寄せ集めではなく、全体像から逆算する
- リスクフロー分析: 部分故障が全体にどう波及するかをシナリオ化
- 冗長化構造: 単一点故障で全損しないように設計
- 運用・保守・人間系要素を含めた設計: 技術と人の関与を同時に扱う
今日では航空宇宙・金融・エネルギー・クラウドシステムなど、社会インフラ級のシステム開発では必須の基盤思想となっています。
20世紀の日本における限界
しかし1980年代の日本では、この「横断的な発想」がまだ未成熟でした。
技術は「機械（機）」と「電気（電）」の縦割りサイロ構造に閉じており、横断的なリスク設計や運用シナリオ統合が不足していました。
その結果として顕在化した事例を2つ取り上げます。
事例1: 高速増殖炉「もんじゅ」ナトリウム漏洩事故（1995年）
何が起きたのか
- 冷却材に用いられていた液体ナトリウムが漏洩し、空気に触れて自然発火。
- ナトリウムは水や空気と激しく反応するため、取り扱いに極めて注意が必要。
- 構造上の欠陥というより、「取り扱うリスク特性」と「運用時の監視・対応設計」が十分に統合されていなかったことが問題。
システムズ・エンジニアリング的視点
- 「化学特性」「配管設計」「監視センサー」「緊急時シナリオ」を横断的に考える必要があった。
- 実際には「機械設計部門」「電気制御部門」「運転マニュアル作成部門」がサイロ化しており、全体のリスクフローを描く体制が弱かった。
事例2: JAL123便墜落事故（1985年）
何が起きたのか
- 後部圧力隔壁の修理不備が引き金となり、飛行中に隔壁が破壊 → 垂直尾翼損失 → 操縦不能。
- 単一の隔壁破壊が致命的なシステム全体の喪失につながる設計構造。
- 「一部の構造欠陥」が「システム全体のフェイルセーフ不全」へと波及。
システムズ・エンジニアリング的視点
- 部品や修理工程ごとの品質管理に加え、「隔壁破壊時のシナリオ」「冗長化」「緊急操縦手段」など全体を横断する設計が求められる。
- 当時の安全思想は「部品ごとの信頼性向上」に偏っており、「想定外シナリオに備えるシステム全体設計」が十分でなかった。
サイロ化（分断化）された技術領域
1980年代の設計プロセスは、部門ごとに縦割り化されており、相互のリスクを統合的に扱う仕組みが弱かったのが特徴です。
| 領域 | 実態 |
|---|---|
| 機械設計（構造系） | 機体フレーム、圧力隔壁、尾翼などの物理構造を担当。強度・疲労・腐食の計算重視。冗長性は「構造強度」で語られる。 |
| 油圧・電気設計 | 制御系統（操縦桿〜舵面）や油圧ラインの配置などを別部門が設計。配線や配管の経路重複リスクへの意識は弱かった。 |
| 運用部門 | 整備・修理履歴・ログ管理を中心とし、設計部門と組織的に分離されていた。技術的フィードバックが届きにくい体質。 |
現代のSPOF対策との決定的な違い
1980年代の航空機設計と、現代のネットワーク／クラウド設計を比較すると、設計文化そのものに大きな違いがあります。
| 項目 | 1980年代航空機設計 | 現代のNW設計・クラウド設計 |
|---|---|---|
| 冗長性の重視 | 主に機能冗長（論理系統の多重化） | 構造冗長＋物理分離＋経路多様性 |
| 故障前提の設計 | 壊れない前提（フェイルセーフ） | 壊れる前提（フェイルオーバー／フォールトトレランス） |
| 共通障害領域の意識 | ほぼゼロ | ネットワーク分離、AZ/Region分散、ケーブリング分離が必須 |
| 設計文化 | 中央集権的・権威主義的（米国主導） | DevOps的・分散・検証主義（テスト駆動・IaC） |
つまり、「壊れないことを前提にするか」「壊れることを前提にするか」 で思想が真逆なのです。
学術的整理：チャールズ・ペロー『ノーマル・アクシデント』の再現
社会学者チャールズ・ペローは、その著書『ノーマル・アクシデント』において、高度に複雑かつ密結合されたシステムでは、事故は例外ではなく、むしろ必然（ノーマル）であると指摘しました。
JAL123便の事故も、まさにこの理論が示す典型例といえます。
- 高度な技術信頼（部品強度や設計信頼性に依存しすぎていた）
- 複雑な制御依存（油圧・電気系統が密結合し、尾翼損失が操縦不能に直結）
- 運用部門との断絶（整備・修理情報が設計改善に十分フィードバックされなかった）
- 異常への学習不在（「隔壁破壊シナリオ」の演習や代替操縦策が欠落）
つまり、事故は単なる「一つの修理ミス」ではなく、システム全体の構造条件が事故を必然化していたと理解できます。
この視点は、システムズ・エンジニアリングにおける「全体俯瞰」「リスクシナリオ設計」の必要性を、社会学的に裏づけるものでもあります。
現代的な示唆
これらの事例は、「設計ミス」というより「縦割り技術文化の限界」に起因していました。
現代のシステムズ・エンジニアリングでは以下のようなアプローチが常識化しています。
- 全体アーキテクチャ設計: 各技術領域を統合したシステム像を描く
- リスクフロー分析: 部分故障が全体にどう波及するかをシナリオ化
- 冗長化構造: 単一点故障で全損しない設計
- 運用シナリオ演習: 設計時に「運用・保守・緊急対応」を組み込む
ITエンジニアへの応用
航空機や原子炉だけでなく、私たちが日々触れるクラウドシステムや大規模サービスも同じです。
- インフラとアプリのサイロ化 → 全体リスクが抜け落ちる
- 単一リージョン障害 → 冗長化設計なしでは致命的
- 想定外のトラフィックや利用シナリオ → 運用設計に組み込む必要
つまり、
「縦割り最適の先にある“全体アーキテクチャ”の視点」こそ、現代エンジニアに求められるシステムズ・エンジニアリングの本質です。
まとめ
- 現代のITはクリティカル領域と不可分であり、閉じた工学領域としては成立しない
- 1980年代の大事故は、縦割り技術文化の限界から生じた
- その反省から成熟したのが、システムズ・エンジニアリングの横断的発想
- ITエンジニアもまた、部分最適を超えてシステム全体を俯瞰する視点が求められる
Discussion