サッカーのワールドカップは意外と盛り上がったのだが、 期待されていた経済効果の実態はどうだったのか。 噂によれば、 日本チームの試合がある日には宅配ピザの売上が倍になったらしい。 確かに経済効果はあったみたいだが、 その結果が負担増というのでは何か訳が分からない話になってしまう。

※ そもそも経済効果というのは、 金がこっちからあっちに動くという話であって、 基本的に「儲かる」ということとはあまり関係ない。

§

今回のワールドカップで一躍スターになったのはバイロム社である。 チケットの売れ残り問題や、ホテルの大量キャンセル問題で連日盛り上がった。 日本でどの程度の部屋がキャンセルされたのか分からないのだが、 韓国の場合、トータルで57万室という報道があったので、 似たり寄ったりではないかと思う。

成程、それだけの部屋がキャンセルになったら経済効果は凄いものがありそうだ。 ホテルも困ったようで、 最後は損害賠償の訴訟も検討しているという話まで出てきたようだが、 これは納得できない話である。 ワールドカップという世界規模の大会のホストをする国は、 国際社会の一員として、 他国に模範を示すことができるレベルであって欲しいのだが、残念なことだ。

キャンセルが大量発生したのにキャンセル料は全く貰えなかったというのだが、 これは当たり前の話である。 ドタキャンで規定のキャンセル代金も払わなかったのなら、 損害賠償しろというのは分かる。 しかし、 定められた期間内にキャンセルした場合には、 ペナルティを払う必要はない。 ホテルや旅行代理店は、 何日以降にキャンセルしたら料金が発生する、 という契約に事前合意しているのである。 そして、実際、キャンセルはその期間内に行われた。 だから1ウォンも1円も払う必要はない。

もちろん、何十万室もキャンセルされたら困るというのは当たり前だし、 何十万室もキャンセルされるという事態は想定していなかったと主張する人もいるかもしれない。 しかし、考えてみると、何十万室も予約が入るということ自体、 特別な状況下にあるのだ。 だったら最初から、 通常の期限より前にキャンセルされても料金が発生するような契約にしておけばいいのだ。 あるいは、大量キャンセルが発生した場合に備えて保険に入るという手もある。 リスクマネージメントの方法はいくらでもあるのだ。 それなのに、契約条件を無視して、 単に見通しが甘くて損害が出たので金を払えというのは、 発想があまりにもルール無視・非社会的すぎる。 もちろん、裁判にしても勝てる訳がないだろうから、 裁判にならないような気はするが。

§

ただ、バイロム社のやり方に納得できるかというと、そうでもない。 一番分からないのは、チケット売れ残り問題だ。 同社はチケットを全部売ったと主張したのだが、 ホテルが何十万室もキャンセルされたら、 チケットも何十万枚も売れ残ったと考えるのが普通である。 しかし、バイロム社は1か月も前に何十万室も部屋をキャンセルしつつ、 チケットは全部売ったと主張した。 しかも、 その完売したはずのチケットが後からインターネットで追加販売されるという謎もあるのだが、 それはさておき、 バイロム社は、チケットが完売したと考えたのなら、 そのチケットを買った人達はホテルに宿泊しないでどうするつもりだと思ったのだろう?

インターネットの販売にしても、 何時間もアクセスしたのに繋がらなかったという噂を聞いている。 TVの報道では、バイロム社の社員は最新のシステムを導入したとか言っていたと思ったが、 あれで最新というのも不思議なら、 アクセスが殺到した後に「サーバを増強した」と発表するというのも謎。 アクセスが殺到したら何時間も待たせるという技術は、 既にソニーがPlayStation2をインターネットで予約する時に完成させているので、 最新でも何でもないのだ。

※ 実際にネットで買ったのだが、 1ページを表示するのに10分待たされたあげく「混雑しています」みたいな、 そういう状況だった。

プログラマーズフォーラムでも、 見積もりは想定される最悪の状況を考えて、開発期間はさらに倍、 というのがクイズダービー(古?)じゃないけど標準的な手法のようだ。 なぜだかその倍という見積もりでも足りないというのが世界の謎なのだが、 そもそも、想定した通りに動いてくれるのならバグなんて出ないのである。

※ クイズダービー: TVのクイズ番組。 大橋巨泉司会。 「はらたいらに千点」という有名な言葉を残した。

§

個人裏ページにちょっと話題を出したのだが、 C言語のQ&Aページには今もたまに質問が来るので、 もうちょっと保守が楽なようにDB化を進めようとしているところである。 個人サイトであろうがなかろうが、 Webサイトの公開で一番大変なのは、 コンテンツをいかにして少ない手間で管理・更新するかという所に尽きるだろう。 多分。

質問で面白かったのが、 チューリングマシンのシミュレーションプログラムを作りたいというもので、 一応の回答はその「裏ページ」にも書いたのだが、 要するにこの主の問題の本質は、どのようにモデリングするか、ということだろう。 「モデリングする」という日本語が正しいかどうか知らないが、 要するにイメージしている処理とコードの中間にあたる何か、をイメージするのである。

チューリングマシンって何なのか知らない人の方が多いかもしれない。 要するに、チューリングという伝説の人が考えた仮想的なコンピュータだ。 実用とかいう話ではなく、計算機科学とか、論理的な話に出てくるので、 見たこともないという人も心配ない。私も見たことはない。

※ 昔は情報科学の授業で必ず出てきたのだが、 最近もそういう話は必須なのだろうか? もちろん、停止問題というのは理論としては重要なことなのだが。

細かい所を除いて紹介しておくと、 このマシンはテープとヘッドという2つの部品からなる。 テープの上の情報に対して、ヘッドは読み書きを行うことができる。 また、ヘッドはテープ上の位置を、 先に1つ進めたり、後に1つ戻ったりすることができる。 もちろんマジで作るとしたら、ヘッドを動かすメカはどうするんだという話になってしまうが、 そこは論理的思考のためということで、深く考えても意味はない。 要するに、それだけの機能があれば一体何が出来るのか、というのが論理的命題。 蛇足しておくと、 チューリングマシンで有名なのは停止問題というもので、 これが面白いという人は学者に向いているかもしれない。 停止問題はともかくとして、実際に何かするようなコードを書いてみようというのがプログラマー向けか?

シミュレーションするというのだから、 ヘッダの位置とかテープの状態を記憶する変数を用意して、 ステップ単位で状態を表示するようなプログラムを書けばいいわけだが、 最初、こんなメインループを書いていた。

---- List 1 ----

    while (1) {
        PrintCurrentStatus();
        NextStatus();
    }

---- List 1 end ----

現在の状態を表示して、次の状態に進む、という処理を繰り返せばいいだろう、 という発想。 間違いではないと思う。 ただ、これは結構杜撰な思考の産物である。 というか、何も考えてない。 チューリングマシンの停止問題とかいう前に、 こんなプログラムだと停電するまで止まらないような気がするが、 冗談はともかく、 この簡単な処理が最終的に List 2 のようなプログラムになった。

---- List 2 ----

    while (1) {
        MoveHead();
        PrintCurrentStatus();
        UpdateStatus();
    }

---- List 2 end ----

NextStatus というのは名前から動作がイメージしにくいと思って UpdateStatus に変更したのだが、これはまあ細かい話。 名前を変えてもまだ分からない。 実は UpdateStatus はヘッドに対応する「テープの状態」を変更するというもので、 MoveHead() は、その名の通り、ヘッドを動かすという処理を行うのだ。 だったら UpdateTapeStatus とでもすればよさそうだが、 そりゃそうだ。 これまた余談なのですが、最近アンダースコアをあまり名前に使わなくなった。 全然使わないわけではなくて、秘技として取ってある。 アンダースコアか大文字か、 というこだわりよりも名前そのものにこだわった方が生産的なのだが、 まあそれはそうとして、 今回は、出題者の要件がちょっとイレギュラーだったので、 List 2 のような順序になっているが、 もちろん、Print→Move→Updateという順序でも構わないというか、 その方が自然かもしれない。

で、ポイントは MoveHead() という処理を UpdateStatus() の中ではなく、 このレベルに引き上げたという所なのである。 反対意見もありそうだし、些細じゃないか、という人もいるかもしれないが、 この仮想機械の処理が 「ヘッドを動かす」「状態を表示する」「(ヘッドの位置以外の)状態を更新する」 の独立した3つの処理であることを表現したということは 大きなポイントだと思う。

§

ワールドカップのチケット混乱事件の原因の一つは、 チケットがまずまとめて一社に販売され、 そこからさらに代理店に回されたというネスト構造にあった。 販売を委託した一社が代理店の販売状況を把握しないで、 代理店に完売したというだけで全部売れたことにしてしまったというのが、 何十倍というチケット購入倍率にも関わらず何万席という空席が出てしまった原因である。 もっとも、FIFAやJAWOCも甘い。 入場時に本人確認する位のやる気があるなら、 Webに代理店用の購入者登録サイトを用意して、 事前にどの席を誰が買ったのかというリストを作る位はできただろう。

下位の処理をブラックボックス化するリスクは、 「下位のレベルで何をやっているか分からなくなる」ということではない。 「必要な場合に下位のレベルで何をやっているか知るための処理が必要になる」 ということなのだ。 その必要な処理を怠ると、 問題が構造的欠陥に発展する。 かといって、それが構造の欠陥なのか、構造以外の対策不足なのか、 という見極めは難しい。 状況が知りたいからといって、 何でもかんでも上位に処理を引き上げると、 それはそれで訳が分からなくなるものだ。

※ 言い換えるなら、 下位の処理に、 必要な情報を取り出すための処理を追加しなければならない、 ということだ。

もっとも、終わってみれば、 「いい事例を作った」ということでは 今回のような騒ぎも評価していいのかもしれない。 それが「チケットを当日売りにするのが一番安全な方法だった」、 というようなオチになってしまっても、 結局、何もしないで出した結論よりは価値があるはずだ。