カテゴリ:ITって、何?( 37 )

「ITって、何?」 第11問 インターネットはなぜタダなの?

  << 情報は無料だが通信はただではない >>


「やっぱりITときたらインターネットよね。そうじゃない?」

--そうかなあ? まあいいけど。たしかに近年のIT普及はインターネットの爆発的普及と重なってはいるね。あらゆるコンピュータがつながりあうことが常識になってしまった現在からみると、すべてのマシンが孤立していた15年以上前の世界は、逆に今や幻のような気がするな。

「ふうん。・・でも、インターネットを使えばタダで遠くまで通信できるんだし、つなげるのは当たり前よねえ。」

--え? いや、インターネットはただじゃないよ。自社内でクローズドな専用線を引くよりは安いだろうけれど、お金がかかる。

「うそ!? インターネットってタダじゃないの?」

--いや、インターネットはタダの代名詞みたいに思っている人は多いみたいだけれどね、それは違う。正確にいえばただの部分とただではない領域がある。

「どこが有料なの?」

--簡単にいうとね、通信はただではない。情報サービスの部分はほとんどが無料だ。

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

--そうかい? だって、君だって、家から個人でインターネットにつなぐときは料金を払っているだろ?

「電話代のこと?」

--いや、それもあるかもしれないけれど、プロバイダへの料金さ。

「あれは自宅でやっているからだわ。事務所や大学からだったらタダよ。」

--会社や大学がタダに見えるのは、その組織自身が接続費用を負担していて、それを個別のユーザに請求していないからさ。

「でも接続料ってインターネットの入り口までの料金でしょ? インターネットの世界に入ってしまえばタダのはずだわ。」

--高速道路は入り口で料金を取られるけれど、入ってしまえば無料だ、と言っているのと同じだね。無料の入り口が、あちこちになければ無料サービスとはいえないでしょう。
 でも、もちろん君の言い分も半分は正しい。というのは、普通の高速道路は距離に応じて料金を取られるからね。インターネットの場合、入り口の接続料さえ負担すれば、あとは地球の裏側まで行っても余分なお金はとられない仕組みになってる。

「やっぱりそうでしょ? でも、どうしてその先はタダでいいのかしら。」

--インターネットというのは、どこかに中心や本部のある組織ではなく、お互いに助け合う互助会のようなものだからね。もともと歴史的には米国で発達してきたコミュニティで、コンピュータを相互接続しあうことでお互いのメリットを享受しようという運動の産物だといっていい。料金を集中的に管理統制しようという考え方からはほど遠い。それに、実際問題として、ユーザがどの経路を使うかわからない。

「どういうこと?」

--インターネット通信の中心技術は、米国の軍事技術研究から出てきている。この研究では、核戦争になって米国の大都市が核ミサイルで壊滅するというシナリオを考えた。

「まあ、物騒ね。」

--そのときにね、ネットワークの結節点にあたる都市がやられたとき、ネットワーク全体の機能が死んでしまっては困ると彼らは考えた。

「日本なんて、東京がやられたらお終いよね。一極集中だから。」

--アメリカ人はそれでいいとは考えなかった。ネットワークの一部分がダメになっても、別の代替経路を自動的に選択できるような通信手順を考案し、それを実験するネットワークを作り上げた。このとき生まれた経路制御の技術が今のインターネットの基盤になっている。
 これを逆にいうと、ある地点から別の地点までの経路は一定していないということだ。障害があったら自動的に回避して別のルートをとっていく。インターネットのように巨大で複雑なネットワークは、常にどこかが工事中だ。故障だけでなく定期補修などを含めてね。そうなると、経路に基づいた使用料金など徴収のしようもない。

「だからタダになったというわけ?」

--いや、そう結論にジャンプしないでほしい。この世の中にタダのものなんてないんだ。
 現実問題として、インターネットを構成しているのはいろいろな大学や企業や団体がそれぞれ自前で持っているコンピュータやネットワークなどの設備とソフトで、それぞれお金がかかるものだ。しかしインターネットに参加しているそれぞれの団体は、こうした設備を、情報交換という目的のために無償でサービスさせてもいい、と自発的な意志で決めて提供しあっている。
 つまりね、インターネットを構築し維持するには費用がかかるんだ。けれど、情報へのアクセス権(サービス)はタダで開放する、というのが基本精神だ。情報交換というメリットを得るかわりに、設備や通信の費用は自分で負担しましょうと考える。一種のギブ・アンド・テイクだね。

「"Let's trade."って訳ね。なんだかとても米国的な発想だわ。」

--ボランティア精神といってもいい。そもそも米国でインターネットが生まれたころには、これは学術目的で非営利だった。だから商業用の情報、たとえば広告宣伝などは流してはいけないことになっていた。そのうち、その有用性が認められて、商用に使えるネットワークも生まれ、さらにそこへの接続サービスをビジネスにする「プロバイダ」があらわれた。こうして、誰でも多少のお金をはらえば使える、今の百花繚乱のインターネットが出現するのさ。

「通信はお金がかかるけれど、情報はタダってことなのね。」

--もっと正確にいうと、こちらの情報は無償で開放しましょう、そのための設備や接続費用も請求しません、だからそのかわりあなたの情報アクセスのサービスもできれば無償にしてください、そういう論理から生まれて発展してきた世界なのさ。情報に大きな価値を認めるからこそ、その代償に設備の費用は自分で負担しましょう、と。
 基盤技術は軍事研究から生まれたけれど、運営の精神は学術サークルによって、なかば草の根的に育てられた。こんな風にして現在のインターネットの性格はできあがったのさ。


             (この話の登場人物はすべて架空のものです)
by Tomoichi_Sato | 2011-01-08 00:01 | ITって、何? | Comments(0)

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--たしかにそうだな。

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

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

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

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

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

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

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

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

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

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

「これが正解なの?」

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

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

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

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

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

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

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

「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)

「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)

「ITって、何?」 第9問 IT屋さんは実際の物事をどうデータに翻訳するの?(つづき)

(失礼、また末尾が切れていたようです。プレビューでは見えているのに、奇妙です。あるいはクライアントの環境によるのでしょうか。いずれにせよ、末尾だけ再掲します)


「でも、じゃあ、たとえば『過程』はどうなの? モノだけでプロセスがなかったら世界観として半端だわ。」

--いい質問だ。プロセスとは、データモデルの世界の上では、インプットのデータを得てアウトプットのデータに変換し出力する仕組みを意味する。つまりね、ここまでの説明はまだ事物の認識論であって、この先がまだ半分ある。それが、データの世界でのモデル化の手法だ。いまのエンティティ同士の関係を、データの集合の中でどう表現するか、それが問題だ。

「そうよね。データへの翻訳と文法の話だったわよね。それで、データの文法というのはそもそもどうなっているの?」

(つづく)
by Tomoichi_Sato | 2010-11-26 23:01 | ITって、何? | Comments(0)

「ITって、何?」 第9問 IT屋さんは実際の物事をどうデータに翻訳するの?

<< エンティティと関係による認識 >>


しばらくの間、彼女は黙っていた。

--・・・どうした? もう質問はおしまいかい?

「ねえ。」

--うん?

「いま、何問目だっけ?」

--え? 知らない。7問目か8問目じゃなかった?

「さっきからあなたに聞いた話を今ずっと想い出していたのよ。なんだか話の筋道がふらふらしていて、核心に近づいていないって気がするわ。ITって何か、という核心に。」

--そうかなあ。ぼくとしては一貫してデータの扱い方の話をしてきたつもりだけれどなあ。

「でも最初はたしか、専門家と一般人とのギャップの話だったでしょ? そのあと情報とデータの違いの話になったけれど、情報技術って言葉の由来になって、それから『セミIT』の話に移っちゃったの。そして半角と全角の文字の違いから、やっとバーコードのデータの話に戻ったかと思うと、またデータベース・マーケティングとやらに話が振れるのよね。そして紙と鉛筆のITの話。20の扉のうち、これで8つを開いた訳だけれど、まるでパッチワークみたいで一貫性がないわ。」

--あのねえ。ぼくは君の質問に順番に答えているだけでしょうが。そしたらパッチワークになるのはしかたが無いじゃない。たとえパッチワークでも、しだいにITの全体像がわかってもらえれば、それで目的達成だと思うけど。

「私はそうじゃなくて、順を追って中核に迫りたいの。でもあなたの答えがのらりくらりとしてちっとも中心に向かっているという感じがしなくて。もしもあなたの言うようによ、ITがデータの取り扱いの技術なら、そこに何か中心的なプリンシプルがあるはずじゃない?」

--ITはデータと情報の間のサイクルをつくる技術だよ。情報を定型化してデータの型にはめるのは、その半分だけれど、まあ、中心になる原理だってあるわな。事実をどういう風にモデル化してデータに翻訳するか、だけれど。

「翻訳なの? だったらわたしの仕事の領分ね」

--翻訳ってのはまあ一種のたとえで、実際には定型化とかモデル化とか呼ぶ方が正しいだろうな。翻訳とちがって答えは一種類じゃない。直訳も意訳もある。やる人のスキルにも大きく依存する。

「あら、それって翻訳そのものじゃない。翻訳者の技量で良しあしが決まるし、直訳も意訳もある。あなたは翻訳を、まるで文章を一対一で機械的に置きかえていく作業みたいに誤解していない?」

--うーん、だとしたら、たしかに翻訳の一種ともいえるかなあ。

「もしそうだとしたら、その中心には何か方法論があるはずだわ。あと、文法とか辞書みたいなものも。IT屋さんは実際の物事をどうやってデータに翻訳するの? データの世界には文法はあるの?」

--もちろんあるよ。そりゃ、データは機械のためのものだから、人間の使う言語の文法とはよほどちがった、むしろ数学的なものだけれど、とにかく決めごとはね。

「じゃ、それを真っ先に教えてくれなくちゃ」

--あのね、ぼくはITの世界の水先案内をして上げている訳だよ。外国を案内するのに、その国の気候風土や雰囲気をまず説明せずに、文法規則や法律を真っ先に教えるやつがどこにいるんだ?

「わかったわ。でももう、そのタイミングでしょ。」

--かなわないなあ、君には。
 いいよ。まずね、事実の世界をどう認識するか、からいこう。

「お、本格的。」

--余計な合いの手はイリマセン。まずね、対象世界は事物、すなわちエンティティの集合であると考える。そして、そのエンティティの集合間になりたつ関係=リレーションを規定する事で事実の構造をとらえる。

「ちょ、ちょっと待ってよ。Entity? Relation? いきなり話が抽象的じゃない?」

--だって認識論だもの。我慢してもらって、先にいきます。各エンティティは複数の属性を持つ。その属性のどれか一つ(ないしは複数の属性の組み合せ)によって、個々のエンティティは同定される。

「・・先生。何か例を示してくれる?」

--急にしおらしくなったじゃない。いいよ、さっきのコンビニの例でいきましょう。店で売られている商品を対象に考える。エンティティとは商品だ。

「ふむふむ。」

--商品はさまざまな属性を持つ。名前、価格、仕入先、バーコードでついている背番号(これをJANコードという)、計量の単位(個数とかkgとか)、値引きの対象かどうか、食料品なら賞味期限、etc.,etc...

「あ、そういうのが属性ね、なるほろ。」

--この中で、どれがエンティティの識別に使える属性か分かるかい?

「う、急に反撃に転じてきたな。そんなの簡単じゃない。バーコードの背番号でしょう?」

--正解です。逆のいい方をすると、他の属性は、複数のエンティティで重複して同じ値になる可能性がある。この、決して重複しない識別用の属性をキー属性と呼ぶ。

「で、関係ってのは?」

--ここに、もう一つのエンティティを考えると関係が生じて来る。
 たとえばね、仕入先というエンティティを考える。仕入先は、会社名、所在地、電話番号、FAX番号、支払勘定口座、担当者名等の属性をたぶんもっているだろう。
 ところで、個別の商品は必ず一つの仕入先をもっているはずだ。

「まあ、それはそうよね。」

--このとき、商品と仕入先というエンティティの集合の間に、1対1の関係が成立している、と考える。

「あ、なんだ、関係ってただそれだけのことなの? わたしもっと複雑なものを想像していたわ。」

--男女関係とかじゃないからね。1対1か、1対多か、多対多か、基本的にはそれだけのドライな関係です。

「1対1はわかったけれど、1対多って何よ、その一夫多妻みたいなの?」

--これはね、たとえば同じ商品でも、複数の卸し問屋から仕入れるケースもあるかもしれないじゃないか。コンビニでどうかは知らないけれど、ふつうあり得るケースだわな。

「そうね。」

--その場合、一つの商品というエンティティにたいして、複数の仕入先というエンティティがむすびつく。これを1対多の関係という。

「じゃあ、多対多は?」

--えーとね・・たとえば、こうしよう。店舗というエンティティを考える。同じコンビニのチェーンに所属する店舗だ。ところで、チェーンストアの本部から見た場合、どの店舗でどの商品を売っているかを把握する必要がある。ね? ところで、商品の品揃えは店舗ごとにちがう。

「え? ちがうの?」

--ちがうよ。たとえば、住宅地にあるのか、都会のオフィス街にあるのか、近隣商店街にあるのかで、売れ筋の商品がちがうからね。それと、同じ立地でも、店舗の規模面積によって品数が変わる。広ければそれだけ数多くの商品をおくことができる。これをうまく考えるのがチェーン本部の仕事だ。
 ところで、店舗というエンティティと、商品というエンティティは多対多の関係になる。なぜかというと、一つの商品が複数の店舗で販売されることもあるし、また一つの店舗は複数の商品をおくからだ。これが多対多の関係だ。行ってみれば乱交関係かな。・・あ痛っ!
 
「品の悪いたとえを出さないでちょうだい!」

--ぶつなよなあ、運転中の男を。
 まあとにかく、基本的な関係はこの3種類だ。あとは、1対多だけれど相手は最大5種類までとか、現実的な制約がいろいろつく場合とか、あるいはis-a関係だpart-of関係だ等々とあるけれど、まあいってみればバリエーションなので省きます。
 これで事実世界の認識の説明を終わる。
 
「ええーっ! ちょっと待ってよ。IT屋さんの世界観って、そんなに単純なものだったの? エンティティだかなんだか、事物が並列にならんで、それに属性がぶら下がって、それに数の関係がなりたつ、っていう、たったそれだけ?」

--そうだよ。えー、まあね、事物が並列でなく、親子関係を持って属性を継承したりする、クラスとインスタンス云々の方法論もあるんだけれど、ここではあえて単純な古典的な方を説明しとります。

「そんなんで世界が説明できるわけ無いじゃない。単純すぎるもの。」

--目的はデータと情報の処理だからね。なにも世界を変革するための哲学をやってるわけじゃない。

「でも、ITは世界を変えているんでしょ?」

--そりゃま、そのとおりで、そこがまあ面白いところだけれど。

「そんな単純な世界観で世界を動かそうとするんだもの、あちこちひずみが出るのも当たり前だわ!」

--まあ待ちなよ。別にどこか世間の隅っこにIT屋が集まってだよ、この世を動かす陰謀を練っているわけじゃないんだから。たとえば複式簿記だってさ、考えてもみなよ、あれで世界のかなりの部分は動いているわけだけれど、ずいぶん単純な割り切りでできている。あれはイタリア人の発明らしいけれど、だからといって彼らがこの世界を乗っ取っているわけじゃないよね。

「あの単純さにも、わたしは異議があるんですけれど。」

--その話は会計士の先生とでもしてくれたまえ。今はITの話。

「でも、じゃあ、たとえば『過程』はどうなの? モノだけでプロセスがなかったら世界観として半端だわ。」

--いい質問だ。プロセスとは、データモデルの世界の上では、インプットのデータを得てアウトプットのデータに変換し出力する仕組みを意味する。つまりね、ここまでの説明はまだ事物の認識論であって、この先がまだ半分ある。それが、データの世界でのモデル化の手法だ。いまのエンティティ同士の関係を、データの集合の中でどう表現するか、それが問題だ。

「そうよね。データへの翻訳と文法の話だったわよね。それで、データの文法というのはそもそもどうなっているの?」

(つづく)
by Tomoichi_Sato | 2010-11-25 22:50 | ITって、何? | Comments(0)

「ITって、何?」 第8問 コンピュータ抜きでもITって可能なの?

<< データを組織化する方法 >>


「データにハングリー、だって。・・なんだか血に飢えたボクサーみたいで、野蛮でケチで頭が悪そうなイメージしかわいてこない比喩ねえ。IT屋さんって、そんなのが理想なわけ?」

--そ、そうかぁ? ぼくにはデータや情報を大切にすることのどこが悪いのかと思うけどね。
 ケチというのは、いいかえれば合理的であるってことだ。一度生み出されても、その場限りで風とともに消え去ってしまう情報がいかに多いことか。お金だったら、たとえ1円玉でも、捨ててしまうやつはいないけれど、情報は捨ててしまってもみな平気でいる。ぼくにはその方が不思議さ。

「ふうん。でもそんな“データにハングリー”な会社って多いの?」

--まあ正直言って、日本ではまだあまり多くない。残念ながら、欧米とか、その影響や教育を受けたインドなんかの方が比率は高いかもしれない。でも、増えつつあると信じているけどね。それに、ケチという点では、転記の問題もある。生み出されたデータはそのまま転用すればいいのに、途中で捨ててしまって、あらためて入れ直して作ったりしている。そんなことをすれば手間が無駄なだけじゃない、時間もかかるし情報の鮮度だって落ちてしまう。ミスの混入もある。もっと合理的に、ケチに徹してもいいはずだよ。

「だからコンピュータを使うIT屋さんの登場なのね?」

--いや、あのね。ITって、コンピュータの利用技術だと思われているみたいだけれど、そうじゃない。本当はデータと情報の利用技術なんだ。IT屋はデータを利用しやすいように組織化する仕事をしている、いわばデータのオーガナイザーさ。コンピュータはそのための道具にすぎなくて、極端なことをいえば計算機なんかまったく使わなくても、データをオーガナイズする仕組みがあれば、それは立派なITだ。

「紙と鉛筆だけでも?」

--もちろん。

「どういう風にやるの?」

--まずね、一つところに集めることだ。データはすぐ確実に探し出すことができなけりゃデータとは言えないからね。各人の机のどこかにばらばらにしまい込まれているようじゃ、見つけるのに一苦労だ。見つからなければ風に乗って消えたと同じことだからね。
 あ、その前にもっと大事なことがある。
 
「何?」

--紙に書き留めて記録することさ。そうしなけりゃ本当に消えてしまう。

「なあんだ、そんなの当たり前じゃない。でも、テープじゃだめ?」

--ま、テープレコーダーでもいいだろうけど、紙の方が検索性はすぐれている。
 紙に書け、ってのは当たり前にきこえるけれど、習慣か意志の力がないとできない。ぼくが会社に入って真っ先にたたき込まれたのは、打合に出たら、後で必ず「打合覚書」を書け、ってことだった。ユーザ部門や業者さんとの打合は必ず記録して、番号を取ってファイルしておく。すっごく面倒に思ったよ、最初はね。でもそれで助かったことが何度あったことか。
 
「そこらへん、たしかに欧米の会社は徹底しているわよね、つきあってみると。」

--なるほど。まあとにかく、そうやって書き留めて記録した紙は、一カ所に集める。そのとき、形式をそろえる。紙の形をA4にするとか、表題と日時と記録者を一番上に書く、とか。

「帳票みたいに?」

--うん、まあ、そうだね。とにかく定型化すること、これが情報をデータに加工する第一歩だ。そのとき考えなくてはいけないことが二つある。それは、整理番号を打つということと、ファイルしておく順番だ。

「整理番号、って?」

--各々のデータ1件1件を、他と区別するためにつける、参照用の番号さ。

「図書館の分類番号みたいなもの?」

--そういうものでもいいし、別に単なる順番で1から機械的にふった背番号でもいい。とにかく、『何月何日にあの件で打合わせたあれだよ、あれ』みたいな言い方ではなく、『打合記録何々番』という言い方で指し示すことのできるような整理番号が必要だ。

「どうしてそんなものが必要なの?」

--あとでそのデータを再利用するときに、指示が正確で簡単になるからさ。さっきのバーコードに商品の名前を長々と書かなかったのと同じ理由だ。名前や内容で呼ぶとダブりがあって誤解の可能性がある。それに整理番号の方が短い。

「あと、ファイルの順番だっけ?」

--そう。日付順でも整理番号順でもなんでもいいから、とにかくどういう順序で物理的にしまってあるのかを決める。そうしないと探すときに毎回、頭から全部めくってみなければならなくなる。

「うちの事務所の場合は、クライアント別に、やりとりの日付順にファイルしているわね、基本的には。・・すごいわ! そしたらもうちゃんとIT化しているんじゃないの、あなたの定義でいけば。」

--定型化してる?

「してるわよ。全部A4サイズだもの」

--そうじゃなくて、記録する内容の方だよ。A4サイズの紙に、書くべき項目の内容と順序と場所は決められているか? 整理番号は取っているか?

「整理番号・・一応うちから発信する分は、日付で連番を取っているわ。でも、書くべき項目の内容って、何よ? 内容なんか毎回変わるに決まっているじゃない。」

--本文の内容はそうだろう。ぼくがいっているのはね、データ1件を構成する項目の取り決めさ。たとえば、整理番号・日付・発信者氏名・クライアント名・タイトル・本文・etc...こうした決まった項目が集まって、データ1件ができあがるということさ。

「なあんだ、そういうこと。それだったら、うーん、人によるわね。でも、今あなたがあげたような項目だったらだいたいカバーしていると思うけど」

--形式化ってね、ほんとは“だいたい”じゃダメなんだ。さっき、データの究極の最小単位は選択肢だ、って言ったろ? 選択肢である限り、メニューは決まっていなければならない。例外は許されない。1件のデータはどんな項目の集合からなるかを決める。1件1件を作るにあたっては、決まった位置に・決まった項目を・決まったメニューの中から選びとる。こうした取り決めをデータの文法というんだ。データの文法が定義されてはじめて、定型化されたと言える。

「だって、本文にどんなメニューがあるっていうの!? 全然矛盾しているわよ。」

--そう。そういう自由なテキストの項目というのもたしかに存在する。そういうテキストはね、文字数の上限だけを決めておく。あるいは、『終わり』の印を決めておく。

「何のために?」

--1件のまとまりの範囲を明確にするためさ。紙だって、えんえんページが続いていたら、どこまでがその1件書類かわからないじゃないか。

「見ていけばわかるわよ。それに、2ページ以上にわたるときは、それぞれに必ず2/9といった感じで通しページを打っているし。」

--たいへん結構。それだったら9/9まで来れば終わりだとわかる。終わりの印が打ってあるのと同じだ。

「お褒めにあずかって光栄ですこと。でもこれのどこがITなの? 徹頭徹尾当たり前のことじゃないの。」

--あのね、それが当たり前に見えるのは君の事務所のレベルが高いからだよ。でも、この当たり前のことができない人は大勢いる。この定型化のところをくぐらないと、データとしての再利用はおぼつかない。君は家計簿ってつけてるかい?

「ぎく。嫌なことを聞くわね。つけてなかったらどうだっていうの?」

--あのね、家計簿ソフトってあるだろ? あれを使えば自分の収支もきちんと管理できそうに思える。でもね、紙の家計簿をつける習慣のない人は、コンピュータの家計簿ソフトを買ってきたからと言って、やっぱり使い切れないことが多いのさ。
 それと同じで、紙と鉛筆の世界でちゃんとデータを蓄積するマインドを持ってこなかった人たちが、システムを入れたからって、データを活かす経営なんてすぐにできるわけない。ほら、最新式の特殊素材のラケットを買ったからといって、フォームもスタンスも直さずにテニスのスコアがあがるわけないだろ? ITにはこういう誤解が多いから困るんだ。売る方にも責任はあるけどね。
 君が勤め先で毎日やってる程度の「当たり前」があれば、データを本当にコンピュータに持ち込むのはあっと言う間だ。
 
「持ち込んだからって、どうなるの?」

--どうなるって? そりゃ別に、大したことはないさ! 保存するのに場所がいらなくなる。検索が滅茶苦茶速くなる。複製が瞬時にできる。遠く離れた場所の人とも共有できる。転用もあっという間にできる。分析もいろいろできる。いや、ほんとに大したことないさ、ITの恩恵なんて、ほんとにね。

「あのね、あなたはそう偉そうにおっしゃるけれど、わたし一つ疑問があるの。」

--どんな疑問だい?

「お話を聞いていると、なんだか図書館のカードボックスみたいなものが究極のデータみたいじゃない?」

--究極かどうかはともかく、あれは定型化の立派なお手本だろうね。

「わたし、図書館のカードみたいにきちんと分類され整理されすぎたデータって、知的には何も生み出さないんじゃないかって思うのよ。本当の創意って、少し無秩序なところから、はじめて創り出されてくるものじゃないかしら。」

--・・・。

「反論はないわけ?」

--あるよ。
 そもそも、何かを考え、何かを決めるときには、まず正確な事実認識が必要じゃないだろうか。ぼくらは詩人や芸術家じゃないんだから、創意といっても無から何かを創り出す訳じゃない。
 このカーナビをごらんよ。今ぼくらがどこの位置にいて、どこに向かって何kmの距離にあるか、道はどう続いていくか。こうしたことを知るのは意味がないだろうか。自分のいる位置が少し曖昧だったら、その分、運転は楽しく創意に満ちたものになるだろうか。
 
「だって。」

--聞きなよ。ITに好き嫌いがあるのはしかたがないさ。でもITはまず事実に関する道具なんだ。道具に対する好き嫌いと、事実に関する好き嫌いは区別しなくちゃね。
 事実をとりまく霧が晴れたら、その分、知的なクラリティがあがるものじゃないだろうか。知的って、本当はそういうものじゃないだろうか。だとしたら、それは、定型化の手続きという代償をはらっても、手に入れる価値があるんじゃないかと、ぼくは思うんだ。

(つづく)
by Tomoichi_Sato | 2010-11-18 22:07 | ITって、何? | Comments(0)

「ITって、何?」 質問7 POSレジは何のデータを集めているの?

<< データに関してハングリーな経営 >>

「でもちょっと待ってよ。本題から外れちゃったわ。セブン・イレブンは何で買う人の男女や歳が分かるの?」

--何で、って、そりゃレジの前に立った人が男か女か、店員が目で見ればわかるじゃないか。

「あ、なんだ。店員の人が見て判断してるわけ?」

--そりゃそうさ。あのレジのキーの側をちょっとのぞいてみれば分かるけれど、一番左側の方のキーの一列は、男女性別と年齢階層のキーになっている。会計をするたびにお客さんの年格好をみて、まずそのキーを打つんだ。

「なあんだ、そうだったの。・・え、だとしたら、私はいったい何歳として見られているのかしら?」

--知らないよ、そんなこと! 各店員個人の判断なんだから。年相応に見られてくやしかったらコンビニに化粧していけばあ?

「あら、お言葉ね。でもどうして性別や年格好が買い物の合計を計算するのに必要なのかしら。」

--え? 関係ないよ、もちろん。

「だって、あのレジは金額の計算のためにあるんでしょ? 内蔵しているマスター・データとかを参考にしながら合計を計算するための機械よね、さっきの話では。」

--あともちろん、レシートの印刷とお金の格納もね。

「でもレシートには私の性別とか年齢とかは書いていないじゃない? そのキーを押しても何の役に立つのよ。」

--君には関係なくても、彼らには役に立つんだ。

「だってレシートになければその情報は消えてしまうんでしょう?」

--消えないよ。POSレジの機械が覚えているからさ。

「え?」

--ああ、なんだか誤解があるみたいだね。POSレジってのはさ、印刷機つき電卓とは訳がちがうんだ。電卓とちがって、あれは入力されたデータをすべて覚えている。

「レシートにうったことを?」

--レシートにうったことだけじゃない、“入力された”ことにもとづくデータはみんなさ。だから性別のキーからの入力は、レシートに結果が出てこなくても全部記憶している。

「え、それじゃPOSレジは計算だけじゃなくて、データも集める機械だってこと?」

--そうです。というよりね、むしろデータを集めるかたわら、計算もしてレシートも打っている、という方が真相に近い。レシートをきれいに打つための清書機械、つまりさっき説明した「セミIT」用の道具が主目的ではないんだ。目的意識から言うとデータ収集の方が主になっている。

「いったい何のデータを集めているの?」

--ぼくもコンビニの専門家じゃないから推測でいうけれど、基本的にはそれぞれのトランザクションの明細とそれにともなう属性情報だろうね。

「なになに? 急に日本語じゃなくなったみたい。」

--あ、ごめんごめん。トランザクションて言葉は、つまり個別の取引のことを指す。

「取引。」

--そう。まあ会計学風には、価値と対価の交換とかで定義されるんだろうけれど、もっと平たく言えばモノやお金が移動するときの毎回の記録と思ってくれればいい。
 たとえばコンビニの買い物ならば、お客さん一人が一度にする買い物のことだ。一人で10個のモノを買うかもしれないけれど、それを1回のトランザクションという風に考える。それは1枚のレシートにまとめて印字される。10個の商品がすなわち明細だ。

「はあ。」

--その取引にともなう属性情報ってのはね、んー、なんだ、つまりその取引を特性づけるような種々のデータ項目のことであり・・

「あのぉ、まるで国会答弁みたいで、あいかわらずぜんぜん日本語になっておりませんわよ、先生。」

--ここらへんのことって、なんだか日常用語でひどく説明しにくいなあ・・日本文化のエア・ポケットなのかしらん。えーとね、具体例でいうと、その取引が何時何分に行われたかとか、どのレジで受け付けられたかとか、売り手の担当は誰だったかとか・・

「あ、お金とは直接関係ないけれど、その取引の状況を説明してくれるような補助的な情報ね。だったら最初からそういえばいいじゃない。あなたの頭が弱いのは日本文化のせいじゃないわ。」

--そりゃどうも。とにかくそういった属性情報の一つとして、買い手の性年齢階級があるんだと思う。

「やっとその話に戻りついたわね。そもそも何でコンビニは客の個人的プライバシーみたいなことを知りたがるのよ?」

--彼らはね、売れ筋分析をしたくてデータを集めているのさ。別にお客さんのプライバシーには関心がない。つまり君という具体的な人間の名前とか、電話番号とかにはね。
 ただ単に、20台の女性だったらどういう商品を良く買うのか、どんな商品と商品を一緒に買うのか、店には何時頃来ることが多いのか、一回あたりいくらくらい買い物をするのか、そういうことを分析しようとしているんだ。

「そんなことしてどうするの? だいたい、そういう売れ筋っていうのは、問屋さんとかの方がよく知っているんじゃないの?」

--案外そうでもない。卸という業態は、どちらかというとメーカーの品物を「おろし」て配送や集金を代行する形で発達してきた。おかげで、卸はメーカーとのつながりが強いところが多い。そのため、へたをするとライバルメーカーの商品は扱えなかったりして、公平な商品の売れ行きはつかめないことがある。
 その点、コンビニはどのメーカーの商品も公平に売る立場にあるから、データは細かいけれども正確だ。これをきちんと集計して分析すれば、こういう立地の店には、何時くらいの時間帯には、どういう客層相手の商品を置けばいいのか、すごく無駄なく分かるはずだろう、という信念があるんだ。こういうのを一般に、データを活用したマーケティングという。
 性別と年齢というのは、コンビニみたいな業態ではとくに大事なデータ項目だけど、お客さんに直接聞くわけにもいかないから店員のラフな判断で入力しているんだろ。君がたとえば会員制割引のカードでも使って買い物すれば別だけれど。

「あら、それだったら正確に分かるわけ?」

--もちろん分かる。だって会員に加入する際に、必ず住所氏名と生年月日を書かせるだろう? そういうデータは、必ず会員名簿のマスタ・データに記録されるから、君の会員番号をカードから読み取れば、後は自動的に性年齢階級は計算できるんだ。
 セブン・イレブンが会員制カードを使っていたかどうか記憶にないけれど、多くのデパートやチェーンストアが、会員制カードを宣伝しているのは、もちろん固定客がほしいせいでもあるけれど、そうすれば自分の顧客のデータベース・マーケティングに役立つ情報がとれるからでもあるんだ。

「はあー。なんだか住基カード番号より先に、コンビニ総背番号制が普及しちゃいそうな勢いね。」

--あちらは政府とちがって真剣ですから。まじめに頭使って仕事しないと競争に生き残れない。だからITの利用も進んでいるのさ。

「あら、急に我田引水ね。それじゃあ、セブン・イレブンのお店は、あのPOSレジっていうの? あれに毎日のすべてのお客の買い物データを蓄積してとっているわけ?

--それだけじゃない。そのデータをネットワーク経由で本社のデータ・センターまで送っているはずだ。あの業界の人たちはね、いわばデータに関してとてもハングリーな経営をしている。

「なにそれ?」

--データからできる限り情報を引きだそう、貪欲にしゃぶりつくそう、という姿勢さ。データはできる限り発生源で、発生時点に、速く正確に取ろうとする。それを処理し、保存し、集中化して、データとしての価値を高めている。そしてデータに基づいて次の経営判断をする。需要にマッチするように商品を供給すれば無駄がなくなる。
 だから、もしいまだに経験と勘と根性の3Kでやっている旧態依然のメーカーや卸がいたとしたら、コンビニに頭が上がらなくても当然かもしれないね。

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

「ITって、何?」 第6問 バーコードには何のデータが入っているの?

<<あらゆるものに背番号をふる>>


「ねえ、それじゃ次の質問。
バーコードはデータなの?」

--な、なんだい、その質問? 悪いけどぜんぜん意味が分からない。

「だからさあ、なんて言ったらいいのか・・セブンイレブンとかで、買いに来るお客さんの歳とか男女の区別までデータとしてとってる、っていうじゃない。」

--たしかにセブンイレブンは客層の性別と年齢階層のデータをとっているよ。

「そのデータって、バーコードの中に入っているの?」

--おいおい、ちょっと待てよ。かりに君がセブン・イレブンでチョコレートかなんか買ったとするだろ、ね? 考えてもみなよ。チョコレートの包装紙にはバーコードが工場で印刷されているわけだ。そのチョコが、どうして君というこれこれの年齢の女性に買われる、って事前に分かるんだい? そんなの分かる訳ないだろう。

「そっかあ。だとしたら、あのバーコードには何が入っているの。」

--バーコードには製品の背番号が入っているのさ。

「この製品は何番目に作りました、とかっていう番号? そういえばパソコンの後ろ側とかにもついているわ。」

--いや、そうじゃない。それはシリアル番号といって、製品ごとに一個一個違う番号だ。そういう番号をバーコードに刻んでいるものもたしかにあるけど、それは例外さ。
 ふつうコンビニに売っているような商品のバーコードは、その商品の種類を示す番号なんだ。同じ種類のチョコならどれも同じバーコードがついている。だからチョコの包み紙に印刷できるんだ。一個一個みんな違っていたら印刷できないだろ。

「じゃあチョコの商品名とか、値段とかが入っているの?」

--名前じゃなくて、コード番号さ。数字そのものだ。ふつう13桁の数字になっている。バーコードの下をよく見ると、小さく数字が印字されているだろ? その数字がそれさ。

「数字なんてあったかしら。ちょっと待って、バッグにチョコが入っているから確かめてみる・・。あ、ほんとだ。数字があるわね。たしかに13桁並んでる。今まで気がつかなかったわ。」

--それでわかったでしょ? コンビニのレジはその番号を読みとって、商品名や値段をレシートに印刷できるんだ。

「でも、どうして名前や値段そのものを打ち込まないの? その方がわかりやすいじゃない。」

--値段は安売りとかまとめ買いの値引きとかがあるから、メーカーの希望小売価格と実売価格は一致しないことが多い。だからメーカーが印刷しても意味ないんだよね。値段は売る店が決めるから。

「わかったわ。でもどうして商品の名前じゃないの?」

--名前はね、まず長すぎる。「ハーゲンダッツ・アイスクリーム・チョコレート味」なんて調子で、軽く20文字とか30文字になっちゃうだろ。バーコードは目立たない程度のスペースにおさまる必要がある。
 それよりももっと大事なことは、名前だけだと、同じ名前がダブる可能性があるんだ。たとえばカセットテープなんていろんな会社が出してるだろ? 「カセットテープ74分」なんて名前だけじゃ、どこの製品だかわからなくなっちまう。当然値段も分からなくなる。

「そうするとあのバーコードは同じ種類のカセットテープでも会社ごとに違うわけ?」

--左様です。細かく言うと、あの13桁は、まず最初の2桁が国番号をあらわしている。日本ならば49か45。日本の会社の製品はほとんどたいてい49からはじまっている。

「どれどれ・・あ、ほんと。」

--次の5桁が会社コード。そしてさらに5桁が会社ごとの製品コードになっている。最後の1桁はチェックディジットと言って、読み取り確認用の数字でそれ自体に意味はない。

「それで全部おさまるの?」

--5桁あれば00001から99999まで約10万種類の製品を持てる。ふつうの会社だったらまず間違いなくおさまる。こうすれば、どの会社の製品をとってみてもバーコードがダブって重なることはあり得ない。桁数には他のバラエティもあるけど、まあ似たような概念だから説明は省くね。

「ちょっと待って。そしたら、最初の質問に戻るみたいだけれど、バーコードって何のためにあるの?」

--レジでバーコードを読みとって、コード番号から商品名と値段を知るためさ。

「だってその商品名と値段はバーコードには入っていないんでしょう? 矛盾してない?」

--商品名と値段は、レジのマスタの中に記憶されている。

「なによそのマスターって。」

--マスターじゃなくて、マスタ。ITの世界ではマスタと短くいう。

「英語にしたら同じMasterなんでしょ? 何わけわかんないこと言って気取っているのよ!」

--どうもすんまへん。
 マスタというのは、台帳のことだ。辞書といってもいいかな。辞書の中には、まず製品のコード番号があって、それに続いて製品名とか、販売価格などのデータが入っている。つまりデータベースさ。データが決められた形式で集まってコンピュータ内に格納されているものだからね。
 
「コンピュータじゃなくてレジじゃない。」

--バーコード付きのPOSレジってのは、あれは実はコンピュータなんだ。パソコンと見てくれはずいぶん違うけれどね。

「ふうん。」

--そしてそのレジの中で、コード番号からマスタの辞書を検索して、商品名や値段を知る。辞書で綴りから意味を見つけるみたいにね。これを商品ごとにくり返す。最後に合計を計算してレシートを打つんだ。こういうひとまとまりのデータのやりとりのことをトランザクションという。

「でも、お客さんが、知らないバーコードのついてる商品をもって来たらどうするの? レジって世界中の商品を知ってるの?」

--店で売っているってことは、その前に必ず仕入れて売値を決めている訳だろ? そのときに店のマスタに、商品メニューとして登録するのさ。

「ということは、バーコードって、商品メニューからの選択肢なのね。」

--まさにご明察! だから、バーコードはたしかにデータなんだ。メニューからの選択肢はデータの最小要素だって説明したとおりに、ね。
 メニューから一つの種類の商品を間違えなく選び出すためには、名前ではやってられない。名前は長くて、あいまいで、おまけに重複する可能性がある。レジでいちいちキーボードから商品名を入力していたらどれほどあほくさく時間がかかるかわかるだろう? そんなことを避けるために、規格化された数字の並びを背番号として使う。背番号は絶対にユニークじゃなければいけない。
 
「ユニークって、特徴があるってこと?」

--いや、ごめん、ITの世界でユニークという言葉は、一つ一つ別々で重複がないことを意味する。その背番号をつかって、マスタという台帳に名前だとか仕入れ価格だとか売値だとかさまざまなデータを登録しておく。こうすれば、お客さんがもってきた商品の背番号さえ入力すればすぐに売値が分かる。
 しかし、背番号は無味乾燥で店員がとても覚えていられるものじゃない。だから、バーコードを印刷して、レーザー読取り機で一瞬のうちに入力してしまうという方法が普及したんだ。
 
「国民総背番号制みたいなものね。」

--まさにそのとおり。もし国民のデータを効率よく集中管理したかったら、名前でなんかとても管理できない。同姓同名は山のようにいるからね。だから背番号をつけようと言う当然の発想になる。

「アメリカなんか、社会保険番号ってのがあって、それが一種の背番号の役をしているのよね。」

--そうらしいね。で、日本では同じような目的で、住民基本台帳を元に11桁の『住民票コード』を何年か前に作ったわけだ。

「でも日本の住基ネットって、私、なんかいやだな。だって、あっちとちがって、お役所の権力が強いでしょ? 好き勝手なことをやられちゃいそうで。」

--それはね、でもITの使い方の問題だからね。役人に管理されたくないからデータ処理が不便なままにしておこう、ってのは、暴走族が来たら困るから川に橋を架けない、というのと一緒だと思うよ。
 だいいち、役所だけじゃなく、病院でも銀行でも、いやそれこそビデオ屋さんでも、とにかく顧客データを管理したいわけだろう? そのときに、国民共通の背番号があるとすっごく便利になる。

「あら、だって、住基カードって、引っ越したらまた新しく役所からもらわなくちゃいけないのよ。毎回変わるなんて、ばかみたいじゃない?」

ーーうーん、物としてのカードはそうかもしれないけれど、個人のコード番号自体は変わらないんだ、引っ越しても。
 それに、結局今だって、運転免許証の番号とか、パスポート番号とか、それに準じる背番号はいくらでもあるんだ。IT屋のぼくとしては、国民背番号に反対する理由は何もないと思う。

「でも、それでも、いやだな、私は。」

(つづく)
by Tomoichi_Sato | 2010-11-04 23:04 | ITって、何? | Comments(0)