私がボーイング737MAXに乗りたくない理由

インドネシアのライオンエア610便、エチオピアのエチオピア航空302便の墜落事故により飛行停止となっているボーイング737MAXについて、アメリカの消費者問題活動家のラルフ・ネーダー氏は恒久的な運航停止を求めたとの報道（リンク和文・英文）がある。

私は「恒久的な運航停止の必要性」については判断する材料も知識もない。しかし、実際に運航再開のめどは未だに立っていないようである。
私は737MAXの事故原因は、単にソフトウェアを修正すれば安全になるというような小手先の対応で済む問題ではなく航空機の安全に関して本質的なリスクを伴うものではないかと見ている。
　すなわち、この事故は単なる技術的問題にとどまらず、ものごとの開発において出発点となる「設計思想」のコンシステンシーの危うさを感じさせる。ボーイングは737MAXだけでなく、すべての機種の設計レビューを行う必要性を感じているのではないだろうか。
　システム屋のはしくれとして、737MAXの事故原因の調査の進展に関するニュースがもたらす情報には、737MAXの事故の背景には、MCASとそれに関連するシステムや機体全体の開発内容の変化とそれに伴う開発体制に内在する課題があるのではないかと強く感じさせるものがある。
　そればかりか、ボーイングないしアメリカ航空当局の航空機の安全性に関する開発体制、検証体制がシステムのソフトウェア化について行けずにほころびが生じ始めているのではないかという疑念が高まるばかりである。特に従来ハードウェア主体の航空機機体システムにおいてソフトウェアのもつ役割の拡大に伴う開発内容の変化に開発体制が対応できていないという臭いがプンプン漂っている。
　今回の事故はその航空機メーカーの開発体制の中で航空機機体システムの全体仕様の総括をどのようにマネージしていくかという「システム仕様に関するガバナビリティの持ち方」という問題に関する「ほころび」の氷山の一角に過ぎなのではないだろうか。

● 737MAX開発への疑問点の概要

① 「本質的に不安定な挙動を示す航空機」の飛行特性をソフトウェアにより仮想的に安定化することの是非に関する判断の主体の不明確さ
② 「航空機の安定性の確保にソフトウェアを介在させること」により起こる開発プロセスの変化への対応のずさんさ。具体的には航空機の安定性の確保にソフトウェアを介在させることにより新たに必要となる開発関連作業に関する認識の欠如
③ ソフトウェアとハードウェアが協働して機能を果たす大規模システムの開発に不可欠な（ハード＋ソフト）全体の開発マネジメントの必要性に関する認識の欠如。
④ それにより生じる、部分最適化の全体最適化への優先に見られる優先順位の逆転。

などがあるのではないかと考えられる。

疑問１：ソフトウェアによる操縦特性の仮想化

第一に、問題となったMCAS ( Maneuvering Characteristics Augmentation System)というシステムを旅客機に適用することの妥当性に疑問を感じる。文字通り訳せば「操縦特性拡張システム」だが、説明を見るとむしろAugmentation SystemというよりもVirtualization Systemといった方がより適切ではないかという機能であると感じる。しかし、AugmentationであれVirtualizationであれ、本来不安定な機体の操縦特性を改善するためにソフトウェアを介在させ、擬似的な安定性を作り出しているものである。これは、安全を第一とする旅客機の設計方針として本当に適切なものなのだろうか。
ソフトウェアによる擬似的な安定性により従来技術では実現できない高性能を実現しようとする考え方は、軍用機では昔から考案されてきた。その例としてコンピュータ制御による安定性の確保を前提として、前進翼の不安定性を利用して運動性能の飛躍的向上を目指した前進翼戦闘機がある。しかし、前進翼の戦闘機は未だに実現していない。
　それはさておき、旅客機には戦闘機のような過激な運動性能を求められている訳ではない。何より大切なのは安全性である。その観点から見れば、今回のMCASの使用目的は運用燃費を改善するために犠牲になった操縦特性の糊塗、要するに操縦特性に関する「まやかし」である。軍用機ならまだしも、民間の旅客機の機体にこのような仮想的な安定性の確保方式を適用することは許される事なのだろうか？

疑問２：安易な「禁じ手発動」－ソフトウェアによるパイロット操作のオーバーライドの是非

　ニューヨーク・タイムズの記事によれば、当初のMCASシステムの介入は控えめなものであったが、どこかの段階でソフトウェアが操縦者の操作を優先（オーバーライド）する様に設計が変更されたようだ。しかも、墜落の危険がある機能であるにも関わらず、それを非常時に解除する方法について操縦者が訓練を受けていなかったのである。
　ここには2点の疑問がある。第1はこのようなオーバーライド機能を設けること自体の是非であり、第2はこのようなリスキーな設計変更についてなんらチェック機能が働かなかった理由についてだ。

疑問３：センサーの信頼性確保方法

　迎角センサーは機体の左右両側面にそれぞれ1個、合計2個設置されていたが、両者の計測結果が異なるときにどちらが正しいかの判断を可能にする第三の手段は無かった様に見える。本来なら、別の迎角測定方式による測定結果との比較や、多数決論理による測定結果の正常性の確認が必要だと思われる。現状は操縦者の操作をオーバーライドするほど優先権を持つ機能の信頼性確保の手法としては著しく不足している印象を受ける。このような重要な判断を担う機器は機器の数だけでなく複数の方法による測定結果を照合する等の方法を用いるべきである。しかも、これらのリスキーな機能を持つセンサーの故障警報機能がオプションだったというのも信じられない話だ。

疑問４：バードストライクは「想定外」か？

事故は仰角センサーがバードストライクを受けて損傷したことにより発生したのではないかと報じられているが、バードストライクは航空機にとって決して想定外の事故ではない。例えばジェットエンジン単体については「鳥打ち込み試験」というバードストライク試験が存在し、実用化するにはこれに合格する必要がある。737の仰角センサーにはこのような試験が実施されたと言う報道はない。要するに想定が甘かったのではないかという疑いがある。

疑問５：あるべき設計方針から乖離していないか？

航空機は（特定の性能追求に特化した軍用機は除く）機体の素の状態での安定性を第一に設計されるべきである。適切な例ではないかもしれないが、結果的には御巣鷹山に墜落したとはいえ、747が垂直尾翼の大半を失っても40分以上飛行できた理由には、操縦者の技量が優れていたことはもちろんであるが、747が「素の機体の安定性が優れていたこと」もエンジンの推力の調整だけで飛行できたことに大きく寄与したはずである。そうでなければ操縦者が技量を発揮する余地すらもなかっただろう。ところが737MAXは素の操縦特性の不安定さをアクティブなソフトウェア制御により補償することで擬似的な安定性を実現している。タラレバになるが、機体に同様な事故が発生した時の飛行継続能力を747と737MAXと比較したとしたら、一体どういう結果になるのだろうか。

疑問６：想定した飛行環境は十分と言えるか　

　竜巻のフジタ・スケールで有名な藤田哲也博士が発見した局地的かつ急激な下降気流である「マイクロダウンバースト」は多くの旅客機を墜落させた。しかし、藤田博士が約30年前にその存在を証明するまでは、マイクロダウンバーストなどという気象現象は存在しないと言われていた。
　ひるがえって、仰角センサーにもとづく迎角の制御は、局地的な急激な上昇気流「マイクロアップバースト」は存在しないという前提のもとに設計されている。その非存在の確証はあるのだろうか。万が一にもそれが存在したら、遭遇時には737MAXは確実に自ら墜落するような制御をするように設計されているように思われる。本当にマイクロアップバーストは想定外にして良いのだろうか。やはり気流の方向により計測する仰角センサー以外に機体の絶対的な仰角を測定できる補助的な測定手段を用いる必要があるのではないだろうか。

疑問７：トータル・システム・デザインにおける「ソフトウエアの位置づけの変化」への対応が不十分ではないか？

　ボーイング社内でのMCASの仕様の変更内容について周知が不十分だったという報道がある。この事故についてソフトウェア開発者の眼で見たらどう見えるかの記事もある。
　筆者の経験に基づく推測では、航空機の機体システムの構成が単純な「組込みシステム」から大規模で複雑な「組込みシステム」へ移行しているのに、開発体制がその変化に対応できていないのが理由の一つになっているのではないかと考える。そう推測する理由については、長くなるので別の機会に述べたい。

筆者の専門は通信システム技術で航空技術の専門家ではない。フォールトトレラントなシステム、高信頼性システム、ミッションクリティカルなシステムの開発者技術者として、この墜落事故の報道を過去の経験と照らし合わせた場合に生じる疑問をこの小論をまとめてみた。しかし、最近の航空技術の専門家の指摘を見ても筆者と同じ感想を述べていることから、筆者のこの事故への感想は決して的外れではなさそうである。