« 2008年5月 | トップページ | 2008年7月 »

2008年6月28日 (土)

公務員は「サービス業」なのか?

公務員は「サービス業」であるのだから、個々の国民は、公務員に対し、色々クレームや注文をいう権利があるとか。

「公僕」という言葉のとおり、「広く公衆に奉仕する者」ではあるのでしょうけどね。あくまで、国民全体に対して奉仕するのであって、個々具体的な「国民」に対してではなく、つまるところ、特定の一国民が公務員に対し、何かを要求することはできないでしょう。

「俺 たち の税金」という言葉にあるように、勝手に「国民の代表」を称して、色々と主張する者があるわけですが。何の根拠もなく、自らをもって、世論を代表している気でいるとは、笑止千万でしょう。それこそ、選挙に立候補して当選した者であるのなら、まだ根拠はあるのですがね(アローの不可能性定理はともかくとして)。

しかしまあ、こうした考えの者が多数であるのなら、本当に公務員の「サービス業」化も考慮に値するかもしれませんね。

「サービス業」であるからには、支払った対価によって、サービスの内容が決まることになるでしょう。国民が支払う対価とは税金であり、税金の額は主として所得によって決まるわけですから、所得別に受けられるサービスの内容を決めることになりますね。

厚生労働省の所得再分配調査によりますと、税・社会保険料による拠出が受給を上回るのは、年間所得が600万円あたりの所得階級からであるようです(平成17年度調査 p.8 にある 「図5 当初所得階級別所得再分配状況」を参照)。

これと、所得税の課税所得を考慮して、以下のように分けると良いかもしれませんね。

  • 1級市民 年間所得が 1,800万円 以上
  • 2級市民 年間所得が 900万円 以上
  • 3級市民 年間所得が 700万円 以上
  • 非市民 上記に該当しない者

市民の等級によって、行政から受けられるサービスが変わるというわけです。非市民は納税を完全に免除して、そのかわりに、一切のサービスを受けられないとしますと、国家財政も著しく改善をみることでしょう。

納税額によって市民を等級分けするというのは、19世紀あたりまでの「自由主義国家」においては、普通にあったはずであるわけでして、応益負担 ― 得られる益に対し応分の負担をする ― という考えから、自然と導かれる発想ではあるのでしょう。こうした考え方が変わって来たのは、第一次世界大戦あたりからでしょうかね。

確かに、昨今は19世紀以前の「自由主義国家」への回帰と思えるようなことを、主張する者もあるわけですから、上記のようなことも本気で検討に値するのかもしれません。

私はまっぴらごめんですけどね。

| | コメント (0) | トラックバック (0)

2008年6月26日 (木)

後期高齢者医療制度の設立趣旨

正直、私もよく理解していないのですけどね。

何かと問題の多い後期高齢者医療制度ですが、そもそも老人保険料の現役世代の負担を減らすことが目的の一つであったはずです。

しかし、実際には業界・業種によっては、かなりの数の健康保険組合が後期高齢者医療制度による負担金増加のために、この4月から保険料値上げを余儀なくされているのが実態のようです。

これでいいのか?後期高齢者医療制度で低所得ハケン労働者が負担増 (木走日記)

「現役世代の負担を減らす」のは、確かに「目的の一つ」なのでしょうけども、それは、将来の若年世代が「過大な負担」をすることのないよう、という話でしょう。つまり、今現在の負担を減らす、というような話ではなく、今後負担が急激に増加するのを抑える、ということではないでしょうか。制度導入当初は、むしろ負担増となるのは別におかしな話ではなく、制度変更によって料率が変わるなら、当然ある話ではないでしょうか。

これは、「健康保険料率を平成19 年度の 61/1000 から 76/1000 へと大幅に引き上げること」を意味しています。

【略】

組合員数45万人、平均年齢34才のこのハケン健保ですが、その平均年収は280万円という、決して多くはないのが実態です。

これでいいのか?後期高齢者医療制度で低所得ハケン労働者が負担増 (木走日記)

実際には、年収に料率をかけるわけではないのでしょうが。まあ、額的には、だいたいこんなものではないでしょうかね。

改定前)

280万円 × 61/1000 = 170,800 円/年

170,800 ÷ 12 = 14,233 円/月

14,233 ÷ 2 = 7,116 円/月 (労使で折半)

改定後)

280万円 × 76/1000 = 212,800 円/年

212,800 ÷ 12 = 17,733 円/月

17,733 ÷ 2 = 8,867 円/月 (労使で折半)

政府管掌健康保険よりは、まだ安そうですね。国民健康保険に対しては、言うに及ばすでありましょう。

元記事の人材派遣健康保険組合の資料にあるとおり、国民健康保険へ負担が集中するのを避けるのが、制度の趣旨であるわけですから、組合健保の保険料負担が増えるのは、制度の趣旨どおりなのではないでしょうかね。

1 制度改革の背景とねらい

(1) 高齢者の医療費は若人の5 倍も高く、高齢化の進行により国民医療費は増加の一途をたどっていますが、高齢者は国民健康保険(国保)に集中するため、特に国保の財政維持が難しくなっています。

(2) 増え続ける高齢者の医療費について、被用者保険(健保組合、政管健保、共済組合)と国保との負担の均衡を図るのが制度改革のねらいで、その結果、健保組合の負担が急増することになります。

(3) 同時に、75 歳以上の後期高齢者からの新たな保険料の徴収や、74 歳未満の前期高齢者の患者負担の増加で、高齢者と若人の負担の公平を図ることにしています。

厚生労働省の資料では、以下のように説明されていますね。おそらく、制度発足当初は負担増となることは、説明されていたのではないかと思いますが。

(1) 後期高齢者医療制度における後期高齢者の保険料の負担率と若人が負担する後期高齢者支援金(若人の保険料が財源)の負担率は、制度発足時は後期高齢者は1割、若人は約4割である。

(2) しかし、今後、後期高齢者人口は増加すると見込まれる一方、若人人口は減少すると見込まれるため、後期高齢者の負担分は支え手が増えるが、若人の負担分は支え手が減っていく。したがって、仮に後期高齢者の保険料の負担率と後期高齢者支援金の負担率を変えないこととすると、後期高齢者一人当たりの負担の増加割合と比較して、若人一人当たりの負担はより大きな割合で増加していくこととなる。

(3) このため、「若人人口の減少」による若人一人当たりの負担の増加については、後期高齢者と若人とで半分ずつ負担するよう、後期高齢者の保険料の負担割合について、若人減少率の1/2の割合で引き上げ、後期高齢者支援金の負担率は引き下げることとする。

「後期高齢者負担率の改定方法について」 『後期高齢者医療制度の概要』 p.11 第1 回社会保障審議会 後期高齢者医療の在り方に関する特別部会 平成1 8 年1 0 月5 日

組合健保の負担を加入者割りで一律にしたのと、国民健康保険、被用者保険、老人保健制度の関係を整理して、広域連合化したという点は、健康保険組合の効率化を図るという観点から、評価して良いのでは、と思います。75歳以上に限定している点は、疑問は残りますけどね(ただ、今回の制度から、というわけでもないのでしょうけど)。

高リスクの被保険者である後期高齢者は、どの保険組合でも「お荷物」になっていて、この点、各保険者の間で政治的に合意しやすかったのかもしれません。個人的には、後期高齢者に限定せず、若年者も含めて、健康保険組合の整理統合、広域化を図っていくのが良いのでは、と思うのですけども。それが、「国民医療の効率化」の本筋ではないですかね。診療報酬引き下げなどより、よほど合理的な手段ではなかろうかと。

| | コメント (0) | トラックバック (0)

2008年6月20日 (金)

思想・市場・暴力

社会の成員内で、生産・分配を行なう手段としては、思想・市場・暴力の3種があり、この3種のバランスによって、社会における「適正な分配」というものが実現されてる、と思うのです。

さらに、だ。関係者が何百何千何万人となったら、そいつらがみんなで話し合って決めたりするのは実質的に不可能だ。2ちゃんねるで何か合意を得てごらん。そもそも、だれが話し合うべきなの? 何を? そしてそんな世界になったら、ぼくはどれほど大量の話し合いを強制されるわけ? 今飲んでいるペットボトルの水を作るのですら、ぼくはいったい誰と話をしたらいいのかさえわからない。水の精製業者に PET 生産者に射出成形業者にラベル業者に...... やってられませんって。お金を通じた市場のよさは、情報のチャネルをしぼることで多くの人々の協力関係と合意を得やすくできること、なんだけれど。

そしてその一方で、値段なんて一つの数字でしかないと思うかもしれない。確かにそれは完璧じゃない。でも、それはみんなが集会を開いて学級会のまねごとをするよりもはるかに豊かな情報量を持っている。

研修資料の余白に:『はだかの王様の経済学』は戦慄すべき本である (山形浩生)

山形氏の書評は、「コミュニケーション・チャネルとしての優劣」という点だけをみているところに、問題があるのではないでしょうかね。

コミュニケーションの手段として、市場よりも強力なものがあって、それは暴力ではなかろうかと思うのです。なにせ、暴力というのは、言葉が通じない相手にも通用しますし、相手は人間である必要すらないという、「優れもの」であるわけです。市場経済という社会機構すら必要ではないですしね。暴力によって、生産を行い、暴力によって、分配を行なえばよろしいわけです。

社会全体を考えれば、暴力による恐怖政治よりも、市場経済による方が良いといえるのかもしれません。が、一部の力のある個人、特権的地位にある個人にとっては、暴力によるほうが、自己の利益を最大にすることができるかもしれませんよね。旧共産主義国において、一般市民が食糧を得るために長い行列を作る一方、「特権階級」の共産党幹部は、お城に住み、召使にかしづかれ、贅沢の限りを尽くしていたように。

市場経済の価格メカニズムは、個人が自己の利益を最大にするよう行動すると、結果として社会全体にとって最適な分配が実現される、と説明されています。しかし、個人が自己の利益を最大にするよう行動するのであれば、それが市場の枠内である必要はどこにあるのでしょうか? 自己の利益を最大にするべく、暴力を行使する、という選択肢も当然ありますよね。なぜ、その選択肢は選ばれない/選ぶべきでないのでしょう?

少々白々しいですが、言いたいのは、市場というものは、自然発生的に生まれたものではなく、それ自体が、ある種の思想の上に成り立っているものではないか、ということです。思想というより、信仰という方が適切かもしれません。それは、自由・平等・博愛といったような、現代日本ではシニカルな目で見られている、そういったものだと思います。西洋社会というのは、基本的に「キリスト教国」の社会である、という点を、私達はしばしば失念しているようにも思うのですよね。

文化とは何であろうか。思想とは何を意味するものであろうか。一言でいえば、「それが表すものが『秩序』である何ものか」であろう。人が、ある一定区域に集団としておかれ、それを好むままに秩序づけよといわれれば、そこに自然に発生する秩序は、その集団がもつ伝統的文化に基づく秩序以外にありえない。そしてその秩序を維持すべく各人がうちにもつ自己規定は、その人たちのもつ思想以外にはない。

山本七平著, 『日本はなぜ敗れるのか − 敗因21カ条』, 角川書店(2004), p119

この本で、山本七平氏が、戦犯収容所の経験から、日本軍の「無思想ぶり」を指摘しています − 実は、この本のこの箇所でも、マルクス主義が出てきているのですが。

将校、一兵卒、朝鮮人・台湾人のグループにそれぞれわかれて、収容所内で「自治」を行なうよう、求められるわけですが、この中で、一番酷かったのが、将校のグループであったといいます。当時は希少であった、高等教育を受けた人達が、収容所内で「暴力団」を作り、暴力に基づく恐怖政治を行なっていて、まことに酷い状況であったとか。

日本人のなかでは、一兵卒の中で、職人のグループが、もっとも立派に収容所内に秩序を作っていて、朝鮮人・台湾人のグループも秩序正しく運営されていたといいます。また、将校であっても、日本の捕虜収容所にいた、英米オランダ人などのグループも、収容所内では、秩序正しい生活を行なっていたとか。

日本人の高等教育を受けた人々は、収容所内で、ろくに秩序を生み出すことができなかったわけです。この理由として、明治以降の「文明開化」にあって、かっての日本の伝統的思想を封建的であるなどとして退けたが、外国の輸入学問を行なうばかりで、結局、伝統的思想に代わるべき思想を得ることがなかったからであるとしています。

翻って、現代にあって、日本人の無思想ぶりには、さらに拍車のかかっている感があるわけでして、上の山形氏の書評においても、「手段としての利便性」という面からしか考えられていないように思うのですよね。これは、私も同様でして、思想・市場・暴力といったものを、便利な道具程度としか考えていなかったりします。しかしながら、こうして、無思想にあらゆるものを「便利な道具程度」としてしまいますと、「暴力を選ばない理由」というものが出てこないように思えるわけでして、それがやはり問題なのでしょう。

| | コメント (0) | トラックバック (0)

2008年6月19日 (木)

エビデンスの無視

「死刑執行 ハイペース」と題する、日経新聞の記事に、町村信孝官房長官のコメントが掲載されています。

「近年凶悪な犯罪が多い、死刑判決が増えてきたということへの対応の一つの姿」とし、死刑執行が犯罪の抑止につながるとの見方を示した。

日本経済新聞 2008/6/18 43面(社会)

「死刑執行が犯罪の抑止につながるとの見方」は、官房長官のコメントからは直接導き出せませんので、この記事を書いた記者の見方である可能性はありますが。

2/1に警察庁が去年の犯罪統計を発表したんですが、殺人の認知件数は1,199件で平成3年の1,215件を下回って戦後最低を記録しました。

平成19年(2007)の殺人発生数は戦後最低 (少年犯罪データベースドア)

「凶悪な犯罪が多い」というのが、何を指すのか明らかではありませんが、殺人については、戦後一貫して減少、もしくは横ばい傾向であるようでして、統計上、「凶悪な犯罪が多い」という事実は存在しないようです。

また、刑罰の「重罰化」により、「犯罪の抑止につながる」という説も、エビデンスによって否定されています。学生時代に、「刑罰に犯罪予防の効果はなく、刑罰の存在は、もっぱら応報により説明される」というのを読んだ記憶があったのですが、最近の報道に接していると、記憶違いだったかと思えてきまして。改めて、調べてみましたが、少なくとも、「重罰化」によって犯罪抑止は期待できない、というのは事実であるようです。

2004年にナッシュビルで開催されたアメリカ犯罪学会では、学会長を中心とするグループによる刑罰による犯罪抑止効果の総合的検証プロジェクトの中間報告がなされていた。そこでは、40以上の抑止効果の実証研究をメタ分析を用いて検証していたが、重罰化には統計的に有意な犯罪抑止効果はなく、刑罰の確実性についても抑止効果は期待できないという結果が報告されていた。その際に、会場から「これだけのエビデンスがそろっているのに、どうして人は同じ過ち(重罰化)を繰り返し続けるのだろうか。」という質問が出された。

浜井浩一編著, 『犯罪統計入門』, 日本評論社(2006), p.34

確か、私が学生時代に読んだ犯罪学の本は、図書館にあった古い本で、1975年くらいに出版されたものであったと記憶しています。最近になって、違う研究結果が出された、というわけでもないようですね。

| | コメント (0) | トラックバック (0)

教育支出の費用効果分析

今朝の日経新聞『経済教室』(2008/6/18 朝刊27面)で、「教育支出の効果分析を」と題し、慶応義塾大学 赤林 英夫氏(経済学)が寄稿されています。

「教育政策」の費用効果分析とは、政府の教育の支出が、どの程度、学力や生活水準の向上に寄与しているか、その効果の計測と予測を行なうことである。効果を金銭価値で示すことができる場合、「費用便益分析」と呼ばれる。

としまして、「教育の社会的収益率」なる表が掲載されています。

教育投資の社会的収益率(%)

国のグループ(平均所得) 小学校 中学高校 大学
高所得国(22,530ドル) 13.4 10.3 9.5
中所得国( 2,966ドル) 18.8 12.9 11.3
低所得国( 363ドル) 21.3 15.7 11.2
世界平均( 7,669ドル) 18.9 13.1 10.8

(出所)G・サカロポロス、H・パトリノスの世界銀行ワーキングペーパー(2002年)

「教育投資の社会的収益率」とは、 「政府の追加的教育投資により、将来どの程度の所得水準の向上が平均的に見込めるか、利回りベースで示した指標」とのことでして、「高所得国も含め、初等中等教育への投資の収益率が相対的に高い」とあります。

私はこれを読んで、「高所得国」にあっても、初等教育への投資が、最も「高収益」が期待できる、というのは、少々意外の感がありました。日本のような先進国にあっても、下から底上げを図るのが、結局は、国民所得の向上に資することになり、つまりは、労働生産性の向上が見込める、ということなのでしょうかね。

| | コメント (0) | トラックバック (0)

2008年6月15日 (日)

ブロートウエアの法則とか、バッチ処理とリアルタイム処理とか

「100のうち50」でいいと言うと、大半のユーザにとっては「ほとんど全部」なんですね。

たとえば、あなたの会社のパソコンに誰かがイタズラをして、MS-Officeをアンインストールして、代わりに「100のうち50」のExcelやWordをインストールしておいたとしたら、あなたは気がつきますか?

たぶん、「100のうち50」のレベルでExcelを使っている人は、相当なパワーユーザです。職場では「Excelの達人」とか呼ばれて、「困ったことがあったらとりあえずあいつに聞け」と言われているような人で、ほとんどユーザはそれ以下でしょう。

だからMS-Officeは「100のうち50」で充分。

予告.inをSaaSワールドの予告として見る (アンカテ)

実際のところ、「100のうち50」どころか、ほとんどのユーザは、「100のうち20」のくらいの機能しか使わないでしょう。しかし、問題は、 ユーザによってその20が異なる、ということではなかったかと。もっと言えば、各ユーザにとっての「必須の機能」が、ユーザによって違っているわけですよ。

多くのソフトウェア開発者は昔ながらの「80/20」ルールに魅了されている。80%の人々は20%の機能しか使わない、というのは大いに意味があるように 見える。それであなたは20%の機能だけ実装すればよく、それでも80%は売れると思い込む。

残念ながら、それは決して同じ20%ではないのだ。みんな 異なる 機能セットを使っている。過去10年間、互いに学ばないと心に決めた 何ダース もの会社が、20%の機能だけ実装した「ライト版」ワードプロセッサをリリースしようとしたのを聞いてきた。

【略】

あなたが「ライト版」の製品のマーケティングを始めて、「どうです、軽いでしょう。たった1MBだ。」と人々に言い、彼らはとても喜んで、それが彼らにとって必須の機能を持っているか聞くが、それがないと分かると彼らは買わない。

ストラテジー・レターIV:ブロートウェアと80/20の神話 (Joel on Software)

「ExcelやWord」といったソフトウエアは、全世界に一億近いユーザがいて、そうしたユーザがそれぞれ異なる 20% の「必須の機能」を持っているわけですね。

ついでに、もうひとつ。

障害があって止まることは許されても、トランザクションの途中経過を外に見せることは許されません。上記の送金の処理中、口座Aから引いた直後にシステムが止まってそのまま復旧したら、私は無一文になってしまいます。

この「トランザクション」という制約の為に、単純な足し算引き算のプログラムを作るのに、凄く高度な技術が必要になります。

ところが、グーグルはこれを捨てています。

グーグルの「計算」は何がこれまでと違うのか (アンカテ)

トランザクション処理に、「凄く高度な技術が必要」になるのは、リアルタイムに応答しなければならないから、だと思います。

利用者がデータを入力したら、1秒以内に応答しなければならない、とかですよね。レスポンスタイムを短くするために、色々と複雑な仕組みが必要になってくるわけでして。そのために、スループットは犠牲とならざるを得なくなっています。

例えば、1,000人分のデータを処理する場合、レスポンスタイムが問題ではないのであれば、直列に処理すれば、スループットは最も高くなるでしょう。”1,000人分のデータを処理する時間”というのは、それが一番短い、ということです。その代償として、個々の利用者は、1,000人分のデータ処理が完了するまで待たされることになりますけどね。

GoogleがWebページをクロールし、検索インデックスを作る処理の場合、 レスポンスタイムよりも重要なのは、スループットであるはず です。巡回先の全Webページをインデックス化するのにかかる時間が問題のはず。

つまり、これは本質的にバッチ処理でしょう。 Googleのインデックス化は、相当高速には実行できるようになっているのでしょうが、それでも、(レスポンスの)リアルタイム性は要求されていないわけです。処理としては、大規模な科学技術計算などが近いのではないですかね。地球シミュレータでやっているような。

| | コメント (0) | トラックバック (0)

「かぐや(SELENE)」 on Celestia - Part4

ようやくプログラミングへと辿り着きました。

が、実際のところ、やることはほとんどないのですよね。色々と調べてわかったのは、「かぐや」軌道データは、ほぼそのまま Celestia で使える、ということでして。プログラミングといっても、「かぐや」軌道データファイルを Celesita の XYZファイルへと変換するだけです。

>ruby traj2xyz.rb KAGUYA_Traj.txt >selene_jaxa.xyz

traj2xyz.rb は、以下のとおりです。

require 'date'

ARGF.each do |line|
  if line =~ /^(\d{4})-(\d{2})-(\d{2})T(\d{2}):(\d{2}):(\d{2})\S+\s+(\S+)\s+(\S+)\s+(\S+)/
    dt = DateTime.new($1.to_i, $2.to_i, $3.to_i, $4.to_i, $5.to_i, $6.to_i)
    printf "%#.5f %#.4f %#.4f %#.4f\n", dt.ajd.to_f, $7.to_f, $8.to_f, $9.to_f
  end
end

KAGUYA_Traj.txt は「かぐや」軌道データを時間順にすべてマージしたものでして、例えば Windows コマンドプロンプト では以下のように作成します。

>type KAGUYA_Traj\0709140216-0709142013.txt >KAGUYA_Traj.txt
>type KAGUYA_Traj\0709142013-0709152300.txt >>KAGUYA_Traj.txt
>type KAGUYA_Traj\0709152300-0709180000.txt >>KAGUYA_Traj.txt
>type KAGUYA_Traj\0709180000-0709190056.txt >>KAGUYA_Traj.txt
【以下略】

| | コメント (0) | トラックバック (0)

「かぐや(SELENE)」 on Celestia - Part3

「かぐや」軌道データについてまとめます。

データ形式

「かぐや」軌道データの形式については、JAXAより以下のように情報が提供されています。

CCSDS勧告文書 ”CCSDS 502.0-B-1 RECOMMENDATION FOR SPACE DATA SYSTEM STANDARDS”1 をみますと、以下のようにあります。

3.2 OPM CONTENT

The OPM shall be represented as a combination of the following:

a) a header; b) metadata (data about data); c) optional comments (explanatory information); and d) data.

CCSDS 502.0-B-1 Page 3-1

OPM というのは、 ”ORBIT PARAMETER MESSAGE” の略です。ヘッダ、メタデータ、コメント、そしてデータ行から成るものであるようです。

Keyword Description Units Obligatory
EPOCH Epoch of state vector & optional Keplerian elements n/a Yes
X Position vector X-component KM Yes
Y Position vector Y-component KM Yes
Z Position vector Z-component KM Yes
X_DOT Velocity vector X-component KM/S Yes
Y_DOT Velocity vector Y-component KM/S Yes
Z_DOT Velocity vector Z-component KM/S Yes

データ行は、時点、位置ベクトル [x, y, z]、 速度ベクトル [x', y', z'] から成るものであるようです。

「かぐや」軌道データ

「かぐや」軌道データの内容について調べます。メタデータの部分をみると、データ行の意味がわかるようになってるようです。

まず時刻(EPOCH)ですが、[かぐや」軌道データでは、以下のようになっています。

TIME_SYSTEM = UTC

UTC というのは、 ”Coordinated Universal Time” の略であるようです。

It is tied to TAI by an offset of integer seconds (called seconds (called 'leap seconds'), which is regularly updated to keep UTC in close agreement with UT1 (within 0.9s).

”CCSDS 500.0-G-2 NAVIGATION DATADEFINITIONS AND CONVENTIONS” Page 4-102

いわゆる、世界時(Universal Time) であると考えて良さそうです。

座標系について、「かぐや」軌道データでは、以下のようになっています。

CENTER_NAME = EARTH
REF_FRAME = EME2000

EME2000 というのは、 ”Earth Mean Equator and Equinox of J2000” の略であるようです(CCSDS 502.0-B-1 Page 3-3)。この座標系がどんなものか、説明した資料を色々と探したのですが、適当なものがみつかりません。 Google で検索するとメモ的なものは出てきます。

The Earth Mean Equator and Equinox of Epoch J2000 inertial reference system is a right-handed Cartesian set of three orthogonal axes chosen as follows:

  • +ZEME2000 is normal to the Earth mean equator at epoch J2000
  • +XEME2000 is parallel to the vernal equinox of the Earth mean orbit at J2000
  • +YEME2000 completes the right-handed system.

The epoch J2000 is the Julian Ephemeris Date (JED) 2451545.0.

JPL Interoffice Memorandum 15 July 1999 312.B/015-993

ユリウス暦2000年時点で、

  • z方向は赤道面からの北極への垂線
  • x方向は赤道面から春分点への平行線
  • y方向は右手系による

ということのようですね。

原点はどこになるか

さて、以上でだいたいのところは調べたのですが、最後に「かぐや」軌道データの原点がどこにあるのか、確認してみたいと思います。おそらく、地球の中心であると思うのですが、資料上でははっきりしませんでしたので。

「かぐや」軌道データの一番最初の時点での、位置ベクトルの長さを計算してみます。

>ruby vectsize.rb 3.381801563861468E+03 -4.822172015202145E+03 -3.237785869454149E+03
6721.09976848816

地球の半径が、 6378.142 km ですから、この時点で地上から 300 km ほどのところにいることになります。原点を地球中心にとっても良さそうですね。

なお、 vectsize.rb は以下のとおりです。

include Math

x = ARGV[0].to_f
y = ARGV[1].to_f
z = ARGV[2].to_f

puts sqrt(x**2 + y**2 + z**2)

ついでに、1時間ごとに、位置ベクトル、速度ベクトルそれぞれの長さを計算してグラフにしてみました。

07

月と地球の間の距離は 38万4,400km だそうです。4 地球のまわりを2回周り、段々と遠ざかりつつ、月へと向かう様子がわかります。また、地球に近づくほど速度が上がるのは、万有引力の法則どおりですね。


1. http://public.ccsds.org/publications/archive/502x0b1.pdf

2. http://public.ccsds.org/publications/archive/500x0g2.pdf

3. http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20010056226_2001089749.pdf

4. 月 (Wikipedia)

| | コメント (0) | トラックバック (0)

2008年6月14日 (土)

「かぐや(SELENE)」 on Celestia - Part2

Celestia に天体の軌道データをどう入力するか、という点についてまとめます。「かぐや」の軌道データを入力するために、必要最低限のことだけを調べました。

Celestia のデータファイル

以下の種類があるようです。

  • STC (STar Catalog) files tell Celestia where to draw stars.
  • DSC (Deep Space Catalog) files tell Celestia where to draw Nebulas, OpenClusters and Galaxies.
  • SSC (Solar System Catalog) files tell Celestia where to draw planets.
  • XYZ and Spice trajectory files tell Celestia where to draw SSC or STC objects. They're an alternative to using EllipticalOrbit definitions.

    A (not so) Brief Introduction to Celestia Addons (3rd edition)

太陽系内の天体については、 ”SSC (Solar System Catalog) files” を使えば良いようですね。

SSCファイル

Celestia includes its own SSC files in its \data\ directory to define the solar system: all of the planets and many of their moons, along with asteroids, comets and a few spacecraft. The solar system's planets and moons are defined in the file named solarsys.ssc in Celestia's data directory.

A (not so) Brief Introduction to Celestia Addons (3rd edition)

SSCファイルは、 %CELESTIA_HOME%\data 以下にあるようです。例えば、国際宇宙ステーション(ISS)は、 spacecraft.ssc 内で、以下のように定義されています。

"ISS" "Sol/Earth"
{
        Class "spacecraft"
        Mesh "iss.3ds"
        Radius 0.040
        Beginning           2451138    # Zarya module launched 20 Nov 1998
        # Ending ????

        EllipticalOrbit {
                Period          0.064176392
                SemiMajorAxis   6767
                Eccentricity    0.0016886
                Inclination      51.5684
                AscendingNode   343.1518
                ArgOfPericenter 346.2476
                MeanAnomaly      13.8216
                Epoch           2452028.18381755
        }

        UniformRotation
        {
        Inclination    51.5684        #
        MeridianAngle  90             # orientation corrections by Matt McIrvin
        AscendingNode 343.1518        #
        }

        Albedo        0.10
}

”SSC-Scripting Guide (Version 1.0)”1 によりますと、 ”EllipticalOrbit” 要素により、地球中心からの極座標で、天体の位置・速度が定義されているようです。なお、地球中心が原点となるのは、先頭で "Sol/Earth" が指定されているからで、地球以外の惑星や太陽を原点とすることもできるようです。

「かぐや」軌道データは、 [x, y, z] のデカルト座標系によって与えられています。この場合、 ”EllipticalOrbit” 要素の代わりに、 ”XYZ and Spice trajectory files” が使えるようです。

spacecraft.ssc 内より例を探すと、 ”Cassini” の ”SampledOrbit” 要素に XYZファイルが指定されています。

"Cassini" "Sol"
{
        Class "spacecraft"
        Mesh "cassini.3ds"
        Radius 0.011

        InfoURL "http://saturn.jpl.nasa.gov/home/index.cfm"

        Beginning 2450736.893877314 # 1997 Oct 15 09:27:11

        SampledOrbit    "cassini.xyz"

        FixedRotation { }
}

”Radius”要素は、天体の半径をキロメートル単位で指定するようです。”Beginning”要素は、天体軌道の開始時点を、ユリウス日で指定するようです。

XYZファイル

cassini.xyz ファイルを見ると、以下のような形式となっています。

2450736.8939 138193070 56107309 -424
2450736.8946 138192732 56108444 -386
2450736.9008 138189870 56119338 35
【以下略】

カラム一番目がユリウス日で、二番目以降は、 [x, y, z] とデカルト座標系での天体の位置をキロメートル単位で指定したものであるようです。

  • The xy plane is the planet's equatorial plane at the reference epoch J2000 (For the Earth it is the orbital plane on Jan 1, 2000).
  • The x axis points at the ascending node of the equatorial plane on the ecliptic.
  • The z axis is perpendicular to the xy plane and points to the planet's north pole .
  • The y axis completes the right handed coordinate system.

    Guide to Celestia Data Files by Thomas Guilpain 2

座標系は、ユリウス暦2000年時点で考え、

  • xy平面は赤道面
  • x方向は、惑星中心より赤道と黄道が交わる点(春分点)へ向かう方向
  • z方向は、惑星中心より北極方向
  • y方向は、右手系をなすようにとる

となるようです。


1. http://www.celestiamotherlode.net/creators/bhegwood/SSCGuide.zip

各種のドキュメントは、以下にあります。

http://www.celestiamotherlode.net/catalog/documentation.html

2. 以下ですが、広告がうるさいです。間違って広告をクリックしないよう気をつけてください。

http://members.fortunecity.com/guilpain/Fichiers%20xyz_uk.htm

| | コメント (0) | トラックバック (0)

2008年6月13日 (金)

「かぐや(SELENE)」 on Celestia - Part1

Celestia というのは、オープンソースの3D天文シュミレータでして、以下のサイトからダウンロードできます。

Celestia Home

JAXA のサイトで、月周回衛星「かぐや(SELENE)」の軌道データが公開されています。このデータを使って、 Celestia で「かぐや」の軌道をシミュレートしてみよう、と思い立ちました。

月周回衛星「かぐや(SELENE)」の軌道データの提供について (JAXA宇宙教育センター)

作ったものはこちらです。 Celestia の Add on の形になっています。

selene_jaxa.zip (833.9K)

Celestia のインストール

インストールといっても、 上記サイトからダウンロードした、Windows用のインストーラを使ってインストールするだけです。ただ、 Celesita は、3Dの描画を OpenGL ライブラリで行なっており、この点は注意が必要です。つまり、インストール先PCに搭載されている、ビデオカードとそのドライバが、 Celestia の要する OpenGL ライブラリ機能をサポートしていない可能性があります。

私の試した環境は、以下のとおりです。

バージョン Celestia 1.5.1 (Windows)
OS Windows XP
PC TOSHIBA dynabook Qosmio E10/1KLDEW
ビデオカード NVIDIA GeForce FX Go5200

最初に上記環境で、 Celesita を起動しますと、 "Driver component sizes mis-match" と、 OpenGL ドライバのエラーが出て、起動できませんでした。予想がつきますが、ビデオカード関係は、FAQのいの一番であるようです。

Q1:

Celestia crashes, what it draws is messed up or it's extremely slow. What can I do?

A1: Celestia makes use of the most advanced features of OpenGL that the graphics driver claims to support. Unfortunately, many OpenGL implementations have serious bugs in the new code for those advanced features.

Therefore, the very first thing to do is to

a) Upgrade to the most recent drivers for your graphics card.

A preliminary Celestia User's FAQ

ということですので、 ”the very first thing to do” の ”a)” に従い、ドライバのアップデートを行なうことにしました。

dynabook Qosmio E10/1KLDEW, E10/1KCDE ディスプレイドライバ(NVIDIA GeForce FX Go5200)のアップデート

私の環境では、これで起動するようになりました。

「かぐや」軌道データ のインストール

”selene_jaxa.zip” ファイルをダウンロードし、展開しますと、 ”selene_jaxa” というフォルダになります。このフォルダを、(その中身ごと)以下のファイルパス以下にコピーします。

%CELESTIA_HOME%\extras

なお、"%CELESTIA_HOME%"は、 Celestia をインストールしたフォルダです。

フォルダをコピーした後、 Celestia を起動すると、 「かぐや」軌道データが読み込まれます。 メニュー ”Navigation” -> ”Solar System Browser” を実行して、 ”Solar System Objects” -> "Earth" を展開すると、 "Selene" というオブジェクトが見つかります。これが「かぐや」です。

01

スクリーンショット

「かぐや」軌道データは、 2007年9月14日 02:16(UTC) より始まります。日本時間では、9時間プラスですから、11:16 ですね。ちなみに、打ち上げ時刻は、 10:30 です。

以下はこの時点の画面です。わかりにくいかもしれませんが、 中心にある赤い丸が 「かぐや」です。

02

太陽電池パドル展開。 2007年9月14日 11:44 (日本時間)。

03

周期調整マヌーバ1回目。 2007年9月19日。

04

月周回軌道投入マヌーバ。 2007年10月4日 06:20 (日本時間)。

05

月周回軌道への投入。 2007年10月19日。

06

| | コメント (0) | トラックバック (0)

2008年6月 7日 (土)

個人でできることは個人でやり、集団では集団でしかできないことをやる

後からプレゼンのデータ、チャットのログ、要点まとめWiki、完全なまとめWiki、授業を受けた人のblog記事、塾講師のフォーラムでの授業後の議論等を収集するので十分だ。授業中はノートにコピーする機械になるより、話を全力で聞いて、全力で突っ込んだり議論したりと頭をはたらかせていた方がいい。(この突っ込み力、議論力、まとめ力、も評価したいし、できるだろう。ジョーク力なんかも評価したいが)

無駄だらけの現代授業を最適化しよう (高校生奮闘記)

今の授業を見てみると、要するに物凄い『受け身』の授業だと思うのだ。基本的には先生が板書し、説明しているだけ。生徒的にはそれこそブラウン管の向こうのものを見ている感覚に近い。こういう授業では殆ど頭を使わない(俺だけかもしれないけどね)。これをもっと双方向的な授業にしたいのだが、今は構造的にそれが出来ない状況になっている。

授業の最適化について捕捉 (高校生奮闘記)

このエントリを読んで、まさに私が高校生ぐらいの時分に、体育会系の友人が語っていたことを思い出しました。

日本の部活動では、ランニングや、筋トレなど、一人でできるような基礎トレーニングも、いちいち、部員全員を集めて集団でやっている。時間の無駄だと思う。一人でできるようなトレーニングは、各自でやれば良いのであって、集団でやる必要はない。集団でやるのなら、連携プレイや、フォーメーションなど、集団でしかできないトレーニングをやるべきだ。実際、欧米ではそうするのが普通らしい。

当時は、なるほどなあ、と感心したものなのですが。これって、学校の授業にも当てはまるのではないですかね。

学習というものを、知識のインプットとアウトプットに分けますと、インプットの部分というのは、一人でもできるんですよね。教科書でもノートでも参考資料でも、インプットすべき内容を渡して、それを生徒が各自で勉強してくればよいわけです。

しかし、アウトプットの部分に関しては、一人でやるのはなかなか難しいわけです。日本の学校では、アウトプットといえば、ペーパーテスト(だけ?)になるかと思いますけど。他にも、ディスカッションですとか、プレゼンテーションですとか、色々あるんですよね。

欧米の学校の授業というのは、ディスカッションが中心になっていると聞きますけど、それは、上のような考えに基づいているのではないでしょうかね。つまり、ディスカッションの題材となる知識については、各自で教科書なり参考資料なりを事前に勉強してくることになっていて、授業ではそれを前提に集団でディスカッションする、という形になっているのでは、と想像するわけです。

インプットの部分は、ITツールを使うことで、”高速道路論”にいうように、現在よりももっと効率化し、浮いた余裕を、アウトプットにまわしたい、ということだと思いましたけどね。正論と思います。

日本の教育が座学、つまりはインプットに偏重していて、アウトプットといえば、ペーパーテストぐらいしかない、というのは事実でしょう。この方式のメリットは、コストパフォーマンスの高さであろうと思います。少数の教師で多くの生徒を相手にすることができますからね。まさに大量生産方式でして、”教育工場”とは言いえて妙です。

| | コメント (0) | トラックバック (0)

2008年6月 5日 (木)

プログラマの採用

PHPプログラマが見つからない、とお嘆きのようです。

We've been through all job sites, newspapers, local and foreign forums, and recruiting agencies, trying to find the candiate. We haven't found even one. At least three are needed right now. More will be needed in the nearest future.

Where did all the PHP programmers go? (Blog of Leonid Mamchenkov)

エントリ後半では、例のごとく、PHPという言語を攻撃し始めるのですが...

それよりも、”市場”で見つかる候補者の”質”についての部分が本質的のように思います。

What I cannot understand is why people with more than one Bachelor Degree in Computer Science recommend using bubble sort.

曰く、コンピュータサイエンスの学位を持っている人達が、バブルソートを使うことを薦める理由がわからない。

And what I don't understand is why technical people with years of team work, get pissed off or burst into tears when you ask them a technical question, and a simple one at that, during the job interview.

If you are wondering what sort of questions I've been asking, here is an example. A simple questions would be something like: "What is the difference between the stack (also known as FILO) and the queue (also known as pipe, also known as FIFO)?". Most of the answer is already in the questions, isn't it?

曰く、「スタックとキューの違いについて説明してくれ」 といったごく簡単な”技術的な質問”に答えられない。

アメリカでも、まともなプログラマが”市場”にいない、という話はときどき聞こえてきますよね。

どうしてプログラマに・・・プログラムが書けないのか? (Jeff Atwood / 青木靖 訳)

優れた開発者を見つけるには (Joel Spolsky / 青木靖 訳)

Joel Spolsky 氏の以下の見解には、私も賛成します。

優れたソフトウェア開発者というのは、実際のところ他の分野でも最高の人材というのは、単に マーケットには出てこない ものなのだ。

優れたソフトウェア開発者は、その全職歴を通して、 たぶん 平均で4回くらいしか職に応募しない。

【略】

数値的に言えば、優れた人々はごく少なく、彼らは決して求人市場に現れない。無能な人々は、たとえ彼らが 同じように数少なかったとしても、 その職歴を通して何千という職に応募する。だからねスパーキー、Craigslistの履歴書の山を見直してごらん。そのほとんどが雇う気にならないような人だったとしても、それは驚くようなことだろうか?

日本の場合は、もっと雇用流動性は低いわけですが。この辺の事情は同じだと思います。

優れた人は、責任のある仕事を任されるわけで、そうした仕事は一年や二年で終わったりはしませんし。普通、仕事が一区切りつくまでは、会社を辞めたりはしないでしょう。会社の側も、そうした人を簡単に手放したりはしませんしね。どこも、優秀な人は囲い込もうとするはず。私も基本そうします。

それに、優秀な人というのは、自分で動かなくても、色々なところから声がかかるでしょうから、そもそも、”市場”を通らずに、コネで職場から職場へと動くんじゃあないかとも思います。

プログラマを雇おうとする側からみると、雇用流動性などというようなものには全く期待できない、と思います。結局、”市場”よりコネじゃないですかね。

| | コメント (0) | トラックバック (0)

2008年6月 4日 (水)

自社開発でノンプログラミングを実現

『システム開発 JOURNAL Vol.4』(毎日コミュニケーションズ, 2008.5) の特集「作らない開発」で、NECビッグローブの事例が取り上げられているのですけど。

曰く、

  1. 機能を徹底してAPI化
  2. 独自の ESB (Enterprise Service Bus) を構築
  3. API呼び出しのための、独自の言語(マッピング言語) を作成
  4. 画面構築には、 Visual Frame を採用

によって、ほぼノンプログラミングを実現したとか。

最初に全体を見通してユースケース分析を徹底的に行います。そして、必要な機能や画面の分析を詳細に行い、その結果を図表形式で書くことが、NECビッグローブの社員の仕事です。

でまあ、「実際の開発はパートナーに任せています」ということだそうで。

一方で、

自社のシステムを自分たちで作っているため、ノウハウを蓄積して部品などを用意できました。外部に委託した開発ではこうした動きをとることは難しいでしょう

ともおっしゃっているわけでして、何だか矛盾している感じではあるのですけど。この場合、システムのアーキテクチャやコアコンポーネントについては、自社で開発したということなのでしょう。一度出来てしまえば、拡張は容易なため、拡張モジュールの開発、画面構築は外注している、となりますかね。

プログラミングの理想というのは、”一度作ったら同じものは二度と作らない”というものでもあるわけでして、自社に理想的なソフトウエア・アーキテクチャを開発することができれば、プログラマは不要になる、ということなのかもしれません。ある意味では、プログラマの仕事というのは、プログラマを不要とするための仕事、ということでもあるような。

| | コメント (0) | トラックバック (0)

2008年6月 3日 (火)

三菱東京UFJ銀の障害は切り替えミス?

『日経コンピュータ』(2008.6.1) 「ニュース&トレンド」に1ページの記事が載っていました。何でも、「未来バージョン」のモジュールを誤ってリリースしてしまったとか。

今回の障害で、セブン銀ATMで使えなくなったキャッシュカードは、旧東京三菱銀のものなのだそうでして、旧UFJ銀のものは問題なく使えていたとのことです。もともと、統合前にはセブン銀との接続は以下のようになっていたとか。

  • 旧東京三菱銀 : NTTデータのCAFIS 経由で接続
  • 旧UFJ銀 : 「直結方式」で接続

システム統合では、旧東京三菱銀のシステムを、旧UFJ銀の方式へと、変更することになっていたそうで、旧東京三菱銀のカードについては、以下のように段階的リリースの計画となっていたそうです。

  • 5月 : 従来どおり、CAFIS経由で統合システムに接続
  • 6月 : 直結方式で統合システムに接続

5月の統合作業で、電文中の案内文部分を設定するモジュールを、6月リリース予定のものにしてしまったのが、今回の障害の原因となったとあります。

この話のとおりであるとしますと、もともと、セブン銀のATMというのは:

相手先 接続方式 案内文の設定
旧東京三菱銀 CAFIS経由接続 半角カナ
旧UFJ銀 直結方式接続 かな漢字

と、相手先によって異なる仕様を持っている、ということになりそうなのですけど。利用者からみると、使うキャッシュカードによって、利用明細の案内文が半角カナで印字されたり、かな漢字で印字されたりする、ということになりますか。そういうものなんですかね?

| | コメント (0) | トラックバック (0)

汎用機からPCへ、バッチからオンラインへ

汎用機上に作られたシステムのほとんどは、以下のようなものであろうと思います。

  1. バッチ処理のシステム
  2. COBOLで書かれている
  3. フラットファイルをプログラムからプログラムへと順に受け渡して処理が進む

一方で、汎用機でもオンライン・トランザクション・システム(OLTPシステム)というのは、存在していたわけでして、有名なところでは、旧国鉄・現JRの マルスシステム(予約・発券システム) ですとか、銀行のオンラインシステム といったものがあります。

第1次オンライン化は、1960年代後半から70年代前半にかけて推進された個々の銀行の本支店をオンラインで結ぶというエレクトロニクス化である。第1次オンライン化では、金融機関のコンピュータ・センターと本支店の端末が結合され、当座預金、普通預金などの勘定科目ごとのオンライン処理がすすめられた。このような勘定系のオンライン化は1960年代後半から都市銀行を中心に始まった。この第1次オンライン化により金融機関の事務コストが減少しただけでなく、同一金融 機関内であればどの店舗でも預金の預入、引出ができるようになった(経済 企画庁総合計画局(1991)による。)。今日では当たり前の、このようなサービスもコンピュータの導入により、即時に他支店にある勘定の残高が判明し、そこから引き落しなどができるようになったため、初めて実行可能となった。また、現金自動支払機(CD、Cash Dispenser)の使用や公共料金の自動引き落し、給与振り込みなどのサービスが普及したのも第1次オンライン化の推進と並行している。今日では自動引落は当然のごとくうけとられているサービスであるが、アメリカのように自動引落が行われていない国もある。わが国では、電話料金(昭和30年)などの公共料金に始まり、税金(昭和42年)や各種会費,クレジットカードの支払いにまで普及している自動引落はこの第1次オンライン化によって利用可能になったのである。

銀行の第1次オンラインについて

1960年代後半から1970年代前半にかけては、OLTPシステムの基礎技術を確立した時期であるとされており1、この時代、日本の情報システムは、世界的にも最先端のレベルにあったのであろうと思います。また、この時代は、データベース・システム、トランザクション処理システムといった、”ミドルウエア”は当然存在していなかったわけでして、このレベルのソフトウエアから、手組みで開発していたのではないでしょうか。

OLTPシステムの標準化・オープン化が始まったのは、1980年代末から1990年代にかけてとされています1。この時期は、情報システムの”ダウンサイジング”が始まった時期とも一致していたわけでして、汎用機からUNIX機、さらにはPCへとシステムのハードウエアが変わり、また、汎用機上のシステムをUNIX機、PCへと移行することになったわけです。このときに、単に汎用機上のバッチ処理システムをそのまま異なるハードウエアへと移行するのではなく、クライアント・サーバ(C/S)型のシステムへと”再構築”して移行したのです。つまり、バッチからOLTPへと処理形態も変わったわけでして。

もともと、汎用機の時代から、OLTPシステムというのはプログラム開発の難度が高いとされていたのですよね。特に初期のオンラインシステムでは、データベースやトランザクション処理からスクラッチ開発していたわけですから、当然でありましょう。C/S型システムが主流になったときには、すでにRDBMSパッケージが存在していたわけで、一番難しい部分をスクラッチする必要はなくなってはいたわけですが、それでもバッチ処理に比べれば難しいのは当然であったと思うわけです。

その後、C/S型システムから、Webアプリケーションへと、システムの主流は移り変わってきたわけですけど、OLTPシステムという処理形態は変わっていないのですよね。変わったのはフロントエンドなわけですけど、この面では、むしろ汎用機時代の中央集中処理へと回帰しているともいえるわけでして。実際、 タンデム・コンピュータ の NonStop システムなどは、現在の Enterprise Java のアーキテクチャにかなり似ていて、フロントエンドに”スクリーンCOBOL”なる言語を使うのはご愛嬌というものですが、フォールトトレラントの部分なんかは、今でも先進的に感じますね。

最初のシステムは T/16(後に NonStop I と改称)である。システム設計は1975年に完了し、最初の製品は1976年にシティバンクに売られた。

【略】

NonStop I は、システムのフェイルオーバモード実現の鍵であった独自オペレーティングシステム Guardian を搭載していた。他社はフェイルオーバーを実現する際に他のCPUでプログラムを再始動させていたが、Guardian では全ての処理はメッセージパッシングを使い、全ての操作でチェックポイントが設定された。結果として Guardian ではプログラム中の任意の位置から処理を再開することができる。これにはスタックベースのプロセッサがほとんど内部状態を持っていないために、プロセスをCPUからCPUに移動しやすいという点も影響している。全ての命令はスタックからデータを取り出し、演算結果をスタックに戻す。演算中に障害が発生したら、スタックを他のCPUにコピーして失敗した命令から処理を再開することができる。

タンデム・コンピュータ (Wikipedia)


1. 渡辺榮一、J・グレイ他著, 『OLTPシステム』, 近代科学社, 1995

| | コメント (0) | トラックバック (0)

« 2008年5月 | トップページ | 2008年7月 »