2016-05-26

近況

しばらくブログを書いていなかったが、いろいろと忙しかった。

今、とある仕事をしているのだが、その仕事内容がまことに精神的に辛い。その仕事内容はまだ公開できないのだが、とりあえず言えることとしては、1文字は1バイトではないということと、C++の標準ライブラリの正規表現ライブラリはUnicodeに対応していないということと、C++のlocaleは多言語対応の足かせになっているということだ。

さて、もうひとつ憂うべき事態としては、メインで使っているラップトップが故障した。去年の冬頃からどうにも挙動がおかしいと思っていたが、いよいよ使い物にならないほど挙動がおかしくなってきたので、memtest86+にかけてみたところ、なんと4900件ほどのエラーを出したところで動作を停止した。完全にメモリが壊れている。

さて、メモリが壊れているだけなら新しくメモリを買ってくればいいのだろうが、このラップトップはその他のスペックが2016年の基準から見て劣っている。ディスプレイの解像度は低いし、WiFiも5GHz帯が使えない。そろそろ新しいPCを買わねばなるまい。

とりあえず今は、別件で手に入った中古のゲーミングラップトップを使っている。これは、GNU/Linuxでゲーム環境を構築するために試しに買ってみたもので、nVidiaの不自由なGPUであるGTX 670Mが積んである。とりあえずUbuntu 16.04をインストールしてみたところ、自由なドライバーであるNouveauで動作した。そのままゲームも遊ぶことができたが、FPSが絶望的に出ない。仕方がなく、nvidia-driverを入れてみると、まともなFPSが出た。しかし、なぜかXrandRが動かないため、ディスプレイの回転ができない。

ところでゲームだが、最近は、ゲームといえばfactorioしかしていない。factorioは極めて高い中毒性のある自動化ゲームで、プログラマーならば必ずハマるだろう。先週は職場の同僚5人でマルチプレイをして、10時間かかってロケットを打ち上げた。

ところで、factorioには列車があるのだが、つながった同一の線路上に複数の列車を走らせる場合、信号を使わなければならない。この信号の使い方は、ゲーム内になんの説明もない。factorioの公式wikiには、OpenTTDと同じだからそちらを参照しろとしか書いてない。

これについて列車好きの同僚に教えを請うたところ、排他処理の起源は鉄道だったという事実を知らされた。なるほど、信号で区切られた区間に存在できる列車は一つだけという排他処理なのだ。これを理解したので、ようやく列車ネットワークが組めるようになった。なんのことはない。単なる排他処理である。ただし、一つの区間のアンロックと同時に、別の区間をロックするという特性がある。

現実の鉄道の排他制御では、区間の独占通行権を示すタブレットと呼ばれる物理的なトークンをやり取りしていたようだ。また、駅間が電信でつながっていて、タブレットを入れると、数値が駅間でインクリメント、デクリメントされ、釣り合いが取れた時だけタブレットが排出される装置まで存在したそうだ。それはセマフォではないか。

自宅でのfactorioのLANパーティもいつか開きたい。

2016-05-11

BitKeeperがオープンソース化された付記DVCSの歴史

BitKeeper

BitKeeperは最初の分散ソース管理システムである。今後はオープンソースのApache 2.0ライセンスとして提供される。

BitKeeperは高速で、エンタープライズレディな、分散ソースコード管理であり、大きなプロジェクトから小さなプロジェクトまでスケールする。

「最初の」という主張には語弊があるが、DVCSの歴史を考えると、あながち間違いでもない。

DVCS(分散バージョン管理システム)を最初に実装したのは、Sun WorkShop TeamWareである。

Sun WorkShop TeamWare - Wikipedia, the free encyclopedia

これは名前通り、Sun Microsystemsによって開発されたDVCSで、その主要な開発者として、Larry McVoyがいる。

Larry McVoy - Wikipedia, the free encyclopedia

Larry McVoyはその後独立してBitMover社を立ち上げ、BitKeeperというDVCSを開発する。BitKeeperは2005年までLinuxカーネルの開発に使われていた。

BitKeeper - Wikipedia, the free encyclopedia

Larry McVoyは、1990年台前半に、Sun MicrosystemsはSunOSをオープンソース化すべきであると主張していた。

The Sourceware Operating System Proposal

もし実現していれば、Linuxは今日の興隆を見なかったかもしれず、我々はSunOSを使っていたかもしれない。

そもそも、Sunの生い立ちたるや、IBMのメインフレームのような巨大で高価なコンピューターに対して、より小型で安価なUnixワークステーションを販売して成功したというものだ。とすれば、次は個人でも所有できる、さらに小型で、さらに安価なPCが流行するというのは、自身の成功体験から予測できたはずである。PC用のハードウェアを売る商売でSunは儲けられたはずであり、OSは自由にできたはずだ。我々はIBM PC互換機ではなく、Sun PC互換機を使っていて、WindowsやGNU/LinuxのかわりにSunOSを実行していたかもしれない(Sunのユーザースペースツールは使いづらいのでGNUはまだ残っていたかもしれない)。

にもかかわらず、Sunは近視眼的な判断によってSunOSをオープンソースにはしなかった。

さて、1993年にSunOSのオープンソース化を主張したLarry McVoyは、残念ながらその主張を実践しなかった。BitMover社を立ち上げてBitKeeperを開発したが、BitKeeperはプロプライエタリであった。2005年まで、Linuxカーネルの開発に使われていたが、無償版で提供されていない機能を実装したLinuxカーネル開発者であるAndrew Tridgellの行為に激怒してコミュニティへのBitKeeperの提供を辞めた。

そして、gitが生まれることになった。gitは圧倒的な速度でDVCS市場を独占していき、BitKeeperなど誰も相手にしなくなった。そして今日に至る。

残念ながら、BitKeeperのオープンソース化は、10年遅かった。もう手遅れだ。

2016-05-08

xkcd 463: 投票機

xkcd: Voting Machines

Premier Election Solutions社(以前はDiebold社)は、自社で開発したオハイオ州の選挙用の投票機が、McAfee アンチウイルスソフトウェアの問題によって障害を起こし責任を追求されている

「ちょっとまて」
「投票機にアンチウイルスソフトウェアだと? 間違ってるだろ」

「なんで? セキュリティは重量だろ?」
「もちろんそうだが、なんと言うべきか」

「保護者の教師の説明会で、教師が授業中は常にコンドームをつけているので安全だと保護者の説明したとしよう」

「なるほど、厳密に考えると、付けていないよりは安全・・・」
「間違ったやり方のヤツがいかに多いことか」

titleテキスト:これで俺はまた暗号会議を追い出された。いいだろ。いい例えなんだからさ。

2016-05-05

MITがSICPを教えなくなった理由

Programming by poking: why MIT stopped teaching SICP | posterior science

このNYC Lisp meetupの動画で、Gerry Sussmanに対する質問として、SussmanとAbelsonの古典、The Structure and Interpretation of Computer Programs(SICP)に基づく、伝説的な6.001講義をなぜMITはやめたのかと聞かれている。

Sussmanの回答としては、SussmanとHal Abelsonは1980年代から延々と教え続けるに嫌気が差し、1997年に、学部長の事務所に行って、「俺らはやめる。後どうするからは勝手に考えろ」と宣言した。より重要なこととしては、SICPのカリキュラムは、今日のエンジニアリングに求められるエンジニアを育てることができないからである。1980年代と1990年代には、エンジニアは複雑なシステムを組むのに、単純で十分に理解されている部品を組み合わせた。SICPの目的は、そのようなシステムを理解するための抽象的な言語を提供することだ。

今日では、状況が変わっている。今のエンジニアは、自分が完全に理解していない複雑なハードウェアのためのコードを日常的に書いている(そして、大抵の場合、企業秘密により完全に理解するのは不可能である)。ソフトウェアでも状況は同じだ。プログラミング環境は、多大な機能を提供する巨大なライブラリ群の集合として存在している。Sussmanの今日の生徒は、その時間の大半を、ライブラリのマニュアルを読み、どのように組み合わせれば目的が達成できるのかを把握することに費やしている。Sussman曰く、今日のプログラミングは、「より科学に近い。ライブラリを持ち寄って、つっつき回すのだ。プログラムを書くには、突っつき回して、どのように動作するかを観察する。そして、「目的を達成するために改造できるか」と考えるのだ」。SICPの「合成による解析」という物の見方である、小さな、単純な部品を組み合わせて大きなシステムを作るということは、もはや今日の状況にそぐわなくなった。今や、我々のプログラミングはつっつき回すことで行われている。

なぜPythonを選んだかということについて、Sussmanは、"late binding"に決定したと冗談を飛ばした。Pythonには大量のライブラリがあり、教育者の様々な実習に使いやすい(たとえば、ロボットを制御するソフトウェアを書くなど)

Sussmanは、SICPカリキュラムは現在のカリキュラムより洗練されていると考えているものの、正しいカリキュラムのあり方についてはまだ答えが出ていないという。

たしかに、今のプログラマーは、ハードウェアの仕様書を元にを直接操作するコードは書かないし、OSを実装していないし、コンパイラーも実装していないし、古典的なアルゴリズムやデータ構造さえ自分の手で書く必要がなくなっている。ライブラリが発達してその必要がなくなったためでもあり、また個々の機能があまりにも高度になりすぎて、到底一個の人間の手に負える作業量ではなくなったということもある。

不自由なハードウェア、ソフトウェアが蔓延してその詳細がわからなくなり、また自由なソフトウェアであっても、その内容が複雑になりすぎ、一つ一つ完全に理解するには時間が足りなすぎる。

何にせよ、平均的なプログラマーが実現できる機能は昔よりはるかに複雑になっていることは確かだ。

2016-05-02

Craig WrightがSatoshi Nakamotoだとする証明はない

WiredとGizmodeにより、Craig Wrightなる人物がbitcoinのオリジナルの設計者にして最初の実装者、Satoshi Nakamotoであると報じている。

Bitcoin’s Creator Satoshi Nakamoto Is Probably This Unknown Australian Genius | WIRED

This Australian Says He and His Dead Friend Invented Bitcoin

bitcoinのオリジナルの設計者にして最初の実装者は、当時Satoshi Nakamotoと名乗っていた。一見、日本人のような名前であるが、彼は自らのことを多く語らず、またできるだけ身元の特定に繋がる痕跡は隠していた。当然、国籍はおろか、個人かどうかすらもわからない。彼の書いたコードのコメントはすべて英語で、非英語ネイティブにありがちな文法ミスはみあたらない。また、彼の当時のフォーラムへの500件ほどの投稿を調べると、GMTで5時から11時にかけてほとんど投稿がみられないので、Satoshi Nakamotoはこの間には睡眠をとっていたのではないかと推測されている。この時間帯はJSTに生きる人間の一般的な睡眠の時間帯とは異なっている。

Satoshi Nakamotoの正体には様々な憶測が飛び交い、日本人である京大の望月新一教授や、たまたまSatoshi Nakamotoという名前であるアメリカ人がメディアによって正体であると噂されたりもした。

さて、このCraig Wrightなる人物は、自ら作者であると名乗りでた人物であるが、発言がまるででたらめであると言われている。Bathurst大学で博士号を取ったと自称しているが、大学は否定した。また、彼のブログによる証明というのも、bitcoinの公になっているハッシュ値にすぎず、ブログで提示しているbase64っぽい文字列に至っては、デコードすると単なる平文のブログ本文にもある文字列になるというお粗末さである。

Jean-Paul Sartre, Signing and Significance - Dr. Craig Wright BlogDr. Craig Wright Blog

そもそも最も簡単な照明である、当時Satoshi Nakamotoが使っていた最初のPGP秘密鍵で署名した、「Craig WrightはSatoshi Nakamotoである」というメッセージを出して、少なくともSatoshi Nakamotoが当時使っていたPGP秘密鍵は所有しているという証明をしていない。

よくある詐欺師であり、目的はSatoshi Nakamotoを自称して出資を引き出すためではないかと言われている。

と、ここまでならよくある話だが、何故か今回の話にはおまけがある。bitcoin開発者であり、当時のSatoshi Nakamotoとも対話していて、暗号理論も理解していて証明の真贋も見分けることができるであろうGavinが、Craig Wrightは確かにSatoshi Nakamotoであるとコメントしているのだ。

このため、bitcoin開発者はGavinのコンピューターがハックされた可能性を考慮して、Gavinからコミット権限を取り消す措置をしている。まだGavinからハックされたというコメントはない。

Peter Todd on Twitter: "FYI, @gavinandresen's commit access just got removed - Core team members are concerned that he may have been hacked. https://t.co/7re7z16TeR"

ちなみに、Gavinがハックされたとか詐欺に加担しているのであれば、最も簡単に利益を上げる方法が取られていない。すなわち、「私はサトシだ。今から私の持っているbitcoinを全部売る」と宣言して、bitcoin取引市場に多大な売り注文がやってくると誤認させ、市場を混乱に陥れてbitcoinの価値を下げたところでbitcoinを買い占め、市場が落ち着いた後で売り払うという方法だ。

Satoshi Nakamotoが今更名乗りでても、それ自体は別に興味深くはない。本人の名声とか政治的迫害を別にすれば、Satoshi Nakamotoでなければできない設計や実装は今さら存在しない。ただし、Satoshi Nakamotoのウォレットに入っているbitcoinは莫大であり、市場に放出された場合、大混乱に陥るだろう。

こういった事情により、一概に詐欺とも言いがたい事態となっている。

コンピューター科学のアカデミック業界の残念な現状

mhoye on Twitter: "Extremely angry with the state of academic CS research right now. (1/n)"

MozillaでFirefoxのエンジニアリングコミュニティマネージャーであるMike Hoyeが、コンピューター科学におけるアカデミック研究の残念な現状に激怒している。

コンピューター科学のアカデミック研究の現状に激怒している。

MozillaがBugzillaを始めとした多数の情報を公開した結果として、多くの研究論文が書かれている。

我々はそのような研究には注目している。論文はじっくり読んでいるし、研究結果にしたがって今後の方向性も決めている。

しかし、我々は常に変化する世界に生きている。そのため、我々はデータをもとに結果を再検証して、仮定が正しいことを確認する。

ここで我々が行いたいことは、我々はある意思決定をある論文Xの結果をもとに行いたいのだが、その結果は最新のデータでも妥当であろうか? と言えることだ。

まともな世界では、そのような検証は以下の3ステップで行えるはずだ。

  • 論文著者のバージョン管理システムのレポジトリをクローン
  • 論文著者のプログラムを最新のデータに対して適用
  • 新しく生成されたグラフを見る

データはまだ仮説を支持するものであるか? 素晴らしい。この方向で進めよう。結果が変わった? 何故なのか考えてみよう。いずれにせよ。全員が満足する結果となる。

しかし、これは実現しない。なぜならば、コンピューター科学の研究者はコードもデータも公開しないからだ。奴らはLatexで整形したWordドキュメントをペイウォールに阻まれたPDFとして公開する。

奴らときたら、科学の原則である、「妥当性」とか「再現性」とか、中でも最も基本的な原則、「現実に即しているか」などは、クソ喰らえの姿勢だ。

人間が知識や学習結果を共有しないことの時代遅れがいかに時代遅れであるかを見てみようか。

ギリシア火薬の製法は失われた。ダマスカス鋼の製法は失われた。アンティキティラ島の機械は紀元前200年に失われ、同等の精度を持つ時計を再び作るには1500年代まで待たねばならなかった。

いいか。よく聞け。お前の未公開のコードと、お前の未検証のデータと、お前のペイウォールに阻まれた博士論文は、この輝かしい因習の一部であるのだぞ。

お前の目的とやらが、学士を得て卒業することなら、まあいいだろうよ。大抵の人間が望むことだ。だが、院にまで来てやることか?

お前の業績により世界をよりよい方向にインクリメントするためには、世界はお前の業績を読めなければならないのだぞ。

俺は結果の報告書など読みたくない。そんなのは、ワインを注文しているのに、赤っぽい色の液体について報じた新聞記事の切り抜きをFAXしてよこされるのと同じだ。

検証可能なデータと動くコードなしには、お前のコンピューター科学の博士論文の命題とやらは命題ではない。それは単に命題が存在するかもしれないという未検証の主張に過ぎない。

まとめると、俺は大変に失望している。もっと言うべきことはあるが、俺はこれから長年の研究とツールを再現するためのコードを書かねばならないのだ。

2016-05-01

超会議2016でドワンゴの運営スタッフとして焼きそばを焼いた感想

「江添さん、超会議で焼きそばを焼きませんか?」

恰幅のいい同僚が話しかけてきた。この男はドワンゴの料理研究部の部長である。

ドワンゴには福利厚生として同好会の設立を会社に申請でき、受理された同好会には部費も支給される。最も、会社が経費として出す金なので、いろいろと制約がある。例えば、飲食費用には使えない。料理研究部は調理器具や職場近くのキッチンのレンタルなどに部費を使っている。

「焼きそば? 少し前に話題になったアレをネタにするつもりですかな。しかし、もう旬は過ぎてしまったのではありませんかな」

「アレ」というのは他でもない。一時期、ドワンゴから退職が相次いだ時期があり、その時のある退職者に対して、退職理由がよくわからないとドワンゴの川上宣夫会長と伊藤直也氏がスシをつまみながらのインタビュー記事で書かれたことを受けて、元ドワンゴ社員のkuzuhaが、言及されている退職者というのは自分であろうと名乗りでて書いたブログ記事が発端で、一時期ドワンゴと焼きそばが炎上したアレだ。

僕は初回のニコニコ超会議が開催される前にこの話を聞いてさっさと退職したので実際には経験をしていませんが、ニコニコ超会議には社員が強制的に動員され、列の整理や焼きそば屋台などに従事させられました。正直に言ってソフトウェアエンジニアとして雇用した人間に焼きそばを焼かせるのは雇用契約違反なのではないかと思います。立て付けとしてはお客様の文化に触れる、本気で楽しんでくださっているお客様の姿をじかに見られる他にない機会であるという言い分です。

ドワンゴは大量退職に関する印象操作をやめろ - hiroki-uemuraのブログ

この炎上以降、Googleの検索欄に"ドワンゴ"と入力すると"焼きそば"がサジェストされ、"ドワンゴ 焼きそば"でググると、ドワンゴに対してネガティブな情報ばかりヒットするようになってしまった。

私がドワンゴに入社する以前の話であり、この当時の状況は人からの伝聞と風のうわさでしかわからないのだが、kuzuhaの記事には間違いがある。初代超会議のフードコートでドワンゴのエンジニアに課された料理は「焼きそば」ではなく「あんかけチャーハン」だったとのことだ。当時、ドワンゴの社内チャットでは、「会社は焼きそばではなくチャーハンですと訂正するIRを出すべきでは」などと無責任な冗談が飛んでいた。

ところでチャーハンといえば、ドワンゴには非公認のチャーハン部があり、名にし負うハンドルネームがチャーハンである部長の強力なリーダーシップのもと、毎週一度近所の中華料理屋に臨んで大盛りのチャーハンを食らうという活動をしているが、同部ではチャーハンの重量以外に、食べづらさ、胃もたれなどの完食への困難性への度合いを総合的に評価した、実質係数なる独自用語が飛び交っていて、1.2kgのチャーハンを完食した部員は尊敬され、中でも、1.2kg完食者の「来る者拒まず、去る者追う」という発言は名言としてSlack上で永久にPinされている。

それはさておき、同僚の話によれば、転んでも無料では起きない精神をもってこの炎上ネタを利用し、来る超会議2016ではエンジニアがフードコートで焼きそばを焼く企画があるという。そのために、フードコートに自らの意思でアサインされるエンジニアを募集しているという。

「いえね、やはりこういう企画は表に名前の出ている有名なエンジニアさんを採用したほうがいいと思いますし、焼きそばを焼くのも悪くありませんよ。なんでしたらフルタイムではなくパートタイムでも構いません。基本的には他のブースにアサインして途中2時間ほど抜けて焼きそばを焼くという形でのエンジニアの参加も予定しています。焼きそばを焼いていただけるのでしたら、特別に企画にかけあって希望のブースに優先的にアサインされるような配慮も致します。そしてですね。あまり言いふらしてほしくないのですが、休憩時間を通常1時間のところ、焼きそばブースは特別に2時間取ろうと予定しております」

「ほう、2時間?」

「はい、といいますのも。焼きそばを焼く鉄板はすごく熱くなるので、普段から仕事で焼きそばを焼く本職の人でも3,4時間ぐらいが限界だとか。我々素人に換算しますと、もっと短い時間で限界になるでしょうし、休憩時間も多めに必要なわけです」

巨体に似合わぬ高い声で、同僚は官僚的な勧誘文句を連発する。実際、この同僚はこの手の官僚的な細かい規則主義、手続き主義を極めて得意とする男であり、その才能は公私において遺憾なく発揮されている。今回のこの企画に割り当てられたのもその才能故だろう。この企画を遂行するにあたっては、外部のイベント設営会社、イベント運営会社、ましてや食品を扱うので消防、保健所などとの極めて役所的で煩雑なやり取りをしなければならないだろう。

そういえば、この同僚はドワンゴ社員の労働組合の代表でもあった。以前、ドワンゴとドワンゴ社員の労働組合との労使協定が危うく締結できなくなる危機があった。理由は会社と労働者との待遇の提示と要求の不一致という高尚なものではなく、単にドワンゴ社員がズボラで会社と労使協定を締結する際の労働組合の代表を選ぶ投票に参加しないというだけであった。

雇用者と被雇用者の労働組合との間で労使協定が締結できない場合、何が起こるのかというと、労働基準法の定める範囲外の労働が違法になる。読者の中には、労働基準法の範囲内の労働しか認められないのはとても良いことではないかと考える人もいるだろう。もしそう考えているとしたら、読者は労働基準法を読んだことがないだろうから、今すぐ読むべきである。

労使協定を結ばない労働基準法の定める範囲内の労働というのは、極めて制限が強い。一日の労働時間は最大8時間であり、1週に最大40時間である。残業や休日労働は認められない。緊急時のみ認められるが、事後に行政に残業や休日労働を行った旨を届け出なければならない。これは、夜中や休日にドワンゴの提供するサービスに障害が発生した場合でも、次の営業日の営業時間になるまで修正作業が行えないことを意味する。例えばニコニコ動画でそのような障害対応を行った場合、ユーザーが可及的速やかに離れてしまうだろう。Webサービスにおいては、障害はいつ何時でも即座に対応しなければ死活問題なのだ。また、定時が存在するようになり、全労働者は同じ時間に一斉に出社し、同じ時間帯に一斉に休憩を取り、同じ時間に一斉に退社することになる。

もちろん裁量労働制はなくなる。ドワンゴの特に極端な社員の一日では、早朝に就寝し、昼過ぎに起床して出社し、出社で疲れたので仕事など当然できるわけもなく、まず飯を食いに行き、16時から朝会と称する部署のメンバーが集まっての活動報告を行い、18時頃からそろそろ昼になってきたから本腰を入れて仕事するかなどとうそぶきながらようやく活動を始める。そんな裁量労働制もなくなってしまう。

事態は極めて逼迫しているというのにドワンゴの労働者はどこ吹く風といった時、この同僚は各個撃破の地道な根回しを行って何とか票を集めて従業員代表になり、労使協定を締結させ、ドワンゴの裁量労働制を維持し、ひいてはドワンゴの労働基準法違反を回避させた男である。

かかる経緯で、筆者は超会議2016で焼きそばを焼くことになった。

なお、フタを開けてみると、この同僚の根回しが強力すぎたためか、はた、祭り好きの人間が多かったのか、焼きそばブースへのアサインを希望するドワンゴのエンジニアが応募多数に付きお断りする事態が発生していたらしい。

そもそも元をたどればこの焼きそば企画の発端は、kuzuhaの上記のブログ記事なのだが、この企画を社内で提案した人間は、実は途中で退職しているそうだ。そのため、同僚は退職者の企画を引き継いだ形になる。この規格の経緯を考えるとなんとも形容しがたい何らかの違和感のある不思議な気分になる。

今回の焼きそば企画では、"ドワンゴ 焼きそば"でググった時の検索結果のネガティブな結果を変えようという意図もあるらしい。なんと、物理SEOというわけか。当日はよりシュールなネタとして、特別なスタッフカードを装着することとなった。そのスタッフカードには、顔写真と名前と「私は自らの希望で焼きそば担当になりました。」とそらぞらしく書いてある。

この同僚の苦労はともかく、焼きそばブースにアサインされただけのエンジニアは、前日のリハーサルと当日の本番に労働するだけであった。

リハーサルの日は雨が降っていた。焼きそばブースの現地でのリハーサル開始として指定された時刻は16時であった。これは朝が弱いエンジニアへの配慮である。というのは方便で、実際には、消防と保健所の検査が終わるまで鉄板に火を入れることができず、調理実習ができないためである。筆者は大幅に寝坊をして現地の到着が15時半になったが、ブースには誰もいなかった。しかたがないのでニコニコ頂神社の壁を登っていた。グレードは8級以下に感じた。今回のビレイは派遣されたプロが担当するそうだ。焼きそばもプロが派遣されているという。今回、ボードゲームがないのは残念だ。

16時になったのでフードコートに戻ってみるが、やはり誰もいない。まさかと思って控室に行くと、全員いた。エンジニア達は爪楊枝にN高のシールをはって食べ物に指す旗を作るという地味な単調作業をしていた。エンジニアの人件費を考えると、この旗は相当高いに違いない。しかし不思議だ。プログラマーにとって単調作業は忌避すべきものであるが、我々はたまに単調作業の魅力に惹かれてしまう。これは一体どういうわけだろう。

その後、待てども待てども検査はなかなか始まらず、とうとう前日は調理実習が何もできないまま解散した。筆者はその足で、海浜幕張にあるPEKIPEKIというクライミングジムに行った。去年登れなかった課題がまだ残っており、しかも登ることができた。また、クライミングマシーンのExtream設定をクリアした。一年たって上達を感じる。

さて、当日、ようやく鉄板に火を入れることができるようになったので、焼きそばのプロの実演を見た。出来上がったカレー焼きそばを食べたが・・・とても粉っぽくて食べられたものではない。どうやらレシピに記載されたカレー粉の分量が多すぎるようだ。調整してまともな味にした。

今回の焼きそばには、ドワンゴのニコニコ動画チームのK1の設計したカレー焼きそば、ニコニコ静画チームのまさらっきが設計したイカスミ焼きそば、ニコニコ生放送チームのK2が設計したピザ焼きそばの3種類の焼きそばが用意されている。カレー焼きそばには、カレー粉が入っている。イカスミ焼きそばにはイカスミが入っている。ピザ焼きそばは肉の代わりにシーフードミックスで、トマトピューレを入れた上で、上からパルメザンチーズをかける。

今回、焼きそばブースにアサインされたレシピの設計者はまさらっきだけだ。試食の結果、イカスミ焼きそばが一番美味しかった。まさらっきはグルメをわかっているものと見える。問題は、唇と歯が黒くなってしまうバグが発覚したことだ。

ピザ焼きそばは、極めて粘着質で、パック詰めが難しいという運用上の問題が発覚した。

今回は、オープンソース焼きそばということで、レシピがGitHubで公開されている。ライセンスは煮るなり焼くなり好きにしろライセンスだそうだ。

dwango/yakisoba-sauce: Open source recipe of yakisoba-sauces for chokaigi 2016

とはいえ、物理的存在に自由不自由の区別は存在しないのだが。

売上としては、カレー焼きそばが最も多く売れ、イカスミ焼きそばが最も売れないという結果になった。

価格は800円だそうだ。焼きそばにしてはやたらと高い。イベント価格とは言えあまりの高い値段に罪悪感がある。とはいえ、後述する焼きそばを焼く労働の辛さを考えると、妥当ではないかと思えるようになってしまった。

さて、肝心の焼きそばを焼く労働の苛酷さについて述べる前に、もうひとつ書いておくことがある。エンジニアとしての演出だ。

せっかくだから鉄板の温度を計測して表示してはどうか、また、焼きそばのそれぞれの売上もカウントして表示してはどうかと、アサインされたエンジニアの一人が主張し、実際にそのための装置を作った。その実装が笑えるほど面白かったので紹介する。

まず、鉄板の温度の計測方法であるが、接触するセンサーは衛生上問題があるので使えない。赤外線のセンサーを用いることにした。そのため、中国製の赤外線センサーを買った。さて、赤外線センサーを分解して、中身だけ取り出し、温度情報を取得すればいい。ドワンゴの電子工作部の部員に依頼したが、温度情報を取り出す方法がわからない。唯一測定できる信号線は、液晶ディスプレイにつながっているもので、0.1mm以下の線が何本もあり、これを手作業でハンダ付けして一本一本取り出すのは極めて困難なのでやりたくないとのことであった。したがって、計測装置は極めて笑える富豪的な実装になった。

すなわち、温度を表示する液晶ディスプレイをカメラで撮影し、画像認識して温度を得るというものである。このためにカメラとRaspberry Piが用いられた。

しかし、残念ながら、当日の表示に温度表示がつくことはなかった。理由はわからないが、鉄板の温度が60度ぐらいに表示されてしまうのだ。表面に塗った油が煙を出すような状態でその温度は明らかにおかしい。この赤外線温度計は確か500度まで対応していたはずだがなぜだろうか。あるエンジニアは、鉄板の温度が高すぎてオーバーフローしたのではないかという説を出した。温度が9bitで管理されていた場合、512度以上になるとオーバーフローする。しかし、9bitなどという中途半端なビット数で管理するだろうか。「いや、ビット数を増やすと信号線が増えて回路も増えて手間もコストもかかる。組み込みならよくあること」と言っていた。

しかし、冷静に考えると鉄が600度になると赤黒く発光するはずであり、そんなに高温になるだろうか。

「もう乱数でも表示しておけばいいんじゃないか。どうせ気づかないぜ」などという冗談まで飛び出した。

さて、焼きそばの種類ごとの売上をカウントするボタンはうまく機能した。ボタンは、100円ショップで売っていそうな透明なタッパーを容器として、ボタンを3つ取り付けてある。容器の中には基板が入っていた。

「それはArduinoかな」
「ラズパイですよ」
「ラズパイ? たかがボタン3つの制御のために?」
「何言ってるんですか。富豪的プログラミングって言葉知ってます?」
「たかがボタン3つの制御のために一昔前のスマフォに組み込まれていたARM CPUと100MB以上のメモリが必要なのか?」
「今はIoTの時代ですよ。ボタンもsshdぐらいお話できないと不便ですよ」
「ボタンの制御にH.264をデコードできるGPUを詰んだMinecraftもインストールされているコンピューターが必要なのか?」
「それは・・・うーむ」

3つボタンの容器は2つあったので、このシステムにはRaspberry Piが3つも使用されていることになる。なお、実際にはログの集計に使うソフトウェアにメモリが16GB以上必要でMacBookまで持ち出すはめになった。富豪的プログラミングにもほどがある。

さて、そろそろ肝心の焼きそばを焼く労働について述べねばなるまい。当日のフードコート奥には、3枚の鉄板が設置された。一枚の鉄板で一度に40人前(パック詰めのときには、目分量でかなり多めに詰めたので、実際にはもっと少ないだろうが)の焼きそばを焼くことができる。カレー焼きそばの材料は、豚こま切れ肉1.5kg、キャベツ1.5kg、カレー粉適量、もやし2kg、麺4kgである。

このスケールでは、焼きそばの調理は重労働である。まず鉄板が熱い。読者は何をいまさらと思われるかもしれないが、やはり鉄板は熱い。焼きそばをかき混ぜるには、ヘラを動かすために鉄板の上に手をかざさなければならず、極めてあつい。そして材料は重い。まさか焼きそばの麺があれほど重たいものだとは思わなかった。

そして、焼きそばは休みなしにひっきりなしに焼かねばならなかった。というのも、作ったそばから売れて在庫がなくなっていくからだ。会場には焼きそばの保温器が設営されていたが、果たして必要だったのだろうか。

フードコートのボトルネックは注文を聞いて現金をやり取りする部分で、そのためにスループットが上がらず行列ができてしまうのだが、たとえそのボトルネックが解消されたところで、焼きそばの生産速度はすでに追いつくのも難しいほど限界であった。

また、パック詰めも焼きそばの調理ほど肉体疲労はないが、地味に手間のかかる面倒な作業であった。トングで焼きそばを掴んで、パックにいれ、輪ゴムをかけなければならないのだ。カレー焼きそばとイカスミ焼きそばは普通の焼きそばなのだが、ピザ焼きそばはトマトピューレを入れるため、やたらと粘着質な出来上がりになってしまい、トングで掴んでパックに移す作業が極めて面倒であった。

興味深いのは、フードコートの売れ行きである。行列ができていると呼び込まずともどんどん人が来るのだが、行列ができていないとまるで人が来ない。これは一体どういう群集心理が働いているのだろうか。先の単調作業への魅力といい、なんだかやたらと心理学への興味が深まる。

こうして、過酷な2日間に渡る焼きそばブースでの業務が終わった。始まる前は、「ところで、ちゃんと焼きそばは食べられるんでしょうね? 目の前で焼いているのに食べられないとか拷問ですよ」などと言っていたエンジニアは、あまり焼きそばを食べていた気配がない。

超会議のフードコートで焼きそばを売って実感したこととしては、希望せずに強制的にフードコートに配属されたら、少なくとも転職を考えるぐらい疲労するということだ。

だいぶ披露したとはいえ、ボルダリングは別腹だ。超会議2日目の後は海浜幕張のクライミングジム、PEKIPKEIには行った。前日リハーサルで落とせなかった課題が落とせたので満足して帰った。来年もまたこよう。

写真

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0