バグ検出ドリル（1）「さあ、バグを見つけよう」：山浦恒央の“くみこみ”な話（101）（4/4 ページ）

記念すべき連載第100回を突破した「山浦恒央の“くみこみ”な話」。今回の第101回からは、新シリーズ「バグ検出ドリル」が始まります。山浦氏が出題する問題に取り組んで、バグを見つけ出す力を養おう！

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

4．単位系にまつわる大事件

　問題2を読んでも、単位系のバグの重要性についてピンと来ないかもしれません。本問題の出題理由は、単位系のバグが原因で、大問題に発展したケースが少なからずあるためです。以下に実例を示します。

4.1 火星探査機で起こった大事件

　1999年にNASA（米国航空宇宙局）の火星探査機（Mars Climate Orbiter）が単位の間違いで、目標軌道を外れました。ご存じの通り米国の単位系は「ヤード・ポンド法」です^※2）。例えば、大リーグ中継で投手が投げた球速は、マイル^※3）で出てきますし、ゴルフの飛距離はヤードで表現します。

※2）［参考文献1］によると、ヤード・ポンド法を採用している国は、米国以外ではミャンマーやリベリアぐらいだそうです。

※3）1マイルをメートルに変換すると、1.61kmとなります。大リーグ中継を見ている人はピンとくるでしょう。筆者もTVに100マイルと出ると、「大体球速160キロで、大谷翔平の最速球ぐらいだな」と脳内変換できます。また、温度の単位は華氏です。摂氏0度は華氏33度なので、日本人には非常に分かりにくいのですが、米国で小学校を風邪で休んだり、高熱を理由に会社をズル休みする場合、電話で「熱が100度あります」と言えば、相手は、「お大事に」と言ってくれるそうです。摂氏で37.7度ですので、「非常にそれらしい熱」ですね。

　［参考文献1］の記述を引用すると、原因は、「ヤード・ポンド法で計算しているエンジニアからのデータを受け取るミッションコントロール（火星探査機を地上から管理・制御するセンター）では、常にメートル法を使っており、発射時からのずれが蓄積されて、大失敗してした」と書いてあります。直接の原因は、ヤード・ポンド法でデータを作る側と、メートル法のミッションコントロール側の食い違いが原因です。

　この原因は、仕様を両者でしっかり取り決めていなかったことです。根本的には、単位系を全世界で標準化していれば、同じミスは起こらなかったでしょう。

4.2 旅客機で起こったヒューマンエラー

　単位の取り違えでヒューマンエラーが起きた事件もあります。［参考文献1］によると、1983年7月23日、エア・カナダ143便が単位を間違えたことが原因で、飛行中に燃料切れとなりました。当時、ヤード・ポンド法からメートル法への移行中で、143便は、メートル法を採用した機体でした。フライトに必要な燃料の重さは正しく計算していたのですが、そこから飛行機に残っている燃料分を引いて給油量を計算する際、リットル単位の燃料量をキログラムではなくポンドにしたそうです。結果、飛行中に燃料切れでエンジンが停止し、緊急着陸しました^※4）。この事件は、ソフトウェアによるものではありませんが、単位系が人間に誤解を与える原因になったことには、変わりありません。

※4）この緊急着陸は、機長の卓抜な操縦により、着陸進入時にグライダーのように斜めに滑空して減速。その結果、死者を出すことなく着陸し、「ハドソン川の奇跡」と並び、航空機事故史上、最も有名な奇跡となりました。着陸したギムリー空港の名前を取り「ギムリー・グライダー」といわれています。多くのテレビ番組や、紹介記事で取り上げられています。例えばこちらのWebサイトを参照してみてください。

5．自己採点シート

　今回の自己採点シートをリスト4に示します。

問題	内容	配点（点）
平均を求めるプログラム	3分間考えた	＋30
	変数avgが0クリアしていないことに気付いた	＋10
	ループが1つ足りないことに気付いた	＋10
2点間の距離を求めるプログラム	3分間考えた	＋30
	単位系のエラーを見つけた	＋20
プラスアルファ	筆者が気づいていないバグを見つけた	＋5×件数
リスト4　自己採点シート

　リスト4には、今回の2問の配点を示しました。基本的には、100点満点になるように設定していますが、筆者が想定していないバグを見つけた場合は、プラスアルファで「＋5×件数」としました。事実上、無限点取るバグはありますが、そこは気にしないこととしますので、ガンガン見つけてください。

6．まとめ

　「どんなバグが発生しそうか」を推察することは、バグの未然防止に役立ちます。新シリーズでは、エンジニアのバグを見つける能力の向上を目的とし、バグ入りの問題を出題しました。皆さんの結果は、どうでしたでしょうか。

　今回は、特に単位系に着目した問題を出題しました。数字は、単位をつけないと、簡単に重大バグとなります。ご注意ください。また、「仕様の抜け」は、今後もソフトウェア開発、特に、仕様のバグの王様として君臨することでしょう。開発組織で、どのように仕様の抜けを軽減できるか、考えてみてください。

参考文献

参考文献

［1］「これだけ!単位（これだけシリーズ」（伊藤幸夫、寒川陽美、2015、秀和システム）

【 筆者紹介 】

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

東海大学 大学院 組込み技術研究科 非常勤講師（工学博士）

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

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