1997年04月07日：「十一ぴきのネコ」
1997年04月08日：“工数”について
1997年04月09日：「プログラム書法」「ソフトウェア作法」
1997年04月10日：いしいひさいちと、ソフトウェア・テスト
1997年04月11日：運転中の意識の空白
1997年04月12日：フォトン・ベルトの脅威
1997年04月13日：彗星とスパゲッティ

1997年04月07日：「十一ぴきのネコ」

　パソコンショップ・コムロードから電話。リブの修理上がりは今週末になるそうである。修理に出したのは３月１７日。ほとんど一ヶ月かかった訳だ。

　図書館から借りたままになっていた、井上ひさしの「十一ぴきのネコ」を読む。ほとんど驚愕に近い感動。この愉快なミュージカルが、まさか、こういう結末を迎えるとは．．エピローグに至って、思わず涙がこぼれた。（会社で休憩時間に読み終えたので、涙目をごまかすのに、苦労した。）やはり、井上ひさしは、凄い。

1997年04月08日：“工数”について

　“工数”という用語（概念）を、初めて知ったのは、学生時代である。確か「Ｏｈ！ＰＣ」誌か「インターフェース」誌の記事だった。異種ＢＡＳＩＣ間か高級言語か、とにかく、あるソースファイルを別のソースファイルにコンバートするツールを作製する、という話題だったと思う。

　つまりは言語の自動翻訳であるから、完璧なものは（相当な手間暇をかけない限り）できないのである。その記事では、ざっと９０％位のソースコードは自動変換できるところまでこぎつけてから、「工数のバランスを考えて、ここまでとした」と結んでいた。つまり残り１０％は、手作業で書き換えれば良い、という判断である。

　きったねーーっ！　というのが、当時の私の感想であった。要するに不完全な、未完成品ではないか。デスティネーション側のコンパイラで１００％通るソースファイルにコンバート出来てこそ、変換ツールではないか！

　それがとても青臭い（現場を知らない）理想論であったことを、今では無論、知っている。全体の９０％を変換するプログラムを書くのに要する“工数”を１とすれば、残り１０％を変換するためには、５、あるいは１０もの“工数”を要しよう。全体の１／１０の自動処理に、それほどの“工数”をかける値打ちがあるか。つまりは、その変換ソフトを書き始めてから、変換対象の全ソースを（自動処理あるいは手作業で）変換し終えるまでの、“総経過時間”が問題なのだ。

　これと本質的には同じ問題が、文書作製の現場で起こっている。

　大勢の同僚や部下（や上司）が、会議の資料を作るのに、大変な“工数”をかけているのだ。なぜなら、ＭａｃやＷｉｎｄｏｗｓのツール群を使えば、実に美しいプレゼン資料が作れるからである。時間をかければ。

　時間をかけなくても、そこそこ美麗な出力は、すぐに得られる。しかしなかなかそこで我慢できないらしい。手間をかければかけるほど、説得力のある美しい出力が得られるのだから。“必要以上に”美しい出力が。

　ケースバイケースなのである。そのプロジェクトの命運を左右するような、社内（あるいは、社外への）プレゼンであれば、一週間かけて練りに練り上げるがよかろう。しかし、例えば部内のちょっとした打ち合わせであれば、裏紙に鉛筆で書いてコピーすれば十分なのである。必要ならば、あとで清書すれば良い。（そして、結局、その必要がなかった、ということが珍しくないのだ。）

　かつてＬａＴｅＸが一世を風靡した時（今でも使われていると思うが）、本来の執筆作業に加えて、編集者の仕事まで著者が引き受けることになってしまった、という批判がなされたものだ。人間には学習能力がなく、何年たっても、何十年たっても、同じことを繰り返し続けるものであるらしい。

1997年04月09日：「プログラム書法」「ソフトウェア作法」

　ついでに昔話を、もうふたつ。今では全然通用しないであろう話をひとつ。そして今でも、それどころか、今後もずっと通用するであろう話をひとつ。

　私は大学ではＦＯＲＴＲＡＮと（ミニコンの）アセンブラを習った。趣味ではＢＡＳＩＣをやった。そういうバックボーンを持って入社して．．そして最初の１年間（正確には、２年目の最初の頃）、結構暇だったのである。（今では考えられないことだ。昨今の新入社員は、最初から仕事の山である。）そこで仕事中に何をしていたかと言うと、会社に持ち込んだ私物のＰＣ−９８０１Ｆ１（知っていますか、この型番？）に、Ｌａｔｔｉｃｅ−ＣだかＯｐｔｉｍｉｚｉｎｇ−Ｃだかを乗せて（ＯＳは、ＣＰ／Ｍ−８６だったかＭＳ−ＤＯＳだったか、記憶が定かでない）、

「プログラミング言語Ｃ」（Kernighan, Ritchie, 共立出版）

に載っているサンプルプログラムを全て打ち込んで、コンパイルしたのである。確か全部で２７のプログラムのうち、ひとつだけ動かなかったと記憶している。（静的配列の例題だったと思う。）

　これが、私がＣについて書籍で学習したことの、全てである。その他の書籍も参考書も問題集も、いっさい読んだことがない。“原典”を読み、“原典”に記されている僅か２７の例題を手で打ち込んで、コンパイル＆実行しただけ。

　そして、この“原典”は、その“難解さ”で有名であるが．．私は少しも難解だとは思わなかった。確かに、今読み返してみると訳文は明晰でないし、終わりの方の、ＵＮＩＸとのインターフェースに関する説明については、当時は目を通しただけだったのだろうとは思うが．．

　なんとも古臭い学習方法である。丁度、論語を習うのに、訳書も参考書もいっさい読まずに、原文だけを「読書百遍、意、自ずから通ず」と、読み下しているようなものだ。今ならもっと効率の良い、便利な勉強法がある。私は私のやったことを、人に薦めはしない。しかし．．密かに誇りに思っているのも、また、事実なのである．．

　．．という、過去の遺物的妄言の次は、悪いことは言わんから老兵の言うことも聞きなさい的進言である。

「プログラム書法」（Kernighan, Plauger, 共立出版）
「ソフトウェア作法」（Kernighan, Plauger, 共立出版）

　この聖典２冊を、今の若い人たちは読まないらしい。

　とんでもないことである。

　読まない理由は、「書法」の例題の多くがＦＯＲＴＲＡＮとＰＬ／Ｉで書かれており、「作法」はＲＡＴＦＯＲをベースとしているなど、今となってはオールドファッションな（あるいは耳慣れない）言語の知識を要求されることにあると言うが．．情けないことだ。この程度の「異種言語」をスラスラと読みこなせないプログラマに、ＣやＪＡＶＡが使いこなせる訳も無い。

　この２冊は言語を超越している。「書法」はまさに「論語」であり、何度でも味読すべきもの。そして「作法」こそは、ＵＮＩＸシステムの思想の神髄であり、ｇｅｔｃ／ｐｕｔｃから始めて、ありとあらゆるソフトウェアツールを、さまざまなフィルタ、暗号化／復号化、アーカイバ、ソーティング、パターンマッチング、エディタ、文書整形、マクロ処理、そして字句解析／構文解析に至るまで、ひとつひとつソースコード付きで作り上げてゆくのだ。そして（誇張ではなく）全てのページに、ソフトウェア開発の、その思想の本質を語る、宝石のような言葉が散りばめられている。これを聖書と言わずして、何を聖書と言うか。断言するが、短く見積もって今後１００年、これを越える書物は出現しない。

　もしもあなたがソフトウェア開発に従事していて、この２冊を読んだことがないのならば．．今すぐ買って読みなさい。これは命令である。

1997年04月10日：いしいひさいちと、ソフトウェア・テスト

　ネタが無いので、ソフトの話を続ける。題材は、いしいひさいちの漫画、「わたしは猫である殺人事件」。これの７８頁の四コマ漫画。出版社の編集部で、寄せられたハガキのうち、ある作家の作品の悪口を書いているものを破り捨てている。その作家に見られると面倒だからだ。その作家が編集部を訪ねてきて、どうかね私の本の評判は、と聞くと、編集長は、これこの通り、悪い評判のハガキは１枚もありません、と、お追従を言いながら、良い評判のハガキの束を見せる。それでその作家には、彼らが情報操作をしている（悪い評判のハガキを処分している）ことが、判ってしまったのである。なぜなら、自分で自分の作品の悪口を書いたハガキを、３枚出していたからだ。

　これは、ソフトウェアの残存バグの個数を推定するために使われる、良く知られた技法に似ている。すなわち、テストチームには知らせずに、バグを意図的に混入するのである。テストチームが、それらのバグの何％を発見できるかで、未知のバグが、あとどれだけ残っているかを推定できるのだ。

　．．というテクニックは、書物で読んで知ってはいるのだが、実際に適用したことはない。そうでなくとも大量のバグを叩き出すのに追いまくられ疲れ果てているテストチームに、万が一、意図的に仕込まれたバグが存在するなどと言うことが知られた日には、ただではすまないであろう。[;^J^]

　洋風居酒屋Ｒで、食事と酒。３０００円位で、それなりに満足出来る。

　黛敏郎死す。

1997年04月11日：運転中の意識の空白

　人を驚かすのは、時と場合を選ばなければならない。特に、走行中の自動車の運転手を驚かすなどは、論外である。

　だいぶ前のことだが、反対側車線の車が、突然バックを始めたことがある。まぁそれ自体は、何か事情があったのだろうが．．そのスピードが尋常でない。４０キロ出ていたかどうか忘れたが、それなりの巡行速度で走っていた私の車と、ぴったり同じ速度。完全に同期して、こちらが直進、向こうが後進したのである。５０メートル近くに渡って。

　右を見た私は、同じく右を見ているその運転手と目がぴったりと合い．．その相対位置を保ったまま、５０メートル近くも走ったのである。その間、ずっと彼の目を見ていた訳ではないが、一種異様な非現実感に捉えられ、しばらく意識が飛んでいたことは、白状する。極めて危険な状態であった。

1997年04月12日：フォトン・ベルトの脅威

　昨日から、「吾妻ひでお　著作リスト」の改訂を始めている。改訂と言うよりは、新リストの追加である。従来、書籍（等）の５０音順で並べていたリストしかなかったので、「発表年代順全作品リスト（簡易フォーマット版）」と「同（詳細版）」を追加するのだ。特に前者は、作品名から、それの収録単行本を、サクッと引ける形式になる。そもそもは、かつて作り掛けて放り出していたリストでは、あった。これがなかなか時間がかかる。

　ｆｊで、面白い記事をみつけた。

From: "Yuuichi.Ueda" <gc-frc@cools.com>
Newsgroups: fj.comp.misc,fj.rec.movies,fj.rec.sf,fj.sci.astro,fj.soc.culture,fj.soc.history,fj.soc.internet,fj.soc.misc
Date: 11 Apr 1997 17:52:00 GMT
Message-ID: <01bc46a0$b0f9bdc0$LocalHost@gc-frc.kobe.jp>
Subject: 電脳コンピューター社会の終焉か！？超文明時代への飛翔か？フォトン・ベルトの脅威！？

という奴である。

　内容は、愚にもつかぬトンデモ系であり、サブジェクトから大方想像できる類のものであるから、引用も要約もしない。（実のところ、最初の一文から最後の一文まで爆笑物であり、どこかを選択的に引用するということが、不可能なのだ。全文引用は、この場合、著作権的に濃い目のグレーであるし。）興味のある向きは、ネットニュースを読んで欲しい。

　何が面白かったか（取り柄だったか）と言うと．．読みやすかったのである。普通この類は、やたらと文章が長く、独善的な（自分にしか通用しない）用語を定義せずにバンバン使い、しかも論理的整合性が無いものだから、読みにくいったらありゃしないのだ。それらに比べるとこの記事は（内容が無いことには違いはないが）遥かに読める。文章をパーズする段階で引っかからずに、ダイレクトに戯言の内容そのものを笑い飛ばせる。

　息抜きの慰み物として、セーブしておいてあるのである。[^J^]

　リブの修理が終わっているはずだが、時刻が中途半端なので、明日、取りに行くことにする。

1997年04月13日：彗星とスパゲッティ

　「吾妻ひでお　著作リスト」の改訂をなんとか終え、朝から酒など飲んで昼寝する。

　起きてからコムロードに電話をすると、なんと、リブはまだ修理から戻ってきていないと言う。あのなぁ、確かに今週末と言ったであろうが。まぁここまでくれば、月曜日か遅くとも火曜日には上がってくるだろうが、こういう「蕎麦屋の出前」状態は、感心しない。一日延ばし、一週延ばしされると、計画が立たなくなるのである。「いつ戻ってくるか見当もつきません」と言われる方が、まだましだ。メーカーの開発の人間として、逆の立場になりやすい身である。大いに自戒する。

　で、気を取り直してみれば、素晴らしい好天である。無論絶好の彗星びより。夕方から浜名湖畔の研究所まで、車を３０分飛ばして観望会に出かけるが、今日は主催者と私のふたりだけ。人数も少ないと言うことで望遠鏡は出さず、肉眼と双眼鏡で１時間弱眺めてから解散。（昨日も好天であり、同じく観望会は開かれていたのだ。さすがに連日なので、参加者の足も遠のいたと言うことであろう。私は私で、昨夜はアジマリスト的労働に従事していた。）

　晩飯は、スパゲッティ専門店のＳ。初めての店であり、メニューはかなり豊富なのだが、取り敢えず注文してみた「卵とニンニクのスパゲッティ」は、たいして美味しいものではなかった。もう少し色々なメニューを試してみるまで、評価は保留する。

倉田わたるのミクロコスモス

Last Updated: Apr 15 1997 

Copyright (C) 1997 倉田わたる
Mail [KurataWataru@gmail.com]  Home [http://www.kurata-wataru.com/]