今こそ、プログラマの時代

── プログラミングの勧め ▼小学生へのプログラミング教育 　小学生への「プログラミング教育」必修化が検討されているという。 　私が育ったアナログ世代とは異なり、デジタルネイティブ世代を相手にする教育だから、教え方にもそれなりの創意・工夫が必要になるのではないかと思う。どのような教え方をするのか興味のあるところだが、そう簡単にベストの方法が確立されるとは思えない。失敗を繰り返しながら少しずつ良い教育方法が築かれていくことになるのだろう。 　どの世代が相手であろうと「プログラム作りに必須の技能」としてプログラマなら身に付けなければならないものがある。そういうものは適当な時期を選んでしっかりと教え込んで欲しいものだ。 ▼分かりやすい文章 　たとえば「分かりやすい文章」を書く能力が求められる。プログラム作りに限らず最も基本的で必須の能力であるが、小学生が直ぐ身に付けられる類いのものとは思えない。 　どんな言語でも構わないが、日本語、英語、あるいはコンピュータ言語、何でも良いから「自分の考えを抜かりなく、誤解の余地なくしっかりと相手に伝える」ことができるようになってほしい。それができなければ、相手が人であろうとコンピュータであろうと思い通りに動かすことなどできる筈がない。 ▼誤解を与える 　政治家はよく「誤解を与えた」という表現を使って弁解しようとするが、これは「相手が間違って解釈したのだ」と主張し責任の大半を相手側に押し付けようとするものである。 　しかしそんな身勝手な言い分けはプログラミングの世界では通用しない。プログラムの記述で「誤解を与えた」としたら、それは自分の表現方法が間違っていた、あるいは自分の説明が足りなかったということを意味している。全責任は自分の側にあると知るべきであろう。 ▼定年という壁 　ところで、私が定年を迎えて技術者としての職を辞さねばならなくなったとき、自分ではまだまだ技術者として生きていけるのに、と悔しい思いをしたことを覚えている。しかし今の社会はそういう制度になっているのだから仕方がない。更に続けたければ自分で会社を興すしかないのだろう。そういう才覚のない私めは、定年がなく長く続けられる仕事として芸術家の道を選べばよかったと思ったものだ。あるいは小説家になるという手もあった。たとえ売れない作家であっても、定年がなければ自分の気の済むまで仕事を続けられる。 　私はこれまでの経験から「プログラミングというのは文章を書くのと同じことだ」と思うようになっていた。「自分の考えを抜かりなく、誤解の余地なくしっかりと相手に伝える」ことができればよいのだと。それなら私にも続けられる。小説家になろう。いや、小説家にならなくても、プログラミングの道があるじゃないか。 ▼昔プログラマ 　これ以後、私は大学教師としての職についたのだが、同時に「昔プログラマ」を自称するようになった。昔はプログラマだったが、今はもうプログラマではありませんよ、という意を込めた積りだった。しかし本当のところは「プログラマ」という肩書に執着していたのかもしれない。 （図：名刺） 　大学教師というのは実は世を忍ぶ仮りの姿であって、本当のところはこっそりとプログラマの積りになって、プログラム作りを続けてきたのである。教師としての自分の身辺で発生するいろいろな問題の解決にコンピュータを利用してきた。しかし誤解の無いように記しておくが、自分の身辺に係わる問題だけが対象であって、他人のための仕事をしてきた訳ではない。 　教材として使うテキストの作成、課題提出システムの構築、その他自分の趣味に関係するゲームプログラム(！)の作成も含まれている。金儲けが目的ではないから、自分に関心のあることだけを、誰の許可を得るまでもなく自分だけの判断でできるのだ。これほど自由な仕事はない！ 　その間、いろいろなプログラム言語を勉強し活用してきた。C/C++, Perl, Javascript, VBA, ...。 ▼ソフトウェア危機 　昔「ソフトウェア危機」という言葉が叫ばれるようになった時代があった。コンピュータが強力になり、大きなソフトウェアの開発が必要になってきたのである。この調子で進むと沢山のプログラマを養成しなければならない。いや、日本の全国民をプログラマにしてもまだ人数が足りなくなると予想される事態になったのである。全国民であるから当然、赤ん坊も人数に含まれていた。 　赤ん坊プログラマをどうやって教育しようと考えていたのか、そこのところは明らかでないが、この問題提起のお蔭で「ソフトウェア工学」という分野が切り開かれ、当面の危機を免れることができたのである。 　このときは赤ん坊プログラマが話題になったが、流石に高齢者をプログラマにするという発想は出てこなかったと記憶している。何となれば、当時コンピュータの世界では「３８歳定年説」というのがあって、ソフトウェア技術者が４０歳以上でも務まると思っている人はいなかったからであろう。 ▼高齢者プログラマ 　しかし今や、高齢者の雇用促進が求められている時代である。定年後も年金受給が可能になるまでの期間、どのように生活していったらよいかも問われている。たとえ雇用されなくても、有意義に過ごすテーマが必要ではないかと思う。 　私は、高齢者もプログラマを目指したらよいのではないかと提案したい。 　定年後もプログラミングをしたいというような酔狂な人は少ないかもしれないがゼロではなかろう。昔、ソフトウェア技術者だった高齢者にもプログラマとして復活する道があっていいのではないか。 　高齢になっても小説を書き続けている作家は沢山いる。評判になるのはほんの一部の作家だけで、その陰には売れない作家も沢山いるに違いない。 　昔のプログラマにもプログラミングの道があるじゃないか。小説家に劣らず、プログラマになれる人材は沢山いるに違いない。売れない小説家がいるのなら、売れないプログラマがいてもいいじゃないか！ 　しかも、プログラミングはボケ防止に最適なんですよ。 ▼高齢者プログラマの心構え 　高齢者プログラマを目指すなら、次のような注意が必要である。 (1)金儲けは考えない 　高齢者は電話詐欺の餌食になりやすい。自分が作ったプログラムが他人に評価されるのはうれしいことではあるが、他人からの「いいプログラムですね。売れますよ！」とか「買ってくれる人を紹介しますよ」などという甘言に乗ってはならない。したがって金儲けをしたいという考えがあったら止めておくことです。 【注】私は公開するプログラムはすべて無料で使ってもらうことを前提としています。すべてのプログラムには「Copyleft」のマークを付けることにしています。 (2)短編小説をねらう 　企業でソフトウェア開発の経験があったからと言って同じような大型物件の開発に挑戦したりはしない方がよい。あれは大河ドラマのような大長編小説であって、一人で作るのなら短編小説、あるいはショートショート程度にしておくことである。 (3)手頃なプログラム言語を用いる 　使用するプログラム言語は、若い時代に使用した言語が馴染み易くていいかもしれない。しかしできるだけ無料で手に入るものに限定すべきである。 【注】私は６０歳代になってからＰｅｒｌを勉強しました。文法規則を守り厳密に記述しないと受け付けないモードと、いい加減に書いて「良きに計らへ」とシステムに任せられる怠け者向きのモードがあって、私のような怠惰な男には最高の言語なんです。お奨めしますよ。 ▼作品の公開 　私の作品は、以下の場所に公開されています。参考にしてください。 　「Perl Program集」 「昔プログラマ」改め「昔も今もプログラマ」 ■

(昔プログラマの) プログラミング奮戦記（その２）

── JPEGファイルの解剖と解析 ▼JPGファイルの解読 　先の「JPEG画像から縦横のサイズを取り出す(昔プログラマのプログラミング奮戦記)」で紹介したようにデジタルカメラに記録された画像データから、付随する情報を読み取るプログラムをＰｅｒｌ言語で記述しようと試みてきた。この種のファイルはJPEGファイルと呼ばれているが、いろいろな形式がある。ここでは、Exifファイルフォーマットと呼ばれ規格化されているものを対象としている。 ▼Perlプログラムでの処理 　先に紹介したプログラム(*1)の中で使われている GetJPGsize という関数を使うことにより、画像の横の長さと縦の長さを求めることができるようになった。 　これが使えると、手作業によらないで沢山の画像ファイルに対し一括して適用できるようになり大変な省力化になる。しかし残念ながらこの関数の記述では、複数のJPGファイルに対し繰り返し適用しようとすると２度目以降はうまく動作しないという不都合が発生してしまう。つまりこの関数では、繰り返し同じ機能を発揮してくれないのである。 　プログラミングの世界では、こういう状況を「reusableでない」と言う。reusableでない関数は、全くとは言わないまでもほとんど利用価値がない。 【注】(*1)これまで、GetJPGsize.pl というファイル名にしてきたが、関数名とファイル名を区別するため、以後ファイル名は AnalizeJPG.pl とする。 　不都合が発生する原因をいろいろと追究してきたが、原因は未だに解明されていない。文字コードを扱うのが専門のPerlという言語で、無理やり処理しているのが原因なのかもしれない。Perlでこの種のデータをただやみくもに読み込んだりすると、データの一部が壊される可能性があるからである。たとえばデータの中に改行コードがあると、Perl処理系は実行環境に合わせて変換するのが普通である。 　Perl では改行は '\n' と表現されるので，一文字から成るように見えるが、実行環境によっては１文字（CR）の場合、あるいは２文字（CR+LF）の場合と違いがある。それぞれに実行環境に合うよう自動的に置き換えられる。したがってただ無暗に読み込んだりすると、たまたま制御コードと同じパターンのデータがあれば、誤って変換され結果としてデータが壊されてしまうことになる。そういうことにならない様、ここではライブラリ関数の read ではなく sysread の方を用いることにした。更に、データ構造をしっかりと確認し、画像を構成する本来のデータ部分はできるだけ触れない（読まない）ようにすることにした。 ▼JPGファイルの構造を学び直す 　ここで、JPGファイルの構造をしっかりと学び直すことにした。 　インターネット上で「JPGファイルの構造」とか「Exifファイルフォーマット」を指定して検索すれば有益な情報が得られる。 　現時点で公表されている資料では、Exifファイルフォーマットのバージョンは v2.1 と記されているものが最新のようである。残念ながら私の使っているカメラでは、Exifファイルフォーマットはv1.1であるから古い仕様であることが分かった。 　素人カメラマンの私にとって、ファイルフォーマットが古いからと言ってそう簡単にカメラを買い替える訳にはいかない。したがってここでの説明は最新の仕様に沿うものではないので、もしかすると互換性がない部分があるかもしれない。以下は考え方だけを理解してもらえばよいので簡単な説明で済ますことにしよう。 ▼解剖と解析 　方針として、先ず全体の「解剖」(JPGvivisect.pm で処理)を行って、その後で個々に「解析」(AnatomyJPG.pl で処理)するという手順を取ることにした。ただし、呼び出しの手順は AnatomyJPG.pl から JPGvivisect.pm を呼び出すようになっている。 （図１：処理の手順） 　JPGファイルでは、本来の画像データの前に情報セグメントが複数個置かれている。 （図２：JPGファイルの構造） 　この「情報セグメント部」に属する「各情報セグメント」の「種類」と「位置関係」を明確にする必要がある。つまり解剖して各セグメント(内臓)の種類と位置と寸法が分かるようにする。そして全体の骨格が明確になった後で、初めて個々のセグメントの中を解析することにする。 ▼解剖プログラム(JPGvivisect.pm) 　解剖プログラムは最も基本的なプログラムなのでパッケージ化し、ライブラリとして使えるようにしてある。 　この「解剖結果」を記憶する場所として %HashTBL という名のグローバルなハッシュ変数を用意する。グローバル変数なので他のモジュールからもアクセスできるようになっている。 　各セグメントは先頭にはマーカー(２バイト)があり、次に長さ情報(２バイト)が置かれている。この値がマーカーに続く情報部分(セグメントパラメータ部)の長さである。つまりこの２バイトの長さを置く場所も情報部分に含まれる。 （図３：セグメントの構造） 　%HashTBLというハッシュ変数をどのように使うかを説明しよう。 　ハッシュ変数というのは、＜キー＞と＜値＞を対にして記憶するものであるが、%HashTBLでは＜キー＞として JPGファイルのセグメント情報を示す「マーカー」を利用する。＜値＞としては、そのマーカーの＜位置情報＞を記憶する。 （表：代表的なマーカーの一覧） Merker Code SOI(Start of Image) FFD8 APP0(JFIF) FFE0 APP1(Exif) FFE1 APP1(Exif) FFE1 DQT(Define Quantization Table) FFDB DQT(Define Quantization Table) FFDB SOF0(Start Of Frame 0) FFC0 DHT(Define Huffman Table) FFC4 DHT(Define Huffman Table) FFC4 DHT(Define Huffman Table) FFC4 DHT(Define Huffman Table) FFC4 SOS(Start Of Scan) FFDA EOI(End Of Image) FFD9 　ただし、同じマーカーが繰り返し登録される可能性もあるので、＜位置情報＞には登録個数とそれぞれの位置情報を保存できるようにする。そのため、値はリスト形式にしてある。 　　( [0], [1], [2], [3], .... ) [0]に登録個数、[1]以降に位置情報が置かれる。 　最初に 　　$HashTBL{ ＜キー＞ }[0]; とするとマーカーが%HashTBLに登録され、値を置く位置の[0]はまだ空であるがPerlでは空はゼロと解釈されるので、 　　$i = ++$HashTBL{ ＜キー＞ }[0]; と書いておけば [0]の値が 1 に、$i にも 1 が代入される。 次の行の 　　$HashTBL{ ＜キー＞ }[$i] = ＜位置情報＞; で＜キー＞に対応する＜位置情報＞が[$i]つまり[1]の位置に保存される。 以下同様にして、登録のたびに[0]に個数が それぞれの位置情報が[1],[2],[3],[4],... に保存されていく。 ▼解析プログラム(AnatomyJPG.pl) 　解析段階では、この解剖段階で得られた情報を使って一般の利用者（カメラ愛好家）が必要とするであろう各種情報を得られるようにする。得られた「解析結果」は %DataTBL という名の、これもグローバルなハッシュ変数上に保存し共用されるようにする。 　解析結果を記憶したければ、適当に識別名を付けて値を代入すればよい。 　$DataTBL{'File Name'} = "$fileString"; 　例えば、SOF0('FFC0')マーカーに属するデータを得たければ 　$pos =$HashTBL{'FFC0'}[1];   として'FFC0'マーカーの位置情報を取り出し getByte関数を使ってセグメントパラメータ部から値を取り出す。 　$H = getByte($pos+5,2); 　$W = getByte($pos+7,2); 　これらを $DataTBLに保存するときは、数値にコンマを挿入(insCom関数)したり、数値の単位も合わせて記録しておくと利用するときに便利である。 　$DataTBL{'横幅'}=insCom($W)." Pixel\n"; 　$DataTBL{'高さ'}=insCom($H)." Pixel\n"; 　詳しい技法については、 　　解析プログラム(AnatomyJPG.pl) や 　　解剖プログラム(JPGvivisect.pm) を参照してください。

新【悪魔の辞典】(8) 総理の友人

●総理の友人：
(1)こまったちゃん

(2)自分の言いたいことだけ言って、相手の話は聞かず、質問には答えないで逆に個人攻撃で返す、そういう性格の持ち主と（例外的に話ができ）頼み事さえも聞いてもらえる人

(3)「総理夫人の友人」とほぼ同義

(4)罪を犯しても訴えられることはない、と当初は信じていられる人

(5)中には、借りた金百万円を返そうとしても受け取ってもらえないという幸運な人もいる

【注】「総理の友人」に相応しい“意味” を募集したところ、残念ながら応募はありませんでした。多分、官邸の方から何らかの圧力があったのではないかと思います。

マンホールの蓋が新しくなった

　家の周辺道路で、最近マンホールの蓋が新しいものに交換されつつある。今日、いよいよ我が家の前の道路上でも、その交換作業が始まったようである。

 　私は直前になって、記念のため古い蓋の写真を撮っておきたくなった。家の前ではもう作業中なので、隣の家の前にあるまだ交換作業に取り掛かっていない場所にあるマンホールの写真を撮ることにした。

　すると作業主任らしき人が近づいてきて挨拶をしてくれた。いい機会だと思い、いろいろ聞いてみた。

　新しいマンホールの蓋の文様を尋ねたら「普通のものですよ」とのこと。あの「ツツジ」と「ツバキ」の川崎市の新しいバージョンを期待していたのでちょっとがっかりしたが、途中用事があり外出から帰宅すると新しいものに交換されていた。見ると、やはり「ツツジ」と「ツバキ」の新しいバージョンだった。作業主任は「カラー版ではない普通のもの」という意味で言ったらしい。

　中央にある市の花「ツツジ」を、市章と７つの市の木「ツバキ」が囲んでいる。ツバキの数は７つの区を表しているらしい。花には７つの穴があるので雨水用マンホールであることが分かる。下部に「傘のマーク」と「16-M01」の文字が入っている。

　その下にある白いものがカギらしい。古いマンホールは自由に開けられたが、これは特別な工具がないと開けないようになっている。テロ行為に利用されないよう配慮されている。大雨でマンホールの蓋が飛ぶ事故がよくあるが、そういう心配はなくなったことになる。

　最近は、地域ごとに斬新なデザインのマンホールを作り互いに競い合っている。その写真を蒐集しているマニアもいるようだ。以下に示すようにカラー版にもいろいろなバージョンがある。私も蒐集してみようかな、とふと思った。

新幹線を利用して

── 自動改札・券売機と格闘する 　名古屋での法事に出席するため新幹線で日帰り往復することになった。恥ずかしながら、私にとっては久しぶりの新幹線利用だったので自動改札や券売機と格闘することになった。その顛末を記しておこうと思う。 ▼乗車ルート 　私は、新幹線で東京から関西方面に行くときは何時も新横浜駅から乗ることにしている。これが一番早くて運賃も安い。先ず、家の近くのＪＲ南武線の駅から乗車し、武蔵小杉経由で東横線に乗り換える。そして菊名駅からはＪＲ横浜線で１駅の新横浜駅で降り新幹線に乗車するというコースである。 　会社勤めをしていた頃は、先ず菊名までの乗車切符を買い、新横浜で乗り越し精算をしてから切符売り場の窓口で駅務員から直接新幹線切符を購入していた。手際よくやればこれで十分に間に合っていたのである。 ▼切符とＩＣカード 　その後、技術が進み切符に代わってＩＣカードを使う時代となった。しかし頑固な私めは、それでもずっと切符を買うことに拘ってきたのである。 　消費税が上がり１円単位で運賃に付加されるようになったとき、何故か切符購入者だけは１０円の単位まで切り上げられるという差別を受けることになった。その結果、ＩＣカード利用者よりも損をする立場になってしまったのだ。頑固な私めもさすがにこの差別には耐えられず、諦めてＩＣカード利用者へと寝返ることになった。 　さて、話が本論からそれてしまったように思われるかもしれないが、実はこのＩＣカードと自動改札の相性の問題について私は触れたかったのである。切符を利用する場合は問題ないのだが、ＩＣカードでこの「私の新幹線乗車ルート」を利用するとき、果たしてうまく通過できるかどうか少し心配になってきたのである。 ▼自動改札という関所 　周知の通り、ＩＣカードでは自動改札から入場したときに料金計算がスタートするが、未払い状態のまま乗車していることになる。降車駅の自動改札から退場するときに初めて料金が確定し支払い完了となる。乗り継ぎで利用する自動改札という 関所 でも同様に処理が行われている。途中の関所をいいかげんに通過することは許されない。 　一方、切符の場合は最初から前払いされているから、今までは途中の関所の通過がそれほど厳密にチェックされることはなかった。どんなルートを取ろうとも、最終的に降車駅で切符を見せれば不足分は精算されるから何となく心理的には楽であった(こちらは別に不正行為をはたらいている訳ではないのだが)。新たなＩＣカード利用者にとって、乗り継ぎで関所を通過する際は未払い状態のチェックが必要になるから切符の場合よりも緊張を強いられるのは避けられない。自分の行為に何かミスがないか、常に注意していなければならなくなったのである。 ▼不正行為の扱い 　実は、私は企業での在職中、自分の守備範囲の中に自動改札システムのソフトウェア開発を担当するグループを(一時的だが)抱えていた時期があった。私は技術的な詳しいことは知らないが、耳学問でいろいろな知識を得ていた。 　自動改札では、どんな種類の不正行為も必ず発見することができるという。ただ、不正を発見しても常にそれを指摘して乗客を捕まえる訳ではない。不正行為の回数がある程度の限界を超えたとき、初めて駅員が後ろから「もしもし」と肩を叩きながら呼び止めて事情を聴くことになるのだそうである。 　部下がそういう仕事をしていると、上司である私も自動改札を通過するときは常に「模範的な乗客」を演じる必要があった。「不正行為など以ての外」と心して通るようになったのである(もちろん普段でも不正行為はしていませんけどね)。自動改札の周辺で挙動不審者とみなされることも避けなければならない。そういう訳で、私にとって自動改札とは「模範的な態度」で、流れに乗って「素早く通り抜ける」べき場所だったのである。 ▼切符を予約 　出発当日は朝の早い時間に出掛けるので、ラッシュアワーの混雑に不慣れな年寄りが新横浜の駅で新幹線切符を購入するというのは少し無理がある。そう考えて安全のため前日に切符を予約することにした。 　前日の午前中に隣り駅の「みどりの窓口」へ行くと、既に長い行列ができていて１３名ほどの人達が並んでいた。やれやれと思ったがこれは私も並ぶしかない。しばらくすると、若い駅務員が回ってきて列に並んでいる人達に順に行き先を聞いてはメモしてくれている。手続きを迅速に済ませるためなのであろう。私も行き先を伝えると、ルート間に私鉄が入るので１枚の切符にはできないと言う。菊名から名古屋までの切符だけになります。それなら、あちらの自動券売機で簡単に買えますよ、と外にある切符売り場の方を指さすのであった。 ▼自動券売機に挑戦 　そう言われると「できません」とは言えないので、私は外に出てタッチパネル式の券売機に挑戦してみることにした。 　やってみて驚いた。何でも指定できるようになっているではないか（当たり前だが）。色々な選択肢があるので今までは敬遠し、人の居る窓口で口頭で自分の意思を伝えていたのだが何でも指定できるようだ。座席指定では座る位置まで含めてすべて自分で指定できるようになっていた。今までは、回数券とか、観光地で利用すると便利なフリーキップとか、割引で得することが分かっているものでなければ決して手を出さなかった機器が、かなり身近なものに感じられるようになった。 　こうして無事に名古屋までの片道切符を手に入れることができた。ただ、支払いを「クレジットカードで」と指定したところ、パスワード入力を求める画面があの大きなタッチパネル画面に大写しになったときは驚いた。多くの人々が後ろから見ている前で、私は自分の「極秘！のパスワード」を入力しなければならなかった。初めての経験であった。 ▼関所を通る（往路） 　さて、いよいよ当日になった。菊名までは順調であった。私が心配していたのは、東横線の菊名駅から横浜線へ通じる自動改札がどうなっているか、ということだった。ＩＣカードと新幹線切符をどう扱えばよいのか分からなかったのである。表示を確かめながら無事に横浜線に通じる専用の自動改札の場所を見つけた。 　何やらアナウンスされているようだ。改札機へ投入する順番を教えてくれているらしい。日本語の堪能な！私めは「最初に切符を」、「次にカードを」と言っていることを素早く察知したのである。自分の予想とは逆だったが、そんなことは先刻承知と何食わぬ顔をして「先ず切符の投入」、「次にカードの接触」の順に対応することにより無事に関所の第一関門を通過することに成功したのである。 　人の流れに乗って素早く自動改札を通過しながら私は考えていた。なるほど、こうすればよいのか。帰りの関門通過も同じ要領でやればよいのだな、と。 ▼関所を通る（帰路） 　法事も無事に終り、３時過ぎに帰路についた。 　名古屋駅に戻り新幹線の切符売り場で再びタッチパネル式の券売機の前に立った。今度は「名古屋から新横浜、更に横浜市内(つまり菊名)まで」という指示をして座席指定の切符を無事に手に入れることができた。いいぞ、この調子だ。こういうことをスマートにできなくなると、やがてボケが始まるのだろうなどと考えていた。 　新横浜駅には５時過ぎに到着し無事に下車。横浜線で再び菊名駅の東横線に乗り換えるための自動改札という関門前にやってきた。帰宅する人々で改札前は混んでいるが、今度は、今朝学んだばかりのことを応用すればよいのだと気楽に考えていたのである。 　先ず自動改札に新幹線切符を挿入した。すると何んとしたことか！　ゲートが音を立てて強制的に閉じられてしまった！！　そして切符の排出口から、私が投入したばかりの新幹線切符と、更に何故か普通の乗車切符(140円分)が１枚添えられて出て来たではないか！！！　何だ、これは？ 　私は大いに動揺してしまった。排出されたばかりの新幹線切符には赤で何か印刷されているように見えた。しかし自動改札という関所は常に 素早く通り抜ける を信条としている私めは、それを確認する余裕はなく排出された切符類を掴み取ると素早く自動改札の流れから離れることにした。そして５メートル程横にある駅務員がいる窓口へ持っていくことにした。 　駅務員は心得たもので、私が何も言わないうちから素早く新幹線切符だけを回収し、１４０円の乗車切符の方を手近な自動改札機の挿入口に入れて、私に向かってさあ通ってくださいと合図したのである。私は、ここでＩＣカードをタッチすればよいのですね、と確認してから通り抜けたのである。 ▼私の推測 　しかし分からない。何がどう処理されたのか理解できないままであった。以後、家に着くまでの間今の出来事をどう解釈すればよいのか考え続けることになってしまった。あのとき新幹線切符に赤で何か書いてあったような気がするのだが確かではない。しっかりと確認すればよかったと思ったがもう後の祭り。後は推測するしかない。 　多分、こういうことではないかと思う。 　ＪＲ側はこの関門で新幹線切符を回収しなければならない。しかし乗客(私)に何か菊名駅通過の証明書となるものを持たせる必要がある。乗客が東横線に乗って行くのなら、到着駅で清算できるように菊名駅通過を証明できる１４０円切符(使用済み！)が必要になる。あるいは、東横線に乗らずにそのまま菊名駅の改札から外に出ることもできる。そのための証明書だったのではないか。 　もしこの推測が正しいとすれば、私が最初に新幹線切符を挿入したときそのまま回収し、排出口からは証明書として１４０円切符を排出すればよいのではないか？　何故そうしなかったのか。分からない。 　多分、その小さな切符の排出に気が付かずそのまま証明書なしで通過する乗客が出るのを恐れたのかもしれない。つまり乗客を信頼していないのであろう。どんな乗客にも対処法がすぐ分かるようなシステムであって欲しいものだ。 　そう言えば、あのときの１４０円切符はどうなったのだろう。全く忘れてしまっていた。私はＩＣカードを持っていたから不用だったが、・・・。そうか、こういう不注意な乗客が多いことを考慮して作られたシステムだったのかもしれない。 　いずれにしても、これから東京五輪・八輪(ゴリン・パリン)のために来日するであろう諸外国の人々に容易に理解できるようなシステムであってほしいと思う。それが本当の「お・も・て・な・し」というものであろう。■

高齢者

── 電車で席を譲られる 　人間誰しも、何時かは経験しなければならないと覚悟を決めていることがある。それもあまり歓迎したくない事である場合が多い。そういう事態が突然我が身に訪れた。 　電車に乗っていて席を譲られることを始めて経験したのである。もちろん、これまでにも席を譲られたことはある。しかし明らかに高齢者であるという理由で譲られたことはなかったと思う。私の年齢からして何時かはそういう事態になることは当然予想されていた。それが現実のものになっただけのことで、そんなことは常に“突然”起きるに決まっていると言われるかもしれない。しかし私にとっては“突然に訪れた”と表現したくなるくらいショッキングな出来事だったのである。多分、心底では“予想したくない”出来事だったからであろう。 　そのとき私は、何時もの通り急行に乗って３つ目の駅で降りる積りだったから乗車時間は１０分も掛からない。少し混んでいたので入り口から奥の方へと移動した。私が立った位置の前の席では女学生が熟睡している。その右側の席では３０歳代と思われる外人の若者がイヤホーンで熱心に音楽を聴いている様子。私は吊革につかまりながら車窓から外を眺めることにした。 　電車は２つ目の駅を過ぎ、次は私の降りる駅になるがこの区間は急行が止まらない駅が続くので比較的長い区間である。突然、右の席の若者が「はっ！」と言うような声を発し突然立ち上がった。乗り越したことに気が付いたという風に見えたが「どうぞ」と言う声がした。私の右側に立っていた女性に席を譲るのだなと思ったが、そうではなく彼の視線は私に向いており私に席を譲りたいと言っていることが分かった。その瞬間、私はかなり動揺した。沢山の乗客が居る中で一番の高齢者と指摘されたような気がしたのである。「いや、結構です」といったんは断ったが、尚も勧められたのでその好意を無にするような失礼があってはいけないと思い「ありがとうございます」と言って座ることにした。すると若者は「ドウイタシマシテ」と返してきた。 　私は、海外から来た留学生が礼儀正しい日本人の中で生活するためのマナーをしっかりと学習しそれを実践している場面を(勝手に)想像していた。「次、降りますから」などと言って断り、折角の好意を無にしている人をよく見かけていたので、ここは日本人として彼の好意をしっかりと受け止めてあげなくてはいけないと思ったのである。 　実は「電車で席を譲る」という行為については以前から考えていたことがあった。以前教師をしていた頃、「情報倫理」の授業で毎年学生に課すレポートのテーマとして「自分の倫理観がどの程度のものか、自身の経験に照らして記述せよ」という課題を出していたのである。そして“自身の経験に照らして”と“手書き”でＡ４用紙一枚にまとめるという２つの条件を付けることにしていた。こうすると、学生が得意とする「コピペ」という行為がし難くなるのを経験的に知っていたからである。「ＣＤの不正コピー」とか「ソフトウェアの不正使用」とか、学生の立場でも法に触れるか触れないかすれすれのテーマはいくらでもある。そういうテーマを取り上げてくれることを期待して課題設定しているのだが、案に相違して学生たちは「倫理」の意味を拡大解釈し「道徳」の分野に属するテーマばかりを取り上げてお茶を濁そうとする者が多かった。その際に、彼らが取り上げるテーマが横断歩道での「信号無視」と、この「電車で席を譲る」だったのである。 　私は、若者たちのそういうレポートをいやと言う程沢山読まされてきているので、最近の若者たちの電車で席を譲る行為についての考え方を知悉していた。要するに彼らは電車内で席を譲ることができないのである。「譲ろうか、止めようか」で迷う。迷ったら先ず実行されない。この外人の若者は直ぐ決断したのに、日本の若者はそれがなかなかできないのはなぜか。なぜ迷うのか、なぜ躊躇するのかというと、自分が周りの人から「いい子ちゃん」を演じていると思われたくないからなのだと言う。つまり「いい子ぶりっこ」と思われたくないのだそうである。周りの人の思惑ばかり気にしている若者が多い。「こうすべきだ」と思ったら断固実行する人が少ない。まず「周りがどう見るか」を気にしてしまうらしい。 　高齢者や身障者あるいは妊婦らしき人を見つけると、高齢者の私でも席を譲ろうとする。そのときのコツは「譲ろうか」という考えが頭に浮かんだら、迷わず立ち上がることだと思ってそれを実践してきた。あの若者も譲ろうと判断して即座に立ち上がったように見えた。日本の若者たちもこれを見習うべきであろう。 　ただ、あの若者の判断の内、相手が高齢者かどうか判断する能力だけはもう少し磨きをかける必要があるのではないかと思う。日本では高齢者かどうかの判断は大変に難しい。何しろ日本では、経済状況の変化によって「高齢者」の定義が恣意的に変わってしまう可能性がある珍しい国だからである。 　私自身も、高齢者とみなされないように精々努力することにしよう。 　私は、譲られた席に座ったまま尚も考えていた。席を譲ったのに直ぐ立ち上がり電車を降りてしまったのでは彼もがっかりするかもしれない。この区間が少し長かったことで少しは救われるかな、等と考えている内に電車はようやく駅に滑り込み、ホームに到着しようとしていた。丁度良い間合いだ。私は席を立つ際にその若者に向かって「ありがとうございました」と声を掛けてから電車を降りたのであった。私も、彼も(多分)お互いに少し良い気分になれたような気がした出来事であった。■

桶屋が儲かる (1999-05-01 掲示の再録です)

・1999-05-01 社内情報誌に掲載 ・1999-11-15 個人ホームページ(Knuhsの書斎)に掲載

── デバッグのやり方 　春一番の吹く季節がやってきた。 　寒い冬が過ぎて春が来るのだから、誰もが心浮き立つような気分になるはずだが、私にとっては一番耐えがたい季節の到来である。それは私が花粉アレルギー症だからである。杉花粉に悩まされているのは私だけではなかろう。毎年の春の行事の一つだと考えてしまえばそれはそれであきらめもつく。薬をのんだりマスクをするなりして自己防衛すれば、杉花粉くらいは何とか乗り切ることもできる。 　しかし五月頃に起こるアレルギー症状には何とも耐えられないものがある。私の場合のアレルゲンは“オオアワガエリ”と呼ばれる道端のどこにでもある雑草なのだ。五月頃になるともう戸外でマスクなどしている人はいないから、自分だけマスクをするのは何となくはばかられて、どうしてもやせ我慢をしてしまう。その結果、呼吸困難になって入院するはめになった年もあるほどなのだ。 　ところで、春の風が吹く季節になると私はいつもある言葉を思い出す。それは「風が吹けば桶屋が儲かる」というあれである。この言葉の意味するところは「思わぬ結果が生じる」あるいは「あてにならぬ期待をする」ことのたとえであると言われている。だが私は、これは我々が携わるソフトウェア開発という仕事、とりわけプログラミングのデバッグ作業と密接に関係している言葉のように思えてならないのである。 　そもそも、なぜに桶屋が儲かったのかというところから問題を掘り下げてみましょう。それはもちろん桶屋の商売が繁盛したからなんです。 　なぜ繁盛したんですか。 桶を買う人が増えたからでしょうね。 　なぜ増えたんですか。 無論、桶がだめになったから買い替えが必要になったんですよ。 　じゃ、なぜ桶がだめになったのか調べないといけませんね。 それは、実は鼠が桶をかじったからであることが分かっています。 　なるほど。じゃ、なぜ鼠が桶をかじったりしたのでしょうか。 それはですね、鼠が異常に増えたからなんです。 　あぁ、なるほどなるほど、そういうことですか。 　感心していてもはじまらない。今度は鼠がなぜ異常に増えたのか、その理由を調べなければいけないですね。 そうです。いろいろ調べてみると鼠が増えた理由は、実は鼠を獲る猫が減ったのが直接の原因であることが分かってきたんです。 　ほ～、それでは、今度はなぜ猫が減ったのかを追求する必要が出てきましたね。 そうなんです。ところが、意外なことにそれは猫を捕獲する人が増えたからだということが分かってきたんですよ。 　へぇ～、そいつは驚いた。なぜに猫を捕獲する人がそんなに増えたんですか。 それそれ、そこが一番調査の難しかったところなんです。実は猫の皮なんですよ、問題は。三味線に張る猫の皮が大量に必要になったんです。 　何と！三味線ねぇ、よくそこまで分かりましたねぇ～。なるほど、なるほど。 　それでは、きっと三味線が大量に売れたんでしょう。 そう、そうなんです。実は眼に障害のある人が増えたので、その結果三味線をひく人が増えたといわれています。 　どうも、昔の話なので現代では到底理解できないことですね。 　それで分かりましたよ、なぜ眼に障害のある人が増えたのか。多分風が吹いて砂ぼこりがまったんでしょう。その結果眼に障害のある人が増えたということでしょう？ ご明察！　ちょっと論理に飛躍がありますがね。実はそのとおりなんですよ。 　それでやっと分かりましたよ。桶屋が儲かった原因は、風が吹いたことが本当の理由だったんですね。 　‥‥という訳である。 　プログラム作りのテスト段階で不具合が発生した場合、一般にその原因の究明は大変に難しい（もちろんプログラムの程度にもよるが）。多くのプログラマは、日夜“デバッグ”と呼ばれる困難で孤独な作業に取り組んでいる。そういったデバッグ作業では、不具合の直接の原因Ａを見つけてもそれで問題が解決する訳ではない。その直接の原因Ａが予想外の現象であるならば、今度は再びそれを引き起こした原因Ｂを追求しなければならないのである。そして原因Ｂが見つかったら、今度は（多分また）原因Ｃを捜すことになるであろう。そのようにして原因Ｄ，Ｅ，Ｆ，‥‥を捜し続けるのである。最終的に原因Ｘ（それ以上はさかのぼるべき特別な理由がないもの。大抵は設計のし忘れなど）を見つけるまで。 　つまり、桶屋が儲かったという事象から始めて、風が吹いたという原因にまで逆に（１点の飛躍もなく）一つ一つたどっていくという、いわゆる“推理作業”を行わねばならぬのである。そして、風が吹いたという最終的な原因Ｘを捜し当てたら、今度は風Ｘから桶Ａに向かってもう一度たどっていく。そして不具合のすべての兆候が、それで完璧に説明がついて初めて（デバッグ作業では特にこれが重要なのである！）その障害の原因が完全に究明されたと断ずることができるのである。 　もちろん、その障害を修復するにはまた別の努力が必要であることは論をまたない。つまり風が吹かないようにするか、あるいは風が吹いても砂ぼこりがたたないようにするか、とにかく何らかの対策が別途立てられなければならない。プログラマとは誠に難儀な商売ではある。 　現在のようにコンピュータ資源が十分でなかった時代には、自分に割り振られたコンピュータ使用時間が来るまで（それも僅かな時間しか割り振られないのだが）机上で上記のような推理を働かせたデバッグ作業を繰り返したものである（これを机上デバッグと称する）。そして時間が来ると、その限られた時間内の実機テストで確認するという手順になっていた。机上デバッグが不十分だと必ず実機テストに失敗し、また出直しとなってコンピュータ時間の確保から始めねばならぬのである。 　最近のプログラマは、コンピュータ資源を豊富に与えられているので何時でも実機テストができる。その結果、十分な推理作業を行わずに絨毯爆撃でいろいろと試しては結果を見るというデバッグ姿勢を取りがちである。桶屋が儲かったのは、多分雨が多かったためではないか、あるいはエルニーニョのせいではないか、‥‥などといろいろとやってみるのである。これだとコンピュータ使用時間がいたずらに増え、結局能率が悪くなってしまう(*)。 【注】(*) もっとも、そうやって徹夜をしているプログラマの方が管理者の目には熱心に働いているように見えるのだからソフトウェア稼業というものは実に難しいものである。 絨毯爆撃で運良く解決したように見えても、別のケースで再び問題が顕在化するかもしれない。根本的な解決をはかるには、やはり完全な推理作業に取り組むべきではなかろうか。豊富なコンピュータ資源は、推理作業を助けるデータの収集にこそ向けられるべきであろう。そしてピンポイント爆撃で一発で虫を退治したいものである。 　そういう完璧な推理作業を繰返してプログラマとしての経験を積んで行くと、いつか「桶屋が儲かった」ら即座に「風が吹いた」に違いないとピンとくるようになるのである。こういったベテランの勘は大事にすべきであろう。しかし経験を積んでいない者の勘は、単なる“カン”であって信用するに足らない。 　気象の世界では「風が吹けば桶屋が儲かる」に相当する言葉は「東京で一匹の蝶が羽ばたけば、一ヶ月後にニューヨークに雨が降る」というのだそうである。私は持ち前の好奇心から、どうして東京からニューヨークまでつながっているのか、その流れを追ってみたくなった。そこで、博識をうたわれているお天気キャスターの森田正光氏にＴＢＳラジオ局を通じて質問のメールを送ってみた。しかし数ヶ月過ぎても何の回答も得られない。彼にも分からぬことがあるのであろう（しかし返信なしは気に入らん）。私はこの問題の解明作業を今後も続けようと思っている。ご存知の方は是非ご教示いただきたい。■ 【追記】 　この拙文に対しては多くの読者から反響があった。私信なのでそのまま掲示することはできないが、「東京で一匹の蝶が羽ばたけば、一ヶ月後にニューヨークに雨が降る」（これを、一般には「バタフライ効果」というのだが）について、「北京で今日蝶が羽を動かして空気をそよがせたとすると、来月ニューヨークでの嵐の生じ方に変化がおこる」ではないかという指摘があったことだけは報告しておきたい。カオスの話では必ずと言っていいほど引き合いに出される話なのだそうである。しかし、その間のつながりがどうなっているのかは、相変わらず分かっていない。 【追記】2008-5-20 　アメリカのマサチューセッツ工科大学名誉教授のエドワード・ローレンツは、60年代の初めに天候の変化をコンピュータで再現する実験を繰り返していた。あるとき、“0.50612”と打ち込むべきところを、丸め(四捨五入)て“0.506”という数字を使ったところ打ち出されたグラフは数字を丸めなかったときとは大きく異なるものとなった。半端な数を切り捨てるかどうか。それは小さなチョウが舞うか止まるかの違いに似ている。チョウの羽ばたきが地球規模の気象を左右することもある。そんな「バタフライ効果」という言葉が広まったのはこの体験がきっかけであったという。この効果は、物事が複雑に揺れ動く「カオス」と呼ぶ現象のなかで表れる。自然界はそんな複雑さに満ちている。(朝日新聞の記事から引用)