シュレーディンバグの概念
皆さん、こんにちは。雨宿りとWEBの小噺へようこそ。 パーソナリティーのkeethことくわはらです。
この番組では、手間苦しく変化するWEB業界の中、 興味深い裏話や小噺など、
そっと一息つけるお話をお届けします。 今回の話題は、プログラマーなら一度は経験したことがある
不思議な現象、シュレーディンバグについてお話しします。
はい、先日とあるXでのポストを見つけまして、 投稿内容を読ませていただきます。
どのポストだったのかは、後ほど概要欄にもリンクを貼っておきます。 突然良いアルゴリズムを思いつく。
とにかくがむしゃらにプログラムを書きまくる。 アセンブルもリンクもエラーなく一発で通る。
実行する。全くバグらずに完璧に動作。 嘘だろ?そんなはずはない。と不安になる。
今ここ。 というポストがありまして、これ結構バーズってまして7万3000いいねついてました。
ブックマークも3300。これがブックマークつくのはちょっと面白いなと思いましたけど。 投稿に対してのリプライですね。
ここもたくさんあって、そのリプライにも結構共感するものがありましてですね。 感じたことというか、この投稿から僕も共感するものがあったりとか、
これってこういうことだなみたいなとか 思うことをお話しようかなと思ってまして。
これ自身はですね僕も何度も経験しております。 やっぱりうまくいきすぎていると本当に大丈夫かって不安になるわけですね。
開発したりリリースしている途中で やっぱバグってましたとか
動かないなぁみたいな。なんかわかんないけど動かないっていうのもあって、これは嫌なんですけど。 とはいえ何もなく本当ストレートに終わってもうあとリリースを待つだけ
なるのはすごく怖いんですよね。テストもちゃんと通ってますし、 モンキーテストやったりとかいろんな人たちで動作検証とか
バグバッシュとかをやれば基本的には何か出るんですけど、 それでも出る量が少なかったりとか全然出なかったりすると
ものすごい不安になっちゃうんですよ。 これ自体悪い感覚ではないと思ってますし、本当に自分みたいな人間、心配性な人間は
どこまでも疑いを持ってしまう。 その代わり品質を高めるとこにつながるので悪くはないと思ってるんですけど、
これと似た話で今回の不思議な現象、 シュレーディンバグの話したいと思いまして、
コードがうまく動かないとか明らかにバグがあるみたいな感じですね。 実際にバグが発生している。
デバッグする調査のために僕はフロントエンドエンジニア長かったので、 ソースコードの中にコンソールログを入れます。
入れた途端に、なぜか正常に動くんですよ。 さっきまで動かなくあり、100%バグが発生したんですけど、
コンソールログを前後とかに特定の機能、ここが原因でしょうというのを突き詰めて、 その前後にコンソールログを出して確認しようとしたら急に正常に動き出した。
そしてそれ以降コンソールログを外してもこのバグが現れないみたいなことが起きるんですね。 すごい不思議な現象なんです。
これは何なんでしょうかねみたいなところですけど、 これがシュレーディンバグという名前のものになります。
シュレーディンバグという名前は皆さんご想像の通り、物理学の有名な思考実験ですね。 シュレーディンガーの猫から来てます。
量子力学の話ですね。 観察されるまでは粒子が複数の状態を同時に取り得るという原理がありまして、
シュレーディンガーはこれを説明するために箱の中の猫が生きているか死んでいるか、 箱を開けて観察するまでは両方の状態が共存しているというパラドックスを提案してました。
これをプログラミングの世界に当てはめてみたところ、 バグを観察しようとする行為そのものがバグの状態そのものに影響を与えてしまうという現象。
デバッグの実例
これをシュレーディンバグと呼ぶそうです。 僕今回初めて調べて知りました。
冒頭でも実体験を共有したんですけど、 本当はJavaScriptのコードでコンソロログを追加したらバグが消えるパターン。
あとは本番環境で発生しますけど、開発環境だと再現しないみたいな。 これ結構クラシックなパターンですね。昔からあると思います。
僕はDockerコンテナを使ってスペックだけ違うとはいえ、 環境自体OSとかはミドルウェアとかは一緒のはずなのに、
プロダクションとディベロップのコンテナで 動作が違うみたいなことを経験したことがありまして、他の方もあると思います。
完全一致じゃないからっていう理由はあると思いますけど、 にわかには信じ難いですよ。こんな悪夢のような話があるんです。
また動作確認のために動いているところをお客様であったり、 ステックホルダーに見せることもあると思います。
いざ見せようとしたら動いちゃう。その逆もありますよね。 今まだ動いてたのに、いざ見せるときになって変なエラーとか
うがいが出て、なんか動かないんですよねみたいな。 これ本当によくあるんですけど。
今バグの修正中なので見せられないんですけどと言って、 いいから途中まで見たい。いざ動かしたらお前動くじゃないかみたいなことを
言われたことを僕もありまして。本当不思議なんですよ。 エンジニアなのでゲイン匿名は多分できるはずなんですけど。
これなんで起こるかっていうところなんですけど、 一応理由をつけようと思ったらいくつか出てきて。
一つはまずタイミングの変化ですかね。 デバッグコードを追加してプログラムの実行タイミングが微妙に変わるんですよ。
ほんの1秒なので、0.0何秒みたいな。 もっともっと短いかもしれないですけど。
その微妙にタイミングが変わって、 強豪状態みたいなのが解消されるのじゃないかなっていうのが一つ。
あとはメモリのところにも何か影響あるんじゃないかと。 どっちしろコンソールログ追加して変数のスコープトとか生存期間みたいなのが微妙に変わったりとか。
さっきの処理のタイミングとかによってメモリの使うところもタイミングがずれるとか。 参照の扱いが変わってしまうとか。ないと思うんですけどね。
あとは最適化に際が出てしまう。 コンパイラーの最適化の挙動が変わること。
リリースの不安
これも0ではないと思っているのであるかなみたいな。 最後は、さっきの量子力学の話も一緒に出ましたけど量子効果。
じゃないですけど、環境の微妙な違いによって。 これはもっと冗談半分でアホみたいな話なんですけど。
例えば宇宙船とかによってビット判定みたいなこともごく稀にある。 この現象自体はあるんですけど。
これがコンピューターに影響とかシステムに影響するかみたいなのは、 ほぼほぼないな思いますけど。
見えない要因みたいな一つの例として。 こんな感じで何かあるかもしれないという。
所詮電気信号で全部やっているとはいえ、 それ自体に何か見えないものの影響があるっていうのは否定できないかなみたいな思ってたりします。
本当に一個一個のケースバイケースで特定しようと思ったらできるんでしょうけど。
この時エンジニアとしてはどんな真理なのかみたいなことが個人的には面白い。
冒頭の紹介したXの投稿ですけど、 バグがあるはずなんだけど見つかんなくて、
リリースされてしまって問題がなかった場合とか。 これもすごい不安になるんですよ。
本当に問題ないのとか、誰かお客様が使ってて重大な不具合とか障害が発生するとかすごく怖くて。
起こるならリリース前に我々の手元で起きてほしい。 でも問題がなかったりして。
シュレーディングバグの概念
でもそのままサービスがいろんな大人の事情で終了になった場合、 何も問題なく終わったら、
これもこれで不安というか誰かが勝手に直したのか、 運良く誰も起きないまま終わったのかみたいな感じに思うんです。
この不確実性に対する人間の対処法として、 とても興味深い真理ですよねみたいなところです。
エンジニアはよく自分の安定のために多分解決したんだろうというふうに解釈をしたりします。
知らず知らずのうちに誰かの修正とか実装で解釈をします。
最後、プログラマーエンジニア同士で合わされるジョークみたいなのがありまして、
なぜQAエンジニアは量子力学が嫌いなのか。 答えは観測すると状態が変わってしまうからだ。
もしくは私のコードには量子の不確定性原理が適用されます。
バグの位置と存在を同時に正確に知ることはできませんみたいなものがあります。
嘘です。聞いたことないです。 調べたらあるかもしれないです。
シレーディングバグと戦うための対処法というか実用的なもの。
僕は今までこうやってきたというのと、 他で調べた感じ皆さんもこうやっているなみたいなところですけど、
一つはロギングのレベルを上げましょう。
さっきのコンソールログだけじゃなくて、 体系的にロギングの仕組みを実装しましょう。
二つ目は再現性を高めるというところですね。
自動テストでバグを補足する仕組みを作る。 さっきのロギングとも連携するものかなと思います。
あとは三つ目、非同期処理のところの注意を上げましょう。
特にJSだと非同期処理が予期せぬタイミングで問題を引き起こすことも 間しばしばありますよねというところです。
四つ目、環境の一貫性ですね。 さっきもドッカーの話、コンテナの話をしたんですけど、
開発環境と本番環境の差分をなるべく最小限にしましょう。
ラスト、謙虚である。 これはマインドセットの話ですけど、
完璧に動くコードだとしても、やっぱり疑いの面を持ちましょう。
僕らが完璧と思っているものが本当に完璧か分からないところですね。
というところで、今回の話もいろいろ喋りましたけど、 予期せぬ不具合とかバグってやっぱり隙もろだなと思いますし、
うまくいっているときほどエンジンとして不安になるのも仕方ないなというふうに 思う面も僕はありますよというところで、
今回も終わりが近づいてきたので、エンディングです。
エンジニアの心構え
結局のところ、プログラミングは科学であると同時に、 時に魔術のような側面も持ち合わせているのかもしれませんね。
シュレーディングバグはその象徴なんですけど、 バグが消えたときに何で直ったのか分からないけど、
とりあえず良かったなと思うのは、とりあえず自然な反応だとは思います。
ただエンジニアであれば、結果があるんだったら原因もあるはずですので、
根本原因の追求を諦めないのがエンジニアだよなというのは思います。
とはいえ、それでも原因不明な事象っていくらでもありまして、
今はどうしても分からないけど起きていないし、
もう一回起きたときに改めてその材料を元に調べましょうみたいな。
なので一回経過観察で蓋を閉めるみたいなこともよくあります。
これエンジニアなので絶対できるでしょと思われがちなんですけど、 エンジニアでも分からない問題って結構あるんですよね。
他にも分からないけどとりあえず再起動したら直ったとか結構あるんですよ。
困ったら再起動は僕らの中では割と通説だと言っていいんじゃないですかね。
よく聞く話ですし。
キャッシュ周りとかメモリ周りのところのバンチ、アドレスの不具合が起きたりとか、
なんかあるんじゃないかなっていうのはありますね。
皆さんも不思議なバグ体験とかあれば、ぜひコメント等で教えていただけると嬉しいなと思います。
次回以降のエピソードで紹介させていただければ嬉しいなと。
この番組面白かったよという方はぜひチャンネル登録もお願いします。
もし聞いていて気になることや話してほしいトピック、感想などありましたら、
概要欄のフォームやXでハッシュタグ、ウェブ小話でつぶやいてください。
ウェブはアルファベット、小話は漢字でもひらがなでも大丈夫です。
それではまた雨宿りしに来てください。
今回もお聞きくださりありがとうございました。
雨宿りとウェブの小話、お相手はキースでした。
さよなら。
