言い伝え「水引いたら高台に逃げよ」の有効性

年始早々、インドネシア・スマトラ島沖地震のニュースに対照的な2つの記録を見ることができた。

記事「インド洋大津波　生死分けた逃げ道選び　スリランカ・ヤラ国立公園」(Yahoo! News[産経新聞])によると、現場からの逃げ道はジャングルをかき分けた先の岩山と、川沿いの道だけだった。「高い所か、逃げやすさか - 瞬時の判断が生死を分けた」という。

「津波は濁流となって川沿いにジャングルを駆け上ったからだ。海岸から約三百メートルの岩山から見ると、車が浮き、低くなっている川に沿って津波がジャングルの奥深く流れ込んだ」 と同記事。狭くなっていく水路では水流の速度は増すはずだから、それでなくとも途方もない津波から逃れることなどかなうわけもなかった。 逃げやすいところには水も入りやすい。実に皮肉な結果だ。

対照的に、驚異の目で報じられている地域がある。時事通信社の報道によると、震源からわずか60キロのシムル島(Simeulue)では、住民約65,000人のうち津波による死者は、3日までになんと6人にとどまっている。他の地域の犠牲者数からしても驚異的な生存率だ。

なんでも、同島には「海水が引いたら高台に逃げろ」という教訓が伝統的な教えとして住民の間に語り継がれていたそうだ。 この教訓には「スモン」という名前がついている。「海水が引いたら次には必ず大きな波が来る、という教えが昔からある。･･･ 住民らはこの言い伝えに従い、水が引いた時、すぐに丘へ避難したという。」

大変驚いた。相当な人数がかなり早いアクションで行動できたことになる。
しかも水が引いたときに、疑わず、一斉に。

Wikipedia英語版の「2004 Indian Ocean earthquake」 のページからリンクされているニュースソースによれば、後の世代に教訓を残した、シムル島(Simeulue)を襲った1907年の津波は数千人の死者を出したようだ。それだけに、その教訓へのリスペクトは十分あったかもしれない。それでも、1907年の津波を経験した人なんてほとんどいないだろう。それで突然やってきた類例のない津波にそこまで機敏に対応できるだろうか。事実、島民は適確な行動の対価として命を得たのだ。

各新聞の社説、論説は、およそ「警告・警報の流布」か、「国際的救援」をうたうものばかりだ。本当に論じなければならないのは危険を感じた、あるいは警告を受けた時の人間の行動のあり方ではないだろうか。

教訓：
Speed means secure.
逃げやすいところは攻められやすい。

時系列の節目？

年末に近づくとところどころにアップされる「総括」は読んでいて楽しいですね。私も、いいのが書けるといいんですが、ちょっと書くスイッチが入らないです。 blogで随時時系列の記録を残しているからかな。何か残せたか、何をやりかけか、などを考えたりはしますけど、ここでまとめる気がしない。なぜかしら。

今、なにげなく年末に感じることは、年の区切りがあまり大きな変化に思えなくなってきていることですかね。年賀状は書かないし、帰省もしないのでその分のタスクもありません。

年末だろうが平生だろうが時間軸はシームレスなものですから、それをこつこつ過ごすのが気持ちよく感じてきたんだと思います。てことで、私は年末年始とくにいつもと変わりなく、ちょっと長めの連休、くらいのノリです。 それくらいが心地良いんです。

1985年くらいからの、なにがしかの成果物が世に残っていますが、振り返れば5年ごとに大きく流れに変化があります。 2000年代前半5年は、そこそこスリリングで楽しかったですよ。成行に任せるのは好きではないほうなので、後半の5年もまた、振り返れば大きな変化を感じられればいいなと思います。

2005年以降も、いろいろ一緒にやっていきましょう。よろしくお願いします。

足の裏の米粒。

「IT関連の人材」が何かをあえて定義しないにしても、そう呼べる人材が不足しているという感覚は多くの人が持っているようだ。「デキル人いないですかね」「凄腕の人ってどうやって育てるんですか」。あるいは「IT人材の育成ってどうしたらいいですかね」「オープンソースソフトウエア書けるプログラマってどうやって育てるんですかね」と。意見を聞いてくださる方がいることはありがたいが、さてどうしたものだろう。


人材教育？

IT人材育成会社、教育機関は、IT業界で働きたいものの経験がない人間を集め、高額な授業料と引き換えに数年授業を受けさせ、「資格」というシールをペタっと張って人材を「作り」、世に送り出してきた。ところがどうだろう。かつての飛ぶ鳥を落とす勢いも、いまや見る影もない。教材も教師もスタッフもすっかり古びてしまい、卒業生の評判と同期して就職率が激減。特別な成果もミラクルも期待できないため、いまや非常にお寒い位置にいる。


需要の問題？

最近、電車の吊り広告のトピックに、SE、プログラマなどの大失業時代を危惧するものが目に付くようになった。「転職してはいけない。今、あなたはたぶんもらいすぎている」と。なかなか良心的なメッセージだ。雇用促進している会社は、外向けには「不足」といいながら内向きでは「飽和」と言っている。この構造をある程度理解しなければならない。

たとえば、収益を上げている会社がM&Aによる事業拡大というわかりやすい方法をとってくると、拡散の時代から収束の時代への遷移は加速する。そこでは組織の再構築が行われ、バッティングするレイヤーが整理される。もちろん、組織が最適化されると事業は拡大するのでハッピーなわけだ。

そこに「大失業時代」があるとすると、「必要不可欠」ではないレイヤーにもっとも大きな影響があることになる。これまではなんとか仕事のあったのだが、専門性があるわけでもなく、特別伸びるわけでもない、教育会社か企業に「作られた」人材。そのような人たちは「整理」を宣告されると、なぜ自分がそんな目に遭わなきゃいけないのか、さっぱりわからない。また、新たな「シール」を求めて行動する。そして自分を「作ってもらえる」ところを求める。（その新しい「シール」は、「社長」だったりする場合もある）


コミュニケーションスキル？

そんな状況の中、「コミュニケーションスキル」という、IT関連の知識とは関係ないことを教える人たちが現れた。「コーチング」「プレゼンテーションスキル」とかそういうものもこの類だ。IT業界にまともに日本語を話せる人が少なすぎるのは事実なのでありがたい部分もあるが、そうかと言って技術者が修練を怠りつつ口八丁、というのは問題だ。これらは中身あってこそ意味があるものなので、中身の詰まった人間を生産する手段ではない。

突っ込まれるとさっぱりわからない言葉を、さもわかったようにあやつるプレゼンテイターって増えているが、名刺をもらうと「シニアSE」とか書いていたりするから失笑モノだ。言葉遊びで煙に巻くとお金が出てくるほど、ユーザ企業は無知ではなくなってきている。


資格？

「スキルを身につける」という言葉に摩り替えて、ぱっと見てわかる差別化、競争力をわかりやすく身に着けることにエスカレートする。わかりやすい解決策としてもたらされたのが「プロフェッショナル資格」。日本にどれくらいあるんだろう、昔から結構資格マニアっているよね。

しかし、他の業界の「資格」は「免許」の意味合いがあることが多いのに対し、IT業界はそうではない。これを競争力確保という観点では何ももたらさない、むしろ消費者の貯金を食いつぶすだけのものになっていることに早いところ気がつかなければならない。

「試験」にいいところがあるとすると、未知の、特定のテーマに関して十分に勉強する際の習熟チェックに使うという部分だろう。資格試験は、勉強意欲の里程標になってくれるかもしれない。TESTはTESTであってそれ以上でもそれ以下でもない。IT資格、Ph.D、MBA、あるいはどんな資格をとることを目標にしていても、それそのものは自分をその道のプロフェッショナルにしてくれるわけではない。

ある賢い人が言ったんだそうだ。
「資格とかけて足の裏の米粒ととく。
　取るまでは気になってしょうがないが、取っても食えない。」

はっきり言えば私はプロフェッショナル人材を「作る」方法を知らない。もちろん、これまで学校や先生と呼べる人たちから学んでこなかったというわけではない。結局彼らから私が得たものを説明するとすれば、学んだ内容というより、「学び方」ではないかと思う。そこでは自分を習熟者、プロフェッショナルとして「作ってもらう」ことは完結しない。

自分が「そうなる」と決めて前進している人同士が、相互になにがしかの刺激を与えあうのが、成長できるプロフェッショナルコミュニティの姿だと思う。

"As iron sharpens iron, so one man sharpens another. "
- Proverbs 27:17

POPFileの決め手になる「ベイズ理論」って何だ？

スパムを判断するためのメカニズムに迫る

POPFileはいったいどのようにしてこれほどの高い精度でメールを正しく分類できるのだろうか？　その秘密はベイジアンフィルターにある。POPFileはこのベイジアンフィルターという数学理論を採用してメールを解析しているのだ。

ベイジアンフィルターの基礎となっているベイズ理論(Bayes Theory)は、古く18世紀の牧師であり数学者であったトーマス・ベイズ(Thomas Bayes)という英国人によって考え出された原理だ。
ベイズは、「物事を判断する確率は、その物事の観察者にとっての不確かさである」と説き、神の存在でさえ数学的に示すことができると述べたそうだ。この考え方で物事を推定することをベイズ推定(Bayes Estimation)という。
簡単に言うと、新たなできごとを予測する際には、すでに起きている事実と、観察者自身の経験を考慮に入れることにより、かなり正確に推測できる、という考え方である。実生活では当たり前っちゃー当たり前だが、数学的にやるとなると簡単そうには見えない。

たとえば、あなたに宅配便で小ぎれいな小包が届いたとしよう。それが何かうれしいプレゼントか、そうでないかを予測することだろう。単純に確率を述べるなら、いちかばちか、50パーセントという確率だというのもあながち悪いとはいえない。でも、どこか実際的ではない。
実際には、その小包の大きさ、重さ、差出人、内容に関する記載事項などという観察に基づく「事実」と、過去の「経験」に基づく確率、つまりプレゼントだと思ったらそうでなかったという確率、あるいは期待通りだった確率を考え合わせるからだ。これを考慮に入れてはじめて、実際の結果にかなり近い予測が可能となる。

この考え方で正しい分類を予測するために、POPFileは最初にいくらかユーザーのトレーニングを受けると、それらのメールから学習する。
つまり、添付ファイルやHTMLのタグやコメントを取り除き、残されたヘッダと本文をコーパス（corpus）と呼ばれる単語群に分解する。 そして、分類されるメールの共通点を知るために、出現頻度の高いものを重み付けし、こうしてメールにおける各単語の出現と各バケツに分類された確率を計算できるようにコーパスデータベースを構築する。

新たなメールを受け取ると、POPFileはそのコーパスデータベースに基づいて、「バケツ」への分類に影響を及ぼす単語を抽出し、その単語の有無や出現回数などから計算して、いずれのバケツに分類するかを決定する。
その作業の過程で、POPFileは未知の単語にも遭遇するわけで、それによってセルフトレーニングを行うため、ユーザが間違いを指摘しない限り、自然に精度の高いコーパスデータベースができあがっていく。 間違った分類をしたことを指摘される（つまり手動で再分類される）と、POPFileはそのデータベースを訂正する。これにより、POPFileは「観察者の判断」を学習し、分類精度を上げることができるのだ。

ためしにPOPFile UIの「履歴」メニューから、spamに認定されたメールの「件名」をクリックしてみて欲しい。すると、メールヘッダと本文のあちこちがバケツと同じ色にされて表示されている。
さらに、ページの下のほうから「単語の頻度を表示」「単語の確率を表示」というリンクをたどると、各メールの分類に大きな影響を及ぼした単語が順に表示されており、大変興味深い。

POPFileのデータベースにスパムで使われる単語が十分蓄積されていくにつれ、業者はスパムらしからぬ単語を使ってメールを送らない限り、その判定をすり抜けることは難しくなっていく一方だ。
しかし、そのようなメールでは、スパム業者の目的を達することはできないだろう。スパムのフィルタリングの技術が向上するにつれ、彼らのビジネス上の目的が立ち行かなくなり、ついにはスパムメールという手段をあきらめてくれるようになればよいのだが。

(この文章はiNTERNET Magazine 2004/3, p.105に掲載された文に若干加筆したものです)

オープンソースの責任の所在？

マイクロソフト社のバルマー氏は、自身の講演においてLinuxについてどう考えているかについて示した際「Linuxのアキレス腱は誰も責任を負わないこと」だと述べています。これについて、いくつかのblogで「じゃあMSはどうなんだよ」との指摘を拝見しました。いずれの主張も、なにがしかの事実や現状を観察して出てきたものでしょう。ただ、残念ながらこの講演を直接聞いていないのですが、わたしがバルマー氏に質問できるのなら、ビジネスとしてどの局面において「責任を負う」ことが欠落していることを指摘したいのか、そこを尋ねたいですね。

「ソフトウエアそのものの責任を負う」？

LinuxカーネルにせよUNIXライクに統合されたものにせよ、複数の人間によるプログラムの複合体であることは言うまでもありません。プログラムが企業によるものであれ、個人によるものであれそのコードに対する責任をプログラマが負っていることは事実です。つまりプログラマが企業ハードウエアに対応するデバイスドライバをIBMやNECのような企業が作ってオープンソースとしてコントリビュートしているケースでも、個人が何かのコードをコントリビュートした場合でも、です。

対価は金銭とは限らないのは言うまでもありませんが、とにかくそれに対しその「責任を果たす」ということを、コードを公開し、著作権者を銘記し、フィードバックを集約していくことなどの方法で果たしています。それを怠ると、そのコードは、他人に引き継がれるか、オルタナティブコードの出現などにより淘汰されていきます。つまり、時の経過と共に、より効果的に責任を負う著作者によるコードへと選択されていきます。

別にオープンソースだから責任を果たしやすく、プロプライエタリだと責任を果たしにくいというハナシではありません。無責任なコードが永久的に許容されつづけないことをどう保証するのかについて、プロプライエタリなソフトウエアとオープンソースソフトウエアではアプローチが異なるだけです。（この部分はもう少し話したいことがありますが、今回はここで止めます。）

「ソフトウエアの利用に責任を負う」？

オープンソースソフトウエアによるビジネス実現に対価を得ることは構わないことになっています。プロプライエタリなソフトウエアは有償でライセンスを取得することにより、活用することができます。この局面で、インテグレータはMSのようなプロプライエタリなソフトウエアも、オープンソースソフトウエアも、どちらでも選択することができます。この場合に、MSのような主体者がないオープンソースソフトウエアに関する責任は誰がとるのか、という問題があるでしょうか？ありません。オープンソースインテグレーションの責任においては、シンプルな話、対価に対しその責任があるというのが答えです。

築地で寿司を食べる場合、客はその寿司のクオリティの責任を誰に求めますか？魚自身にですか？漁師ですか？市場関係者ですか？運送業者ですか？違いますね。寿司屋に求めます。なぜか。単純に、客は「寿司屋のサービス」に対価を払っているからです。それがインド洋のまぐろなのか、近海モノなのかなんてのは関心はあるかもしれません。が、責任という観点では、それはどうだっていいんです。「近海モノがおいしいらしい」という理由、あるいは最近見た「あるある大辞典」で知った知識をもとに（ものの例えです）、「近海モノ」を注文することがありますが、それでも「寿司屋のサービス」に対価を支払っているのです。

寿司屋は、その魚のクオリティを確保するために、あらゆる手段を使います。実際に海に出ている漁船を調査したり、市場関係者の特定の目利き人やディーラーに選定をアウトソースしたりと、さまざまな方法をとるわけです。どうするかは寿司屋が決め、寿司屋は素材に対しその対価を支払います。この連鎖の最後は「海」ですが、ここはオープンソースソフトウエアよりもはるかに「責任」の所在が見えない世界です。もっともはるかに安定し、完成しているように思いますが。いずれにしても私たちはそれに依存して生きているのです。神は偉大です。

もちろん、Redhat、TurboLinux、MiracleLinuxのようなディストリビューションベンダーが負うべき範囲は当然存在します。彼らは編集価値により対価を得ていますから、どのソフトウエアを自分たちのディストリビューションに含めるのかに関し、責任があります。自分たちも開発に参加することにより、その責任を果たしやすくなっているのでしょうが、それでも全部を自分たちで作る必要はありません。また、Debianのように、ボランタリで編集価値を生み出しているものもあります。彼らは彼らなりに「対価」が何であるかを知っています。

そこで、インテグレータは、どの方法で「素材」を調達するかを考え、選択します。良くないものは使わなきゃいい。ただ、シェア、評判、情報、あるいは経験など、どの根拠によって選択するにせよ、それが顧客の要件を満たしているものであることを証明する責任があります。それに対して対価を得ているのですから。

問題は、「オープンソースソフトウエアによるシステムの品質に責任を持つのは誰ですか？」と顧客から尋ねられたときに、SIerが「最終的に導入するインテグレータ、つまり私たち」だと明確に答えようとしないことではないでしょうか。最近、あるインテグレータ会社の社長さんと話していて、「この厳然たる事実を誰も明確に述べようとしない」と言っておられました。指をさして、「あいつのせいだ」と言いたい傾向のためです。マイクロソフトの製品がハングアップしてブルースクリーンを出しても、「うちのせいじゃありません、MSのせいです」と。食中毒を起こした客に、「最近の築地は良くなくてねぇ」とか言うのと大差ありません。

市場がないと寿司屋が経営できないのと同様、外部から調達したものをもりあわせてサービスにするという図式は非難の対象ではありません。むしろ、現状のITサービス提供連鎖においてエンドユーザから最大の対価を得る位置にいるインテグレータの目利き力不足で、かつ自分でロクに扱えないものをテキトーに扱って対価を得ているのであれば、それこそ非難されるべきだということです。オープンソースを扱ってなにがしかのサービスあるいは製品を提供する企業が、誰でも扱えるなどのメリットだけを享受し、その品質や性能に関しあまりにも無責任、という状況に問題があるのでしょう。

バルマーさんがこう言ったのであれば良かったのに。「オープンソースで無責任なビジネスをやる会社が多い」と。
ほんとはマイクロソフトさんこそお困りのはずですしね。あ、いや、矛先がそれてラッキーだったのかな？;-p