2016年3月22日に発生したANAのシステム障害について、ANAが日本ユニシスへの損害賠償を検討している
表記の件を考察してみる。
例によって、ANAさんとか特定のSIerさん、ベンダーさん、メーカーさんとかを批判する意図はありません。 不幸にも社会的インパクトがあったシステム障害について、 エンジニアとしてどう向き合うべきかの糧にしたい、という思いで書いています。 （というわけで、今更ですが表記が気持ち悪くならない範囲で個別の社名は書かないことにします。）
参照した記事は以下。
目次
損害賠償の根拠・理由
損害賠償というからには「U社さんがとある債務を履行しなかったことが今回のシステム障害の原因であり、ANAが損害を被った原因である」という論法になるはず。
もはやここから先はANAとU社さんの個別の契約の話なので、私のような第三者がとやかく言う内容ではないわけですが、
- ANAは上場企業であり、世界中に数多くの株主が存在する
- 会社は法律を遵守した上で、株主の利益を最優先に考える
- ANAは株主の利益を守るために、行うべきことは行わなければいけない
- でないと、役員が株主から「債務不履行」で損害賠償請求をされてしまう
こんな事情があると思われるので、ANAも株主に「ちゃんと株主利益考えてますよアピール」としての「損害賠償請求の検討」をいわなければいけなかったと推測。
U社が履行すべきだった債務とは？
個別の契約の話なので超推測ですが、帰着するのは「なんで冗長化してたのにシステム全体が止まっちゃったの？」という点だと思われる。
2016年3月22日に発生した、全日本空輸株式会社（ANA）の国内線システム障害についての考察 - わかりやすい
にも書いた内容に少し関連するけど、
- 設計が悪かった←設計者の瑕疵
- 設計は適切だったけど、設計を実現する機器の選定を誤った←機器選定者の瑕疵
- 機器が、設計どおりに動くための要件を満たしていなかった（今回の機器を選定したのが悪かった）
- 設計は一見適切だが、設計を実現する機器が世の中に存在しない←設計者の瑕疵でもあり、「そんな要件満たす機器はありません」と指摘できなかった機器選定者の瑕疵でもあると思われる
- 「故障機が故障シグナルを送信することでフェイルオーバーさせる」は、故障機に何かしら動作を期待している時点であやしい
ほかにも「運用が悪い（障害が長期化したのは、構築時に想定していた復旧手順を適切に履行しなかったことが原因である）」、という主張も出てくるかもしれませんね。
教訓
仮定（推測）の上に教訓もへったくれもないですが、
- 無理が通れば道理が引っ込む
- 「絶対止めるな」に対しては「コスト」か「納期」か「嘘（実は止まっちゃう）」で責任を取ることになる
- システム要件は現実的なものを定義しましょう
- 設計はシステム要件を最低限満たす、シンプルなものにしましょう
- 機器選定は、設計要件を最低限満たす、稼動実績の高いものにしましょう
- 実は運用が一番大事ですよね
- 運用してシステムとしての役割を果たさせる（目的）ために構築する（手段）のであって、「作った（目的）ものを動かし続けなければいけない（尻拭い）」ではないはず
- 無理・誤りに気づき、適切なレールに戻せると幸せですね
- だいたいシステム作るときには、予算と納期（下手すると採用すべき機器まで）が決まっているのに、要件はぜんぜん決まっていない、なんてことがよくあるので、まぁ、難しいですよね…。
ITによって世の中がもっと便利になりますように。 また、それを支える側にも適切な責任と利益が与えられますように…。
