<   2010年 12月 ( 8 )   > この月の画像一覧

「ITって、何?」 インターチェンジ(2/2) 『データをデザインする方法』

<<実習:住所録データベースを考える>>


--さて、住所録の目的は何だろう?

「目的? 住所録に目的なんて無いわ。」

--そんなことないだろう。いろいろな目的に使うはずだ。電話をかけたり、手紙を書いたり、冠婚葬祭のお知らせとか、年賀状・・

「じゃあ、電話帳と、年賀状の宛名印刷を主な目的とした住所録。」

--OK。じゃ、まず、必要なエンティティと属性を洗いだそう。

「なんか大げさねえ。要するに、人がいて、その人の名前と住所と電話番号があればいいんでしょ?」

--電話番号って、自宅の? それとも勤務先の?

「それは両方あった方がいいわ。・・っていうことは、こうなるのね。」

 +--------+
 | 住所録    |
 +--------+
 |名前      |
 |住所      |
 |自宅電話番号  |
 |勤務先電話番号 |
 +--------+

--キー属性は何? この表の中で、辞書における「見出し語」に相当する属性はどれだい。

「何って、名前に決まっているじゃない!」

--同姓同名があったら? 同じものが二つ以上あると、キー属性には使えないよ。

「私の知り合いには今のところいないわ。」

--もし出てきたらどうする? でてこないという保証はないね。

「やな人ねえ。じゃ、電話番号にしたらどうかしら、自宅の。これを見出しにするの。これだったら各人で必ず異なるはずだわ。」

--ふうん。でも、夫婦の二人とも知り合いの時はどうするの? 自宅の電話番号は同じだから、二人のレコードが同じキーの値になるよ。」

「意地悪! じゃ、どうしろっていうの?」

--キーの値が夫婦同士で重ならないように、個人個人に整理番号をつけてキーにするしかないね。

「いやよ、そんなの。まるで背番号じゃない! 私は国民総背番号制に反対なのに、何で自分の住所録のためにつけなきゃならないの。」

--OK、じゃ、この問題は後回しにしよう。ところで、仕事の上だけのつきあいの人で、会社に年賀状を出さなきゃならない人はいないかい?

「いるわよ。そしたら、住所のところに会社の住所を入れればいいじゃない。」

--自宅と勤務先と両方知っている人はどうする。そういう人もいるじゃないか。

「・・そうねえ。そうしたら、住所を二つ持ったらどうかしら、自宅と勤務先の。」

--なるほど。その場合はさあ、年賀状を印刷するプログラムはどちらの住所を印刷したらいいか迷っちゃうぜ。

「じゃあ、どうするの?」

--自宅住所と勤務先住所の二つのフィールドの中で、どちらを年賀状の宛先に使うかを判断するためのフィールドを別に持つといい。こういう、YesかNoかの判断をするためのスイッチみたいなフィールドをフラッグと呼ぶことがある。手旗信号の旗だ。

「わかった。そしたら、結論は、こうね。」

 +--------+
 |  住所録   |
 +--------+
 |●整理番号   |
 | 名前     |
 | 自宅住所   |
 | 自宅電話番号 |
 | 勤務先住所  |
 | 勤務先電話番号|
 | 宛先フラッグ |
 +--------+

--そうだね。これで一応、電話帳兼住所録になる。

「でも、この整理番号制って、どうしてもやだな・・。それに、ちょっと待ってよ。これじゃ、知り合いの夫婦のところに出す年賀状は、二人別々になっちゃうわ。」

--たしかにそうだな。

「うーん・・あ、わかった! そのときは、夫婦二人の名前を、『名前』のところに入れればいいのよ。データを夫婦単位にするの。それに、そうすれば自宅電話番号をキーにできるから、へんてこな整理番号なんていらなくなるわ。」

--なるほど。でも、夫婦では勤務先の住所や電話番号は違うよ。

「だったら、夫婦それぞれの勤務先についてのフィールドを持てばいいのよ。これで完成。どうお、先生?」

 +----------+
 |    住所録   |
 +----------+
 | 名前       |(夫婦の場合は両方の名前を入れる)
 | 自宅住所     |
 |●自宅電話番号   |
 | 夫の勤務先住所  |
 | 夫の勤務先電話番号|
 | 妻の勤務先住所  |
 | 夫の勤務先電話番号|
 | 宛先フラッグ   |
 +----------+

--なるほど。なかなか良くできているね。夫婦二人を単位として、1レコードに押し込めるというのがアイデアだな。ぼくも思いつかなかったよ。

「でしょ? でも、・・ってことは、あなたの考えてる正解とは違うわけ?」

--ぼくは実はもう自分用のデータベースを作ってあるんだ。それは、こうしている:

 +---------+       +--------+
 |  個人住所録  |       | 勤務先住所録 |
 +---------+       +--------+
 |●整理番号    |   +--> |●勤務先コード |
 | 名前      |   |   | 勤務先会社名 |
 | 配偶者氏名   |   |   | 勤務先事業所名|
 | 自宅住所    |   |   | 勤務先住所  |
 | 自宅電話番号  |   |   | 代表番号   |
 | 勤務先コード  |<<--+   +--------+
 | 勤務先部署・肩書|
 | 勤務先電話番号 |
 | 宛先フラッグ  |
 +---------+

「何、これ。わたしのと全然ちがうじゃない。」

--そう。どうしてこうなっているかというと、まず、ぼくの場合は会社単位のつきあいの人が圧倒的に多い。それと、この業界は転職や会社の引越、それも事業部単位での引越が多い。勤務先の住所を個人のレコードに書き込んでしまうと、大勢のレコードを直さなくてはならなくなる。だから勤務先のエンティティを独立させたんだ。

「これが正解なの?」

--いや、君のは君ので正しい。こういう問題は正解は一つだけではないんだ。さっき、事実認識は人によって違うと言っただろ。
 ぼくのつきあいの範囲と君のつきあいの範囲は違う。君は翻訳業で個人事業者が中心だから、夫婦単位の知り合いが多い。ぼくは会社員で変転の多いIT業界が中心だ。だから住所録データベースのデザインが違うのは当然さ。ぼくのデザインを君に押しつければ窮屈になり、逆をやればぼくが面倒になる。事物のデータへの翻訳のしかたは一通りとは限らなくて、データの性質と目的をよく考えながらデザインしなければいけないんだ。それにはけっこうスキルがいることはわかってくれたかい?

「ふーん。でも、こんな、フィールドだとかエンティティだとかって、普通の人は覚える必要あるのかしら?」

--まあ用語は忘れてもいいよ。でも基本的な概念は知っておいても損しない。パソコンの構造やプログラミング言語について勉強するよりも、ITを理解するにはずっと有益だ。

「でもね。住所録なんかはいいでしょうけれど、こんなぎちぎちで窮屈な形式にしばられないで、もっと自由に情報をデータにする方法はないものかしら。」

--“自由”の意味にもよると思うけれど、あるといえばあるよ。それはインターネットの世界でホームページを作るHTMLというやつさ。ホームページも一種のデータベースだけれど、これはかなりフレキシブルな構造を作ることができる。だから情報を表現するのに向いているんだ。

「インターネット! そうよね。やっと話がITっぽくなってきたじゃない。データについての石頭な講義はもうおしまいにして、もっと情報よりの話が聞きたいわ。」

--やれやれ、わかったよ。それじゃお腹もくちたことだし、車に戻ろう。別の高速に乗り換えることでもあるし、話も少し情報産業の方向に切り替えようか。
by Tomoichi_Sato | 2010-12-28 19:53 | ITって、何? | Comments(0)

クリスマス・メッセージ: 子どもの国から抜け出そう

Merry Christmas !

生まれて初めて乗った飛行機は、旧ソ連のアエロフロートだった。大学を卒業し社会人になる直前の3月、いわゆる卒業旅行に出かけたのである。ドイツにいた知り合い(父の部下)のNさんを頼って、モスクワ経由でフランクフルトを訪れたのだ。Nさんは忙しいさ中にもかかわらず、わたしをいろいろな場所に案内してくれた。

その中で最初に印象に残ったのは、じつは鉄道の駅だった。フランクフルトの中央駅だった思うが、遠くからの列車が発着するホームが多数並んでいる。驚いたのは、改札も何も通らずに、いきなりホームの列車まで行けることだった。そもそもヨーロッパのこの種の駅は、改札が無いのだった。「切符は?」とNさんにたずねたら、「もちろん買って乗るのさ」と窓口の並びを指さしてくれた。

しかし改札がないんじゃ、すぐ隣の駅までの切符を買って遠くまで乗るインチキもできるじゃないですか。それどころか、切符を買わずに無銭乗車だって可能ですよ? −−そんな疑問を口にした若いわたしに、Nさんは、その後ずっと忘れられぬ言葉で答えてくれた。「みんな、ちゃんと切符を買うんですよ。ここは、大人の社会なんだから。」

大人の社会。だとすると、自分が生まれ育った国は、大人の社会じゃなかったんだろうか。ならば、子供の国だとでも言うのか。あまり欧米崇拝趣味のないわたしには、なんだか癪にさわった。だが、そもそも『大人』って何だろう? そういう疑問は日本に戻っても頭の中で渦巻いた。

ちなみに、欧州の列車だって、車内での検札はある。検札で正規の切符を持っていない事が分かると、かなり高額の罰金を科せられる。また、地下鉄や郊外電車などは自動改札システムを持つ路線も多い。そういう点で、不正を防ぐ仕組みはちゃんとある。ただ、メインの部分が、利用者への『信用』の上に成り立っているのだった。

大人って何だろう? どうすれば大人になれるのだろう。その問題はずっとわたしの頭を悩ませた。自分は大人といえるだろうか? 他人から、いや自分自身からも信用しうるだろうか。年齢だけは重ねても、仕事や私生活で、自分の未熟さ幼稚さのため幾度も苦い思いをし、大人であると言い切るだけの自信は、なかなか生まれなかった。そんなある時、大ベテランのプロジェクト・マネージャーと話していたら、

子どもは、自分のしたいことをする。大人は、自分のすべきことをする。

という定義を教えてくれた。この言葉はなぜか、すとんと腑に落ちた。たしかに、自分の願望や欲にばかり動かされる者は、子どもと言えるかもしれない。

睡眠や食欲といった生理的次元からはじまって、娯楽の次元、そして競争に勝ちたい、出世したい、お金持ちになりたい、といった社会的次元まで、欲求の姿は多種多様だ。だが、そうした願望に突き動かされて騒々しく行動する人々を見ると、なんだか自身の欲の奴隷と化しているようにも感じられる。大人というのは、だとすると、自分の欲求を時に応じて抑えたりセーブしたりできる人かもしれないと思った。

でも、「すべきこと」って何だ? 仕事や家庭や社会の最低限の義務だけでは、大人であるには足りないようだ。普通の人はたいてい、それを果たしているし。「したいこと」は自分の中にいくらでもあるが、「すべきこと」は自分の中だけをいくらほじくっても、必ずしも見つからないのである。なぜなら、それは、他者の期待の中にあるからだ。

わたし達は、お互いに対して、何を期待するのか。「プロジェクトのマネジメントとは、すなわち期待のマネジメントだ。チーム員の、ステークホルダーの、そして自分自身の期待を、どう形にして、どう方向付けるか。それが仕事の成否を決める」と、くだんの大ベテランは物静かに教えてくれた。期待のベクトルを合わせると、おのずから「すべきこと」が見えてくる。方向がばらばらだと、組織のエントロピーばかり高くなって、すべきことが見えなくなるらしい。

わたし達の社会は、1990年頃を境に、見えない大きな変化を迎えた。そのことがこの国を、バブルの有頂天から失望の20年間に突き落としてしまった。その変化とは、第一に人口と学歴と組織階層のピラミッドの相似形が崩れたこと、第二に経済の力関係が供給側から需要側へとシフトしたことである、とわたしは考えている。しかし、それだけではない。もっと重要なこと、わたし達の心性のレベルで大きな変化があったはずである。それでなければ、社会がこれほどまでに回復力の弾性を失うだろうか。では、その変化とは何か。最近、サイトの読者の方から「静寂の価値」というエントリに関連して、なぜ社会がかくもにぎやかで騒がしいのかとの質問を受けて、ようやく気づいた点がある。

高度成長期以降、わたし達の社会は大量生産・大量消費で成り立ってきた。そこでは、人は次々と欲望を持って消費してもらわねばならない。そのために広告や宣伝といった手段で、あらゆる媒体を使って、人々を刺激し続けている。20世紀後半にTVや映画やネットが発達し、普及した背景にも、広告宣伝が大きな役割を果たしてきた。これが興奮性の情報を湯水のごとく人々に浴びせ続け、「にぎわい」を演出し続ける、主導因だと思われる。

言いかえるなら人々を、欲望に動かされてだだをこね、何でも人と一緒になりたい「子ども」状態にとどめるために、現代は努力を払っている訳である。発達した工業化社会はどこも必然的に、「子どもの国」に向かうドライブがかかっている。そして、日本は、それがとても成功したのである。欧州社会だって事情は似ているはずだが、あいにくあそこは「大人」であることが大事とされる(少なくとも「大人」であることが無理にでも求められる)場所である。時に不便で、時に嫌みで、しばしば息苦しい社会ではあるが、それが彼らの特質を少しは守っているのだろう。

わたしの知っている優秀なマネージャーは、たいてい物静かである。あまり騒々しい人には、プロマネはつとまらないようだ。大人の特性の一つは、落ち着きがあることだからだ。よくできた仕組みは静かにスムーズに動く。創造性は、にぎわいだけでなく、孤独で集中できる時間を必要する。こうしたことを認めて、また耐えられる人を「大人」と呼ぶのだと思う。

年の瀬のひととき、家族や親しい人と一緒に、争いや喧噪をはなれて静かに過ごすべき、平和の季節がまたやってきた。いつでも騒ぐのは、子どもである。大人は静かだ。私たちの社会は、大人であろうと意思する人が足りないのだろう。少子化問題ではなく、「大人不足問題」こそ、真の問題なのかもしれない。
by Tomoichi_Sato | 2010-12-23 22:58 | 考えるヒント | Comments(2)

「ITって、何?」 インターチェンジ(1/2) 『データをデザインする方法』

<< デザインの図と見方 >>
(今回はインターミッションです。データ・モデリングに興味のない方はとばしても結構です)

 食後のコーヒーに手をのばしながら、彼女はいった。

「ふう、やっと人心地ついたわ。・・さっきはなんだか専門用語の羅列でおどかされ続けたみたい。でもねえ、もしもデータベースの文法ってのが、あなたのいうように四角四面で単純なものなら、誰でも簡単にデータの世界への翻訳ができてしまうんじゃない?」

--まあ、簡単かどうかはともかく、ある程度の翻訳はできるだろうね。少なくとも、ちょっと慣れれば翻訳の結果を理解することはできると思う。建物のフロアプランをみて理解できるようにね。

「でも、フロアプランと違って、ここには創意工夫の入る余地はあまりないんじゃない? ふつうの言語の翻訳の世界だったら上手へたがあるけれど、このデータベースの翻訳の方は単純だもの。」

--おいおい、冗談はやめてくれ、このデータ・モデリングの世界だって上手へたはものすごくあるよ。いや、ふつうの翻訳以上に、人による差は大きいと思う。

「あら、どうして? 現実の世界にある事物の『属性』と『関係』を、単にそれぞれ、えーと、マスタ・テーブルだっけ? それのフィールドと、参照の関係に置きかえるだけでしょ? すっごく機械的で、主観的な判断とか曖昧さとかが入り込むすきまはなさそうに思えるけれどな。」

--馬鹿いわんでくれ。そんなに機械的であってたまるか。

「そうお?」

--そうさ。事物とその属性って簡単に言ってくれるけれど、データの対象となる事実の捉え方はそんなに自明じゃない。

「そうかしら。客観的事実は事実だと思うけれど? ITは事実に関する道具だ、ってあなたさっき宣言したばかりじゃない。」

--客観的事実は一つしかないかもしれないけれど、その記述のしかたは多様だよ。

「なんだか哲学の講義みたいね。」

--だって認識論だもん。さっきも言ったけど、ITってじつは西洋哲学の子供なんだ。非嫡子かもしれないけどさ、実用の道具だからね。

「あらまあ高尚だこと。でもそれじゃ説明になっていないわよ」

--たとえば、新聞記事の事を考えてごらん。あるいは歴史の教科書でもいいかな。客観的事実ってのは限りなく多様な説明が可能なものだ。
 たとえばどこかに事件があったとする。環境汚染にまつわる経済事件にしようか。記者が問題をおこした会社に直行する。現場で色々な事を取材する。舞台となった会社はどういう会社か。本社の所在地からはじめて、社長の名前、年商、従業員の数、業種、おもな商品・・その会社に関連する事がらは際限なくある。
 でも、そのすべてを記事に書きはしない。記者はその中から、事件の記述に必要と思われる事を、自分で判断してえらぶわけだ。経済紙の記者なら、その事件が業界に与える影響を考えて、市場のシェアだとか株価を中心に書くだろう。でも、市民運動に近い立場の雑誌記者なら、その会社が消費社や地域に対してとってきた態度や、政治とのつながりに注目するかもしれない。でき上がる記事は、同じ事件を対象にしてもまったく違う。客観的事実は一つしかないとしても、さ。

「人はそれを報道の偏向とよぶんじゃないの?」

--そうだろうか? だとしたら、偏向のない報道なんてありえないんじゃないかとぼくは思う。記事のスペースは有限なのに、事物が持つ属性はのほうは限りなく沢山ある。その属性の取捨選択や焦点のあて方は、記述の目的や関心のあり方に応じて違っても当然だろう。
 話がへんな方向に行っちゃったけれど、データベースを設計するときにも、どの属性を選んでどれを捨てるか、事物の捨象のしかたは人によって個性が出る。かなりスキルの差が出るところだ。翻訳と同様、うまいへたがあるのさ。

「その、うまい下手って、どういうところにあらわれるの?」

--下手だとね、データに無理や無駄が多くなって、使いにくくなる。たとえばね、さっきのコンビニのデータの例でいけば、商品マスタの中に仕入先の電話番号が入っていたろ、最初?

「うん。」

--あのままだとね、もし、ある仕入先が引っ越して電話番号が変わったとき、その仕入先から買っているすべての商品のレコードについて、データを直さなくちゃならなくなる。商品が100個あったら、100ヶ所の修正だ。間違える可能性がすごく高い。しかし、もし仕入先のマスタが独立していたら、直すところはたった一ヶ所で無駄がない。

「あ、そうね。」

--これはほんの一例。ソフトの良し悪しの半分以上は、データベースの設計の良し悪しで決まるんだ。へんてこなデータ構造になっていたら、ちょうど建物の土台の形がゆがんでいるのと同じで、その上にすなおで頑丈なビルを建てることなんてできやしない。
 たぶん、普通の人は、ソフトを評価するときには画面やプリントアウトの見た目で使いやすさをはかるだろう。それはそれで間違いじゃないけれど、一面でしかない。建物を、外観だけで判断するようなものだ。
 ぼくらプロのIT屋は、むしろデータベースの構造を見る。ちょうど建築士が設計図から建築構造を判断するようにね。
 
「さっきの、四角い表をみるわけ?」

--いや、あれは具体的なデータの入っている表だよね。そうじゃなくて、データの入れ物、器としてのデザインを見るんだ。・・ちょっとその紙を貸して。ああ、サンキュ。図を書いて説明しよう。
 たとえばね、さっきの例で言えば、最初のデザインは、こうだ:
(注:以下の図は等幅のフォントでご覧ください)

 +--------+
 |  商品マスタ |
 +--------+
 | 商品名    |
 |●JANコード   |
 | 単価     |
 | 仕入先名   |
 | 仕入先電話番号|
 +--------+

 これに対して、2番目の、仕入先マスタを独立させたデザインは、
 

 +--------+       +--------+
 |  商品マスタ |       | 仕入先マスタ |
 +--------+       +--------+
 | 商品名    |    +ー>|●仕入先コード  |
 |●JANコード   |    |  | 仕入先名   |
 | 単価     |    |  | 仕入先電話番号|
 | 仕入先コード |<<ーー+  +--------+
 +--------+

 という風に表現できる。
 
「・・何、これ?」

--エンティティとリレーション(関係)を表現した図で、頭文字をとって「E-R図」と呼ばれてる。それぞれのエンティティとその属性をまとめて四角で囲ってある。●のついているのはキーとなる属性だ。矢印は参照関係を示している。

「矢印が <<---> ってなっていて右左の形が違うのはなぜ?」

--これは、仕入先コードという属性が商品マスタと仕入先マスタの間で多対一の関係になっていることを示している。まあ、このE-R図の書き方はいろいろ流儀があるんだけれど、これはその簡単なサンプルだ。

「さっきみたいに口で説明されるよりは、この方がたしかに分かりやすいけれど・・あなたのITの話って、ちっともプログラムのことが出てこないのね。」

--プログラムは裏方でね。いわば、データが主ならプログラムは従なんだ。データ構造が決まればプログラムは自ずと決まる。建物のレイアウトが決まれば空調のダクトやエレベーターの通し方が自ずと決まるようにね。それに、プログラムは計算機のハードが進歩すればどんどん変わるけれど、データは生き残る。データの方がソフトよりもずっと寿命が長いんだ。

「こんな図だったら、私でもかけそうな気がするけどな。」

--そうかい? それじゃ、試しに書いてみる? 例は何にしようか。

「住所録なんてどうかしら。」

--住所録。いいね。じゃ試しにやってみよう。

(つづく)
by Tomoichi_Sato | 2010-12-19 18:37 | ITって、何? | Comments(0)

「システム輸出」戦略は成立できるか - 日本アラブ経済フォーラムに出席して

チュニジアで開催された「第二回 日本アラブ経済フォーラム」という国際会議に参加してきた。日本からは官民あわせて約400名が出席したようだ。アラブ各国からの出席者はそれを上回るだろう。

チュニジアは地中海に面した、北アフリカの小国である。両隣にはリビアとアルジェリアという産油国があるが、自国はあまり天然資源に恵まれていないため、教育、商業、観光に力を入れている。人口約1千万人のほとんどがアラブ系でアラブ連盟に属し、公用語はアラビア語。ただし仏の植民地だった影響でフランス語は広く通用するし、英語もちゃんと通じる。首都チュニスの12月の気候はやや肌寒く、アフリカと言えばどこも暑い、というステロタイプの思い込みは、空港に降り立ったとたんに間違いだと思い知らされる。

日ア経済フォーラム」は、昨年(開催地:東京)に引き続き、第2回目である。閣僚級が集まるオープニング・セッションにはじまり、「エネルギーと環境」「人材育成」「観光と投資」などの全体セッションと続き、クロージング・セッションで終わる。また途中に分科会として、「太陽エネルギー」「水」「原子力」「インフラ」「アラブにおけるビジネス」「IT、ハイテク、衛星」のWorkshopがはさまる。わたしは「インフラ」の分科会で、"Project and Program Management"と題する短い講演発表を行った。

ところで、上記各セッションの中に、「石油」が無いことにお気づきだろうか? アラブといえば石油、というのが日本における共通理解(=固定観念)だろう。だがアラブ世界の国々は、4種類に大別できる。産油国と、そうでない国。そして、中東と、北アフリカである。共通点はアラブ民族とアラビア語、そしてイスラム教だが、全部を一緒くたに考えることはできない。とはいえ、人口は合計3億人以上、人口増加率も経済成長率もそれなりに高く、中国・インドに次ぐポテンシャルを持っている地域だと言えよう。

日本からは、外務大臣と経済産業大臣の二人の閣僚が出席した。それなりの力の入れようがわかる。ところで、フォーラム終了後にネットで日本のニュースを検索したところ、「外相、経済外交を陣頭指揮」といった見出しが出てきて、思わず笑ってしまった。これは、現場を見ていない記者による、あおり記事にちがいない。なぜなら、このフォーラムを全面的に仕切っていたのは経済産業省だからだ。

わたしも今回初めて知ったのだが、日本には「中東調査会」と「中東協力センター」という、ちょっと見よく似た組織が二つある。前者は外務省の、後者は経産省の外郭団体である。そして、今回のフォーラムで会場のセッティングから送迎の手配まで、ロジスティック関連の雑務を一手に引き受けていたのは中東協力センターの方だった。セッションの企画や調整は経産省から官僚が大勢出張してきて切り回している。え? 外交って外務省の仕事じゃなかったの? というのが、諸般の事情に疎いわたしのような会社員の、率直な感想だった。

両大臣のスピーチも対照的だった。外相のスピーチは、経済協力から中東平和への言及まで含んだ、しっかりした内容だ。ただし、本人は用意された原稿を読んでいくだけ、というもの(原稿は官僚の作成だろう)。もっとも外相は北米、インドネシア、チュニジア、そしてアルジェリアと連続して世界を飛び回っており、超多忙な仕事ぶりであるのは確かだ。一方、元技術者だという経産相は、正直あまり立派な文章とは感じなかったが、とにかく自分で考え感じたことを話していた。

その経産相のスピーチの骨子が、じつは日本の「新経済成長戦略」と「産業構造ビジョン2010」なのである。あなたは日本政府(経済産業省)が最近、日本の経済まき直しのための戦略を立てたことをご存じだろうか? その上で、今年『戦略五分野の強化』という政策を打ち出した。それは、次のような5点からなっている:
・インフラ関連/システム輸出(原子力、水、鉄道等)
・環境・エネルギー課題解決産業(スマートグリッド、次世代自動車等)
・文化産業(ファッション、コンテンツ、食、観光等)
・医療・介護・健康・子育てサービス
・先端分野(ロボット、宇宙等)

とくに海外については、最初のインフラ関連『システム輸出』という新しい用語に注目して欲しい。これは、従来の日本の輸出が、自動車一辺倒、あるいはもう少し広く、単品としての「製品輸出」一辺倒だったことへの反省から出た言葉である。アジアや新興国のニーズは、工業化・都市化に伴う社会インフラの整備だ。それらは、鉄道であれ水道であれ発電であれ、マスタープランにしたがって構築・統合されるべき「システム」である。ところが、これらシステム全体の青写真を描き、実現にむけてリードしているのは欧米諸企業である。日本が車両や水処理装置やタービンなど個別の製品をいくら輸出してみても、それはいわば「部品メーカー」でしかない。当然、南欧や韓国メーカーとの価格競争に巻き込まれよう。部品メーカーがちっとも儲からないのは、日本国内を振り返ってみても明らかである。

「いや、うちの最新式水処理装置はそれ自体が高度な制御機能を持つシステムです。」などと主張しても、それは意味がちがう。地域の給水系ネットワークという、より大きな絵の中では、それは点に過ぎないからだ。途上国の政策をリードし、プランを牛耳っている者がどこか他にいる限り、日本企業は下請けの地位に甘んじなければいけないのである。

それでは、マスタープラン作りから全体の具現化までの、トータルな実行のためには何が必要か。それが「プログラム・マネジメント」の能力である、というのがわたしの発表の趣旨だ。プログラムとは、互いに関連し協調して遂行される複数プロジェクトのまとまりのことである。意味のあるプロジェクトを発進させ、また途中で価値を失ったプロジェクトは中断撤退させる。これは個別PMではなく、プログラム・マネジメントの仕事である。自分でここを押さえないと、あなた方は欧米に振り回されますよ、それでいいんですか? とアラブの人たちに訴えたわけだ。どれだけ相手に通じたかは分からないけれども、アラブ諸国は欧米の植民地として苦い目に遭っているから、その点だけは日本に親近感を持ってくれるだろう。

それにしても、このような国際会議の成功・不成功は何をもって測るのだろうか? 事情通によると、3点あるらしい。(1)参加者の人数、(2)成果としてのアウトプットがあること、そして(3)継続しうること、である。まず参加者の人数については、合計1,000人近い参加があったから、合格だろう。アウトプットとしては、「チュニス宣言」という文書が挙げられる。この中で日本とアラブ各国は、具体的な協力分野と方法について記している(ちなみに協力分野のトップはインフラである)。継続についても、第3回を2012年に日本で行うことが合意された。

だから大成功だった、と主催者は結論したいだろう。わたしもとくに異議はない。しかし、各セッションが対話としてかみ合っていたかというと、疑問に感じた瞬間もないではなかった。その理由は、日本側の意識にあると思える。'80年代・90年代の日本の輸出は「売ってあげる」だった(とくに途上国に対しては)。ところが2000年代に入ってからは「買って下さい」の立場に、力関係が逆転している。ちょうど、国内での生産形態が見込生産から受注生産に変化したように。だが、日本の大企業や年配者達は、まだこの変化に気づいていない人が少なくないようだ。今回のフォーラムは、そうした気づきを促した点に、最大の意義があったのではないかと思うのである。
by Tomoichi_Sato | 2010-12-15 23:17 | ビジネス | Comments(0)

次回更新は少し遅れるかもしれません

「日本アラブ経済フォーラム」という会議に出席するため、北アフリカのチュニジアに出張に来ています(Project and Program Managementに関して、短い発表をする予定です)。

あいにくアクセス環境が不安定なため、今週は「ITって、何?」はお休みします。また、次回更新も、帰国まで多少遅れる可能性があります。

よろしくご了承ください。
by Tomoichi_Sato | 2010-12-10 23:50 | ビジネス | Comments(0)

リアルタイムとは何か

先日、数理計画法ツールのベンダーである数理システム(株)の主催するセミナーで、竹内郁夫・東大名誉教授の講演を聴く機会があった。テーマは「射程内に入った実時間ごみ集め」、LISPのリアルタイム・ガーベッジ・コレクションの話である。ミーハーの私は、竹内先生の書かれた名著「初めての人のためのLISP」(今年再版された)を持っていき、サインをお願いした。と、驚いたことに、「じゃあ筆を出すから」と言って、鞄から小さなケースに入った毛筆を出して、さらさらと献辞をしたためてくださった。日本語へのこだわりといい、毛筆といい、なんて粋なんだ! と感心した次第である。

ところで、竹内先生の講演内容は大変面白かったが、『実時間』という概念について、なんとなく無条件に前提されているように感じられた点が、ちょっと気になった。むろん、LISPのごみ集め性能については、セル消費とスイープによる回収の速度の比較として明確に規定され、実験で測定されている。しかし、どうなればリアルタイムと呼びうるのか、それは技術者の常識的感覚に任されていて、そこまでは定義されていない。

LISPに限らず、バックグラウンドで任意のタイミングでガーベッジ・コレクションが走りうる処理系では、リアルタイム性の議論がうるさい。そこで一般的に言われていることは、プロセスが動作するたびにタイミングや時間がばらつかないようにすること、あるいは、開発者が実行タイミングや実行時間を確定的に計算できるようにすること、といわれる。産業用システムや組込系ソフトでは高いリアルタイム性が要求される。だから処理時間の「予測可能性」が重要である、との認識があるわけだ。あるいは、「確定論的(Deterministic)スケジューリング」が可能であること、と言ってもいい。

だが、これは本当なのだろうか?

ERPの覇者、SAP社の「R/3」のRとは、実はReal Timeの頭文字であった(初期にはR Systemという名前の汎用機ソフトから出発した)。でも、R/3はなぜ「リアルタイム」なのだろうか? 開発者は処理時間を確定的に設計できるだろうか? 答えはまったくNOである。あの三層アーキテクチャで非同期処理が走っているのに、確定論が成り立つわけはない。

あるいは、たとえば工場内でICタグとPOPシステムをつかって、ワークの位置情報を「瞬時」に読みとったら、リアルタイムなのだろうか。瞬時性にこだわるならば、DCSで制御弁の開度を1秒周期で制御することは、リアルタイムだろうか。では、スペアパーツを倉庫から払い出して、3分後にその情報を端末から入力したらリアルタイムではなくなるのだろうか。

もう少し続けよう。以前、「リスク」の定義として、「目指すべき目標値ないし理想状態から逸脱する可能性があり、かつ、その影響をリアルタイムに回避・抑制できないような事象(群)」をリスクと呼ぶ、と書いた。その場ですぐに回避可能な事象はリスクではない。自動車を40km/hで運転しているとき、ずっと前方を車いすで横断する老人がいても、ハンドルやブレーキを使ってほぼ実に避けられる。だが小学生が物陰から飛び出してきたら、そうはいかぬ。だからリアルタイム性は、リスクを議論する上で必須の項目である。ではそのリアルタイムとは、一体何なのか?

じつは、答えはたった3文字の漢字で書ける。それは「時定数」である。管理対象の時定数よりも十分速くコントロールが可能であれば、それがリアルタイムなのである。

プロセス・プラントのDCSが1秒周期で制御弁の開度を決められれば、それはリアルタイムだ。中を走っているのは秒速数m~数10mの速度をもつ流体である。秒以内の単位で制御できなければ相手は系から逃げてしまう。しかし、わたしは以前、時定数が150時間もある超多段蒸留装置のフィード・フォワード制御をやったことがあるが、このときは30分間隔でオンライン分析計からあがってくる情報が十分リアルタイムだった。

倉庫の物品払出し作業は、品目数にもよるが数十分単位であり、その手配リードタイムは数日以上である。だから3分遅れの情報でも、十分速いリアルタイム性を持つ。そして本社財務部門にとっては、財務諸表が一日以内で得られれば十分リアルタイムだ。だからSAP R/3はリアルタイムだと主張できたのである。

だから、リアルタイム性を議論するときには、管理しようとしている対象が、どの程度の時間スケールで動いているのかを考えなくてはいけない。従来の議論で抜けていたのが、この時定数の感覚である。各人が分野毎に、無意識に前提して、話をしてきた。だからちょっとでも分野を超えると、さっぱり話がかみ合わなくなる。

応答が何マイクロ秒以内ならリアルタイム、といった閾値は存在しない。確定論的スケジューリングだからリアルタイム、という議論もおかしい。現実の世界で、「確定論」でスケジュール通りに動く物事が一つでもあるだろうか? 生産スケジューリングからコンピュータのジョブ・スケジューリングまで、スケジューリングとはすべからく「近似値」の上に成り立つものだ。その近似値の精度が、制御目的の時定数に比べて十分であるかどうだけが重要なのである。
by Tomoichi_Sato | 2010-12-05 17:48 | ビジネス | Comments(0)

「ITって、何?」 第10問 データの世界には文法ってあるの?(2/2)


「・・・こうしてIT屋さんの単純な世界観が、コンピュータの中のデータの構造に翻訳されたというわけね。なんて平板で単純なのかしら。」

--君はそう思うかもしれないけれど、アリストテレスの認識論でも、事物(エンティティ)は属性と量と場所と時間と入出力(正確には能動と受動)と関係で決まる、とされていた。つまり、これが西洋的な事実の認識なんだ。

「いきなり西洋哲学!? とんでもない所に救援願いを出したわね。」

--そんなことはない。ある意味、ITってのは西洋哲学の子孫なんだ。すごくその影響を受けている。あまり日本人の技術者は気がついていないけどね。

「・・なら、『関係』の方はどうなったの?」

--それはこれから説明する。関係というのはね、あるフィールドの値が選択肢で規定されるときに、それを別のマスタ・テーブルへの参照として表現する事だ。

「え? もう一度いって。」

--あのね。さっきの表でいくと、商品の仕入先の名前と電話番号というフィールドがあっただろ? でもね、これはよく考えてみると、これは商品の属性ではなく、取引先の属性だ。

「たしかにそうね」

--だから、本当はこんなフィールドを商品マスタの中に抱えているのは論理的におかしい、ってことになる。商品の属性は、どこの会社から仕入れるかということだけに留めるべきだ。そして、仕入先の属性データは、「仕入先」というエンティティのために別のマスタを用意して、そこに格納すべきだろう。たとえば、こんな:

仕入先コード 仕入先名  仕入先電話番号
----------------------
1001   昭和食品(株) 03-3456-1234
1002   (株)三田製菓 03-7654-9000
・・・    ・・・     ・・・

 このテーブルにもキー属性が必要だから、「仕入先コード」という背番号をつくることにした。これは各社に対してそれぞれ一つの番号を振りあてている。

「それで商品のマスタの方はどうするの?」

--商品マスタには、「仕入先名称」や「電話番号」のかわりに、単に「仕入先コード」のみを記録する事にする。つまり、こんな風に:

商品名     JANコード   単価  仕入先コード
--------------------------
チョコレート  4912345670001 192   1001
キャラメル   4906543218046 75   1002
メロンパン   4900223360097 120   1001
・・・     ・・・    ・・   ・・

 これをみるとわかるとおり、『商品マスタ』と『仕入先マスタ』の二つのエンティティをあらわすテーブルが、「仕入先コード」という共通のフィールドをキーにして“関係づけられて”いる。
 別の言い方をすると、『仕入先マスタ』というテーブルは一種のメニューとして定義されていて、商品の仕入先は、その『仕入先マスタ』からの選択肢になっている。複数の商品が同じ仕入先コードを持つことができるから、ここには多対一の関係が成立していることになる。これが、データベースにおける関係の表現なのさ。
 
「うーん・・なんだか複雑ね。わかったようなわからないような・・」

--そりゃね、本当だったら何週間もかけて講義するようなデータベースのスキーマの話を3分で話しているんだから、分かりにくいかもしれない。そこはかんべんしてもらわないと。
 とにかく、このようにして、複数のテーブルが関係をもって組あわさって作るものが『データベース』なのです。ちょうど、部屋と部屋が廊下やドアでつながり組合わさって建物ができるように、ね。

「センテンス同士が接続詞でつながりあって文章ができるようなものかしら。」

--そうともいえるかな。とにかく、ここでちょっとまとめておこう。
 データの最小単位とは、有限の選択肢の中から一つを選んだものを指す。これは(選択肢のメニューさえ決めれば)数字で表現できる。選択肢で定義できないようなものは、それが満たすべき規則を決める。これがフィールドで、いわば単語にあたる。
 レコードとは、フィールドが決められた順序で決められた数だけ並んだものをさす。データの並び方を決める約束事をデータの規則と呼ぶ。
 対等なレコードが複数並んだものを、テーブルという。レコードを識別するためのフィールドを、キーと呼ぶ。キーの値はそれぞれのレコードごとに必ず異なっていなければいけない。
 エンティティとその属性を表現するテーブルのことをマスタと呼んだりする。マスタは、選択肢のメニューをあらわす辞書としても機能する。
 あるテーブルが、別のテーブルのキーとなるフィールドを共有することによって、テーブル間の関係が生じる。
 データベースとは、複数のテーブルが関係を持って成立するものをいう。

「ふう。これがデータの世界の文法規則の全貌というわけね?」

--そのごく概略のありさまです。まあ、細かな点をいろいろはしょっているから厳密には不正確なところもあるけど、理解してもらう助けにはなるだろう。見慣れない用語も多くて申し訳ない。消化不良になりそうかな?

「・・そうね、飲み込むには時間がかかるかも。
 消化といえば、それにしても、なんだかお腹がすいてこない?」

--そうだな、ぼくもずっとしゃべりどおしで、のどがカラカラだ。もうそろそろインターチェンジだから、パーキングエリアのレストランでも探そうか。ちょっと休憩して何か飲みたいな。

「賛成。わたしも、お腹がぺこぺこよ。」
by Tomoichi_Sato | 2010-12-02 23:36 | ITって、何? | Comments(0)

「ITって、何?」 第10問 データの世界には文法ってあるの?(1/2)

<< データの辞書と文法の話 >>


--文法、っていい方が適当かどうかわからないけれど、たとえるならば単語・文・文章にあたるものはそれぞれあるね。文章はどうやってできていて、単語というのが何で、単語をどう並べれば文章になるかの原理がある。

「それがコボルとかなんとかのコンピュータ言語なのね」

--あ、それは違う。ぼくがここでいっているのはあくまでもデータの構成原理の話。ぼくはここではコボルだのパスカルだのといったコンピュータ言語の話は一切するつもりはない。COBOLもPascalももう時代遅れだけれどね、まあそれはさておき。

「え、どうしてなの? それって違うものなの?」

--まったく別です。コンピュータ言語というのはね、プログラマという職種の人が、計算機で行う処理の細かな手順を書き留めるためのメモみたいなものだ。つまりプロセス、過程に関する記述。それは機械ならびにプログラマが解釈できればいいもので、普通の人が理解する必要はない。
 これからぼくが説明するのは、データの構造の話で、つまりデータというブロックをつみ上げてデータベースという建物を作るときの考え方だ。どうやってフロアプランやレイアウトを作るか。これは、すくなくとも、その建物を利用する人にはみな関係がある。フロアプランがわからなければ行きたい場所にたどり着けずに迷ってしまうから。
 プログラム言語なんてものは、いってみればエレベーターの制御方法や、空調ダクトをどう通すか、みたいなものだ。これは一般人には関係がない。

「じゃあその、フロアプランの規則を説明して」

--建物がふつう四角い部屋が集まってできているように、データベースというものも普通は四角い表からなりたっている。

「四角い表、って?」

--普通にどこにでも見かけるような表さ。たとえば、こんな風な:

商品名     JANコード   単価  仕入先名    仕入先電話番号
----------------------------------
チョコレート  4912345670001 192   昭和食品(株) 03-3456-1234
キャラメル   4906543218046 75   (株)三田製菓 03-7654-9000
メロンパン   4900223360097 120   昭和食品(株) 03-3456-1234
・・・     ・・・    ・・   ・・・     ・・・
                      (等幅フォントでご覧ください)

 この表はすなわち、さっき説明した事物の世界における、コンビニの「商品」というエンティティに対応している。

「四角はわかったから、運転中にハンドルから両手を放すのはやめて! それに、いまどきコンビニにキャラメルなんて売ってないわよ。それにメロンパンですって、ふふふ。あなたの頭の中って小学校時代の駄菓子屋から進歩していないんじゃないの。」

--いいじゃないか、そんなこと! ・・とにかくね。これは商品という事物一つ一つについて、その属性が並んでいるという形式になっている。横に続くそれぞれの行が個々の事物で、縦に並ぶ項目が属性に対応する。

「それがExcelみたいな表計算なのね。」

--いや、あのね。ここでは当分の間、表計算ソフトのことは忘れてほしい。表計算ソフトというのは表みたいな「見え方」をつくったり計算したりするソフトで、ぼくがここで語っているのは四角い表という論理的な「構造」なんだ。

「なんだかよくわかんない。」

--混乱しやすいことはみとめる。でも、ここではソフトとかプログラムの話をしているんじゃなくて、その底に横たわっているデータの構造とか「文法」とかの話をしているんだろ? どうかしばらくの間、表計算ソフトのことは忘れてほしい。

「わかったわ、まだわかんないけど。それでその、属性だっけ、それがどうなったの?」

--データの四角い表の横1行が、事物の世界では個別のモノに対応する。これをね、データの世界では『レコード』と呼ぶ。さっきまでは、データ1件、とか言わざるをえなかったけれども、これからは1レコード、と呼ぶことにする。それから、事物の世界で属性と呼ばれている、表の縦の列は、データの世界では『フィールド』と呼ぶ。

「Field? なんで急にそんなところに“平原”が出てくるの?」

--このフィールドって用語は、はるか昔に、パンチカードでデータを集計していた時代からのなごりでね。カードの10桁目から20桁目まで、みたいな区画を意味していた。今ではフィールドやレコードよりも、もっとモダンな用語があるんだけれど、こういう慣習は根強いので、まだぼく自身ももっぱらこう呼んでいる。

「あなただって駄菓子屋時代から進んでいないもの。でもこれ、本当に文法の話?」

--このレコードが、言葉でいえばセンテンスにあたる。レコードの中の各フィールドの値が、単語に相当する。この単語というのは、前に説明したとおり、定型化されていなければならない。

「定型データの究極の最小単位は選択肢だ、っていってた、あれ?」

--ご名答。ある定められたメニューがあって、その中から特定の選択肢を一つ選ぶ。数値というのも、前に説明したように選択肢の一種だ。そして、どのフィールドにはどの選択肢が許されているか、メニューを定義しているものが、いわば言語における音韻規則にあたる。

「ふーん。でも、ちょっと待って。あなたがさっきあげた表の例でいくと、値段は数字かもしれないけれど、あとは選択肢でもなんでもないわ。たとえば電話番号。」

--いい質問だ。電話番号の各桁は、0から9までの数字とハイフンの中から選ばれる。そしてその組みあわせは、一定の条件を満たしている必要がある。全部で12桁以内、ハイフンは必ず2個、そして最後は必ず4桁の数字が続いている事、など。あるメニューからの選択肢という形をとれないようなものは、「単語」として許される範囲の規則を明確に決めなければならない。これも一種の文法さ。

「もしも規則に反するような単語がデータの中にあったらどうなるの?」

--データの処理をするプログラムが正常に動かなくなってしまう。たとえばさ、電話番号のデータをつかって、電話を自動的にかけるようなプログラムを組んでいたとしよう。もし数字とハイフン以外の文字が混ざっていたら、電話をかける装置が誤動作してしまう。だからふつうは、そういう文法に反するようなデータをユーザが入力しようとしたら、そこで警告のメッセージを出して受け付けない、という風にプログラムで防御しておく。ちょうど不審者の侵入を防ぐカード式エレベーターのように。これがプログラムの仕事だ。

「ふうん。でも、じゃあ商品名の方はどんなルールがあるの?」

--そう、こういう名前に類するフィールドは、一番規則がゆるやかだ。ここでは、名前に許される文字の種類、たとえばカナだけなのか、漢字も許されるかなどを決め、それから、字数の最大限を決める。20文字以内、とかね。

「ふーん。でも、最大何文字とかって決めきれないような場合はどうするの?」

--その場合はたとえば、『終わりの印』を決めておく。何文字でも好きなだけ続けていいけれども、文字列のおしまいである事が分かるような特殊な記号をおいて、それで締めくくる。

「よく外国の雑誌で一つの記事のおしまいを示すためにページの隅にロゴみたいなマークを打っているけれど、あれみたいなものかしら。」

--かもね。ただし、あれは文章の終わりで単語のおしまいじゃないけれど。
 さて、こうして定型化された単語・すなわちフィールドの値がならんで、一つのセンテンス・つまりレコードを作る。もちろんレコードの中でどのフィールドがどの順番で並ぶのかに関しても、きちんとした規則が必要になる。ちょうど言語の文法が語順を規定するようにね。
 同じ規則で作られた対等なレコードが並んでいる表を、テーブルとよぶ。

「それがさっきの四角い表なの?」

--そうだ。

「それがさっきの、えーと何だっけ、エンティティに対応するって訳?」

--そうです。

「つまりそれが翻訳なのね」

--事物の世界から、データの世界への翻訳です。あるエンティティについて、キーとなる属性と、その他の属性を並べたテーブルは、その事物の『マスタ』とよばれる。たとえばさっきみたいな表は、コンビニで売る商品のマスタ・データなので、「商品マスタ」という風に呼んだりする。
 マスタは一種の辞書だと思えばいい。辞書と同じで、最初に見出し語があり(これがキー)、それに続いて説明の記述(属性)が並んでいる。マスタを引けば、そのエンティティに関するデータを得ることができる。

「こうしてIT屋さんの単純な世界観が、コンピュータの中のデータの構造に翻訳されたというわけね。なんて平板で単純なのかしら。」
by Tomoichi_Sato | 2010-12-02 23:32 | ITって、何? | Comments(0)