イチから全部作ってみよう（36）技術者の「まぁ、いいか」が社会に与える重大影響：山浦恒央の“くみこみ”な話（205）（3/3 ページ）

ソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」。第36回は、「箸休め回」として、ディーゼルゲートと「737MAX」の不祥事例から、エンジニアの日常的な判断や倫理観が社会に与えるシリアスな影響について取り上げる。

[山浦恒央 人間環境大学 環境情報学科 教授（工学博士），MONOist]

4．事例（2）ボーイング「737MAX」

　ボーイング（Boeing）の小型ジェット旅客機「737MAX」において、2件の墜落事故が発生しました。737MAXは、同社の737シリーズをベースに開発した旅客機で、既存の737からさまざまな変更を行った機体です。

　737MAXでは、胴体を拡張し、燃費向上を目指して従来と比べて大きな新型エンジンを搭載しました。その影響で、機首が上がりやすくなるため、MCASという飛行制御システムを搭載しました。これは、特定の飛行条件において、機首下げ方向の力を加えるシステムです。

　MCASには重大な設計上の問題がありました。事故につながった重要な問題の一つが、迎角センサーから異常な情報が入力された場合の挙動です。737MAXには、左右それぞれに迎角センサーがありましたが、MCASは基本的にそのうち一つのセンサーからの情報を使う設計でした。そのため、迎角センサーの一つが故障して誤った値を出力すると、MCASが誤情報を正しいものと扱い、機首下げ方向へ作動させる可能性がありました。

　墜落事故では、ソフトウェアだけではなく、設計上の判断、安全性評価、パイロットへの情報提供、訓練、組織内の情報共有、認証プロセスなど、複数の要因が関係していました。同社のテストパイロットでさえ危険性を認識していたのに、上層部は握りつぶしました。

　その結果、737MAXを正式にリリースした1年5カ月後の2018年10月29日、ライオン・エア610便が墜落し、乗員乗客189人全員が亡くなりました。この墜落事故についてボーイングが「問題なし」と発表した5カ月後の2019年3月10日、エチオピア航空302便も墜落し、乗員乗客157人全員が死亡。合わせて346人が犠牲になりました。ライオン・エア機が墜落した時点で、きちんと対処していれば、少なくとも2回目の墜落は防げたのです。

　事故の原因は明白で、米国の商業航空市場で急速かつ着実にシェアを拡大していた欧州主導のエアバス（Airbus）に超短期間で対抗するためでした。「人力操縦のボーイング、コンピュータ制御のエアバス」と言われ、技術的に遅れていたボーイングは、燃費の良い新型機を開発する時間を一挙に短縮するため、従来の737の胴体を拡張し、低燃費の新型エンジンを積みます。

　新しく開発した新型の航空機なら、型式証明の取得に10年、パイロットが操縦免許を取得するのに数カ月かかりますが、既存機体の拡張なら型式証明は半分の5年で取得できますし、パイロットの操縦免許も2週間、実際は、iPadによる2時間の講習だけでした。型式証明取得の期間を短縮し、操縦士養成のコストを下げ、燃費の良いエンジンで燃料コストを下げ、新エンジンの搭載で上がり気味の機首も下げるなどの課題を全て吸収したのがMCASでした。

　MCASの存在が公になれば、機体も操縦方法も別物になります。型式証明やパイロットの操縦免許の取得に通常の時間がかかります。これ以上、エアバスに後れを取ることが許されなかったボーイングは、MCASの存在を秘匿しました。ライオン・エアとエチオピア航空の事故では、パイロットが操縦かんを引いて機首を上げようとしているのに、機体は勝手に下降したのです。FAA（米国連邦航空局）は、世界中の737MAXを20カ月間、飛行停止にしました。

5．「声を上げればいい」という簡単な話ではない

　今回取り上げた不祥事は、いずれも超名門の製造会社での積極的で意図的な不正です。皆さんは、このレベルではないにせよ「このバグ、放置すると危ないかもしれない」「この仕様、本当にこれでいいのだろうか」と思っても、「まあ、いいか」で終わらせてはいないでしょうか。

　このようなプロジェクトに配属となった場合、「将来、大きな問題になるので、私はキチンと声を上げる」と思うでしょうが、話はそんなに簡単ではありません。例えば、家族がいて、住宅ローンが残っていて、同僚の友人を敵に回してまで戦えないという人もいます。大勢の中の一人だから、他社も同じ不正をしているから、罪は軽微と考えたりします。つまり、「不正を見つけたら、勇気を出して告発しましょう」と簡単に言える問題ではないし、正解もありません。

　少なくとも今日からできることは、「この判断の先に誰がいるのか」を考えることです。バグや仕様を一つとっても、その向こうには、使う人がたくさんいます。最悪の場合、バグがライオン・エアやエチオピア航空の墜落事故につながる可能性があるのです。その人たちのために、キチンと調査し、周りの人に相談し、必要なら記録に残す。地味な行動に見えても、「まあ、いいか」をやめる第一歩です。

6．終わりに

　今回は、2つの事例から、「まあ、いいか」の先に何が起こり得るかを考える回としました。一方は意図的な不正で、もう一方は、隠蔽に技術的／組織的要因が重なった問題です。

　これら2つの事例から学べることは、「問題に気づいたとき、自分はどうするか」です。例えば、「このバグを放置すると危ない」「会社にとって都合が悪いから、この問題は報告しない」「この仕様は本当にこれでいいか」という場面があると思います。

　上記のような場面になった時、「まあ、いいか」で済ませてはなりません。立ち止まって事実を確認し、誰かに相談して、場合によっては記録する。そして、自分の判断の先に誰がいるかを考える。こうした小さな積み重ねが、今日からできる第一歩です。これが、エンジニアのプライドであり、倫理です。

山浦先生執筆の書籍が販売中です！

　本連載で取り上げた「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の書籍「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から好評発売中です。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しています。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。

　前著「ソフトウェア技術者のためのバグ検出ドリル」（2019年11月刊行）も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。

画像クリックで出版社のWebサイトへ

　両書とも興味のある方は、Amazon.comや書店でチェックしてください！

【 筆者紹介 】

山浦 恒央（やまうら つねお）

人間環境大学 環境情報学科 教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科准教授、2016年より非常勤講師。2025年4月より、人間環境大学環境情報学科教授。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。