tech
ハッカーの遺言状──竹内郁雄の徒然苔
第10回:料理とプログラミング
元祖ハッカー、竹内郁雄先生による書き下ろし連載(毎月下旬に掲載)の第10回。今回のお題は「料理とプログラミング」。
ハッカーは、今際の際(いまわのきわ)に何を思うのか──。ハッカーが、ハッカー人生を振り返って思うことは、これからハッカーに少しでも近づこうとする人にとって、貴重な「道しるべ」になるはずです(これまでの連載一覧)。
文:竹内 郁雄
カバー写真:
Goto Aki
今年の6月、札幌で開かれた「オープンソースカンファレンス 2014 Hokkaido」で、ひょんなことから「ハッカーの遺言状ライブ」と題するトークをすることになった。仕掛け人は北海道のIT業界を仕切っている(?)クッピーこと、三谷久美さんである。「梅雨のない札幌でビール飲みませんか?」という殺し文句は、すべての負要因を排除してしまった。
行ってみると、ずっと雨だったし、2日にわたって2回のトークがプログラムされているなど、この殺し文句のおかげで死ぬことになった。というわけで、「遺言状ライブ」の環境は期せずして整った。今回はそのライブトークの一部を文章化しよう。やはり、遺言状は公正証書(?)にしなければ……。
私が電通大で学部3年生に対する「プログラミング言語論」なる講義を行ったとき、最初に出したクイズが「アルゴリズムとプログラムとソフトウェアの違いを述べなさい」である。このうち「プログラムとソフトウェアの違い」には多様な答えがあり、なかなか面白かった。読者諸兄もちょっと考えていただければと思う。
次に出したクイズが「コンピュータをなにも知らない、諸君のオバアちゃんにプログラムが何であるかを説明したい。どう説明する?」である。コンピュータが世に出る前、プログラムは式次第とか、映画や音楽会の演目といった意味だった。もっと根源的には、「pro」(予め)+「gram」(書く)という成り立ちなので、将来のイベントやパフォーマンスの順序だった企画という意味である。早期退職プログラムという、「計画」のような使われ方はここからくる。だが、このあたりの説明から始めたら、オバアちゃんはさっさとあっち向いて寝てしまう。
答えは表題が示唆している。プログラムは料理のレシピと酷似しているのである。こうずばり言ってしまえば、オバアちゃんは「フーン、その程度のものか」と安心して寝てくれよう。どっちみち寝てしまうのが残念だが……。
たしかにレシピは手順書だ。ほかにも手順書の類は数多あるが、レシピほど一般家庭に身近かなものはなかろう。かつ、プログラムとのアナロジーが思ったより深い。
1990年代半ばに平凡社から刊行された電子百科辞典「マイペディア」の項目「コンピュータ」について書いてほしいと頼まれたことがある。その中のプログラムのところで、以下のような説明をした。
プログラム(計算の手順、あるいは命令の系列)は、レシピ(料理の手順)とよく似ている。たとえば、次のような単純な、ちょっと間抜けなレシピを考えよう。
[1] ジャガイモの皮を剥く
[2] 鍋にお湯を沸かす
[3] ジャガイモを鍋に入れる
[4] 串でジャガイモを刺してみる
[5] まだ硬かったら[4]に戻る
[6] 鍋からジャガイモを出す
通常の手続き型言語がもつ、逐次処理、条件判定と分岐、繰り返しがこんな他愛もないレシピにちゃんと含まれている。上の例には明確な条件分岐はないが、たとえば、「白菜がなければ、キャペツで代用する」といったものがこれに相当する。
逐次処理、条件分岐、繰り返しどころか、下手な言語にはない並列処理がレシピにはある。たとえば、ジャガイモを茹でながら、別の小鍋で(茹で時間の異なる)絹さやを茹でる、なんて平気で書いてある。
[k1] 絹さやの筋を取って冷やす
[k2] 小鍋にお湯を沸かす
[k3] 絹さやを鍋に入れる
[k4] 再び沸騰したらすぐに上げる
しかも、[1]と[2]、[k1]と[k2]もそれぞれ並列実行できる(ただし、[1]と[k1]の並列処理は難しい)、というか、手際のいい料理人だったらそうする。
料理をすれば、自然にプログラミングの腕が上達するというのは、そう間違いではない。手順の最適化をいつでも考えないといけないからだ。男は料理をするものじゃないと豪語するよりは、ついでに料理もしたほうがいい。逆に、女性は料理が得意でありながら、どうしてあまりプログラミングしないのだろうと、つい思ってしまう。
では、少し私の料理に関する自慢話をしよう。20年ほど前、私がNTTの基礎研究所にいたころ、武蔵野拠点から厚木拠点にまるごと移動になった。自宅から通勤するにはさすがに遠いので多くの人が拠点からクルマで10分程度のところにある単身寮に入った。私は結局3年間、週日はそこにいたのだが、飲み会以外で外食したのは1回のみ。つまり、ほぼ完全に自炊だった。外食しなかったのは、ビールが主食である私はクルマで行くような場所に行けなかったからである。厚木の3年間、昼サッカーをしたあとの昼食は自分で1分15秒茹でるソーメンか、かき氷であった。
単身寮の部屋は25平米程度で、小さなキッチンには小型の電磁ヒーターが1口しかない。これでは並列プログラミングというか並列処理ができない。そこで、ワゴンとカセットガスコンロを1個追加して、デュアルCPUにした。帰り道に寄れるスーパーで買物をして、主食のビールのほかに大体(お手軽も含めて)3品を作った。なにしろ小さなキッチンなので作業スペース、つまりコンピュータにおけるメモリスペースが足りない。こういう環境では究極の並列処理が必要になる。なにが究極かというと、料理作成、食事、洗い・片付けを細粒度で並列に処理するからだ。つまり、作りながら食べ、その合間に片付けも行う。多くの場合、食べ終わったときにはみんな終わっているのだ。このことから容易に導かれる系は、すべてを飲みながら行ったということ。要するに高並列キッチンドリンカーなのである。このうえ、アルコールもチャンポン並列だと、超並列になるのだろうが、私はビールオンリーである。
ところで、レシピがプログラムなら、料理はプログラムの実行だ。だからプログラミングに例えるのは変だ。しかし、世の中には「Programming by Example」という概念がある。この流儀だったら、料理をプログラミングと言ってもいいだろう。私は巷の仕様書(レシピというかプログラム)をほとんど見ない。見たとしても料理とは関係ないときで、どちらかというと料理の基本、あるいは「料理の心やツボ」を読み取るためである。なので、実際の料理は常に味見しながらの手探りである。つまり、アジャイルプログラミングなのだ。こうして、半完成プログラムが経験としてどんどん記憶に刻まれていく。
私は自宅でもときどき料理を作る。上品な和食は無理だが、タンシチューやカレーなどは随分手間隙かける。つまり、忍耐強いプログラミングをする。タンシチューは圧力鍋を用いても3日がかりである。何度トライしても2日だと美味しくならない経験則がある。タマネギやニンジンの中の糖分がカラメルになるまでコトコト煮ることが必須のようだ。これだけの手数をかけて煮込むから、不断のコードレビューというか、不断のテスト工程が不可欠である。なにしろ焦がしたら一巻の終わり。なお、私はカレーにもシチューにも一切小麦粉を使わない。フードプロセッサで砕いた野菜がドロドロになるのをもってよしとする。
2011年から3年間、毎年4カ月程度エジプトに滞在したときも、会合以外の外食は1回もしなかった。事前に、エジプトの味付けや調理法が口に合わなさそうという情報を得たので、エジプトにおける「プログラミング」のために周到な準備をしたのである。調味料は醤油、白だし、本だし、中華味、酒、みりん、酢、味噌、胡麻油、おかか、七味、一味、わさび、ラード、……。乾燥データとして、干し椎茸、大豆(with 豆腐製造キット)、高野豆腐、うどん、わかめ、きくらげ、片栗粉、こんにゃくの粉、……、ツールは包丁、皮むき、固めるテンプル、菜箸、冷凍食品鋸、……、ライブラリとして、即席ラーメン、炊き込みご飯の素、……。「エジプトに何しに行く?」と疑われる荷物である。
酢はどこにでもあると思うかもだが、エジプトで買うと酢酸かと思うような刺激がある。ラードは豚の香りが欲しいときに使う(エジプトでは豚肉の入手はほぼ不可能)。高野豆腐はお湯で戻して揚げると油揚げもどきになる。和風煮物にコンニャクは必須。自分で作って初めて知ったのだが、50グラムの粉から1.6L程度のコンニャクが製造できる! これはたしかにダイエットになる。炊き込みご飯は自分でゼロから作ったほうが美味しいことが分かったので、ライブラリとして持参したものは人にプレゼントすることになった。
エジプトの牛肉は固い。野菜も、一説にはシリカ成分が多いので、日本のものより少し固い。なので、圧力鍋は必須なのだが、こんなものまで持参するわけにいかない。大きなスーパーに行って見つけたのが、Te-Falの8L。これより小さいのがない(日本の家庭用は4.5Lが標準)。でも、いろんな人にご馳走することが多かったので、これは正解だった。だが、「Te-Fal」が変。通常これは「TeFal」だ。安かったので、パチモンかと思ったが、一応フランス本社の技術でエジプト国内生産らしい。なぜ、ハイフンが入るのかは、いまでも謎(※1)。
借りたアパートのキッチンは6畳程度だろうか。5口のガスレンジがデンと構えている(写真1)。
5並列が一応可能だが、能力がヘテロ構成で、かつ過密だったので実際には3並列が最大だった。食事をするのがリビングで、30畳弱はある(写真2)。レンジから食卓までは約20メートル歩く必要がある。いい運動だった。
せっかく圧力鍋を買ったのだから、日本では高嶺の花となったタンシチューを作りたい。エジプトでは肉が約1桁安いのだ。ところが、どこに行ってもタンが売ってない。近所の、天井から牛の肉塊がぶら下がっているような肉屋に行って、ベロを指差しながら英語で聞くのだが、タンはないという。E-JUSTの現地女性職員に聞くとまったくないわけではないらしい。馴染になった近所のMetroというスーパーの店長に話をしたら、トングなら入手可能だという。タンでもトングでもいいから頼む、今度の週末までに入るかと聞くと「ボクラ」という返事。これは明日という意味らしいが、インシャラー(神の思召のままに)の世界なので、「そのうち」と解釈したほうがいいらしい。行くと「まだ入っていない」という。データが揃わなければプログラミングできない。
それから、私と私のタンシチューに期待する某先生と2人がかりで、トングはいつ入るのだと攻めまくったためか、ある日、スーパーに入ると我々と店長のやり取りを知っていた店員たちがみんな、「やったね!」という表情でVサインの会釈。とうとう入手できたのであった。
こんな話を講義の合間の雑談で学生たちにしていたら、学生のI君が、タンならタイミングがよければ簡単に手に入るという。どうも家が大きな農家らしい。半信半疑だったのだが、ある日「冷凍が届いた」とのこと。それにしても、日本では高級品のタンが、店では手に入らず、こんなふうに手に入るというのが不思議だ。あとで分かったのだが、エジプト人は(少なくとも大学の教員、学生は)タンを食べないらしい。
届いたタンの袋を見てまたびっくり。2本と聞いていたが、異様に大きく重い。一体何本のタンが入っているのだろう? その正体を写真3に示す。
なんとタンに続くもろもろの部分が繋がったままではないか。圧巻は目にも鮮やかな、多分モー音発生器(声帯)である。このように余計なものがついているデータの処理もプログラミング技法の重要な課題だ。さっさと切り取って捨ててもよかったのだが、エジプトのゴミ収集事情を考えると生のままでは捨てにくい。結局、大容量の圧力鍋で加熱してから捨てた。
話が本来のプログラミングから脱線してしまった。料理に限らず、食事には、ダイクストラの「食事する哲学者」問題にも見られるように、コンピュータ科学を連想させるものが多い。たとえば、英国人の間で論争が絶えないという、紅茶にミルクを先に入れるか後に入れるかという順序問題とか、寿司に直接醤油を垂らすのか醤油皿を使うかという「アルゴリズム」の問題とか……。これはちょっと強引すぎる連想だったかな? でも、同期や排他制御にはかなり直接的な関連がある。
私の息子は学生時代にファミレスの厨房でアルバイトをしていた。OSの研究室にいたためか、厨房の限られたリソース(電子レンジやガスレンジなど)を活用して、お客さんの多様な注文に応え、かつ同じテーブルにはほぼ同時に注文品が届くようにするために、デッドライン制御を含むスケジューリングの方法論が役に立ったそうだ。それはいいが、うまく行きすぎて、どんどん仕事を入れられ、学業に差し支えるようになり、結局辞めざるを得なくなってしまったとのこと。過ぎたるは及ばざるがごとし。
ほかにも、釜飯やひつまぶしに付いてくる小さな茶碗はキャッシュだし、私のようなビール飲みのスループットを上げるには、店員の作業効率や負荷をちゃんと計測したパイプライン処理が重要な技術になる。つまり、ちょうどジョッキが空きそうなときに次のジョッキが届くように注文するのだ。安直にダブルバッファリングするのは、ビールがぬるくなる可能性があるし(私の処理能力だと、その心配はあまりないが……)、テーブルリソース、つまり狭いテーブルトップの無駄使いだ。
料理ではリバースエンジニアリングも重要な技術だ。つまり、どこかで美味しいものを食べたときに、どう料理したらそれを再現できるかを推定する技術である。易しいものと難しいものがあるが、精進料理の素材だけで作られた各種の肉(もどき)料理は難しかった。私はどぜうの柳川ではなくて、丸鍋が好きである。これのリバースエンジニアリングは割と成功したほうだと思っていたが、あるとき有名な駒形どぜうのWebページにレシピが出ているのを発見し、目からウロコが落ちた。重要な処理とコツを見落としていたのだ。やはり、リバースエンジニアリングは奥が深い。ちなみに作っているところを見て探るのは、リバースエンジニアリングではなくて、産業スパイだ。
さて、札幌のオープンソースカンファレンスでは、エジプトでの料理の四方山話をしたのだが、エジプトで入手できたものの中ではサルサソースが美味しかったことを紹介した。ただし、輸入品だった。そして、ソースは美味しかったけれど、蓋をきちんと閉めておかないと冷蔵庫でも割りと早く腐る、つまりオープンソースは腐りやすいという駄洒落を披露した。
実はこの駄洒落には落ちがある。畏友の玉井哲雄さん(東大名誉教授、現法政大学教授)が2001年に「bit」誌(Vol.33、No.1)、2010年に東大出版会の月刊誌「UP」(No.457)に、「ソフトウェア」の語源について書いている。今日的な意味での「software」の初出は、米国の統計学者John W. Tukeyが1958年1月に「American Mathematical Monthly」に書いたものとのこと。もちろん、昔からある「hardware」(金物)に対比した造語である。
その後、さらに玉井さんが調べたところ、1850年のCharles Dickensの小説に、「soft-ware」というハイフン入りの言葉が出てくる。これは、街でゴミの山から金目のものを収集し、それを売って生活を立てている人々を題材とした小説とのこと。それによれば、「ごみ収集の区分としてはさらに、ソフトウェア(soft-ware)とハードウェア(hard-ware)と呼ばれるものが重要だ。前者はあらゆる野菜と動物類、要するに腐るものすべて、を指す」(※2)。
いやあ、「ソフトウェアは腐るもの」とは言い得て妙。いまから160年以上前に、ソフトウェアの本質を見抜いていたディケンズに敬意を表さずにはいられない。(つづく)
※1:つい最近、スーパーで「T-Fal」というのを見た。この会社のアイデンティティ戦略はなんとも不思議。
※2:このあたりの詳細は、玉井さんのWebページを参照されたい。
「ソフトとソフトウェア」
「ソフトウェアの語源」
本連載は、毎月下旬に掲載していく予定です。竹内先生への質問や相談を広く受け付けますので、編集部、または担当編集の風穴まで、お気軽にお寄せください。(編集部)
SNSシェア