社員ブログ／イベント

モンティホール問題

突然ですが、モンティホール問題はご存じでしょうか？

こんな問題です。
３つの扉を用意して、そのうちの１つだけがアタリの扉で、開けると商品（もともとの例では新車）があります。ハズレの扉を開けるとヤギが出てきます。
まず、プレイヤーが扉を１つ選びます。次に司会者はプレイヤーが選択した扉ではない残り２つの扉からハズレの扉を１つ開けます。
司会者がハズレの扉を開けた後、プレイヤーは最初の選択を変更することができます。
プレイヤーは最初の選択を変更すべきでしょうか？
…という問題です。

答えから言ってしまうと、選択を変更した方が当たる確率は高くなります。
最初の選択のまま変えなければ 1/3 の確率、選択を変更すると 2/3 の確率でアタリです。
したがって、プレイヤーは選択を変更すべきです。
人間の直感を数学が裏切る（選択を変えなくとも確率は変わらず 1/3 に思える？）例として有名な問題ですから、答えをご存じの方も多いと思います。確率の問題として解くことができなければ、コンピュータでシミュレーションしてみればよいでしょう。例えばこんなプログラムでもシミュレーションできます。

実行してみると確率はきちんと大体 2/3 (=66.667%)と出ます。

上記のプログラムはごくごく簡単な誰にでも書けるプログラムです。そして、ある意味、こうした問題にあたったときにはこういうやり方をしても数年前まで問題はなかったのではないでしょうか。

私の個人的な所感に過ぎないのかもしれませんが、最近はこういうやり方ではすまなくなってきているように思います。それは、扱うデータ量や計算量が飛躍的に大きくなった結果、ではありますけれども、それは今まで何回も言われてきた「扱うデータ量や計算量が飛躍的に大きくなった」とは根本的に違うように感じます。実際問題、過去にデータ量や計算量が大きく変わったことは数多くありましたけれども、今のようにはあまり感じませんでした。

例えば、この感じは私自身はゲームの業界の出身ですので、計算量という意味で２次元から３次元になったときを思い出します。つまり３角形のすべての頂点を透視変換しなければならなくなった時ですね。そもそも、単精度であろうとfloat を扱う時点で遅い、くらいのことを当時のプログラマは思っていました。それを数千数万の莫大な積和計算をやろうというのですから、当時のプログラマーは大丈夫かと感じた人も多かったことでしょう。
ちなみに今現在は、その時と比べてもはるかに大きな計算量になっています。１ピクセルを描画するために直接的にかかっている計算だけでも莫大なものです。光源と法線と色とシェーディングの補間式すべてを計算する必要がありますから。

上記の例でいうならば、プログラマは３次元空間を扱うための数学を新たに学ぶ必要がありました。２次元のときは中学生程度のごく初等の数学だけ分かれば問題ありませんでしたが、３次元になってくると高校レベル、ものによっては大学レベルの数学が必要になってきます。結果として、かなりの数のプログラマがついていけずに脱落しました。職人的な意味でのプログラムの書き方にいくら長けていても、数学がわからなければこの分野のプログラムはできません。

個人的には同じようなことがデータ処理の世界でも起こりつつあるということを感じます。モンティホール問題の例でいうならば、きちんとベイズでいう事後確率を使ってコンピュータでのシミュレーションによらず計算できるような人でなければ、オペレータ的なプログラマとしての仕事以外はなくなっていくのではないでしょうか。

データ量や計算量がきわめて大きい場合は、理論的にデータをふるい落とす部分というのは最初から考慮しておく必要があります。いくら高速になったからといっても、１ペタバイトの処理をしようと思ったら、何の計算をするのかというその目的にあわせて理論的に可能な限りの最適化はあらかじめ済ませておく必要があるでしょう。その例としては議論の余地がありそうですが、私が意味しているのはDFT（Discrete Fourier Transform）に対するFFT（Fast Fourier Transform）のような関係です。つまり、プログラミングの文脈においての実装の工夫の限界というのはその辺にあるのではないかと思うのです。

そういう意味で、今後は大きなデータを扱うプログラマにはもっとデータサイエンティストとしての側面を求められるようになっていくようになっていくのではないかと思います。しっかりした理論に基づいて、その応用ができることが求められると思うのです。現場たたき上げも重要ではあるのですけれども、より広い視野をもった、正規の教育を受けた人たちがより活躍するようになるのではないでしょうか。

これは特定製品における保守開発で見られるような、その特定製品における Json職人や DB職人のような人々とコンフリクトを起こすことが予想できますし、最終的には多くのそういう人々を駆逐する結果になるかもしれません。

ただ、こういうことは歴史を見ても珍しい例ではなく、そこから学ぶことも十分に可能ではあるとも感じます。
例えば、ライト兄弟は飛行機の初飛行の栄誉は得ましたが、その会社は飛行機のメーカーとして成功しませんでした。彼らは自転車屋でしたから、自転車のつくりと考えの限界を突破できなかったからです。エジソンは直流電源にこだわって会社を傾けました。彼は独学であったために正規の教育では教わるはずの三角関数がわからず、交流を理解できなかったからだという説があります。

今後、つづけてエンジニアとしての活躍を望むのならば、最新の技術的なトレンドについて頭に入れるだけではなく、それはどういった分野のどういった理論をベースにした考えなのかという基礎の部分についても問われるようになるのかもしれません。
学生の方々から時々「どんなプログラミング言語の勉強をしておけばよいのか？」といったような質問をいただくのですが、個人的な立場で答えることが許される場合、情報系だったり、いわゆる理系の学生さんには「学校の勉強をきちんとよく理解しておくことが大切であると考えています」と答えています。コンピュータの言語は様々な特徴はありますけれども、その気になればとりあえず数時間後には使えるようになりますが、理論はなかなかそうはいかないからなのです。

Wacky