地理的名称トップレベルドメイン

.tokyoというドメイン名が販売されはじめている。

以前は TLD(Top Level Domain)は、業種(.com .gov .org .net ...)と国別(.jp .uk .tv ...)があったが、もっと自由な文字列を使えるようにしようということで、新しく汎用ドメイン(gTLD=generic TLD)のルールが創設された。
300-delegation-1020x391-22jun14-en.png
誰が決めた?というとICANN(The Internet Corporation for Assigned Names and Numbers)という国際「非営利」団体。
2013年からgTLDの発行がはじまっているが、その実績はICANNのホームページの"new gTLD-Delegated strings"に掲載されている。H26.6末で320余が登録されている。


新しいgTLDを作る場合、その管理者がICANNに申請して審査を受け、承認されねばならない。審査は185千ドル、また認められてからも毎年25千ドルをICANNに支払う。(上のICANNの説明で「非営利」と括弧をつけたのはそういう理由。年間1億ドルも利益を出しているらしい)
巷間、.toyota とか .sony とかが話題になったが、今のところどちらも登録されていないようだ。

文字列を自由に認めると、tokyo とか osaka などの地名もアリとなるが、これを無制限に認めるとその地名を持つところから苦情が出るおそれがある。そのためICANNは、国・州・県レベル程度までについては自動的に、そうでない場合でも地名と認識してクレームがあるのなら、地理的名称トップレベルドメインという区分を設けて、その地域の政府(自治体)の支持文書取得(正確には無関心宣言もある)を義務付けた。このことが.tokyoとか.osakaができるかも、と新聞報道されたわけだ。

都道府県は、これは面倒だと思った。地域の宣伝になるかもしれないからドメインができることは歓迎だが、支持文書を出すという事務が新たに発生する。事業の性格上、同じ名前のドメイン管理者は1者となるわけだが、東京都は外部有識者を交えた審査会を作って、事業者を1者選定した。大阪府はドメイン発行ポリシーに条件(公序良俗に反する名前不可とか、府内市町村名の予約、など)を付けて、それを満たせば支持文書を発行し、1者に絞るのは民間セクターに任せた。大阪府のやり方は無責任に見えるが、実際には1者に絞るのは難しい。判断基準は地元への貢献ぐらいしかない(ニューヨーク市はドメイン管理業者に市に「上納金」を払わせることにし、それが高いところを選ぶという噂)。
ICANNは厳しい経営事項審査、技術審査を課すから、1者に絞って審査に落ちたらどうなるのか。かといって先にICANNの審査を受けろとはならない、185千ドルもいるから。結果、大阪府の支持文書は4社に出されている。

もし、地理的名称TLDが大量に発行できるなら、自治体自身が管理者になって発行手数料を稼ぐことも考えられただろうが、慎重な行政としては、そういう夢のようなことは考えていない。実際、.tokyoが発行開始されてから2か月だが、今のところ発行事業者のページ以外、Google検索では上がってこない。ところが、ICANNに対抗するようにJPRSが創設した国内の地域ドメイン .tokyo.jp こちらは結構発行されている。.jp は世界的にも信用できるドメインと評価されているから、ブランドでは上なのかもしれない。なお、.osakaはまだできていない。
意外なのは.nagoya。それなりの数のサイトがある。日本で最初の地理的名称TLDということが良かったのかもしれない。今のところどこもICANN申請費用の元がとれたとは思えないなぁ。ICANNの目論見違い、というところだ。

ところで、日本人は目的のページを開く場合、だいたい検索エンジンを使うのではないだろうか。URLがわかっているサイトを開くときでも、アドレスバーに直接URLを叩き込むことは稀だと思う。だからこの話を聞いても、それがそんなに効果のあるものなのか、それで多くのサイトがgTLDを使うようになるのか、どちらも疑わしいと思った。
ところが、欧米ではそうでもないらしい。米国人のお客さんに家のPCを使ってもらったとき、その人はいきなりブラウザのアドレス・フィールドにURLを書き込んでいた。

関連記事
スポンサーサイト

久々のシンフォニーホール

今日は久しぶりにシンフォニー・ホール。
IMG_20140629_132808_296.jpg IMG_20140629_132839_754-crop.jpg
(ホール内は撮影禁止なので、外観写真のみ)

アマチュア・オーケストラだが、エキストラにはプロが混じっているらしい。それなりに活動費を持っているらしく、シンフォニー・ホールである。去年はいずみホールだったからさらにレベルアップ?

flyer_44th.jpg本日の演目は、ブラームス/大学祝典序曲、チャイコフスキー/ヴァイオリン協奏曲、ドボルザーク/交響曲第9番「新世界より」。

出演者の一人から聴きに来てと言われたわけだが、アマチュアでもわかりやすい曲の場合は意外に聴けたりするものである。
ただし、わかりやすい曲というのは、演奏が簡単ということではない。
こういう管弦楽作品(演目中なら特にドボルザーク)は、一人では曲にならないが、潰すのは一人でできる。特ににティンパニなら。
で、誘ってくれた出演者がティンパニ奏者。
なので、ティンパニが失敗しないか、はらはらしながら聞いた次第。

バイオリンのソリストはまだ23歳のK都府立医大生だそうだが、艶やかなチャイコフスキーで、わかりやすい良い演奏だった。アンコールにプロコフィエフの無伴奏ソナタ、パガニーニのラプソディー。

一番心配なドボルザークのティンパニも大きなミスはなかったと思う。(ブラームスではちょっととちってたが)
アマチュアでもちゃんとしたホールでやると弦楽器は聴ける。管楽器は個人の技術がもろに出るから敢えて論評はしない。
まぁ、全体としては悪くはなかったのでは。

帰りにO阪駅のTully'sで休憩。Tully'sははじめて入ったが、「本日のコーヒー」はハズレ。酸味がなく、焦がした黒豆のようなコーヒー。まだネスカフェ・ゴールドブレンドの方が良い。なお、Starbucksもストレート・コーヒーはイマイチだと思う。どちらの店もストレート・コーヒーではなくて、甘味と香料を足したお菓子のような飲み物がメインだろう。
私は決してコーヒー通ではないから信用してもらわなくて良いが。
関連記事

Cloudfoggerとオンライン・ストレージの使用感

前にオンライン・ストレージを使う場合は不安なので暗号化ソフトのCloudfoggerをしばらく使ってみると書いた(⇒クラウド用暗号化アプリ(Cloudfogger))が、その続報。

まずオンライン・ストレージのおさらいをしておこう。
オンライン・ストレージはいろんなサービスがあるが、メジャーなのは、Dropbox、Google Drive、OneDrive、SugarSyncなどであろう。いろいろ試して、SugarSyncは凝りすぎている感じがして、わかりにくい。他の3つのサービスは現在も使っている。
storagelogo.png
Dropboxは自動同期が基本で、インストールしているすべてのシステムでデータが同期されるのに対し、Google Drive、OneDriveは自動同期させるフォルダを指定する。Dropboxは無料の容量が小さいが、自動同期が基本だからデータ量が多いと各端末のローカル・ストレージもそれだけの量がとられるから、やみくもに大きくするのは良くない。他の2つは、単なるデータ置き場と、日常作業(刻々更新)用は分けて、後者のみ自動同期するのが良い。
いずれのサービスでも自動同期を行うにはクライアント・ソフトをインストールするわけだが、これはローカル・ストレージに同期フォルダを確保し、常駐の更新監視タスクがクラウド側をチェックし同期を行うという仕掛けと考えられる。

さてCloudfoggerの使用感であるが、暗号化を行う理由は、オンライン・ストレージに置くデータが万一漏洩しても、重要な情報が読めないようにすることで、Cloudfoggerが便利なのは、フォルダ単位で自動暗号化=当該フォルダにデータを保存(複写・移動も)すると、自動的に暗号化されること。
注意が必要なのは、オンライン・ストレージはいずれもWebからアクセスできるようになっているが、Webインターフェイスでデータをアップロードしても自動暗号化は働かない。推測だが、CloudfoggerはOSのファイルシステムの動作をフックしているようで、同期フォルダとしてOSのファイルシステム配下になければ自動暗号化の対象にならないと考えられる。
以上を図示してみた。
illust2.png

前にも書いたがAndroidでは自動暗号化はどうやら使えないようだ。前述の推測どおりとすると、同期フォルダがAndroidのファイルシステムとして認識されなければならないが、ESファイルエクスプローラーではファイルアクセスをフックできないようだし、クライアントアプリへのインテントも用意されていないようだ。

はじめに書いたように、Dropbox、Google Drive、OneDriveを使っているが、どうやらDropboxとOneDriveは今後も使い続けるだろう。
OneDriveのクライアントソフトは管理者権限がなくても問題なく動作するのだが、Dropbox、Google Driveのそれは、管理者権限のないPCでは動作しない。これでは自宅と職場(管理者権限なし)を行き来するには都合が悪い。さすがにMicrosoft、Windowsとの相性は良く出来ているということだろう。

結局25GBあるOneDriveがありがたく、20GBぐらいはデータ置き場にして、残りを同期フォルダとして使っている。さらに、その同期フォルダ中に自動暗号化フォルダを用意して、パスポートや運転免許証、保険証など、いざというときに必要な個人情報を暗号化して保存している。

foggersettings.png foggerfolder.png

Dropboxは歴史がありかつシンプルなので、動作が安定しているし支援アプリ(任意のローカルフォルダと同期するDropsyncなど)も多いのでこれも手放せない。
なお、Google Driveはデフォルトで使うとWord、ExcelデータがGoogleの形式に変換されてしまうので要注意でもある。

以前は、無料アカウントをそれぞれ取得して、オンライン・ストレージの容量をたくさん持とうとしたこともあるが、実用性から考えると、個人が持つ容量はそんなに大きくなくて良いし、いろいろ持っていると管理が面倒。結局DropboxとOneDriveに収斂してきたわけだが、Google DriveはAndroidで必須のGoogleアカウントを持っている限り使える状態にあるわけで、緊急避難場所として使うことになりそうだ。
関連記事

情報連携ネットワークにマイナンバーを流しちゃいけないのか

昨日は、通常の親が付ける名前と、役所が付ける名前(マイナンバー)があると考えて、公的手続にはマイナンバーを使ってもらえば良いと書いた。マイナンバーが流通することがイコール個人(属性)情報が漏洩することではないとも書いたつもり。しかし、国が考えているシステムはそう単純ではない。

mynum01.jpgシステムを見てみよう。
情報連携のリクエストは各機関別の符号を使い、マイナンバーを使わないことになっている。つまり異なる機関間では使っている符号が違い、機関Aが機関Bに情報連携する場合は、機関Aの符号で要求が出され、それをコアシステムが機関Bの符号に変換(*1)してから、機関Bへ伝達することになる。

情報連携ネットワーク上はマイナンバーを流通させないというコンセプトで作られている
マイナンバーは個人を決定的に特定できるタテマエだから、特定個人情報(マイナンバー付き個人情報)は簡単に名寄せができる(というかそれがマイナンバーの目的)。
各機関はもとよりだが、民間企業でも従業員等のマイナンバーは捕捉しているからネットを流れる特定個人情報を取得したら名寄せはできる。それを防止するため、マイナンバー自体が流れないようにするという趣旨である。

マイナンバー自体は秘密じゃないとしても、属性情報にマイナンバーが付属することが危険、これはわかる。しかし、これは属性情報へのアクセスを止めれば良いことであって、マイナンバー自体を流通させないということまで必要だろうか。

この目的だったら、暗号化して送る方法も考えられる。
機関Aが機関Bにマイナンバー付きリクエストを発信する際、Bの公開鍵で暗号化して伝達する
というシンプルな方法ではだめなのだろうか。

当然、国も考えたようだ。単純な暗号化だけでは、暗号が解読されるとマイナンバーが見える。現在のシステムは、万一暗号が解読された場合でもマイナンバーが人目に曝されることがないようにしたというわけだ。(なお、本当に解読できるならネットワーク・セキュリティは根底から崩れ、公的個人認証なども破綻する。考えられるのは秘密鍵の漏洩だろう)

また、副次的効果として、機関AからBへの情報が機関Bにしか読めないよう暗号化されているなら、さらに各機関とコアシステムの間はマイナンバーでなく符号で送る(効果は暗号化と同様)、とすれば二重に保護される(二重封筒)ことになる。
(なお、二重封筒にするかどうかははっきりしない。しかしコアシステムが機関AからBへの情報を読めるとすると、マイナンバーのあるなしに関わらず、コアシステムとしては越権行為のように思う。)
思うに、これだけ凝ったことをするのは、「勝手な名寄せさせない」を説明するために、マイナンバーは流通させないと言う必要があったからだろう。

なるほど、たしかに、良くできている、大変技巧的。だけど、複雑すぎる仕掛けは破綻しやすいとも思うし、コアシステムが新たなセキュリティ・バイオレーションのターゲットになる可能性もあるのでは。
情報連携ネットワーク外では流通する可能性の高いマイナンバーが、このネットワーク上では流れないというのはものすごい逆説だ。

また、やはり、経費が高すぎるのではないだろうか。それにこのシステム、住基ネットワークの存在が前提になっており、住基の改修でさらに経費が必要となることはあっても、住基ネットワークを廃止することはできない。コストはマイナンバーだけではないのだ。(マイナンバーを流通させれば住基ネットワークが要らなくなる可能性が高いと思う)

昔、住民基本台帳ネットワーク反対グループの方が次のように話していたことを思い出す。
「われわれはネットワークのセキュリティを問題にしているのではない。専用ネットワークを使わなくても、暗号技術を使えばインターネットでも安全な通信はできるはずだ。このネットワークに何百億円もかける値打ちがあるのか。われわれが求めているのは自己情報コントロール権である。」

そもそも、ネットワークからの漏洩の危険より、各機関での漏洩の危険のほうが大きいとも思える。それに、もし情報連携でなにか問題が起こったとき、機関AとBの間で電話やメールで「マイナンバー○○○の人の情報ですが」といったやりとりが、権限ある範囲すなわち業務上必要な範囲でだが、ありそうな気がする(それはやっていいのでしょうか?)。

マイナンバーが無くても、名寄せはいろんなところで行われている、これは止めようがない。
米国SSNの失敗は、SSNを知っていることをもって本人認証したことが原因と分析されているようだが、そんな子供でもわかる話ではなく、SSNによる名寄せが起こした問題などの調査はないのだろうか。(ドラマにはありそう、CIAとかが使ってひどいことになるなど)

多くの場合、セキュリティの議論は、何を守るかを忘れたところで行われる。
なぜなら、何を守るかという本質的な部分を明らかにすることができない(あるいはしたくない)からだ。

(*1) 符号変換
符号変換はコアシステムが各機関それぞれの符号に対応する「統一コード」を持っていないと難しい(統一コードが無いと、相対で変換することになる。2000機関あるとして、2000×2000=400万種類の対応関係)。この統一コードには住基コードが使われるようだ。
素直に考えればこれをマイナンバーにすれば良いのだが、マイナンバーは流通させないという縛りがあるから、住基コードを使うのだろう。住基コードは社会一般には流通しないタテマエだから万一漏洩しても、民間企業等はこれを使って名寄せすることはできないという理屈。

なお、住基コードを使う場合、直接、情報連携に参加する(すなわち符号をもらえる)機関は住基コードを持っていなければならない(法改正)。通常の組織はマイナンバーは持っていても住基コードは持っていないから、今後、情報連携を民間等へ拡大する場合、マイナンバーと住基コードを対応させる機関を介することになるだろう。

関連記事

マイナンバーとSSN

018_02.jpg混んでいるレストランでは、入口付近に用意してある順番待ちリストに名前を書いて待つところがある。このとき本名を書かず、歴史上の人物や、アニメの主人公の名前を書く人がいるそうだ。こういう場では偽名を使っても問題は起きない。その名前で呼ばれた人が自分のことであると認識できれば良い。
普通の店の取引は、店が提供する財と客が支払う代価は即時交換される匿名取引だからである。

問題になるとしたらリスト中に同じ名前がある場合。リスト上位の名前を騙って私ですと言って先に入るという悪質なやり口―行列に割り込むのと同じ―も考えられないことはない。だからといって、リストには携帯している身分証明になるものの名前を記入することと言うと、きっとやり過ぎと言われるだろう。
まして、そのリストにマイナンバーを記入しろということはありえない。

しかし、私は思う、国民一人一人に与えられるマイナンバーは流通させればいいじゃないか。親が付けた名前と、役所が付けた名前(マイナンバー)があり、公的・公共的手続きは間違いがないように役所が付けた名前を併記してください、それで何か問題があるだろうか。

佐村河内なんて珍しい名前だと、みんなその姓の人を色眼鏡で見るだろう、個人を特定できるだろう。田中や鈴木だったらいいのか。

一方で「名前の神秘性」という感覚があることも良くいわれる。
中国では、諱(忌み名)は通常使ってはならず字(あざな)を使わなければならない。
名前を知られたら魔力を失う・行使できなくなる民話(ルンペルシュティルツヒェン[グリム]、トム・ティット・トット[イギリス])も世界各地にある。
また、キャッシュカードでは、口座番号がわかれば簡単にカードの再発行ができてしまい実際それによって犯罪が行われたこともあるから、口座番号は隠せと言われる。

たしかに、そういう配慮も必要かもしれない。
しかし、神秘性はともかく、後者の例は、本人確認がきちんとできれば防げる話である。


遅ればせながら最近「マイナンバーがやってくる」という本(*1)を読んだ(Kindle電子書籍で)。そこには米国のSSNの失敗が分析されていた。(以下その引用)
h_220700.jpg「 番号制度の批判でよく引き合いに出されるのが、米国の社会保障番号(SSN)制度である。SSN 制度において「なりすまし」が多発した原因の一つは、SSN を提示することを本人確認に代えてしまったことである。SSN が普及する前は、SSN を知っているのは本人だけだと考えることに合理性があった。そこで、SSN を提示できることをもって、本人であると判断してしまった。つまり、単純にSSN を提示できることを本人確認手段としてしまったのである。(*2)
 しかし、SSN が広く普及すると、本人から開示を受けた第三者がSSN を知り得る状況が飛躍的に増加した。すると、本人しか知らないはずという前提が崩れ、なりすましが多発する状況となったのだ。
 マイナンバー制度では、SSN 制度のような運用は否定されている。第三者がマイナンバーを目に見える番号として取得する機会は少なくない。このため、本人のみが知ると考えて本人確認に利用するのは危険だ。マイナンバーを知っていることを本人である根拠とすることは間違っている。」


本書ではこれに続けて本人認証手段について書かれているわけだが、この分析を裏読みすると、番号自体が公開されていたとしても、その番号で個人情報へアクセスする場合、本人であることを確認すればSSNの犯した失敗は防止できるということであり、番号の流通を止める必要はないとも考えられる。実際、マイナンバーは税の源泉徴収や年金掛け金の天引きのために雇用主に知らせなければならず、番号が公的機関以外の他人に知られることは当然である。取扱事務者がそれを漏らしちゃいけないといっても、多分、徹底はされず、闇マーケットに流れることだろう。

ユニークネスが保証されている名前、それがマイナンバーだと言って良いのではないか。そしてそのコンセプトでシステムを作ればシステムコストは大幅に下げることができるだろう。(メーカーはそれがイヤなのか?)

以前、住民基本台帳ネットワークが導入されたとき、政府は、これは国民総背番号制とは違うと苦しい説明をし、それに対するクレームが市町村に多く寄せられたと聞いている。解釈で改憲できるぐらいだから、総背番号制だというぐらいたかが知れてる。正々堂々とマイナンバーは総背番号だと言えばいいのではないか。

(*1) 「マイナンバーがやってくる 改訂版」市民が主役の地域情報化推進協議会番号制度研究会 日経BP

(*2) 昔、アメリカのTVドラマなどで、登場人物が電話でクレジット番号を言うだけでホテルや飛行機の予約ができるシーンがあって、なんでそんなのでいいのか、と疑問に思ったことがある。また、私が20年以上も前、アメリカに行った時、KDD(当時)のカードを持っていって、そのカード番号を交換に伝えるだけで国際電話ができたことも覚えている。事前に難しいシステムを作るより、問題が起こったときの解決コストの方が安かった時代だと思う。その後、データマイニング技術などで悪質な利用パターンを選び出して取引を停止するなどが行われるようになったと聞いている。


(続く。 明日はマイナンバーの情報システムについて書く予定)
関連記事

「子供達にプログラミングを教えよう」

コンピュータ・プログラミングを学ぶことは、けっして人生のムダではない。
(数学を教えるより、プログラミングを教えるほうが多分、実用的だろう)
実際にプログラムを書くことが(COBOLで書くのは除く)、システム・センスを磨くもっとも確実な方法だと思う。そしてシステム・センスは、何度も言ってるが、あらゆる対象を理解し、言語化する普遍的に必要な資質である。

誰もがプログラミングを仕事にするわけでは勿論ないが、プログラムを書かないということと、プログラムを書けないということには大きな隔たりがある。そして、直接仕事に結びつかない技量を身に付けることができるのは、やっぱり学校で、無理やりにでも子供たちに覚えさせるというやり方だろう。(それでも多くの子供達はプログラミングに興味を持つことになると思う。特に、自分が書いたプログラムがすぐその場で動くという、他の教科ではなかなか味わいにくい体験ができるのだから)

タイトルの「子供達にプログラミングを教えよう」というのは、NHKの「スーパープレゼンテーション」という番組(既に終了)で放送された、TED(Technology Entertainment Design)のプレゼンテーションのタイトル。
MitchResnick.jpg

日本語訳がついた解説サイト(デジタルキャスト->TED日本語)もある。

Scratchというプログラミング言語(環境)を中心にした講演で、子供達がプログラミングを楽しんでいることが語られる。
また、講師レズニック氏の83際の母親が、Scratchを学び、息子のためにバースデーカードをプログラムして送ってくれたということも語られる。

ある大学の工学部の情報系学科の先生(プログラミング論)と話す機会があって、「この頃の学生はプログラム書きますか?」と聞いたら、手を横に振っておられた。
関連記事

W県は良い天気でした

昨日、2か月ぶりにW県で仕事。
自宅から3時間以上かかるので、次からは車で行くつもりだったが、仕事先で旧知の先生と合流して飲みに行くことになっていたので、また電車乗り継ぎ。

W駅でH線からW線へ乗り換えるのだが、W線の本数が少ないこともあって、W駅で降りて昼食をとることにした。
W県はWラーメンが有名。W駅の構内地下通路からW Mioの地下食堂街へ出られる。改札を出てすぐ、Wラーメンの店があったので、定番の「中華そば」\680を注文。食べログポイントは3.51と比較的高評価。口コミには塩からいという意見もあったが、たしかに少し鹹めだが、有名な古潭の鹹さと比べるとむしろ控えめに感じる。まず合格点である。(写真は食べログから)
marumimise.jpg marumiramen.jpg

2014_06_23_12_35_14.jpg
W線車窓からの風景、とても天気が良い。
最寄駅から仕事先まで歩くと10分ちょっと、日陰が少ないので真夏に来るなら帽子を用意すべき。


sugorokuya.jpg
2014_06_23_20_47_39.jpg
夜は約束どおり、某先生と飲みに。
仕事先の職員の推薦の店(食べログでは3.1点)。
さしみ盛り合わせが立派だった。
飲み始めて1時間ぐらいしたところで、アゴ?の開きが「サービスです」といって出されてきた。旅行者で飲み終わるのが早そうと見られたか、酒をすすませる陰謀かもしれない。(悪くないけど)


快速を逃したので、特急に乗ることに。在来線の特急は本当に久しぶり。


関連記事

チーフ・プログラマー・チーム

プログラミングはシステム開発の基本である、仮にプログラミング自体が発生しなくても。

昨日、プログラマー⇒システム・エンジニア⇒プロジェクト・リーダーという階層図を示した(同時に否定した)が、プログラマーの地位が低いというのは、こういう組織論をする人がシステム開発肝心要のところを知らないということなのだと思う。

昔、ソフトウェア・エンジニアリングというのがはやった頃の話だが、システム開発体制としてチーフ・プログラマー・チームというのが有名になったことがある。IBMがプロジェクトを組むときにはこの方式をとるらしい。
CPT2.png
その要点は、チーフ・プログラマーというある意味万能の存在がいて、この人がシステムの全体構成や中核的な部分(たとえばデータベース設計やキーテクノロジーの抽出など)を行い、それを支援するために必ずライブラリアン(ドキュメントを管理し常に最新状態を維持、他にテクニカル・ライティングも)を置く、そしてチーフ・プログラマーの配下に一般プログラマを置き、チーフの指示によってモジュールレベルの開発を担当する。

これが基本構成で、プロジェクトの大きさによってテスター(独立してテストを行う)、バックアップ・プログラマーを置く。せいぜい5~7名ぐらいのチームというわけだが、これで相当大きなプロジェクトを実施できるという。(1年働かせても1億円程度?)

もちろんプロジェクトがもっと大きければ、チームを階層的に設置する必要はあるのだろうが、基本はコンパクトな構成である。「遅れているプロジェクトに人員を投入してはいけない、遅れを酷くするだけだ」と言うが、プロジェクトを動かすには密なコミュニケーションが必要であり、いたずらに膨れ上がった体制は機能しない。
以前、「システムは一人でやるのが理想」と書いたが、チーフ・プログラマーはまさしくその一人である。

この方式の問題点は、多くの人が指摘しているが、チーフ・プログラマーの人材がいないことである。
関連記事

プログラマーとSE

前に本物のシステム・エンジニアがどういうものか書いたが、やはりそういう理解は世間の理解とはズレている。今日は世間的理解のSEについて、プログラマーとSEの関係について考えてみる。
se_kaisou.jpg
以前、プログラマー⇒システム・エンジニア⇒プロジェクト・リーダー(システム・インテグレーター)というようなキャリア・パスが説明されていたのだけど、私の感覚では、役に立つ順はこの逆である。

某民間企業の新採社員と名刺交換したとき、肩書にシステム・インテグレーターとあった。つまり、設計ができず、プログラムが書けない人のことを言うらしい。
実際に開発にかかわるSEに、ここをこうしたらすっきりするのではと提案すると、それにはプログラムを書かなければならないと言う。
結局、役にたつのはプログラマーということになる。

このごろのSEはプログラムを書かないらしい。想像するにこれには技術的理由と開発体制に起因する理由があるようだ。
技術的理由というのは、かつてのメインフレーム・コンピュータ時代は、その技術で統一的かつ斉一にシステムを開発していたが、今は多くのサーバーを組合せ、各種のミドルソフトを使って開発しているので、多様な技術が求められ、プログラムができればシステムがわかるという時代ではないということ。
開発体制に起因する理由というのは、プログラムを書くことが必要でも、それは海外の業者に委託することが多くなっていて、ユーザーサイドのSEがプログラムを書くことが想定されていない、また、その変更は海外への委託内容の変更あるいは追加発注となる。(絶対手戻りが発生すると忠告しているにもかかわらずウォーターフォール開発をやめようとしない)
関連記事

「やってもた」の経過(その2)

やってもた「やってもた」の経過に続いて、2回目の経過観察を受けてきた。

痛みは、日常生活ではあまり気にならないが、咳き込んだ時は痛む。また、起床時にも痛むが、刺すような痛みではなく鈍痛。折れた所が痛むというより、背部。
レントゲン所見では、右第6肋骨の折れた所はくっつきはじめてきている。前回疑わしいとされていたその上の第5肋骨はやはりヒビが入っているようだ。
状態は安定しているが、無理な力が加わるとくっつきかけのところが弾けることもあるので、おとなしくしていてください、とのこと。
IMG_20140621_095400_788.jpg IMG_20140621_095406_234.jpg IMG_20140621_095411_758.jpg

あまり痛まないと言ったので、「お守り代わり」に今までと同じ痛み止めと、湿布薬を処方してもらった。
1ヶ月で治るかと思っていたが、やはり歳なのだろう、もう少しかかりそうだ。
次の診察は、7月5日。また報告させてもらいます。
関連記事

Sleeping Lady

日本―ギリシアは引き分け。通勤電車の中でタブレットに付いているテレビ、フルセグは不安定なので、時々ワンセグ。
こういうイベントのときはやはりテレビの威力だが、通勤の慰みは普通は読書。通勤読書用の本が手元にないことがある。そういう時はタブレットで電子書籍を読むことにしている。
といっても、予めいくらかストックしておかないといざというときに電車の中で検索してダウンロードすることになるので、Amazon Kindleの無料本をときたまチェックする。以前は青空文庫をチェックしていたが、この頃は青空文庫がKindleに収録されてきているので、Kindleだけチェックすれば十分である。

そんなことをしていると、Kindleではpornographyも無料で配信されていることを発見した。このブログのカテゴリは、学校の教科を基本にしているわけだが、外国語のカテゴリはこれからもあまり成長しそうにないから、このことを書いて数を稼ぐことにする。

日本語のポルノ小説もあまり経験はないが、英語のpornographyは全く慣れない分野。そういう私のような人のために、試しにダウンロードした作品の一部分を引用して、その雰囲気を伝えることとしよう。もっとも、本来の目的である通勤電車内読書には不向き(スポーツ紙のエロ小説を読んでるオヤジをたまに見かけるけど)。
sleepinglady.jpg     His cock nudged into her entrance. He was so thick that she knew she was going to come whether she wanted to or not. Maybe not a big, body-shaking orgasm, but he wouldn't be able to miss her inner muscles gripping him. He pressed in, deeper and deeper, so slowly that the inevitable moment was barely kept at bay. Then he cupped her breasts, and she squeezed her eyes tight, her brow tense. His thumbs passed over her nipples, teasing them to eager little peaks. She was trembling, barely holding back.
     He rocked his hips back and entered her again. And again. She moaned, giving into her needs. Her legs involuntarily spread so she could better accommodate all of his girth, and she pressed her heels into the mattress, her body arching up and meeting his thrusts.

Cleo Peitsche "Sleeping Lady"


FannyHill.jpg描写が抑制的なのは、主人公は眠ったふりをしつづけるように言われているという設定のためだろう、女性にも読みやすい作品ではないだろうか。
Kindleは簡単に電子辞書(プログレッシブ英和中辞典、俗語もある程度収録)を引けるので便利、お試しあれ。

ところで、翻訳では読んだことのある古典中の古典"Fanny Hill"をネットで検索すると、Project Gutenbergに全文が採録されている。Project Gutenbergは米国版青空文庫だからKindleにも収録されているのではないかと考えて、あらためてKindleを検索するとやっぱり無料で配信されている。
("Sleeping Lady"に比べると長編だから読み通す気はおきないけど。)

なお、"Sleeping Lady"も"Fanny Hill"も売春防止法違反であり、この点では不適正な作品であることはいうまでもない。
関連記事

<堺雅人>16年大河「真田丸」の主演に決定 

<堺雅人>16年大河「真田丸」の主演に決定 という見出しが目に入った。
これは何かアップしなければ、ということで書きかけの予定稿は急遽中止。

多分、この役者さんを初めて意識したのは、NHK大河の「新撰組」の山南敬助役だったと思う。切れるけれど豪傑ではない山南だったと記憶している。
篤姫のときの徳川家定役は、本当は賢く気遣いできるのにそれを隠しているという設定。
いずれにせよ、豪傑からは程遠いイメージの役である。

堺雅人は、映画「武士の家計簿」出演時には、同名書著者の磯田道史氏が、時代劇では時代状況、人物像をものすごく勉強する役者と絶賛していたが、どんな真田信繁を演じるのだろう。

⇒モーフィングのGIFアニメ(出来は悪いけど)
sakai2.gif sana_10.jpg sana_20.jpg sana_30.jpg sana_40.jpg sana_50.jpg
関連記事

日本酒の古酒

デパートに買い物に行ったら、ちょっと変わったお酒が出ていた。
大七 生酛純米古酒「不倒翁」、4合瓶で1,728円(税込)
IMG_20140614_184801_351.jpg
平成20年に仕込んだ酒を長期保存したという触れ込みの古酒である。
ネットで調べると結構古酒ファンもいるようだ。純米大吟醸とは逆方向のように思うが、大吟醸ほど値段が高くないものが多い。(大吟醸の古酒もあるが)

「純米酒を極める」(上原 浩)によれば、しゃんとした酒(防腐剤無添加の純米酒)は冷暗所(日の当たらない押入れでも可)に置いておけば腐ることはないという。我が家ではそんなに長い間一升瓶に中身が残っていることなどなく、また、わざわざ危険を冒して置いておく勇気もないので、そういわれても試したことはないわけだが、蔵元でちゃんと熟成させたものなので安心して試してみた。
IMG_20140615_235139_693-crop.jpg

琥珀色をしている(冷の状態なのでグラスが曇ってる)。泡盛の古酒でもそうだが、年代物はどうして琥珀色になるんだろう。

常温ではやや酸味を感じる。
燗にするとやや香りにくせ(フルーティの反対)が出るように思う。酸味は抑えられる。
軽く冷えた状態だと当然だが、香味の揮発も酸味も抑えられる(感じにくい)。

大七の純米生酛は日本酒の標準で、燗をつけてすっきり飲めるくせのなさが気に入っているのだが、古酒になるとそれなりのくせが出てくる。
のど越しは、冷でも燗でも良い。元の酒の素性だろう。

常用するかと言われればNoだけど、ウナギのかば焼きのような濃い料理には良い(実際、ウナギをあてに飲んでました)。
関連記事

臨時給付金

消費税増税で相対的に不利益が大きいとされる低所得者への対策として、臨時給付金が支給される。
臨時福祉給付金と、子育て世帯臨時特例給付金で、前者は住民税非課税世帯が対象で1人あたり10,000円、後者は児童手当等を受給している世帯で一定所得以下の世帯が対象で1児童あたり10,000円となっている。

この手のばらまき制度は、増税法案を通すための政治的妥協の産物なんだろうと、受給対象とならない私などは冷ややかに見ている。もちろん受給できる人にとってはありがたい制度だと思うけど。

それにしても、居住地のK市では、その案内が全世帯に郵送されているようで、課税世帯であり、子供がとっくに社会人になっている我が家にも送ってこられた。まち全体でそんなに多くの対象がいるとも思えないから、相当数がムダな通知になる。
対して、通勤先のY市では、市役所で受給候補世帯を抽出したうえで、課税通知や受給通知に案内を同封する方法がとられている。
IMG_20140616_195458_122-crop.jpg IMG_20140616_195641_596.jpg


K市の通知文書の裏面には、税情報は高度なプライバシー情報であるからその情報を役所内で目的外利用することができない云々と言い訳が長々と書かれている。
対し、Y市では、そうした疑義が起きないよう税務担当が送付する形をとっている。

たしかに非課税世帯にだけ送付したら、送付されているという事実によってその世帯が非課税世帯であることを周囲に明らかにする可能性はある(「あんなに贅沢な生活をしているのに非課税?」というリアクションも考えられるし)。しかし、これは少々、気の遣い過ぎのようにも思う。
たしかに税情報については高度な守秘義務が課せられていて、同じ役所といえでも他部門が利用することはできないルールのようだが、かつては国税が所得番付を発表していたように、課税情報そのものは秘密ではなく、課税の根拠となる収入や生活の状況のほうが守られるべきプライバシーという考え方もある。(それが守られないなら適正な申告・課税が期待できないという理屈が立法趣旨で、制定当時に国民のプライバシーを重視したとは思えない。)

それはそうとして、このための事務を全国の市町村が行う。制度の周知、対象者(あるいは全世帯)への通知、対象者への支給事務。結構な費用がかかると思う。K市のように全戸通知とY市のような対象候補世帯のみ通知(しかも既存事務に同封)ではコストは随分違うだろう。(とはいえ、これらの事務費については、国費で補助されている。)

もっとも、消費税増税は地方消費税増税(1%→1.7%)も意味しており、予算ベースでH25とH26を比較すると、K市で5.8億→7.3億、Y市で26億→33億となっているから、その程度の事務をやるのは当然だということにもなるが。(税率が上がったわりに予算が上がってない理由は良くわからない)

ところで都道府県はそういう住民対象の事務とかせずに増税の恩恵を受ける、棚からぼたもちかな。
shohizei.png
関連記事

コンピュータ・システム・エンジニア

単にシステム・エンジニアでも良いわけだが、昨日書いたように、フォン・ブラウンのような仕事をする本物のシステム・エンジニアと区別するため、コンピュータ・システム・エンジニアとした。以後はSEと書くことにする。

さて、SEというのは特定の技能を指す言葉だろうか。世間で普通に使われているのはどうもそうではないようだ。コンピュータ周りで働く人で、金物をいじらない人をSEと呼んでいるように思う。
それで、SEというような一般的な名前では、職務やスキルを表していないという意見があり、最近はITSS(IT Skil Standard)などでは、ネットワーク、データベースといったITの専門分野のスペシャリストということで、ネットワーク・スペシャリストとかデータベース・スペシャリストと呼ぶべきという意見もある。あるいはSEを使う場合でも、ネットワークSEとかデータベースSEという具合である。こういう発想だと、SEは専門性が低く、ITスペシャリストより低い地位におかれている。

しかし、私が思うに、これはフォン・ブラウン型の本物のシステム・エンジニアに代わるものではない。現実にはフォン・ブラウン型のSEなどいないからといって、SEをITスペシャリストと言い換えて済む問題とは思えない。本物のシステム・エンジニアがいないという問題なのだ。
やっぱり、「私はシステム屋ですから」というシステム屋の矜持のようなものを期待したい。もちろん、「ネットワーク屋」とか「データベース屋」というのも立派な職能なのだけど、システムズ・エンジニアというのはそれとは違う存在として考えたい。

システム・エンジニアとITスペシャリストの違いは、言語学者と英語の先生の違いのようなものだ。生成文法と英語の文法の違いである。
Chomsky-crop.jpg
関連記事

システム・エンジニア

自分のことを「システム屋」と言うことがある。
昔、某コンサルの人(今は某大学の教授)が、会議や打ち合わせの席で「私はシステム屋ですから・・・」と言うのを時々聞いていて、便利な言葉だと思った。
その先生はその時どう思って使ったのかわからないが、「私はシステム屋ですから」というフレーズには「私は職人ですから」というニュアンスを感じる。整然とした理論体系があるわけではないが、経験と勘で最上のものを作ることには自負がある、そんな感じ。そして自分が慣れ親しんで体の一部になっている技術が、急激な技術革新で陳腐なものになって、もう直接には新しい成果を産むことはなくなる、残っているのはものづくりの智慧として昔語りになるようなものだけ、そういうところも職人的。

「システム・エンジニア」は、そういう卑下と自尊のコンプレックスが付着しないドライな言葉だが、システム・エンジニアというと必ず思い出されるのがアポロ計画のウェルナー・フォン・ブラウンである。
フォン・ブラウンは、自分の専門・職業は何かと聞かれたときに、システム・エンジニアだと答えたと伝えられている。
250px-Wernher_von_Braun.jpg

Systems engineering is an interdisciplinary field of engineering that
focuses on how complex engineering projects should be designed and managed.

(Wikipedia)

2年程前に、宇宙教育に関するイベントでJAXAの職員の講演を聴く機会があった。その方がフォン・ブラウンを意識していたかどうかはわからないが、ロケットを開発・打ち上げるプロジェクト全般を運用する仕事を説明されていた。
※ SE(システムズエンジニアリング)とは
システムの目的(ミッション要求)を実現するための工学的方法論(及び、その一連の活動)です。
なお、ここでいうシステムとは、ある目的を達成するために組織化された機能要素の集合であり、組織化により単なる要素和以上の特性を発揮するものです。(JAXA SE推進室ホームページ)

これらの例でわかるように、システム・エンジニアとは、システムあるところ、より正確にはあらゆる事象中にシステムを見出し、最適化までを考えるジェネラリストと考えるほうが良いと思う。

世間でいわれるシステム・エンジニアは、コンピュータ関係の技術者というぐらいの意味で使われる例が多い。そもそもシステム・エンジニアと名乗っている人でも、前述のようなシステムズ・エンジニアリングの意義を理解している人は少数で、「システム」は「コンピュータ・システム」の略だという意識なのではないだろうか。
ところで、講演されたJAXAの方は、「システム」と、を強調されていた(英文では通常複数形)。「コンピュータ・システムのエンジニア」ではないということを強調されたのだろう。
関連記事

「アプリ→データ」か「データ→アプリ」か

WindowsPCを使い慣れたユーザーは、ファイルを右クリックしてコンテキスト・メニューを出して、どのソフトで開くか指定する使い方をすることが多いと思う。例えば画像データについては、ちょっとレタッチするとか、サイズを変更するとか、一部をトリミングしようとか、何をするかによって使いやすいソフトが違ったりするので、コンテキスト・メニューはとても便利である。「プログラムから開く」でも良いが、1アクション減らすためソフトのショートカットを shell:sendtoに置いておく。
context.png

Androidにはインテントという機能があり、同様のことができる。Androidの場合はインテントで標準アプリを設定することもできるから、Windowsの拡張子からのソフト決定と同じことをインテントの設定で行うこともできる。
乗換案内とか天気予報、ネット放送といった専用アプリはともかく、オフィス系やエディタの類はファイルブラウザ(私はESファイルエクスプローラー)からインテントでアプリを選ぶのが私流。
share_2014-06-10-14-42-50-crop.jpg

iOSでも似たようなインターフェイスを持つアプリがあるが、iOS自体が任意のデータファイルに対してアプリを選択する機能はないと思う。iOSはまずアプリを選択し、次に処理するデータ(選択の余地なく決められたファイルである場合が多い)を選択する。

表計算ソフトは、初期にはLisaというソフトがあり、Multiplan、Lotus1-2-3、Excelと同種ソフトが競っていたが、今はExcelが完全に主流になったと思う。
この種のソフトでは、機能選択→何に、という操作方法と、対象選択→何を、という操作方法がある。どのソフトも両方の操作が混在しているし、まず機能を選ばなければデータの選びようがないものもあって、どちらを主に考えるかという違いにすぎないのだが、使い勝手は微妙に違うと思う。
Excelの基本は「何に対して何をする」で、他のソフトは「何をする、何に対して」が基本あるいは混在していたように思う。

私は「データ→アプリ」派である。

20年近く前のことだが、施設予約システムの開発を企画したとき、はじめにメーカーが用意してきたユーザーインターフェイスは、メニューを順に選択してから対象のコマを設定する(トップメニューが空き検索、予約設定、・・・とあって、次に施設選択、日付選択となるような)ものだったが、多分に個人的好みだが、端末の画面は予約状況を一覧表示する画面を通常の状態にしておくのが便利なはずだから、その画面からグラフィカルにコマを選んで予約を入れるような流れ、Excelのようなインターフェイスにしてほしいとお願いしたことがある。
メーカーにしてみれば開発方針の根本的変更になるわけだが、なんと、私の希望に応えてくれた(もちろん追加費用なしで)。当時はパッケージがなく、ほぼ完全なスクラッチ開発だったのでメーカーもいろいろ新しい工夫をした。
すばらしいSE達だった。
関連記事

2か月が過ぎました

Ikegami.png
ブログをはじめて2か月経過。
カテゴリもようやく落ち着いてきた感がある。

政治ネタは、賛否の分かれる問題については、どちらにも与しないよう読めるよう慎重に書いたつもり。
池上彰氏は、自分の意見を言わないということであのポジションを保っているそうだ。
(氏と比べるのはおこがましいですが。)

それにしても国政の議論を眺めると、やはり言論戦になっていないものが多いと思う―問答無用、力(数)の論理。詭弁を勉強して意図的にやってるのならまだしも、虚偽論理になってることを自覚してないなら救いようがない。

ところで、ここまで毎日1稿を続けてきて、いよいよネタ切れを心配しなければならなくなってきた。
ネタはまだいくつか用意があるのだが、文字原稿で、前にも書いたように、適切に絵や写真を挿入するのが難しい。

そこで、ブログ開始の月命日ということで毎月13日はお休みすることにした。
兄弟ブログ「語り得ぬ世界」も、稀に開店休業宣言されているから、まぁいいか。

と、月1回のお休みが、週1回になり、そのうち週休二日制になるかもしれないなぁ。

脈絡のない写真を載せて誤魔化すことにしよう。
IMG_20130812_091018_671-crop.jpg
(ハイデルベルク 2013/8/12)
関連記事

ポピュリズムのすすめ

論理や叡智が失われた時代の指導者が心得るべきことをいくつか考えた。

「人は自分の見たいものしか見ない」
塩野七生「ローマ人の物語」で何度も出てくるフレーズ。難しいことは大衆には解らない。彼らに「政治参加」の自負心・満足感を与えるには、彼らが見たいものを見せることが重要である。本当の政治家は、本当にやらなければならないことを大衆に解らせるような愚はおかさない。日本には戦争継続能力がもはやない状態で結ばれたポーツマス条約に対する大衆の怒りを思い出せば納得できるであろう。
romanstory.jpeg

とにかく攻撃すること
攻撃さえしていれば、頑張っている、改革勢力である、という印象を大衆に与えることができる。攻撃と反対とは違う。反対は基本的には守りであり、保守的な印象を与えがち。とりわけ社会全体に閉塞感が漂っているときには、とにかく現状が変わることに支持が集まるから効果的である。攻撃対象は「巨悪」であればあるほど良いが、特定の個人や組織を相手にして真実が見えてしまうような場合は避けた方が良い。

攻撃対象の選び方
攻撃対象としては、大衆から既得権益をもっていると見られているものを選ぶ。そうすればあなたが攻撃すれば大衆はその対象に向けて石を投げつけるだろう。

弱いものを攻撃してはいけない
本当に弱いかどうかは問題ではない。大衆が同情しているような相手を攻撃してはいけない。

枝葉末節から攻撃する
通常、法や社会的ルールの運用では、担当者の裁量範囲を抑えるように厳格(形式的)運用が行われるから、それを逆手にとって制度の抜け穴を使うことができる。こうした技術的欠陥はどんな制度でも避けることはできない。社会の制度やルールの攻撃では、その制度の目的は棚上げし、運用上の技術的欠陥にすぎないものを取り出し、その制度が不合理・不適正であると糾弾することができ、大衆の支持に結びつく。一旦支持を得られれば、本来の制度の目的に即した反論が出てくることが予想されるが心配することはない。「だからこそ改革が必要である」といって論点をすり替えれば、大衆の怒りを欠陥を放置した体制批判に向けることができる。そしてさらに追い打ちをかける、「その目的に沿ってきちんと改革しろ、それがお前の責任だ」と。

わら人形論法
わら人形論法とは、攻撃対象とは別のもの(わら人形)-攻撃対象といささか似ている点があるものを立てて、「似ている」を「同じ」とすり替えておき、そのわら人形を攻撃することによって、攻撃対象を貶める手法である。わら人形として使うものは、もちろん大衆から悪者という評価が定まったものを使う必要がある。
(使用例)○○○は旧帝国陸軍の参謀本部だ。やつらこそが国民を戦争に巻き込んだ張本人だ。○○○はつぶさなければならない。

一時が万事論法
攻撃対象が実際には既得権益集団というほどのものでなくても恐れることはない。細かいところをつつけば、必ず一部に悪事を見出すことができる。そのごく一部をとりだして全体がそうだという理屈にすれば大衆はついてくる。

思ったことをすぐ口に出そう
国民は自分たちの顔色を窺うような指導者は喜ばない。たとえ実態も歴史も知らないような施策でも気に入らないならすぐに攻撃するべきである。まったく見当違いのことを言っても心配することはない。前述の一時が万事論法がある。それでおさまらなくてもあわてることはない。反対者の努力を引き出すことができた、議論する良い機会だった、などと、最後まで強気で通せば良い。もとは指導者の乱心が招いた混乱であっても、指導者が最後にそれをおさめれば、すばらしい指導者だ、という評価を得られるだろう。

dictator.jpg
関連記事

ユネスコ記憶遺産

中国が「慰安婦」「南京大虐殺」関連文書のユネスコ記憶遺産への登録を申請するそうだ。
テレビのニュースでは、日本政府は、中国が政治的意図をもって申請しているなら、取り下げを求めるという報道を行っていた。
おそらく、中国からは「日本政府は政治的意図をもって歴史を抹殺しようとしている」という突っ込みを入れられることになるだろう。

Wikipediaによると、
世界記録遺産の選定における基準は以下のとおりである。
1次的基準
  1. 影響力
  2. 時間
  3. 場所
  4. 人物
  5. 対象主題
  6. 形態及びスタイル
  7. 社会的価値
  8. ほか

2次的基準
  1. 元の状態での保存
  2. 希少性
  3. ほか

文書の信憑性は当然確認されなければならないが、今までの、「あった」vs「なかった」、「30万人」vs「あったとしてもそんな数ではない」という議論が続いてきたことを考えれば、認定は難しいだろうと思う。認定できるほどの文書が出てくればそれはそれで水掛け論に終止符が打たれて良いと思うが、多分、そうはならないだろう。

歴史上の虐殺といえば、かの有名な十字軍によるコンスタンチノープルの大虐殺を伝える文書が歴史の本では良く引用されているけれど、こっちは記憶遺産になってるのだろうか。

我が国の登録遺産としては「御堂関白記」が有名で、かなり読み応えのある解説書も出たし、面白いところつまみ食いでベストセラーになった本もあるようだ(こっちは読んでない)。こういうのがやっぱりいいや。
9784062585675.jpg

そういえば、「憲法9条をノーベル平和賞に」という運動があるが、こっちこそもう少したったら、記憶遺産になるのかも。
関連記事

大都市再編は効率化を目的として良いか

大阪府・大阪市(さらに堺市も)を統合して大阪都にし、旧大阪市域をいくつかの特別区とする、いわゆる大阪都構想の議論を目に耳にする。
構想の賛否については措いておくとして、その議論は稚拙ですれ違い、あまり民主的ではない感じがする。

Osaka.jpg

推進派は、二重行政の無駄を一番の理由にあげているようだが、反対派はそもそも二重行政などないと主張する。改革イコール善vs急激な改革への恐怖、という雰囲気もある。また、市を特別区に分割することもセットの議論で、総合効率も問題だが、そのことはまたあらためて。

推進派が、二重行政として例示しているのは、文化振興や観光行政、商工関連情報施設、図書館、研究所、大学、同種外郭団体など。既に一部については統合や統一的な体制が創られている。

当初、二重行政と指弾された水道だが、府営水道は各家庭までの給水を行うものではなく、市町村水道への水を供給する(淀川を水源としてほぼ全府域)もので、給水設備が二重になっているわけではない。浄水場という同じ機能を持つものが2つあるのが無駄かどうかは、2つの浄水場の能力の合計が、それぞれの需要の合計を超えているかどうかで判断し、かつ、余剰能力を融通することができるかどうかによって評価すべきだろう。結局、統合ではなく府営水道の大阪広域水道企業団への衣替えとなったが、これが大阪市との関係のしこりにならなければ、と思う。

水道に限らず、一般に、府民・市民へのサービス機能は、同様のものがあるから二重とか、無駄というのはいささか結論を急ぎすぎるといわざるを得ない。サービス供給能力が需要に応じたものとなっているかを吟味し、余剰能力をお互いに融通できるかどうかといった効率性を評価するのが正しいと思う。供給過剰ならともかく、需要側が変わらないのに供給側を一方的に減らすことなど考えられないだろう。

役所のやることだから、府がやるべき、市がやるべきというべき論もあるだろうが、市民生活に必須のサービスだが市が担えないという場合は、府が補完するのが自治法の想定だと思う。大阪市ではそういう状況にはなくて、むしろ市のサービス供給能力は市民の需要以上のものがあると考えられる。いわば大阪府域における富の偏在で、ある意味、府としては指をくわえて見ている状況だろう。以前、大阪府の幹部職員には、大阪市域に府が投資する必要はないというような意見の人もいたと聞いている(それが悪いということではない)。

サービス部門以外ではどうか。

まず内部管理部門であるが、組織統合すれば管理コストが下がるかどうかは、一概には言えない。専門組織を作れるので効率が良くなるという考え方もあるし、組織が大きいとルールが複雑化してトータルコストが上がるという考え方もある。なお、ITの発達により内部管理コストは下がっているという意見もある。いずれにせよ、大阪府・大阪市はどちらも大組織で、それぞれ相当の内部管理コストをかけていると思われるから、コストは下がるのが普通で、下がらないとしたら組織編制を失敗したと言えるだろう。

統合を真剣に考えなければならないのは政策企画部門だと思う。これは効率の問題ではない(というか効率良く企画するなんてかなり怪しげ)、施策としての一貫性の問題である。観光行政では観光局がすでに一本化(民間も含め)されているが、観光振興は大阪府・大阪市が別々の戦略でやるより、大阪市内と衛星都市が相乗効果を発揮できるようにするのが当然で、政策企画部門の一本化には期待できる。多分、実働部隊(民間が主)には違いはなく、むしろ府、市それぞれから一貫性のない政策が出ればムダ、混乱のもとになるだろう。
政策企画部門で、おそらく一番大きいのは、広域交通体系に関するものだろう。私にはこれが府市統合の主目的のように思える。住民サービスは特別区に移すわけだから、大阪都により実質的に強化されるのはここだろう。

ところで、政令市というと、かつての六大都市は歴史的・経済的に堂々たるものだったと思うが、今や大安売り状態だ。これは府市統合とは逆向きのようにも思えるがどうだろう。また、政令市内に区長公選の「総合区」設置も議論されているが(これを歓迎する人もいるが、そうすると三重行政?)、一体全体、自治制度に一貫したコンセプトがあるのだろうか。

戦後日本に根付かなかったもの、民主主義と地方自治。(もう一つ、行政委員会制度)
関連記事

WiTVをセットしてみた

ビデオストリーミングについてネットで調べていたら、おもしろい製品を見つけた。
COSTEL WiTV CVS-150CA というもので、ビデオレコーダーのコンポジット出力をそのままストリーミングする機械。
ちゃんと動くかどうか半信半疑だったが、Amazonで3,100円だったので、衝動買いしてしまった。

家のビデオレコーダーにセットした様子がこれ。
丸い白いのがWiTV、レコーダーの前に黒いもやしのように伸びてるのがWiTVからのリモコン操作用赤外線発信器。これでWiTV側からリモコン信号を送るわけで、レコーダーのリモコンでできる操作はだいたいできることになる。
WiTVset.jpg

メーカーが出している専用アプリ(Windows、Android、iOS)があり、このアプリがリモコン付きのビデオストリーミング・プレイヤーになる。なお他メーカーの同様の機器では専用アプリが有料。

専用アプリは、家の外からのインターネット経由でもこの機械を探してくれる。機器ID(MACアドレスを修飾したものが使われているらしい)を頼りにしているようだが、多分、WiTVがメーカーに自分のIDを送って、メーカーがダイナミックDNSのような働きをするサイトを用意しているのだと思う。私の家では特に設定は不要だったが、環境によってはルーターのポートフォワード設定やハイポートの開放などが必要になると思われる。

画質は、最高で720pで、他に中画質、低画質が選べる。ネットの評価ではまずまずのようだが、3G環境では画質以前に接続切れ・再接続が発生するので実用上は厳しいと思う。接続切れ中でも源のビデオ・プレイヤーからは信号が出され続けているので再接続できるまでの分は跳んでしまうことになる。(だいたいSoftbankの4Gは本当にその能力が出ているのか疑わしい。3Gオンリーに設定するほうが早いぐらいだから)

ということでビデオストリーミングとしてはイマイチなのだが、WiTVはリモコン操作で電源On/Offができるし、録画予約操作もできるところが役に立つかもしれない。

ところで、これは以前、著作権法違反と判断されたネットによる再送信(会員制で会費をとって日本国内の放送をネット経由でストリーミング配信していたもの)と同様の仕掛けになるわけだが、個人が自分のために使うのであれば、おそらく違法とは言われないだろう(他人に使わせたらアウトかな)。実際、ネットで調べた使用例では、海外で日本の放送を見るのに利用しているという話が散見される。

これから入れてみようという人のためにいくつか参考になる情報を。

・ビデオレコーダーからはコンポジット出力がちゃんと出ていること
私の家のレコーダーではモニターにHDMIで出していてもコンポジット出力は生きて並行して出ているので問題ないが、そうでないものだと、出力設定が必要になるだろう。

・最初にソフトウェア・アップデート
はじめパスワードを入力しても反応しなかった。メーカーのFAQを見ると最新ソフトウェアにアップデートしないとそういう現象が起こるらしい。なお、アップデート操作は、Androidからでもできるような説明があったが、WindowsPCからでないとうまくゆかなかった。(Windowsでもすんなりとはいかず、「アップデート実行中」のまま終了しなかった。無理やりタスクを停止したが、アップデートは完了していたようで、以後はちゃんと動くようになった)

・Windows用アプリはインストールしておくこと
前述のとおり、ソフトウェア・アップデートはWindowsPCからやるのが良いので、Windows用アプリは必須。メーカーのサイトからダウンロードできる。なお、ビデオストリーミング再生するときには、ffdshow が必要(標準インストールで良い)になるので、インストールしておくこと

・拡張キー設定
リモコン操作は、ビデオレコーダーの機種ごとのプリセットがあるのでそれを選択しておくわけだが、拡張キーというのはそれにプラスしてビデオレコーダーのリモコン操作を記憶させる(アプリではなくWiTV本体に記憶)機能。WiTVの赤外線受発信部が信号を検知するので、それを覚えさせる(多機能リモコンと同様)。キーは15種類しか登録できないので何を登録するかは良く考えること(後から変更も可能だが面倒)。Windows版はキーは5×3で表示、スマホ版は3×5で表示されるので注意。

・iOSは要注意
iPod touchでテスト。パスワード入力するとパスワード変更を求められ、新パスワードを空で返せば良いのだが、メッセージがパスワード不正と出るので慌てさせられる。なお、画面のアスペクトがおかしい(縦長になる)。

というように接続・設定から実際に使えるまでは実は、結構てこずった。手順がわかっていれば30分もあれば十分だが、付属の説明書には肝心なことが書かれてないから、メーカーサイトを調べたり、ffdshowが必要というのもGoogle検索で見つけたりで、調査に時間をとられた。
ネットではいとも簡単に使えるような評価をしている人がいたが、だいたい最初にソフトウェア・アップデートをやらないと動かないなんてことは考えもしないから、それだけでも悩んでしまう。

私はテレビの美しい視聴、どこでも視聴とか、結構テレビ好きで、私のタブレットはDLNAクライアント(DTCP-IP対応)が入っていて、それを使って家のWiFiが入る範囲ならビデオを見ることができ、こちらの方がずっと綺麗に映る(ただしビデオレコーダーの電源を入れておく必要がある。また放送中のものを見ることもできないし、録画予約もできない)。その他、NASにビデオコンテンツを置いておくというのも可能だが、レコーダーからデータを取り出してNASに置くのは結構面倒だから実際にはやらない。また、レコーダーからスマホにコピーする機能もあるが、これも面倒だからやらない。

おそらくこのシステムを使って、外出先でビデオを見るなんてことはしないだろう、そんなものに3,100円出すのはモッタイナイ、こんなこともできるんだと人を驚かせて終わりだろうな。

(以下、Androidタブレットでの画面)
WiTV1-crop.jpg
標準のリモコン操作が表示されている

WiTV2-crop.jpg
これが拡張キー。自分でセットする。

WiTV3-crop.jpg
番組表は読みにくい。外出先で録画予約するなら別の画面で番組を確認したほうが良さそう。

WiTV4.jpg
これはWindows版のアプリ。

続きを読む

関連記事

「やってもた」の経過

先日、やってもたで肋骨を折った話を投稿したが、その後の経過。

昨日、整形外科へ行って、再度レントゲン撮影をして、経過などを診てもらった。
骨折個所はずれたりしていないので、このまま静かに暮らす、
寝起きなどに背中が痛いことがあるという愁訴に対しては、折れた場所だけでなく、強い衝撃が肋骨が接合している部分の胸・脊椎にもかかっているので、そういうことはしばしばあるとのこと。
内服薬(痛み止めのセレコックス、胃薬のムコスタ)を再度処方(ロキサニン湿布薬はまだ2週間分以上残ってる)してもらう。

次回の経過観察は21日。また報告させてもらいます。

IMG_20140607_092820_154-crop.jpgクリックで拡大 IMG_20140607_092820_154.jpg
○で囲んだところが2か所あるが、下の方が折れている場所。
上は写真では確認できない疑い箇所(ここが折れてても治療は同様)

ブログ初心者で投稿用写真を撮るのを忘れがちですが、今回は忘れず撮らせてもらいました。
IMG_20140607_092827_819.jpg IMG_20140607_141553_220.jpg

関連記事

バブル

少し旬を過ぎたが、岩崎日出俊「金融資産崩壊―なぜ「大恐慌」は繰り返されるのか」という本を読んだ。
中心となる記述は、大恐慌がどのように進み、どのように人々の生活を破壊したか。リーマン・ショック後の状況がどの程度似ているか(大恐慌より酷い状態という評価)など。
Iwasaki.jpg
そうしたことはともかく、この本の中でバブル現象を簡単なモデルで示している。

A、B、Cの3人が暮らす島がある。3人とも10円ずつ持っている、これが初期状態。この島の総資産は30円。
Step1 Aが綺麗な石を見つけ手に入れる。
Step2 Bがその石を欲しくなり、10円で買う。
Step3 Cがその石を欲しくなるが、Bは20円を要求、CはAから10円借りて、手もとの10円と合わせて20円で石を買う。
Step4 Aが石を買い戻したくなり、Cは30円を要求、AはBから10円借り、手もとの10円とCへの貸し金10円、合計30円で石を買う。
この時点で、Aは石(30円の価値)とBからの借金△10円、Bは10円とAへの貸し金10円、Cは20円を持っている。島の総資産は60円。

本ではここで、石が突然無価値になったとし、Aには借金だけが残るが返しようがないから破産、Bは債権回収ができないから10円、Cは20円をそれぞれ保有し、島の総資産は30円に逆戻り、と説明する。

シミュレーションはもっと続けることができるわけだが、要するに石を最後に売り抜けた人が得をし、石を持っている人はババを掴んだというわけ。

で、こんなことも考えた。
Aは借金をなんとかしたいから、石を証券化して1/3持分の証券を3枚作って、B、Cに売る。
Step5 Aは10円と石(1/3の権利)、Bは10円と石の証券(1/3)、Cも10円と石の証券(1/3)を持っている。
こうすれば石が無価値になっても、みんなが痛み分けになるんじゃないだろうか。
関連記事

兄弟ブログの主が越中・越後・信濃と回っている。
ブログを読むと上田城にも行ったとかいうので、お城に関係するおもしろい話を一席。
(上田城に天守はなかったと思うので、ちょっと外れですが)

社会人になって間もない頃に、ある講演を聴いた。講師は、構造計画研究所の服部正社長(覚えていた社名からググったら講師名も思い出した)。
30年以上前のことで、手元にメモがあるわけではなくうろ覚えだが、講演の内容は、講師の経験談、会社の話など。そういうとつまらなそうに聞こえるかもしれないが、これが結構おもしろく印象に残っているので、ご披露させてもらう。

講演は、いきなり次の言葉で始まった。
「メモとらないでいいです。みなさん復命書を書かなあかんのでそうされるでしょうが、レジュメ配ってますのでそれで復命すればよろしい。で、ここではレジュメと関係ないことしゃべります。」
 ……なので、私もメモはとらなかった。(とってたとしても30年以上前で、復命書も廃棄されてるだろう)

「最初は逓信省に入って、郵便局舎の建設関係の業務についたが、資材置き場でトラックが出入りするのをチェックする仕事だった。その後、設計事務所をはじめたがなかなか仕事はなかった。

「そうしているとどこかの町で、昔あったお城をもう一度建てたい、という仕事が舞い込んできた。その城なら、誰々が殿様で、その殿様はこういう人で、こんな事件があって、というストーリーが見えてくる。これはみんな学生時代から聞いていた講談のおかげ。といって古図面があるわけでもなく、建築法規上、何層もの天守を木造では作れないから、鉄筋コンクリートで作るわけで、復元とは言えない。それはともかく、講談も役にたつものだ。

(なお、その後、木造復元もできるようになり、構造計画研究所は本格的な復元をやっているようだ。ちなみに講談といえば、数学の森毅先生も東大の学生時代に良くいったらしい。江戸大衆文化が学生にも支持されていた時代だったようだ。)
wakayamajo.jpg
「ところがウチが城を建てたという評判が全国に広まって、あちこちの自治体から城を建ててくれという注文が次々に入るようになった。これで会社が順調にいくようになった。

「そうするとだんだん社員が増えてくる。だいたいは大学の建築学科を出てくるのだが、この頃は家政学部のようなところでインテリアデザインとかやってて、こういうところを出た女子学生が来る。これを建築少女と言ってる。
建物躯体は建築士でないとダメだから、内装の図面とかをひかせるのだが、実に行き届いている。台所なんかはすごく細かく書き込んである。あるとき台所の棚に縦に仕切りを入れてるのを見て、これはなんだ、ときくと一升瓶を入れるところという答え。良く見ると仕切りの左右で幅が違うので、なぜ幅が違うのかと聞くと、広い方は醤油の一升瓶、狭い方はお酒の一升瓶だと。そんなこといわれるまで気付かなかった、ほんとうに細かいところまで考えている。」

(余談。土木の人が言うには、土木工学、機械工学、電気工学、工学部はみんな工学科なんだが、建築だけは建築工学と言わず、建築学科という。やつらは自分たちを芸術家だと思ってる)

で、ここで突然本論に入る。

「私が家を設計するとガランとして何にもないといわれるけど、どう使うかなんて住む人が考えればいいじゃないか。このごろのメーカーがつくるソフトって細かいことまで考えてるかもしれないが、使いにくくってしようがない。その点ハードウェアはどんどん進歩してて、新しいハードが出たらすぐに入れ替えられるぐらい柔軟になってる。それに対し、ソフトウェアの方はあれができない、これができない、移行しようとしてもおいそれとはいかない、とても硬直化している。ハードがソフトになってるのに、ソフトはどんどんハードになっている。」

とまあ、こういう講演だったのだが、コンピュータの専門家より、ユーザーとして専門家である人の方がコンピュータを使うことを良く考えている、ということをコンピュータ素人の私に教えてもくれたというわけ。
関連記事

電子証明書の有効性(続き)

「リアル世界に実在する人間とのリンクがない電子証明書って、一体何だろう。」の続き。

部分的な答えの一つは、そういう証明書でも知り合い同士が了解の上なら、本人認証用として使用できる。
前回「社会的に○○と認識されている人、その本人が操作している」というのが電子証明書の意義だと書いたが、信頼できる第三者によって○○と認識されているという部分がなくても、知り合い同士において、これが私の証明書ということを伝えていれば、証明書の証明事項は何でも構わない(メール証明書ならメールアドレスは記載が必要)。
そして、それだけでも電子署名の効果(公開鍵暗号システムの原理から導かれる)はある。
電子署名の効果
・否認防止―電子署名を付した文書は署名者が発出を否認できない
・完全性―電子署名を付した文書は、その後に改竄されていない

実際、世の中には無料の電子証明書発行サービスがあり、このようなサービスでは、申請者へのメール到着以外に申請者を確認する手順は存在しない。つまり「社会的に○○と認識」という部分はないわけだが、それでも知り合い同士がメールを使う場合には問題はない(PGPを使うのと同じレベルだろう)。

問題は知り合いでない場合。
公的個人認証(JPKI)では、市町村の住民登録と照合して申請者の実在を確認、証明書に4情報を入れるわけだが、昨日書いたように現住所を公開することはリスキーという人もいる。(なお、JPKIは電子申請用途のため、メール証明書としては使えないことになっている)
もし、健全なネット社会で暮らすため、国民全員がJPKIの証明書を使えと言われたら、こういう人は困ってしまう。
ドイツの国民eIDではペンネーム(仮名)の電子証明書が出せる。最初は何のためなのかわからなかったのだが、本人認証の役割しか持たないのであれば仮名でも構わないわけだ。

知り合いでない場合は、相手を信頼するよすががないわけだが、市町村に住民登録しているからといって、その人の言うことを信頼できるだろうか。
できないだろう。そういう人が実在することが保証されれば、ある程度その人の言うことを信頼する根拠にはなると思うが、言うことすべてが信頼できるわけではない。
実務上も、センシティブな申請の場合、さまざまな情報をもとに申請内容の信頼性が判断されるのであって、電子証明書が申請内容の信頼性を保証することなどありえない。
つまり、証明書に書かれていることは、本人の実在と(何か問題があったときの)追跡可能性が高いことを示してはくれるが、それ以上の信頼を電子証明書に求めるのは過剰である。過剰な仕様はたいてい過大な投資・負担を招く。

たとえばJPKIでは転居すると失効することになっている(新制度ではどうなるのか、まだ調べてない)。JPKI証明書は現住所を証明事項と考えているから論理的にはそうなってしまう。
身分証明としてもっと頻繁に利用されている自動車運転免許証は、転居しても失効しない(転居の届け出は義務付けられているが)。
JPKIも失効させなくても良いのではないだろうか。電子証明書発行時点で、その人がその市に住民登録があったということを証明しているものと考えても、実在性や追跡可能性が著しく損なわれるとも思えない。(それより相続が発生したときに原戸籍をみんな集めて追跡しないといけないというほうをなんとかしてもらいたいものだ)

あたりまえの結論だが、JPKIをすべての電子取引やメールに使おうということにやはり無理があるのだろう。それより、民間認証機関が電子証明書を発行する手続きを電子的に行う場合にJPKIで署名を付ける、民間認証機関は本人の追跡ができる情報を保持した上で、住所を隠したい人にはそういう証明書を発行する、JPKIが用途としないメール証明書を発行する、そういう官民役割分担があって良いのではないだろうか。
(そしてそういうサービスがあったとして、元のJPKIが失効したら民間証明書も失効させるべきと考えるか?)
certsample.png
関連記事

電子証明書の有効性

昨日、利用者認証は、本人認証と権限認証に分けて考えるべきとし、その技術的意義としてシングル・サインオンを例として説明した。
このことはシステム実装上の問題だが、認証制度の利用秩序を考える場合も、本人認証と権限認証を分けると論点が明確になるように思う。

電子証明書を使用する認証制度について考える。
一般に、電子証明書には、本人認証と属性証明(権限認証に利用可能な属性情報の提供)の2つの機能がある。
本人認証は秘密鍵の保有者が本人であるという原理による。これは暗号システムが危殆化しない限り有効である。
属性証明はその証明書所有者の情報であり、通常は社会の中でどう認識されているか(「社会的に○○と認識」)について、証明書発行人がリアル社会の手段によって確認して記載する。
これにより、「社会的に○○と認識されている人、その本人が操作している」という利用者認証の意義を持つわけだ。

我が国には公的個人認証制度(JPKI)というのがあり、市町村が住民記録と照合して本人確認を行うことを前提に、都道府県知事が電子証明書を発行する。証明書は住基カードに収容され、秘密鍵のエクスポートはできない。(マイナンバー導入により、住基カードはなくなり、JPKI制度も変更されることになる)
jukicard.png
利用者証明書 詳細情報

[バージョン]
V3
[シリアル番号]
481F
[署名アルゴリズム]
sha-1withRSAEncryption
[発行者]
OU=the Governor of YYYYYYYYYYYYYYYYY
OU=YYYYYYYYYYYYYYYY
O=JPKI
C=JP
[発行年月日]
2009年8月6日15時09分55秒
[有効期間の満了日]
2012年8月5日23時59分59秒
[発行申請送信時刻]
20090806150437
[受付端末識別記号]
A
[主体者の公開鍵情報]
30818902818100AF7D0B35B3E94A6E02F27CA81A35D5B50F1F920FD089FF9BF4C0782FE1E7BE60D03B384B3DA561DFBB999DE2E35DB74BE6AC616FEEBDAB5DBE5D8C68EBB9146AA82FE917E2CACFF9DECB6C33469DD004B4CF14476F16BA7E2A34D66F5CBF1C5D8C8D491198CE4B8A24F2FE29810B1C1521D2215941414500BCE4EBF1C9C2B9730203010001
[鍵用途]
critical TRUE
digitalSignature,nonRepudiation
[主体者代替名]
critical FALSE
氏名 = ■■■■■■■
氏名代替文字の使用 = 00000
住所 = ○○○□□□□市××××××××××××
住所代替文字の使用 = 000000000000000000
生年月日 = ■■■■■■■■
性別 = 男
[証明書ポリシー]
critical TRUE
[1]certificatePolicies:
policyIdentifier=1.2.392.200149.8.5.1.1.10
[1,1]policyQualifiers:
policyQualifierId=CPS
qualifier=http://www.jpki.go.jp/cps.html
[発行者代替名]
critical FALSE
directoryName:
OU=○○○知事
OU=○○○
O=公的個人認証サービス
C=JP
[CRL分配点]
critical FALSE
[1]cRLDistributionPoints:
DistributionPointName:
fullName:
directoryName:
CN=XXXXXXXXXXXXX-shi CRLDP
OU=YYYYYYYYYYYYY
OU=CRL Distribution Points
O=JPKI
C=JP
[認証局鍵識別子]
critical FALSE
keyIdentifier=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
authorityCertIssuer:
directoryName:
OU=the Governor of YYYYYYYYYYYYY
OU=YYYYYYYYYYYY
O=JPKI
C=JP
authorityCertSerialNumber=xxxx
[主体者鍵識別子]
critical FALSE
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[sha1フィンガープリント]
CD431AF7D5CA3DAD0F3ABEEFEEA3B629B08BB742

JPKIの場合、証明情報は、名前、性別、生年月日、住所が入っている。このことに一見、不審な点はないように見える。
しかし、ある会議の席で、弁護士の先生が「この電子証明書には住所が入っているから、私のような仕事をしている者には使えない」と発言されていた。
なるほど、と思った。
ネット上での個人認知がメールアドレスで行われるなら、証明事項はメールアドレスだけでも良い。

一方で、リアル世界に実在する人間とのリンクがない電子証明書って、一体何だろう。

(続く)
関連記事

利用者認証=本人認証+権限認証

ネット・サービスでは、それが正当な利用者によって操作されていることを確認すること、いわゆる利用者認証が必要である。
利用者認証は、本人認証(確認)権限(正当性)認証という、2つの異なる機能に区分できる。すなわち
本人認証:端末を操作している人がシステム利用者として登録されているその本人であることを確認すること
権限認証:操作者がその人であることを前提に、その人に操作権限があるかどうかを確認すること

identify.png本人認証では、本人しか持たない情報を予め登録し、サービス利用時にそれを照合する。
本人しか持たない情報とは、本人の身体的特徴(指紋、網膜、静脈、顔、声紋など、いわゆるバイオ認証)、本人しか所持しないもの(操作用のカード、スマートフォン、電子証明書など)、本人しか知り得ない情報(パスワード)などのこと。このようにさまざまな手法があり、セキュリティ商品としてパッケージされているものも多い。

権限認証は、利用者の諸属性を登録しておき、その人にどういう権限で、どういうサービス利用を認めるかをチェックするものであり、セキュリティ技術ではなく、アプリケーションの仕様上の問題である。

多くのBtoCサービスは、家庭に特別な本人認証デバイス等を前提することができないため、普通はID/パスワード認証が使われる。通常これは利用者登録と表現され、IDの発行、パスワードの指定とともに、取引上必要な属性情報(決済方法、住所、メールアドレスなど)を登録する。IDとパスワードが本人認証にあたり、その他の情報はサービスを提供する場合の属性情報(決済方法によって手数料が違うとか、住所によって送料が違うなどという使い方もなされる)であり権限認証に利用される。

組織内システム(組織内ネットワーク接続、メール、勤態管理、出張届、その他組織内手続)では、利用者はその組織の構成員で、通常、所属部署や職階という属性によって利用できるサービスが異なる。このそれぞれのサービスが独立し、それぞれが認証システムを持っていては、利用者に煩雑なので、シングル・サインオンが望ましいとされる。

ところが、シングル・サインオンを標榜した統合システムはあまりうまくいっていない、という話を聞いたことがある。その原因の一つは、本人認証と権限認証を区別せずに考えたことにあるのではないだろうか。
システムを設計する人々の間でも、意外にこの区別が自覚されていないように思う。

この2つを分けずに考えると、認証用の情報には対象サービスすべてに使えるだけの個人属性データベースを用意することになるが、この組み合わせは新しいサービスができるたびに見直しが必要になるかもしれない。また、実装上は、ネットワークへのログオンを基本に考えることになるが、そのためのディレクトリは利用しているOSに依存するから、他の業務で使えるようにするには無理が生じるだろう。一方、業務アプリケーションはパッケージで提供される例が多く、その場合、パッケージが持つ利用者認証システムを使うのが自然で、これに多くの機能を付加することは現実的でない。

そもそもシングル・サインオンのねらいは、サービスを切り替える毎にID/パスワードを入れ直さなくて良いということでしかない。そのために認証システムを統合する必要などはない。Chromeなどのブラウザがやっているように、各サイト用のID/パスワードを記憶しているだけで十分である(一般家庭でもこれによりシングル・サインオンが実現されている)。
そこまで手を抜かなくても良いが、要は本人認証を各サービスの本人認証へリンクさせることができれば事足りる。各業務アプリケーションはそれぞれが想定する利用秩序に応じて、それぞれが権限認証について考えれば良いだろう。

繰り返しになるが、本人認証と権限認証の違いを認識し、自覚的に設計することがシステム屋の責任だと思う。
関連記事

テニス練習法


今の家に引っ越す前は、目の前が河川公園のテニスコートで、近所の人に誘われて週末テニスをやっていたことがある。
全くの素人がテニスを始めたわけなので、仲間がいろいろアドバイスをしてくれたり、上達法の本を貸してくれたりした。

ある本(書名は忘れてしまった)に、「一流のプレイヤーになれるわけはない、一流プレイヤーをまねることも無理、しかし一流プレイヤーを演じている俳優になったつもりでプレイすることはできる」、というようなことが書いてあった。蓋し名言である。
思うに、直接的に一流プレイヤーをまねるのでなく(錦織のマネなんかできるわけない)、自分が俳優になったつもりなら、失敗しても監督が「カット」と言ってくれるイメージで、案外、冷静に自分の姿を見ることができるのかもしれない。
tennistraining.png
その状況を絵にしてみた。
右から、モーリーン・コノリー、映画「リトル・モー」(コノリーの伝記映画。昔テレビで見た)、練習する初心者。

テニスに限らず、一般に自分を見ている自分をイメージすることは、冷静を保つのに良いと思うがどうだろう。
関連記事

モンティ・ホール問題とExcelシミュレーション

モンティ・ホール問題とは、
monty.pngプレイヤーの前に3つのドアがあって、1つのドアの後ろには景品の新車が、2つのドアの後ろにはヤギ(はずれを意味する)がいる。プレイヤーは新車のドアを当てると新車がもらえる。プレイヤーが1つのドアを選択した後、モンティ(司会者)が残りのドアのうちヤギがいるドアを開けてヤギを見せる。
ここでプレイヤーは最初に選んだドアを、残っている開けられていないドアに変更してもよいと言われる。プレイヤーはドアを変更すべきだろうか?
という問題。(Wikipediaから引用

モンティ・ホール問題と似たもので、3枚のレコード(アナログレコード!)の問題というのもある。
3枚のレコードがある。1枚は両面とも邦楽、1枚は両面とも洋楽、1枚は片面が邦楽でもう1面が洋楽である。どのレコードのどの面かは演奏するまでわからない。今、1枚をとって演奏したら邦楽だった。このレコードを裏返したときに邦楽になる確率は。


詳細はWikipediaをご覧いただくとして、モンティ・ホール問題でも専門家が誤りを犯すなど、この種の組合せ確率問題では直感(主観)が裏切ることがたびたびある。高校のとき、面白半分でもあるのだが、サイコロを振って答えが正しいかどうか確かめてみたりしたことがある。
サイコロを振って記録するのは結構面倒なものだが、今ならExcelを使って簡単に実験ができる。(Excelに内蔵されている乱数がどのように生成されているかはわからないがこの程度の実験なら問題ないだろう)

モンティ・ホール問題のシミュレーションMontyHall.png
関連記事
Gallery
検索フォーム

⇒記事一覧

プロフィール

六二郎。六二郎。


定年退職
苦しい家計の足しに再就職
=いつクビになってもええねん
 言うたもん勝ちや!のブログ
リンク
最新記事
最新コメント
最新トラックバック
アーカイブ
カテゴリ
タグ

ITガジェット 書評 マイナンバー Audio/Visual 

現在の閲覧者数
聞いたもん