バグの歴史の始まり
雨宿りとWEBの小噺、パーソナリティーのkeethこと桑原です。
この番組では、目まぐるしく変化するWEB業界の中、ちょっと一息つける裏話や小噺などをお届けします。
以前、バグについてのお話をしたと思いますけど、
日にちや毎日、プログラマーの世界、エンジニアの世界ではバグとの格闘というのが繰り広げられておりますけど、
このバグっていう言葉、英語にすると虫ですけど、
皆さんも日常に使うことが増えてきたんではないでしょうか。
この業界じゃない人でも、これバグってんなみたいな使い方されてると思います。
今回はバグについて、ソフトウェア史上でバグによって高くついてしまった失敗たちについてちょっと見ていこうかなと思いました。
ではまずバグという言葉の由来からですね。
これはですね、もともとアメリカのハーバード大学でコンピューターの動作不良が起きたと。
Mk2というコンピューターだったらしいですけど、その技術者たちが原因を調査したところですね。
回路に虫が挟まってたんですよ。画が挟まってたらしくて。
この画を取り除いたところ、コンピューターは正常に動き始めましたよと。
この出来事を担当していた方ですね。
女性の方で計算機科学者だらしいですね。
この人のチームは実際にその画をテープで実験ノートに貼り付けて、最初の実機のバグが見つかったというふうに記録をしたらしいです。
なかなか面白いことしますね。
実際のバグ、虫という表現からコンピューターの不具合をバグと呼ぶようになったと言われています。
このこと以前から機械の不具合のことをバグというふうに呼ぶようにあったらしいですけど、
明確にバグというふうに呼ぶようになった起源というのは、この事件のことを指すことが大体多いと言われていて、
大体これで定着していると言っていいでしょう。
ちなみに今言ったノートに貼り付けたというノートは現在スミソニア博物館に保存されているらしいです。
調べたら画像もちゃんと出てきたので、本当に面白いなと思いましたね。
この事件は1947年まで遡るんですね。
9月9日にハーバル大学で起きたと。
そんな時代からもコンピューターが使われているというところは、やっぱりハーバル大学の先進性は伺えると思いますけど、
Y2K問題の影響
画が挟まったから動かないって本当に面白いなと思いました。
まあでもこれは有名な雑学なのでそれは置いておいて、
ここからちゃんとソフトウェアのバグの話ですけど、
これまたすごく有名なというか、僕らの中では忘れられた過去の話ですけど、
むっちゃ懐かしいY2K問題、いわゆる2000年問題っていうのがありまして、
記憶に新しい方も多いと思います。
1990年代の後半にですね、世界中が新しい1000年期の到来に湧く一方で、
僕らプログラマーとかエンジニアはある種の恐怖と不安に駆られていました。
まあ全員ではないですし、ちゃんと実装している人たちからすると全然何もないですよって話なんですけど、
何かというと、多くのコンピューターシステムとかアプリケーションだと、
年号っていうのを下二桁だけで表していたんですよ、その当時は。
まあ全部が全部とは言いませんし、それが当たり前ではなかったんですけど、
まあそういうシステムは多かったと。
で、1999年から2000年に変わった時に、99から0になるっていうところで、
コンピューターがこれをどう評価するか。
今まで1999だったのに、2000ではなくて1900と誤認識するかもしれない、
みたいなY2系問題です。
もしそうなってしまうと、銀行の取引とか航空管制だったり、電力網とか、
社会インフラに結構大打撃、大混乱が起きるんじゃないかみたいなことを懸念されていました。
実際僕ら作ってる側からすると、そんなことはねえよっていうのはもう分かってるし、
さっきも不安と恐怖に駆られたって言ってますけど、
そんな言うほど本当にドキドキするものではなかったっていうのはあります、正直。
本当にデカいシステムとか、日銀レベルまでいって影響のデカすぎるシステムを担当してる人からすると、
本当に恐怖だったかもしれないですけど、
僕らみたいな1回のベンチャー企業の人間からすると、そんなでも実はなかったんですけど。
ただ、世界中の企業とか政府っていうのが、本当に世界中の金額ガーッと総額していくと、
大体3000億ドルぐらい、約30兆円を投じて対策に取り組んでいたらしいですね。
いや、ほんまかよって思いましたけど、
でも起きかねないシステムも実際にあったのは事実として、
あれからこういう金額に連なるんですよね。
結果的には全然大きい問題は起きなかったんで、
対策が成功したっていう風に言えるので、それは良い投資だったかもしれないですけど、
恐怖とか脅威っていうものをかなり誇張に表現されたんじゃないかっていう風な見方は全然ありますよね。
ちゃんと作ったらそんなことないはずなんで。
一応そういう問題がありました。
Y2K問題、2000年問題の大騒動みたいなとこです。
結果的にこれはバグではないんですけどね。
もしでも本当は世間に知られていないバグが発生していた現場もあったかもしれないですね。
これの教訓としては、短期的な解決策っていうのが長期的な問題を生む可能性があるよっていうことを、
僕らはやっぱり何もなかったけど、ここはしっかり学んでいきたいなっていうお話です。
昔はメモリーっていうのはすごい貴重だった時代なので、
年号推しも二桁だけっていうのを保存する選択肢。
それ自体は理にかなっているとは僕も思いましたけど、
それがもう何十年もずっと使われ続けるってことを想定できなかったのかっていうのは、
資料が浅かったなっていう話はしますね。難しいですけど。
今、ソフトウェアとかシステムが20年30年使われるって結構レアケースなんですよ。
楽天とかYahooみたいな超大手のサイトであれば別かもしれないですけど、
そうじゃないソフトウェアって5年?10年もったらもう万々歳でしょうぐらいの。
僕の感覚はそのレベルです。
なのでそんな何百年何十年動くみたいなことを想定するかっていうとどうなんでしょうっていうのはありますけど、
システムというのは基本的には何が起きても時間が経っただけでバグるようなシステムを作るっていうのは
僕らとしてはやりたくないと思いますので、ちゃんと動くようには作ろうと思います。
次のバグに関する失敗の話ですけど、
マリナー1号っていうアメリカ初の惑星探査機なんですけど、
こちらがたった一つのソフトウェアの不具合によって大事故が起きたっていう話です。
何かというとマリナー1号っていうアメリカ初の惑星探査機ですけど、
1962年7月22日に打ち上げられたんですけど、
そのわずか293秒後にソフトウェアの使用の欠陥が見つかって、
これが原因で打ち上げに失敗をしましてロケットは指令されて破壊、爆発したというような経緯があります。
制御プログラムの中の一つのバー、バーっていうのは横線のことですね。
これが抜けていたという、厳密に言うとハイフンではなくてオーバーラインだったんですよね。
書いて欲しかったのは。
なんですけど今回はバーが書かれてしまっていたので予想外の動きをしてしまって、
地上から自爆命令が発生されて爆発したといった感じです。
これまたこれで一つの不具合ではもちろんあるんですけど、
これ俗にミッシングハイフンと言われたりするらしいです。
でもこの表現自体にも誤りがあって、なかなか面白いお話ではあるんですけど、
金額的にはバカにならないですよね。
あの惑星探索レベルってことは、
過ぎ込んだお金はかなりでかかったというふうに言われていて、
調べた限りだと当時のレレートで約1800万ドル、
日本円にすると65億円ぐらいお金をかけてたらしくて、
このバグっていうのは史上最も高価な苦闘店と呼ばれたりすることもあります。
厳密に言うと苦闘店ではないんですけど。
たった一つのミスでこんな巨大プロジェクトが台無しになるっていうソフトウェアの、
もしくはプログラマーの良くも悪くも題材になる一つの事例ですよね。
続いてもう一回ロケットの話が出てくるんですけど、
今度はアリアン5っていうロケットがありまして、
こちらは人工衛星を打ち上げるために開発されたヨーロッパの使い捨て型ロケット。
1996年から2023年にかけて、
欧州宇宙機関ESAとEADSの一部分である
EADSアストリウムスペーストランスポーテーション
っていうところによって製造されて、
そのアリアン計画っていうのがあって、
それの一端を担うアリアンスペース車によって営業販売されていたロケットですよ。
1996年の6月4日に行われた最初の飛行ですね。
こちらがですけども、まさかの打ち上げ37秒後に爆発をして失敗に終わってるんですね。
いやいやいや、歴史上これは高くついたバグのほんと一つであって。
後に64ビットの不動小数点数っていうのを16ビットの整数に変換する過程で
エラーが生じたというふうに発覚したという感じです。
読み取るとエラーというかオーバーフローが起きたのかな?
簡単に言うと前のロケットで問題なかった計算でも新しいロケットは処理しきれなかったみたいな話らしいですけど。
この事故によって損失っていうのは約5億ドル。
今2本円でいくと、昔は100円近かったので2本円にすると500億円ぐらいというふうに言われてまして。
いやこれもこれでさっきのといい勝負する失敗の金額ですよね。
これは基本的な計算処理、単純に変換するだけですからね。
その失敗によって第三次になるという本当に皮肉的な結果になってしまうので
しっかりテストをしていきましょうというのはすごく大事な話ではありますけど
マグ1個でこういうこともあるというのは本当に一つの教訓だなと思います。
そういう意味でいくとウェブシステムをやっているぐらいだとそんな大きいところの失敗には至らない。
いや物によりますね。油断せずにしっかり僕らプロとしてうがいを受けないようにしっかり作っていきたいしテストもしたいなと思いますね。
こんな感じでシステム障害による大きなバグあるんですけど。
日本のシステム障害
今度は国内、日本についての話です。
2020年10月1日ですね。
東京証券取引所がシステム障害によって全銘柄の売買を終日停止になったんですよね。
これは当初の売買が終日行われないという事例として
取引が全面的にシステム化された1995年の5月以来初めてのことだったらしいです。
なかなかですよね。全銘柄の取引が終日ダメだよって。
ビジネス止まるじゃんみたいなぐらいのインパクトのお話です。
さすがに止まることはないんですけど。
株の売買について止まるのは結構でかいと思う。
これも株式の売買システムアローヘッドっていうシステム。
これに障害が発生していろんな投資家の方々をはじめ
多くの市場関係者に迷惑をかけるような事件になってしまいましたよと。
このバックアップ機能の不具合が起きていてこんなことになったらしく。
メモリに障害が発生した場合
本来なら自動的にバックアップ機器に切り替わるはずが
その仕組み自体に不具合があったと。
システムの冗長性とか可用性とか
ここはやっぱりお金に関わるシステムであれば
ここは入念に見ていかなきゃいけないし
責任も大きいなっていうのは本気で思いますね。
当時の中のエンジニアの人たちもひやひやもんだったでしょうね。
日本の金融市場の中心ですよね。
東京証券取引所ですから。
これが丸々1日止まったということで
推定で数十億円の経済的損失が生じたのではないかと言われております。
これもでかいですね。
そもそもやってるシステムとか事業とかが大きい
それの不具合ですからそれはインパクトは大きいんですけど
とはいえ肝が冷えるぐらいのレベルの失敗ですね。
他にもいくつか金額インパクトのでかいやつあるんですけど
ラスト1個だけ出しましょうか。
インテルのペンティアムプロセッサーのバグ
ラスト1個はインテルに起きたバグですね。
1994年のインテルのペンティアムプロセッサーに
駆動小数点数の除算に関するバグが発見されてまして
例えば数字が長いんであれですけど
419万5835を314万5727で割ると
正しくは1.33382…となるべきところなんですけど
今回のこのプロセッサーの計算だと1.33374…みたいな感じで
誤った結果が出てしまいましたよと。
要は計算ミスが起きたよということです。
一般的な要素で計算する分には全然問題にならないんですけど
科学計算とか金融計算においてそういうことが起きると
これは致命的なんですよね。
インテル社としては当時一般ユーザーには別に影響ないんじゃないよ
というふうに主張したんですけど
最終的には全チップの効果に応じることをしたらしいです。
その意思決定の遅れによってインテルは約4億7500万ドル
そのまま100倍して475億円の損失を出したと。
ソフトウェアのバグ管理とテスト
結構痛いですね。
これまたこれで475億円ですから。
名前としてはPentium FDIVバグと呼ばれてます。
IVなのかこれは4なのか。
いや4かな。FD4かな。バグと呼ばれているものですね。
こんな感じで今まで見てきましたけど
ほんとちっちゃいバグですね。
一個一個見ていくとそんな大きくない。
なんならほんと軽微なバグなんですけど
一個誤って数百億円の損失を出すみたいなところがあります。
バグってそこら中にあるし
完全にバグゼロみたいなシステムって僕はないと思ってます。
いやないっていうのはやると思ったらいくらでもできるんですけど
それをやるメリットと費用対効果って考えると
そこを追うべきではないっていうのはちょっと思いました。
まあとはいえ人の命が関わったり
さっきの損失の金額がでかすぎるんであれば
また話は変わるなともちょっと思いますけどもね。
だからといってプログラマーとかソフトウェアエンジニアって
結構怖い職業だって思ってほしくはなくて
本当に価値を生み出せる職業ではあるんですけど
設計だったり実装の確認っていうのを怠ると
こういうことが起きる。
まあでもそれは他の職業でも一緒だと思いますけどね。
一つの事例でしたというところで。
現代じゃあそのバグ対策どうするのって話ですけど
やっぱりテストをしっかりするってところに尽きると思います。
テスト駆動開発っていうのも割と当たり前になってきた。
当たり前に耳にするようになりましたけど
それで開発をやっている現場はそんな多くはでもないと思いますが
少なくともでもテストはしっかりやりましょう。
ユニットテスト、インテグレーションテストとか
E2Eテストをやりましょうとか
ソフトウェアテストで自動化をする。
人がやっぱりテストするんじゃなくて
コンピューターにそのままやらせると。
あとはその継続的インテグレーションですね。
CICDをしっかり回して
ちゃんと定期的にチェックをするように心がけましょう。
またそういうアーキテクチャ組みましょうみたいなお話ですね。
こうすることによって早期にバグを発見するっていうような
プラクティスっていうのが作られますので。
他にもちょっと僕はあんま知らないですけど
数学的にプログラムの正しさを証明する方法っていうのも
あったりするらしくて。
もっと重要なシステムがあれば
これはしっかり使っていくっていうのは大事かもしれないですね。
それでもさっきも言った通り
完璧なソフトウェアっていうのは存在はしないので
特に複雑なシステムになればなるほど
開発者もユーザー側も想像しえない
なんだこれみたいな不具合とかバグっていうのは
やっぱ起きがちなんですよね。
それは想像しえないからなんですけど。
なので僕らは過去の失敗からしっかり学んで
未来は絶対それを起こさないとはいえ
今後も何か知らないわけが起きたときに
早く早急に復旧できたり
大きな問題が起きる前に検知できるような
仕組みを考えていったりとかっていうのを
僕らもしっかり考えながらシステムを作っていきたいなと
はい思いましたというところでエンディングです。
今回もソフトウェア市場におけるバグについての話
いくつか大きいものをピックアップして持ってきましたけど
保持者からするともうヒヤヒヤもんですよね本当
なんかも言いますけど
またバグという言葉自体が
実際の虫に由来するっていうところも紹介しました。
こういう雑学の話もあって
虫が入ってきたせいで発生したバグによって
そんな数百億円の損失が出たらもう何ですか
いたたまれないというかぶつけようない怒りが発生しますからね
怖いなとも思いますけど
やっぱりソフトウェアというのは過去から未来に向けて
どんどんどんどん伝えていくというのは大事な話だと思いました。
そしてまた現代はソフトウェアに支えられて
この社会は生きているし今後もそれは変わらないでしょうと
その影にですね
作っている影には無数のそういう試行錯誤だったり
ああだこうだやったり失敗の歴史もあるっていうのを
持っていただけると僕らとしても今後の励みになるなと
ちょっと思いました。
はいバグの歴史いかがだったでしょうか
そんな感じで僕らも結構大変で
汗を物理的な汗かいてるからちょっと置いといてですけど
頭ね汗をかいていいものを作ろうとしているので
もし不具合が起きたり使い勝手悪かったとしても
すぐにこうこのシステムがダメだとか
クソだっていうのは控えてもらえると
僕らとしても助かるなとも思ったりしますし
裏に人がいるのでリスペクト忘れず
使っていただけたらなと
やばい積極臭いなと思いました
じゃあ終わります
この番組面白かったよという方は
ぜひチャンネル登録もお願いします
もし聞いていて気になることや話してほしいトピック
感想などございましたら
概要欄のフォームやXでハッシュタグ
web小話でつぶやいてください
webはアルファベット小話は漢字でもひらがなでも大丈夫です
今回もお聞きくださりありがとうございました
雨宿りをしながら考える技術の変遷
次回もどうぞお楽しみに
お相手はキースでした
ありがとうございました
