737MAX 技術問題と開発文化

　エチオピア航空やライオン航空のボーイング737MAXの事故は、単なる技術的問題にとどまるものではなく、開発文化的な背景があるのではないかと感じていたが、やっぱりと思うようなニュース（原文はこちら）が流れ始めた。
　ボーイング737MAXの2件の事故の原因は、ソフトウェアの品質不良に限定されたものではなく、MCAS（操縦特性拡張システム）をはじめとする機体全体の設計思想に疑問が感じられると先のnoteで指摘した。
　また、機体の安全性に関係するような重要な機能を組み込みソフトに担わせた場合に生じるソフトウェアの検証の難しさについても別のnoteで指摘した。
　先週のBloombergの記事では、組込みソフトの品質劣化の原因を時給10ドルの外部業者へのアウトソーシングが原因だという印象を与える見出しだが、今回の事故原因を時給の安さだけに導くのは少し論点が違うと感じる。
いろいろな具体的な事実が明らかになるにつれ、当初指摘したように今回の事故の原因は、737MAXの飛行システム全体のトータル・システム・デザインの欠如、すなわち開発費低減のために部分最適化が優先され、『全体最適をチェックする機能』がどうやら存在しなかったか、相当おろそかだった事の方が最大のポイントだろう。「737が成功機種だったのだから、エンジンを交換しただけの737MAXにはトータルシステムの観点からの全体レビューは重要ではない」という安易な開発姿勢が徐々に明らかになりつつある。「実はエンジンの変更は機体の死命を制するほど重要な変更である」という指摘する能力のある人材が開発リーダーあるいは経営幹部の中に結局は一人もいなかったということだ。フルモデルチェンジは厳しくチェックされるが、マイナーチェンジだとついチェックが甘くなることは多い。737から737MAXへの改良？は、実際はフルモデルチェンジなのにマイナーチェンジ並みの開発チェック体制で済ませていたのではないか。

　もう一点、人命にかかわる機能を持つ組み込みソフトを搭載した製品については、その組み込みソフトが「どのような設計思想で開発され、それに対してどのような検証を実施したか」の記録を残すように義務付けるなどのなんらかの規制が必要ではないだろうか。
　ハードウェアの欠陥は再現させやすく発見も比較的容易だが、組込みソフトの欠陥は特定の局面でしか発現しない場合が多く、その局面を再現すること自体が困難な場合が多い。どのような局面を想定した検証が行われたか、どこから先を想定外としたかなど、検証結果のレビューがどのようにして行われたかについてのトレース性の確保は責任の所在の明確化や品質向上のためにも、ぜひ行うべきである。