FreeBSDで複数のLLVM/clangがインストールされてしまった

FreeBSDではgccを止めてLLVM/clangが使われています。昔は他のBSDやLinuxと同様にgccでしたが、今は完全にLLVMに置き換えられています。

ところが気がついて見ると、標準のLLVMの他に、portsから異なるバージョンのLLVMがインストールされてしまっていることに気がつきました。

% cc --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: i386-unknown-freebsd10.3
Thread model: posix
% pkg version -vIL=
*snip*
llvm37-3.7.1_4                     <   needs updating (index has 3.7.1_5)
llvm39-3.9.1_2                     <   needs updating (index has 3.9.1_3)
*snip*

どうしてこうなってしまったのか今後調べてみようと思いますが、おそらくportsから入れた何かのパッケージが特定のバージョンのLLVMに依存する設定になっていたのでしょう。

このような状況はLLVMに限らず、gccであるとか、perlなどでも起きることがあります。特定のバージョンを使わなければならない必然性があるのなら仕方ないと納得できますが、たいていの場合はデフォルトのバージョンでも問題にならないことが多いのです。

FreeBSDに標準でLLVMが入っているのに、さらにバージョン3.7や3.9のLLVMが入るのはリソースの無駄としか思えません。

undocumented feature

昔々のことになりますがNECのTK-85を持っていました。CPUはインテルの8085で、RAMは何と僅か512バイトです。

8085というCPUは、有名な8080を改良したもので、命令が2つ追加されています。当時のインテル製CPUのアーキテクチャはCISCです。命令長は可変長ですが、命令の1バイト目だけみれば後続する命令長が分かるようになっています。要するに1バイトで命令をデコードするわけですから256個定義できるのですが、実際には数箇所の未定義部分があります。

当時のCPUは現在とは違い原始的ですので、未定義となっている命令を実行させようとしても「例外処理」が起きるような機能を持っていません。未定義命令を使ったバイナリを実行させてみると、思いもがけないような結果が得られることがあります。アセンブラでプログラムを書く身であれば在れば有り難いと思うような機能が実装されているのが分かったりします。しかしそれはマニュアルに記載されていませんから必ず利用できるとは保証されません。このような機能は「undocumented feature」と呼ばれます。

ここまで書いた話はハードウェアに関することですが、ソフトウェアであっても同じことです。ハードであれソフトであれ、仕様に関する文書に記載されていない場合でも、操作してみれば何らかの「一見すると有用そうな」挙動を示すことがあります。しかしそれは（厳格に捉えるなら）undocumented featureです。つまりその「機能」は永続的に利用できる保証がありません。

このようにundocumented featureを使うのは慎重となるのですが、問題は特にOSSでは仕様を明示的に示す文書が欠けていることが多いことです。あろうことか「ソースコードが公開されているんだから、文書は要らない」とか言い出す人が出てくる始末です。仕様書とソースコードが同一だとする立場であれば、そこには「バグ」という問題は原理的に発生しません。バグというのは、仕様としてあるべき状態と、プログラムとしての実際の挙動の違いから判断されるべき事柄なのです。

商用製品では、OSSに比べれば 、文書がある程度用意されていますが、些細な点まで全て網羅されているような詳細な文書が用意されているとも限りません。使おうとした機能や、行おうとした操作が、undocumented featureなのか否かを判断するのは、思うほど簡単ではありません。

このようにundocumented featureは恐いので、使わないで済むものなら使いたくないところです。問題は、文書が充実しているとは言い難いことが多い現状においては、確実に「仕様に基づいた機能を使っている」と言い切れる事態は決して多くはないという事実です。否応なしに、undocumented featureを利用しているのか違うのかも不明なままに、目の前で動いているものが「永続的」であるように祈りながら、日々を過ごしていくことになります。

GNATS、BugzillaそしてRedmine

IT開発の現場ではバグ対応が避けられません。受け付けたバグ報告や、対応しているバグや完了した件などを個人的なメモに留めていると、小規模な開発では何とかなっても、関係者が増えてきた場合に対応できなくなります。また個人で対応できていたとしても、何らかの事情で担当できない状況に追い込まれた場合、それを他の人が引き継ぐのは至難の業です。

そこで「Bug Tracking System (BTS)」というものが生まれました。これが「バグ（不具合、障害、問題点）」だけを対象とするのではなく、さらに進化し、開発の中で生じてくる様々なアイディアを含めて運用できるようにするため「Issue Tracking System (ITS)」と呼ばれたりもします。

OSSで提供されているBTSもありますし、商用製品もあります。OSSと製品のいずれが優れているのかは直ちには判断できません。OSSは信用できず商用製品でなければ責任の所在が曖昧になると考えている人もいるでしょうし、製品に比べればOSSの方が利用者が多いから仮に問題があったとしても修正が迅速であるはずだと主張する人もいます。一般論としてはどちらもその通りですが、具体的に個別のBTSについて見ていくと、それぞれの事情があるとして言えないでしょう。

いろいろな主張があるとしても、試しに利用してみるためにはOSSの方が手っ取り早いのは確かです。いろいろありすぎて選択に迷いますが、著名なのは古くからある「GNATS」とか、最近では「Bugzilla」や「Redmine」です。

GNATSはGNUの開発したBTSで、FreeBSDやNetBSDなどがバグ報告を受け付けるために利用されています。バグを報告は「Problem Report」と呼ばれ、一つの報告に対してPR番号が付けられます。その問題の管理はPR番号で行われることになります。

BugzillaはFirefoxでお馴染みのMozilla Fundationが開発し、Redhatなどが利用しているようです。

Redmineは市販の参考書が多く出版されており、利用者コミュニティが活発であることが窺えます。GNATSではPRで管理していたようなことを、Redmineでは「チケット」と呼んでいるようです。

BTSの範疇に含まれるものは数多く、どれを利用すれば良いのか迷ってしまいます。注意しておきたいことは、各々はBTSには違いないとしても、その具体的な実現方法は様々であるので、出来ること出来ないことは個々に異なるということです。何かを選べば、他を選んだなら出来たであろうことが、出来なくなる可能性は高いと思います。妙な例えになりますが、MS-DOS上でC言語を利用しようとして、Lattice-Cを選ぶか、MS-Cにするか、それともTurbo-Cにするかという判断とは違うのです。

いずれのBTSであれITSであれ、ひとつの問題や要望に対する一連の情報を整合性を保って管理するという趣旨は同じですが、そのための実現方法は大きく違います。 その用語も個々に違います。もちろん同じような用語が多いのですが、全く同じである保証はないし、用語の意味を膨らませていたりすることもあります。

このような状況では、自分の要求に即したBTSやITSを選択するには、全てを使ってみるしかありません。インストールマニアでもなければ、そんなことをしている余裕は普通は無いでしょう。機能の詳細に踏み込まずとも、大雑把に比較して対象を数個に絞り込むことは可能だと思います。しかし使ってみないと分からないことも多いので、結局は何かを選択して利用してみることになるでしょう。

選択するためのひとつの考え方は「有名なものを選ぶ」ということです。市販されている書籍が多いとか、Webなどで情報が見つかりやすいとか、または身近で利用されているというような事です。そのような理由で選ばれたものは、機能的に最高レベルではないかもしれません。「有名なものを選ぶ」という判断基準は、「最高レベルを選ぶ」という基準とは両立しないのです。これまた変な例えですが、CP/MやMS-DOSが広く使われていた時代に、OS-9の方が技術的に優れているという主張がありました。これは確かにその通りだと思いますが、OS-9が広く利用されるようにはなりませんでした。

何を選んだとしても、実際に使い始めてみると、期待していたようなことができない可能性があります。その期待が、無いものねだりなのかもしれませんし、もしかすると何かのバグかもしれません。そこで選択しなかった方を調べてみたら、そちらでは出来ることが分かったとしましょう。そこでツールを乗り換えるのも方法のひとつではあります。ですが乗り換えたところで、次にまた別の壁にぶつかったら、また乗り換えるつもりでしょうか。その調子で乗り換えていたら、何時になったら本来の目的である「バグ管理（または要望管理）」ができるようになるのでしょう。

これは、一度決めたら決して乗り換えてはいけないという主張をしているのではありません。そうかといって、気軽に乗り換えることを勧めている訳ではありません。ツールの選択に限らず、「選択」と「決断」は難しい判断です。いずれにしても、何をするにも「自覚的であれ」というのは真理かもしれません。

食べ放題を意味する「バイキング」は大和言葉の一種なのか

『ナショナル ジオグラフィック 日本版』の2017年3月号の特集は「バイキング 大海の覇者の素顔」です。バイキングについては漠然としたイメージしかなかったので、この記事を読むと詳しく学べるのではないかと期待しています。特集によっては、スカパーで視られる「ナショナル ジオグラフィック チャンネル」でも雑誌記事と連動した番組が放送されることがありますが、今のところ関連番組はなさそうです。

日本を含めた世界中で「バイキング」と言ったら8世紀前後に大暴れした集団を意味していますが、日本では食べ放題形式の食堂を「バイキング」と呼んでおり、武装集団としての「バイキング」より食べ放題としての「バイキング」の方が認知度が高いのではないかと思います。

そもそも日本で「バイキング」が食べ放題形式の食堂という意味になっているのかという理由について、ウィキペディアでは次のように説明しています。

日本語では「バイキング」と称されることがある。日本初の食べ放題レストランの店名が「バイキング」であったことに由来する。

ウィキペディアによると、食べ放題形式のことを英語ではフランス語風の「buffet」とか北欧風の「smorgasbord」と呼ぶようです。

日本語では外国由来の単語をカタカナ表記にすることが多くあります。その方式で行くと、食べ放題形式は「ビュッフェ」もしくは「スモーガスボード」となるところです。しかし「ビュッフェ」と言えば「立食形式」を日本ではイメージするでしょうし、「スモーガスボード」にいたっては一般的な認知度は低いのではないかと思います。

日本語独自の「バイキング」というのは英単語の「viking」の訳語ということではなく、見た目は外来語に似ていますが、外国由来の訳語でも何でもなく純粋な日本語だと思います。だから英会話で食べ放題に関する話題をしようと考えた時に「viking」という語を使うのであれば、その英文が表面的な形式として完璧だとしても、意味的には非英語的表現でしかないでしょう。

要するに「食べ放題」を意味する「バイキング」は日本語でしょう。大和言葉とか和語とか言うと、長い歴史を踏まえている訳ではないでしょうから、言い過ぎかもしれませんが少なくとも外来語ではありません。

現在の日本語を構成する単語は、古くからの大和言葉に由来する語、中国から伝来した漢語に由来する語、古くはポルトガル等であったり幕末以降は欧米であったりする国々に由来する外来語などから構成されています。ここで「バイキング」という単語は、大和言葉とは言えないし、中国伝来でもないし、もちろん欧米由来でもありません。あえて言えば多分に勘違いに由来する現代日本語です。

 一見すると外来語のようであって、実は日本独自の単語というのは、他にも事例があります。英語の「stapler」を日本語では「ホチキス」と呼ぶ事例であるとか、紙を複写する意味の「copy」を「ゼロックス」と呼ぶ事例などが思いつきます。

おそらく世界中のどの言語にも同様の現象が存在しているだろうと思います。自国以外から取り入れた単語が本来の意味と全く関係のない意味に使われる事例は日本に限ることではないと思います。

国立西洋美術館「スケーエン デンマークの芸術家村」

国立西洋美術館で日本・デンマーク外交関係樹立150周年記念として「スケーエン デンマークの芸術家村」という展示がおこなわれています。常設展示室の一部を使って開催されています。

19世紀後半から20世紀初頭にかけて描かれた作品が並べられており、透き通るような画風がとても美しく気に入りました。風景や人物を描いていますが、ごく一般的な庶民であり、（作品を描いた背景を学んでいないので不確かですが）著名な何かを表しているわけではないと思います。これより古い時代の宗教画や有名人の肖像画とは違いますし、これより後に増えてくる抽象画のように（何が描かれており、何を表そうとしたのか）頭を悩ませるような作品とも違います。一見すると「わかりやすい」気がする作品です。

作者は何を思って描いていたのでしょうか。図録を買いましたので、各作品には解説がついています。しかしそれは作者の言葉ではなく、解説者の文章です。この展覧会に限りませんが、作者が作品に込めた思いなどは、どうしたらわかるのでしょう。別にそれがわからなくても作品は楽しめるし、それで良いのですが、もう一歩踏み込んで作品を鑑賞したいときもあるのです。そのためにこそ図録があるとも考えられますが、今のところ問いかけに応えてくれた図録は目にしていません。何か他にないものかと強く思います。

鉄道愛好家の呼び方の変化と関心の細分化

鉄道を趣味の対象とする人を昔は「鉄道ファン」と呼んでいました。その中には個性が強く、関心の対象が鉄道にしかないのではないかと思われるような人もいて「鉄道マニア」と呼ばれたりもしました。時代が進み1970年代後半以降になるとアニメファンの中に「おたく」と呼ばれる人たちが出現し、そのキャラクターの類似性から「鉄道オタク」という呼び方がされるようになりました。さらに時代が進むと「鉄ちゃん」という呼び方が誕生し、近年では「乗り鉄」とか「撮り鉄」などの細分化が進んでいます。

昔ながらの鉄道ファンというのは、鉄道に乗って旅行もする（ただし注意しておかなければならないのは、当時は旅行するには鉄道を使うしか方法がなかったという時代背景があったということです）し、 鉄道の写真も撮るし、鉄道模型にも手を出す（ここも注意が必要ですが、今のようにNゲージなどは無く、Oゲージは大きくて場所を喰うので、興味があっても手を出せなかった人もいたということです）し、要するに鉄道に関することなら何でもしていました。だから趣味として「鉄道ファン」と言えば、その言葉に含まれる全ての対象を含意していたと言えます。

ところが今では「鉄道ファン」という言葉だけでは、興味の対象を表せなくなっているようです。つまり「乗り鉄」と言ったら「鉄道に乗ることだけが関心対象」で、「撮り鉄」であれば「鉄道を撮影することしかしない」ようなのです。現実には複数分野に興味がある人が多いのでしょうが、それでも鉄道に関わる全てを対象とする人は少なくなっているように感じます。それが呼び名が細分化されていく現象に現れているように思います。

ここ数年の間に、ブルートレインの廃止、地方ローカル線の廃止、旧型車両の廃止などが続き、その一部はマスコミにも取り上げられて大きく報道されました。そうなると、もう鉄道に愛着する気持ちなど全く持ち合わせていなくて、ただひたするた押し寄せて最終列車にむけて叫ぶだけという、これはファン（愛好家）なのかと疑問を感じる群衆が出現しています。

言葉が細分化されていくことで興味の対象を限定できるようになっています。しかし興味の対象を限定できることで、さらに関心が細分化し、新たな表現を生み出し続けているように思います。

英語を勉強している成果なのかと思えた経験

以前から英語の勉強を続けています。何か直接的な目的があるわけではありません。英語が世界的に重視されている現状があるので、少しでも世界情勢について行きたいというだけの事です。スキルレベルを把握するために毎年TOEICを受験していますが、平均点を多少上回る程度で、目だった成果は上がっていません。

いろいろな教材に手を出すよりは、厳選した教材を徹底的に勉強するほうが良いと言われます。何が厳選された教材なのかは主観的に判断しただけですが、徹底的とも必ずしも言えませんが、成果が上がっていない気がしても、挫けず勉強を続けるようにしています。

それにしても昨今はインターネットや動画配信の発達により、学習用に加工されていない、現実的な英語素材が手軽に入手できるようになっているのは驚くばかりです。そのような現実の英語を耳にしても、いまひとつ理解できたという実感が得られたとも言えない状況でした。

ところが先日「日本外国特派員協会」で行われた記者会見の様子の動画を見ていたら、ある記者の質問が「聞き取れた！」という体験をしました。ごく一部分だけでしたが、今までならば全く聞き取れず、箸にも棒にも掛からないようであったことを思うと、嬉しい経験でした。英語の波に上手く乗れると聞き取ることもできそうな感触ですが、まだ波に長く乗り続けていけません。しかし練習を重ねれば、長く乗り続けることもできるようになるでしょう。

間もなくMicrosoft Windows Vistaのサポートが終了

MicrosoftはWindows Vistaのサポート期限を2017年4月11日とアナウンスしていますので、もう間もなくです。アナウンスされている日付とは一体何なのでしょうか。僕は（自分で勝手に）その日まではVistaに関わるあらゆるサービスは、それまでと同様におこなわれるものだと思ってきました。

現実世界に例えれば、店舗の営業終了日のようなものをイメージしていました。もっとも現実世界の店舗では、営業終了日に向けて在庫を少なくしていくために「在庫一掃セール」のような特売が連発します。しかしソフトウェアの世界では物理的な在庫というものが（現実世界ほど）発生しませんので、サポート期限当日まで、何ら変わることなくサービスが提供されるものとばかり思っていました。

ところが既にWebサイト等においてもVistaを扱うリンクが切れていたりしているようです。店じまいの準備は、かなり進んでいる印象です。

Windows XPのサポート終了の頃にも言われていたことですが、サポート期限を過ぎたOSを利用し続けることはセキュリティ上の深刻な問題が発生するので、使い続けることは止めるようにとされていました。これはその通りで、反論するつもりはありません。それではサポート期限（2017年4月11日）まで、Windows Vistaのセキュリティ更新が「何の問題もなく従来同様に」入手できるのかというと、そんなことはないようです。すでに昨年からWindows Updateの不具合に悩まされています。出来れば最後まで問題を感じることなく使い続けたかったと思っています。

Windows Vistaが入っていたdynabook SS SX/15AはNetBSD/i386に入れ換えるつもりで、その準備は進んでいます。来月には実行に移すことになるでしょう。

同時に利用していたアプリケーションもNetBSDで使えるものに移行するつもりです。Microsoft OfficeはLibreOfficeにします。FirefoxはWindowsでもNetBSDでも同じように使えます。よく使うアプリケーションは移行先が見つかっているのですが、一部に移行できないものが残りました。

Microsoft Visioは直接の移行先がありません。似たようなアプリケーションとしてはInkscapeがあるので、今後はそちらを使うつもりです。VisioのファイルはLibreOffice Drawで開けるのですが、日本語テキストが化けてしまっています。既存ファイルを見るだけならVisio Viewerが使えそうなので、デスクトップPCのWindows10でViewerを利用するしかありません。

またStyleWriter 4という英語の文体チェッカを持っていたのですが代替先が見つかっていません。

「旧型PCをフリーOSで蘇らせる」られるか?

雑誌の特集などでMicrosoft Windowsがサポートしないような旧いPCでもフリーのOS（LinuxとかFreeBSDなど）なら十分に使えるから云々という記事を見かけることがあります。これは間違いではありませんが、「ただし古すぎるものは除く」と条件をつけなければならないようです。

自宅では昔懐かしいGatewayによるノートPCにFreeBSDを入れて使っています。2000年より前に作られたものなので、今となってはメモリも少ないし、CPUだって骨董品です。FreeBSD 10.3の起動メッセージでは次のようになっています。

CPU: Intel Pentium III (447.70-MHz 686-class CPU)
  Origin="GenuineIntel"  Id=0x681  Family=0x6  Model=0x8  Stepping=1
  Features=0x387f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE>
real memory  = 301989888 (288 MB)

最新のマシンに比べれば当然遅いのですが、利用目的を見極めれば、決して使えないわけではありません。しかしながら旧過ぎるが故の問題を感じるようになってきました。

まずはFreeBSD自体の問題です。FreeBSDの最新版は11.0-RELEASEですが、このマシンでは動きません。ブート中にカーネル・パニックを起こして落ちてしまうのです。実は10.0がリリースされた当初も同様の現象に悩まされていましたが、いつの間にか起動できるようになりました。11.0も起動できるようになってくれるのを待っているのですが、もしかするともう駄目かもしれません。

さらにportsからインストールしているアプリケーションの一部が、最近になって更新できなくなっています。コンパイル中に以下のメッセージが出てしまいます。SSE2が使えないと駄目のようなのですが、Pentium 3なのでSSE2は使えません。SSE2が使えるのはPeintium 4以降なので、それ以前のCPUのサポートを打ち切ったという事なのでしょうか。

In file included from utils.c:37:
In file included from ../../../../../src/mesa/main/macros.h:36:
In file included from ../../../../../src/util/rounding.h:35:
/usr/include/clang/3.4.1/emmintrin.h:28:2: error: "SSE2 instruction set not
      enabled"
#error "SSE2 instruction set not enabled"

旧いマシンなので、いろいろとガタが来ているのは感じていますが、そろそろ引退時期を迎えつつあるのでしょう。

なにわ筋線と阪急の接続計画

2017年3月17日の報道によると、JR西日本が大阪駅北側の操車場跡地で開発を進めている地下駅と阪急の十三を繋ぐ計画があるようです（なにわ筋線30年開通 ＪＲ・南海運行、新駅以北は阪急交え協議）。2030年の開通を目指すということです。あと13年ほど先になりますが、その時の交通需要はどうなっているのか、本当に工事が始まるのかなどを考えると、まだまだ一山も二山もあると思います。

阪急の大阪側の拠点は梅田駅です。梅田以南に路線を伸ばそうとしている計画は以前から聞いていましたが、それは大阪市営地下鉄の西梅田駅と十三を結ぶ路線だったはずです（西梅田・十三連絡線）。阪急の十三駅は淀川の北側に接していますし、その周辺は建物が密集しているので、地上に新規路線を乗り入れるのは相当困難であると思います。地下駅にするとしても、淀川の下を潜ってくることを考えると、かなり深い場所にホームを作ることになり、乗り換えは不便な気がします。

今回報道された計画でも事情は似たようなものと思いますが、もっと重大な問題があるのではないでしょうか。そもそも阪急はゲージが1,435mmの「標準軌」ですが、JR西日本や南海は1,067mmです。もしも阪急がなにわ筋線と十三を結ぶ路線を建設するとなると、阪急で唯一の1,067mm路線ということになり、阪急の他路線とは車両の運用が絶対にできなくなります。当然ながら、阪急の三ノ宮・宝塚・河原町などから乗り入れることは出来ませんから、既存の阪急沿線とのアクセスが「改善される」というほどのこともないような気がします。

従来から計画があった「西梅田・十三連絡線」であれば、大阪市営地下鉄もゲージが1,435mmですから、もしかすると十三は地下駅になったとしても、どこかで地上に出てきて既存の路線と繋がる可能性はあります。そうなればアクセスが「改善される」と言えるでしょう。

「鉄道ピクトリアル」の2017年4月号は特集が「阪急電鉄京都線」でした。84ページには「阪急線内の1067mmゲージ」というコラムが掲載されています。阪急は出自の違う神宝線と京都線を抱えていて、ようやく車両規格などが統一できたのに、ここでまた別規格の路線を持とうとするのでしょうか。

宅配便の引き受け削減と仮想記憶におけるスラッシング

報道によるとヤマト運輸では労働負荷を改善するために荷受けを制限する方向で検討しているようです（ヤマト、残業１割削減　宅配の労働負荷に限界）。「宅配便」という小口配送方式を作り出したのはヤマト運輸ですし、Amazonなどによる昨今の通信販売の拡大によって荷物数が激増して、ヤマト運輸に限らず、どこの配送業者も悲鳴を上げているようです。

小口荷物の宅配の問題点のひとつは、配送してみたら不在である可能性を内在していることです。荷物を放置していくわけにはいかないので、1つの荷物に対して、1回の配送では済まず、複数回の配送をおこなう必要が出てきます。詳しい情報を持っていないので、実態については不明ですが、最悪の場合には再配達のために何度も足を運ぶ羽目に陥っていると思われます。

通販の拡大で荷物が増えているのに、さらに不在配達も行わなければならないとなると、必然的に残業が常態化してしまっているようです。

この報道に接したとき、コンピュータの仮想記憶における「スラッシング」が頭に浮かびました。最近はメモリが安価になり事情が変わってきているところはありますが、仮想記憶とはコンピュータの実メモリを補うために不要部分をディスクに追い出すことで、あたかも大容量のメモリを扱っているように見せかける技術です。発想はシンプルで悪くないのですが、調子に乗ってプログラムを数多く動かし過ぎると、実メモリとディスク上の仮想メモリとの入出力頻度が増えてきて、CPUの処理能力が「実際の計算処理」ではなく「ただのディスクの入出力」に奪われてしまう現象が発生します。これがスラッシングです。

宅配における再配達も、もともとの発想は顧客サービスだったのでしょう。宅配便の黎明期には再配達をおこなったところで、本来の配送業務に支障を与えるほどの事もなかっただろうと思います。それが次第に宅配が一般に浸透し、再配達の手間が本来の配送業務を脅かすようになってきてしまったわけです。

通販が一般化すると、気軽に注文を出して、安易に注文を取り消したり、配送されてしまっても居留守を使って受け取りを拒否したりする弊害が出てくると思います。「宅配便」というものが将来的に無くなるとは思いませんが、現状の延長上にサービスが続くとも思いません。

自動車のナンバープレートに英字が使われるようになるらしい

2016年12月に「ナンバープレートに英字導入へ　希望番号で人気数字枯渇」というような報道がありました。自動車のナンバープレートというのは（例えば「品川 330 さ 11-11」であれば）、順に「地域名」（例示の場合「品川」）、「分類番号」（例示の場合「330」）、「平仮名」（例示の場合「さ」）、「一連指定番号」（例示の場合「11-11」）と呼ぶそうです。この中の「分類番号」が現状の3桁では不足するようになったそうなので、英字を使用するのだそうです。これは検討されているのではなく、もう間もなく2017年4月から実際に使われ始めるようです。

この「分類番号」は、現在は数字3桁ですが、以前は数字2桁でしたし、もっと昔は（古い映画などで見ると） 数字1桁でした。不足するたびに数字の桁数を増やしてきたわけですが、今回は「数字」の他に「英字」を使うことで容量不足を補うつもりなのでしょう。

英字を全て使えば26種あるので数字10種と組み合わせれば、数字の桁数を増やすより、桁数を変えずに容量を大幅に増やすことができるはずです。理論的な最大値は、数字3桁であれば10の3乗なので1,000ですが、英数字3桁ならば(10+26)の3乗より46,656となり、46倍以上もあります。

しかし実際には視認する都合で不使用となる英字が出てくるでしょう。「I（アイ）」や「O（オー）」は、数字の「1（イチ」や「0（ゼロ）」 と見間違えやすいので、使われないだろうと思います。また「U（ユー）」と「V（ブイ）」も字体が似ているため誤認しやすいと思うので使わないのではないでしょうか。

さらに問題なのが、現代はIT技術が高度に発達した社会だという事です。警察などの官公庁も、自動車会社や販売店なども、内部システムをコンピュータ化しているところが大部分でしょう。おそらく管理するデータベースでは「分類番号」は「数字で3桁」として内部管理されていると思います。そこに「英数字で3桁」というルールを持ち込むのは、システムにどのくらい影響がでてくるのか、見えにくいのではないかと思います。西暦2000年前に騒がれた「Y2K問題」という社会現象と同じことです。

さらに、高速道路などに設置されているナンバープレート読み取り装置は、画像認識をおこなってナンバープレートの各要素を文字列化しているはずです。認識精度を手っ取り早く向上させるためには各要素に現れる文字種を限定することですが、そうすると「分類番号」は「数字で3桁以下」ということになっているかもしれません。これが「英数字も良い」ということに変わると、全く影響なしという訳にはいかないのではないかと思っています。

緑色の「青信号」と駅ホーム上の「黄色い線」

日本では交通信号を「青信号」と呼んでいますが、正確に表現すれば「青色」ではなく「緑色」のはずです。日本語では昔から「青色」と「緑色」の表現を混用する傾向があるといわれており、最近でも「日本語における「青」と「緑」の混用、経緯を解明 - 東北大」という記事が発表されています。要するに「青信号」と呼ぶのは日本語の習慣的表現にすぎないので許容される範疇だということのようです。

 その一方で色の違いを厳格にとらえる事例もあります。駅のホームの端に点字ブロックが並べて設置されていることが多く、それを駅のアナウンスでは「黄色い線」と呼ぶことがあります。これに対して、「点字ブロックならあるけど、線て何のこと?」とか、「あれは黄色じゃなくて云々」と疑義を呈するむきもあるようです。駅のアナウンスにおいてどのような厳格さを求めているのかわかりません。僕の考えでは、現状のアナウンスでも許容できる範囲です。

人間の眼は自然に存在するあらゆる色彩を認識できるのだろうとは思いますが、認識した色彩が本当に区別できているのか、近接する色彩と混同しているのか、本人以外の他者からは伺い知ることができません。他者が理解できるのは、その色が何と表現されているのかという事だけです。本人の眼から入った色彩が、本人の口から出てくるとき、言語（この場合なら日本語）によって区分された色彩表現によって「デジタル化」されていると言えるでしょう。

RGBカラーコードを使って「（例えば）#95A3D4」のように表現されても、日常会話では困るわけです。

しかも（緑色なのに青信号と呼ぶような）言語の習慣もありますし、日常会話では厳格さよりは大掴みに表現される方が多い傾向があることなども考えると、それらを全て含んだのが「常識」というものなのでしょう。

Kiva

数年前から「Kiva」を通じた活動に参加しています。Kivaについてウィキペディアでは次のように説明しています。

Kiva Microfundsはインターネットを介してマイクロファイナンスを行うNPOで、発展途上国の小規模事業と融資者の仲介を行う。

途上国支援には、日本国内はもちろん国際的にも活動している団体が数多くあります。それらの団体に対して寄附金を渡すというのは、よくある方法でしょう。もし継続的に支援したいと思ったら、毎月だったり毎年だったり、少なくとも定期的に、寄附金を払い続けていくことになります。期間が長くなればなるほど、一回当たりの金額が高ければ高いほど、合計した寄附金額は増えていきます。

これに対してKivaを通じた支援は様相が異なります。対象が途上国であり、金額が少ない（しかし途上国での物価を考えれば、一概に少ないとも言えない）としても、立派な「融資」活動には違いありません。寄附ではないので（返済不能にならなければ）融資した金額は戻ってきますし、戻った分を別の融資先に再投資することもできます。だから寄附行為に比べると、少ない金額で、多くの支援を行うと考えることもできます。

またKivaを通じた融資では融資相手の事情が詳しく示されています。一般的な寄附では寄付先が何処の誰なのか明らかにされないことが多いので、より親近感がわくという特徴もあります。

ただし注意しておきたいのは、Kivaを通じた融資行為と、NGO/NPOなどを通じた寄附行為は、それぞれ違う性質を持つという点です。どちらかがあれば良いというものではなく、どちらも特徴を活かして使われるべきものです。

体感温度は湿度の影響を受けるのか、それとも受けないのか

実際の気温とは別に「体感温度」について言及される場合があります。テレビで天気予報（天気情報と言うべきなんでしょうか）を視ていると、冬場などは「風が強いので実際の気温よりも寒く感じるでしょう」といういうようなコメントを加えていることがあります。ウィキペディにも次のような記述がされています。風が強いと、（夏は気になりませんが）冬だと実際の気温よりも寒く感じるのは経験しているところです。

日本では俗に、風速が1m/s増すごとに体感温度は約1℃ずつ低くなると言われている

それでは湿度の違いは体感温度に影響を与えていないのでしょうか。ウィキペディアをみると、体感温度に対する湿度による補正式が示されています。風の影響の俗説のような簡便な換算ルールはないようです。

ミスナールの提案した補正式（改良されたもの）を利用した計算サイトがあるので試してみました。風速0[m/s]において気温0[℃]の場合に、湿度が5[%]だと体感温度が7.2[℃]と計算され、湿度が95[%]なら体感温度が3.8[℃]と計算されました。

客観的に計測可能な気温とは違って、「体感温度」 というのは主観的な側面を持つと思うので、実際の数値として表すのは困難だろうと思います。上述した計算結果を鵜のみにはできませんが、湿度があがると体感温度がさがるという反比例の結果を示しています。この結果を否定する情報を持っているわけではないので、感覚的な疑問を呈することしかできませんが、計算結果に違和感があります。

違和感を覚える理由の一つは、体感温度を下げる原因として皮膚から水分が蒸発されるときに熱を奪うからだという説明があることです。湿度が高い方が皮膚から水分が蒸発されにくくなるだろうと思うので、体感温度も（湿度が低い時よりは）あがりそうなものですが、反対の結果がでてしまっています。

 また冬に屋内を暖房すると乾燥するので、加湿器を併用することで「暖かくなる」という効果が提唱されています。実際に加湿器を使うことで、気分の問題かもしれませんが、暖かくなった気はします。

湿度が体感温度に与える影響は補正式と実際の感覚とがあっていない気がしてしかたありません。どこかに最新の知見はないものでしょうか。