膨大なデータを分散並列処理するためのソフトウェアの概念にMapReduceがある。 コンピュータ用語を何か他のことの象徴に使うのは勇気がいるが、 なんとなく今やっていることがMapReduceに近い気がしているので浅はかな知識でも引用してみることにする。 ちなみにMapReduceの実装部分について自分は雑誌の記事を真似てサンプルを動かした程度だ。 Wikipedia([MapReduce - Wikipedia](http://ja.wikipedia.org/wiki/MapReduce "MapReduce - Wikipedia"))から引用する。 > MapReduce は、ある種の問題について、多数のコンピューター（ノード）の集合であるコンピュータ・クラスターを用いて並列処理させるためのフレームワークのひとつである。 > Mapステップ - マスターノードは、入力データを受け取り、それをより細かい単位に分割し、複数のワーカーノードに配置する。受け取ったワーカーノードが、更に細かい単位に分割し、他の複数のワーカーノードに配置するという、より深い階層構造の分割を行うこともある。そして、各ワーカーノードは、その細かい単位のデータを処理し、処理結果を、マスターノードへと返す。 > Reduceステップ - 続いて、マスターノードが、Mapステップでの処理結果を集約し、目的としていた処理に対する答え（結果）を得る。 例えばMap処理について他のMap処理とは完全に独立しているため、 並列分散させることが可能で、今の言葉で言えばスケールさせることができる点が面白い。 これを飛躍させてみる。 僕らが今やっている作業はMap処理である。 脳を分散させていろいろな人と会い「一緒にこれやりたいよね」とある種の夢を語る処理を並列に行っている。 もちろん自分一人だけではなく、一緒にやるパートナーにも同じ作業をしてもらっているはずなので、 人員的要員からもスケールしている。 ソフトウェアの処理は基本的に「問題解決」で我々が目指しているものは「仮説検証」なので一概に比較はできないが、 Map処理という概念をなんとなく頭に入れると、可能性を考える処理を平行してたくさん走らせている感覚がする。 ちなみに「目的としていた処理に対する答え(結果)を得る」ためのReduce処理は 7月に入ってからくらいのタイミングで行われる。 わざわざMapReduceを取り出して何がいいたいかと言うと、Map処理が沢山のワーカーで処理することに対して、 僕らは今、沢山の可能性について話し合うという処理をしているんだということだ。 可能性は多ければ多いほどReduceした時にいいものが産まれる可能性が大きいかもしれない。 もちろんReduce処理での負荷が高くなることは承知であるが。 とにかくまずは、多くの可能性を考慮していきたい。