▼

月: 2018年6月

分館は金沢へ行く

東京国立近代美術館行くかなと思ってWebサイトを開いて、

ポチポチ見てたら「工芸館の石川県移転について」という項目があった。

なんだと……と思って見てみたのだが、なかなか複雑だ。

国立美術館は6館で構成されている。

あれ、5館じゃなかったっけ? と気づいた人は鋭い。実は今年4月に1つ増えたんだよ。

東京国立近代美術館、国立西洋美術館、京都国立近代美術館、国立国際美術館、国立新美術館、国立映画アーカイブ となる。

国立映画アーカイブ はもともと 東京国立近代美術館フイルムセンター だったが、今年4月から独立した美術館になった。

この6館のうち、京都国立近代美術館と国立国際美術館(大阪)が近畿圏、残る4館は東京に所在している。

このあたりの事情は国立博物館も似ていて、2005年以前は東京・奈良・京都と、近畿圏2館と、東京に1館だった。

明治以降、首都ということで文化財の集まった東京と、元々文化財の集中していた近畿圏には博物館の整備が急務だったわけだ。

それが変わったのが2005年の九州国立博物館(太宰府市)の開館だった。

従来の国立博物館とは違うコンセプトで、九州が日本の玄関口として活躍してきた歴史を表す博物館になっている。

そんな中で、国立美術館も他地域での活動を充実できないかということが検討されたのだろうか。

そうして考えられたのが、東京国立近代美術館工芸館の石川県への移転だったのだという。

ちょうど文化庁の京都市への移転も決まっており、その流れもあったようだ。

石川県を含む北陸地域では工芸分野の文化的・歴史的蓄積が大きいことを考慮したようだ。

特に漆工だよね。輪島塗とか有名だけど。現に北陸ゆかりの作品もそれなりにあるらしい。

移転先は、金沢市の本多の森公園、石川県立美術館と石川県立歴史博物館の間に挟まれる形で設置される。

今の工芸館より少し広くなる程度だそう。

ちょうど兼六園の近くで、このあたりは多くの博物館が集積しており、その1つとして国立美術館が加わるわけだ。

東京国立近代美術館の工芸分野の作品の7割程度を移転し、移転後も正式名称は「東京国立近代美術館工芸館」となる。

ただし、金沢にあるのに東京って入っているのは違和感があるので、石川県としては「国立近代美術館工芸館」を通称として使いたいと考えているよう。

現在の東京国立近代美術館工芸館はそのまま別館として存続して、東京での工芸作品の展示活動は引き続きこちらで行われる。

というわけで東京での展示活動はこれまでとさほど変わらない感じなのかね。

東京国立近代美術館の分館という形ではあるが、初めて近畿圏と東京以外に国立美術館ができる。

国立美術館に限らず、国立の博物館で北陸に出来るのは初めてじゃないのかな。

分館とはいうけど、京都国立近代美術館も当初は東京国立近代美術館の分館として設立された経緯もある。

最近でも国立映画アーカイブが分館から独立した美術館になったというのもある。

そう考えると、将来的には独立した美術館になる可能性もあるかもしれない。

工芸専門の国立美術館という立ち位置も明確だし、小ぶりでも存在感を示せるのでは?

そうなると、東京に残される工芸館別館はどうなるんだよって話もあるけど。そのときには展示部門は東京国立近代美術館に集約ですかね。

移転は2020年の予定とのこと。すでに工事に着手しているようだ。

今後、北陸の人たちがレベルの高い工芸品に触れる機会も増えるということで、これはよいことだと思う。

どうしても文化財というのは偏在するもので、1つの参考として都道府県別の重要文化財(国宝含む)のデータを見てみると、

絵画では全2017件のうち、東京都で618件(31%)、京都府で488件(24%)、大阪府で125件(6%)など。近畿2府4県合計で969件(48%)となる。

彫刻では全2701件のうち、奈良県で495件(18%)、京都府で378件(14%)、滋賀県で378件(14%)、東京都で213件(8%)など。

なんと近畿2府4県で1516件(56%)にも達する。まぁ彫刻って仏像が多いですからね。奈良県・京都府が多いのはつまりそういうこと。

工芸では全2457件のうち、東京都で757件(31%)、奈良県で209件(9%)、京都府で185件(8%)など。近畿2府4県で773件(31%)となっている。

長らく近畿圏で住んでいたから、少し行けば多くの文化財に触れられたし、それに味を占めて今も時々出かけているし、

引っ越したら引っ越したで、東京まで近いから博物館など行けば文化財に触れる機会は多いわけだけど、

実のところそうもいかない地域の方がよっぽど多いわけですね。

収蔵品が充実している国立の博物館では、各地の博物館に収蔵品を貸し出す活動も行っているが、

やはりコレクションごとやってくると充実した展示がずっとできますからね。

常に取れる方法ではないけど、この件について言えば、なかなかよさそうだなと思った。

アジア勢のみちしるべかな

サッカーワールドカップが行われているが、

日本チームはグループリーグを勝ち上がり、決勝トーナメント進出を決めた。

昨日のポーランドとの試合ではブーイングが飛び、

グループリーグ2位・3位で勝ち点・得失点差・総得点で並び、最後に勝敗を決めたのは警告点の差という、

なんとも後味の悪い結末だったが、決勝トーナメント進出というのは大きな意味があるのではないかと思うところ。

サッカーワールドカップの出場チームの決め方にさかのぼってみる。

地域ごとの大会を勝ち上がったチームが出場しているのだが、地域ごとの割り振りを見てみると、

  • ヨーロッパ 13チーム(今回は開催国枠でロシアが入るので14チーム)
  • アフリカ 5チーム
  • 南アメリカ 4.5チーム
  • 北中アメリカ・カリブ海 3.5チーム
  • アジア 4.5チーム
  • オセアニア 0.5チーム

と、ヨーロッパが妙に多い。逆にアジアは地域人口の割にはえらく少ない。

ちなみに、今回のアジアからの出場チームは 日本・韓国・オーストラリア・サウジアラビア・イラン の5チームとなっている。

あれ? オーストラリアってオセアニアじゃないの? 実は2006年からオーストラリアはアジアサッカー連盟に鞍替えしたという経緯がある。

オセアニアサッカー連盟の加盟チームはニュージーランドと太平洋諸島の小国たち。

ただし、太平洋諸島でもグアムはアジアサッカー連盟に参加しているので、このあたりの境界は単純ではない。

今回はオセアニアではニュージーランドが出場候補のチームになった。

ただし0.5枠なので、他地域と0.5枠を争う必要があり、ここで負けたのでニュージーランドは出場していない。

どうして、こんなに出場チーム数が歪なのかというと、過去の実績から充実した大会になるようにチーム数を配分したから。

決勝トーナメントへの出場チーム数を見ても、ヨーロッパのチームが圧倒的に多く、アジアの実績はあまりよくない。

最近の実績を調べてみると、アジアで決勝トーナメントに出場したチーム数は、

2002年:2チーム(日本・韓国)、2006年:0チーム(オーストラリアはオセアニア枠)、2010年:2チーム(日本・韓国)、2014年:0チーム、2018年:1チーム(日本)

といった具合で、5回平均で1チームとなる。グループリーグで半分に絞られるとすれば、アジアで4.5チームというのはやや多い。

ただ、地域人口の多さやチーム数の多さも考慮して、実績に対しては多めに割り振ってもらっているのが実情らしい。

逆に実績からすればヨーロッパは出場チームは絞り気味で、今回大会ではヨーロッパは14チーム出場して、決勝トーナメント進出が10チームとなっている。

これは予選段階で絞られているということであり、ヨーロッパのあのチームがワールドカップに出られないなんて、と嘆いている人も見る。

チーム数の割り振りは難しいところで、世界大会としての体面と、試合の充実というところのバランスを考えた結果だろう。

ただ、やっぱり枠数に対してアジア勢のふがいなさというのは、上の数字を見てもわかるとおり、

特に全チームグループリーグ敗退という回もあるのがよくない。

実際、2006年の全チームグループリーグ敗退のときに枠を減らされそうになったらしいが、今後はオーストラリアもアジア枠だからって言って死守したらしい。

それぐらいアジアからのワールドカップ出場枠って危ういものなんだよね。

そういう事情を考えてみると、今回、日本チームが決勝トーナメントに進出したというのは大きな意味があることがわかる。

もっとも、2026年大会から、ワールドカップの出場チームは48チームになることが決まっている。

3チームでグループリーグを構成し、各々1位の16チームが決勝トーナメントに出ることになる。

これにより各地域で出場チーム数が増えるのだが、アジアは恩恵が大きく現状4.5チームから8チームになるよう。

というか、もともとチーム数に比して出場チーム数が多いヨーロッパと南アメリカを除いては、倍増近いようだ。

チーム数が増えて、充実した大会になるか? という疑念はあるが、出場数の増える地域の活躍次第かね。

運が味方したような面もあったけど、全体的には悪くない戦いをしたのかなという理解でいる。

といっても僕自身は試合を見ていたわけでも、そもそもサッカーについて詳しいわけではないけど、

いろいろな人から聞き集めた感想としては、そんな感じ。

大会前には出場チームでは最弱クラスと言われていた日本だが、そんな中ではいいところを見せられたんじゃないかなと。

運も味方してくれたが、運だけで勝てるほど簡単ではないでしょうから。

反転の反転なんてするから

以前、マイコンのCRC計算回路とDMAを組み合わせてCRC計算をする話を書いた。

CRC演算は時間がかかるからDMA

とりあえず成功したのだが、その後に困ったことが起きた。

というのも、CRC計算回路内部では右送り(MSBファースト)、ビックエンディアンで計算しているのよね。

以前、このBlogでCRC演算の右送り・左送りの話は紹介している。

CRCの計算で一般的なのは、右のビットをMSB、左のビットをLSBと考えて計算する方法。

除数(0x104C11DB7)のMSB・LSBを反転させた値を使いながら、データを右ビットシフトしながら計算するので、右送りと呼ばれる。

(思っていたCRC32とは少し違う)

普通は一番左のビットがMSB、右のビットをLSBと言う。

右送りはデータを右シフトしながら、すなわちLSB側から順番に計算することなので、このマイコンの説明書ではLSBファーストと書かれていた。

ところが、このマイコンのCRC計算回路は左送りが標準となっている。けど、右送りのCRCがないわけでもないし。

解せないのがバイトオーダーがビックエンディアンということ。

このマイコンのプロセッサーはリトルエンディアンなのに、なぜかCRC計算回路はビックエンディアンになっている。

バイトオーダーとは、複数バイトのデータ、例えば32bitのデータを格納するときのバイト順を表している。

ビックエンディアンは1バイト目にMSBが含まれるバイトが、リトルエンディアンは1バイト目にLSBが含まれるバイトが格納される。

16進数で0x12345678というデータを 12 34 56 78と並べるのがビックエンディアン、78 56 34 12と並べるのがリトルエンディアンである。

このあたりはプロセッサーによるんだけど、リトルエンディアンのプロセッサーが主流のよう。

というわけで、メモリ上に12 34 56 78 9A BC DE F0 と格納されたデータを、4バイトずつ読み込むと 0x78563412, 0xF0DECB9A と解釈される。

ところが標準設定のままCRC計算回路に 0x78563412 を転送すると、78 56 34 12 という順番で、各々左送りでCRC計算することになる。

複数バイト一括でCRC計算回路に転送すると、データの順番が逆になっちゃってるんだよね。

ただ、左送り、ビックエンディアンが実際に使いたいCRCの計算方式とは限らないので、

CRC計算回路の前後で、バイト順反転、ビット順反転をできるようになっている。

右送り・リトルエンディアンの場合は、入力・出力ともに、バイト順反転、ビット単位でビット順反転 を有効にすればよい。

ビット順を反転して入力して左送りで計算すれば、右送りでCRC計算した結果のビット順反転になるので、また反転すればよいということらしい。

左送り・リトルエンディアンの場合は、入力側のみバイト順反転にすればよいはず。

というわけで、正しく設定をすればどうってことはないわけだが、1つ問題があった。

それがCRC計算の初期値だ。

CRC計算の初期値としては 0x00000000 と 0xFFFFFFFF がよく使われる。

世間的には0xFFFFFFFFの方がよく使われているようだが、うちの製品群では専ら0x00000000ですね。

いずれにせよ初期値を任意に設定できる仕組みを付けておけばよい。

その機能を使って、一連のCRC演算を分割して行おうとした。

初期値0x00000000からCRC演算を0バイト目からNバイト目まで計算して、そのCRC(ビット反転なし)が0xEDB88320だったとする。

次に初期値0xEDB88320からN+1バイト目からMバイト目までCRCを計算する、そうして求まるCRCは0～Mバイト目のデータのCRC値になる。

ところがこうやって計算すると、結果が合わないんだよね。

それでおかしいなぁってデバッガで調べてみたら、初期値に値を設定して、なにも計算せずに読み出すとビット順が反転していることに気づいた。

すなわち初期値0xEDB88320をセットしたら、途端に結果が0x04C11DB7になっているということだ。

それで過去の同様の実装例を調べたら、途中の計算では出力側のバイト順反転、ビット単位でビット順反転を無効化して、

最後の計算のときだけ、バイト順反転、ビット単位でビット順反転を有効にするという方法を取っていた。

こんな使い分けをしてるなんて今まで気づいてなかったけど、そうだったんだね。1発計算と同じだと思っていた。

ちなみに初期値を0x00000000 と 0xFFFFFFFF をセットするのであれば、ビット順が反転でも何の問題もない。

だってビット順を反転しても0x00000000 と 0xFFFFFFFFだからね。だから右送り・左送りともにこの値を初期値に設定すればよい。

典型的なケースでは問題にならないことから、マイコンのマニュアルにもはっきりとは書かれていなかった。

回路構成を読み解くと、なぜこうなるかはわかるようになってたけど、ちょっと微妙ですね。

そもそも、なんでリトルエンディアンのプロセッサーにビックエンディアン・左送りが標準のCRC演算回路を載せてるんだって話だけど。

マイコンのマニュアルには、CRC16では左送りが標準っぽいことが書かれているけど、僕が知る限りではCRC16も右送りが主流だと思うんだけどね。

左送り+ビックエンディアンというのは、最初のバイトのMSBから順番にという点では一貫性があるけど、

いや、それなら右送り+リトルエンディアンで、最後のバイトのLSBからっていう方を選べよと思うんだが、ようわからん。

まぁ前後で反転すればよいというアプローチはその通りだと思うんだけど。

腹が減るから時間単位有給休暇

今日は健康診断なので、出勤時間を2時間遅らせた。

は? という内容だが、それなりの理由がある。

今回の健康診断は食事制限がある。理由は血液検査のため。

なぜ血液検査で食事制限があるのか、一見するとわからないかもしれないが、検査項目に空腹時血糖があるせいだ。

初年の雇入時健康診断のときもそうだったのだが、それ以後は血液検査がないので食事制限なしだった。

実は去年までは年齢によって血液検査の有無を分けていたようだが、今年からは全従業員が血液検査を受けることになった。

どうも脂質異常で引っかかる人が多いので、年齢によらずに対象にした方がいいんじゃないのって話だったらしい。

まぁ血液検査をやること自体はよいことだと思うんだけど、空腹時血糖の測定のためには10時間絶食にしなければならない。

それでも朝早ければ何も問題ないのだが、今回指定されたのは11時過ぎ、そこまで2時間以上も仕事するのか? という話だ。

というわけで出勤を遅らせることにした。

出退勤を数時間ずらす程度ならば、フレックスタイムを使うことがこれまで一般的だったが、

去年から時間単位有給休暇の制度ができたので、2時間休暇で出勤を遅らせることにした。

今年度は時間単位有給休暇を計1～2日ぐらい使うつもりで計画を立てているので、ちょうどいいなと思った。

というわけで上司に「出勤を2時間遅らせます。2時間は時間単位有給休暇にします」と伝えておいて、出勤を遅らせたのだった。

出勤を遅らせるといっても単純にその分寝てただけ。朝ご飯も食べられないのに起きてても仕方ないし。

去年に時間単位有給休暇の導入したときの説明としては、グループ会社では先駆けての導入とのことだった。

従業員からも好評で、運用面での問題もほとんどなかったということで、グループ他社でも何社か今年度から導入したようで。

うちだとフレックスタイムあるから、時間単位有給休暇でないと対応できないケースは必ずしも多くないが、フレックスタイム制がない会社だと画期的な話だよね。

時間単位の休暇というのがかなり新しい概念で勤怠システムにそれなりの改造が必要なのだけど、乗り越えるべき問題はそれぐらいなのかも。

というかグループ他社で導入するのを知ったのも、各社の勤怠システム改修の通知を見てのことだし。

とはいえ、時間単位有給休暇を実際に使おうとして検討して気づいた不便さもある。

それは1時間単位でしか使えないということだ。

フレックスタイムだと10分とか5分単位で出退勤時間を変更できる。

出勤時間を1時間30分遅らせるというのはフレックスタイムなら容易に対応できる。

ところが時間単位有給休暇では厳密に1時間単位でないといけないので、

切り上げて有給休暇2時間にするか、時間単位有給休暇1時間使った上でフレックスタイムで30分でずらすとかしないといけない。

1日単位とか半日単位より細かくなってはいるのだが、さらに細かい5分単位のフレックスタイムと比べるとね。

あと、ちょっと難しいなと思っているのが、年度末に1日(8時間)未満の端数が切り捨てられること。

もっとも、このことを言うと、それは問題ではないのでは? という反応をされることが多い。

というのも、年度末に失効する有給休暇がある人が大半だからだ。

休暇付与から2年経って消えるのも、年度末に残した端数が消えるのも、結局同じことだから。(制度上は少し差があるのだけど)

でも、僕は計画的に有給休暇を使っていることもあって、有給休暇が消滅した試しはない。今年度末も消えないだろう。

だから端数は気がかりなんだけど、そこも含めてある程度、計画的にやっていきたいなと。

フレックスタイムか有給休暇が選べるところで端数調整の余地があるのは確かなので。

遠すぎて飛べない島

小笠原諸島が日本統治下に復帰してから50年ということで各所で特集が組まれている。

東京都ですから、関東甲信越のローカルニュースでも取り上げられている。

しかし、東京からはとても遠い。日本のどこからも遠いけど。

小笠原諸島が遠いのは距離もそうだが、時間も問題である。

東京から月5便程度の船「おがさわら丸」しかなく、所要時間は24時間、こりゃ遠いな。

そして、おがさわら丸 が小笠原諸島のほぼ唯一のアクセス手段というのが大変なことだ。

そう、航空路がないんですね。

小笠原諸島で一般人の住む父島・母島ともに空港がないのだ。

厳密に言えば、小笠原諸島に属する島で、硫黄島には自衛隊の飛行場がある。

もっとも小笠原諸島と一口に言うけど、父島～硫黄島は280kmも離れている。東京～名古屋ぐらいある。

それでも小笠原諸島からすればもっとも近い飛行場のため、急患輸送にとって重要な役目を果たしている。

小笠原諸島からの急患輸送の方法は2つある。

1つが硫黄島までヘリコプターで輸送し、そこで固定翼機に引き継いで本土に運ぶ方法。

もう1つは飛行艇で直接飛ぶ方法。海上自衛隊 厚木基地の飛行艇を呼び寄せるそうだ。

小笠原諸島への航空路がないことはずっと問題にされてきたのだが、未だに解決していない。

最大の問題が島内に空港を作るのが難しいということ。環境への影響が無視できないからだ。

じゃあ、飛行艇だという考えをする人もいた。

飛行艇ならば水面に離発着するので空港が作れなくてもなんとかなる。

自衛隊でも採用されている新明和工業 US-2は民間航空での使用も想定されているらしい。

しかし、実際に使用するのはハードルが高く、飛行艇による航空路開設は実現していない。

そんな中、東京都知事の小池さんは就任以来、父島への空港設置に熱心らしい。

島民の悲願「空港を」　２６日で小笠原返還５０年　小池百合子都知事は前向きも課題多く (産経ニュース)

小笠原諸島は世界自然遺産に登録されており、その区域内は特に環境保全に気を遣う必要がある。

そのため、区域外の場所で考える必要がある。まずこの時点で場所が限られる。

それで1200mの滑走路を確保して、安全に離発着できるようにしようとすると、海の埋め立てて、近くの山を削り取る必要がある。

これで環境保全に配慮した案というのだから、小笠原諸島に空港を開設することの難しさがよくわかる。

空港の新設に比べれば些細な問題かも知れないけど、飛行機の運用もちょっと難しそう。

想定されているプロペラ機はATR42だろうかな。今後、日本で導入されるプロペラ機はここに集約されていくのでは?

滑走路1200mで1000km程度飛べるという点でも小笠原諸島への航空路に適するだろう。というかそれぐらいしか選択肢がないらしい。

ATR42は西日本各地で大活躍している。日本エアコミューターが鹿児島空港と大阪・伊丹空港を拠点に各地に飛ばしているから。

ところが、東日本では活躍の場はないようで、東京・羽田空港への乗り入れはない。

というのも羽田空港って60席以下の飛行機の乗り入れは禁止なんだよね。さすがに小笠原路線なら緩和されそうだけど。

伊豆諸島への小型機は調布飛行場発着で運航されているのも、そういう背景があるんだろう。(ジェット機で運航されている八丈島路線のみ羽田空港発着)

ちなみに調布飛行場は滑走路800m、もっと小さい19人乗りのDo228が運用されている。これでは小笠原には飛べない。

なお、ATRは800m程度の滑走路で離発着できる ATR42-600S を発売する予定だそう。

父島の空港で、滑走路800m程度なら埋立が不要だとどこかで見たので、1つの道かもしれない。

ただ、ATR42-600Sは航続距離の面で厳しいようで、結局使えなさそうとも。

滑走路1200mというのも小笠原諸島の本土からの遠さを考えるとギリギリと言えるが、

環境面からこれ以上の滑走路を確保するのが難しいのは理解でき、綱渡りだが仕方なしということなのかなと。

いずれにせよ一朝一夕で解決する問題ではないことは確かだ。

別に今まで放ったらかしにしてきたわけではなく、小笠原諸島への空港開設はこれまでも真摯に議論されていたことらしい。

ところが環境面での問題が本当に難しいようで、実現していないのが実情なのだろう。

今、検討されている案を見ても、なかなか厳しい案だと思ったから。

距離の問題がなければ、ヘリコミューターってのがあるんだよね。

実際、伊豆諸島では空港がない島でもヘリコプター定期航路が設定されており、海の状況によらず行き来できるようになっている。

定期路線のある空港がない島にとってはとても画期的なことだったようだ。

航続距離の長いヘリコプターと言われて思い浮かぶのが V-22 オスプレイ、でもあれは民間で使えるものではないよね。

取れる手が少ないってのはこういうことですよ。

実行ポリシーの抜け道?

先日、Windows PowerShell のことを取り上げた。

WSHよりはPowerShell

PowerShellでは他のソースコードを読み込むためには実行ポリシーの設定を行う必要がある。

一度設定すればOKなんだけどbね。

そんなわけで実行ポリシーを設定するのバッチファイルを作ろうかと思ったら、

もっとよい方法があることがわかった。

どうもPowerShellの起動時のパラメータで一時的に実行ポリシーの変更ができるようだ。

さらに起動時に所望のコマンドを実行することが出来るので、

powershell -ExecutionPolicy RemoteSigned -NoExit -Command . .\foolib.ps1

と書いたバッチファイルを用意しておいて、それを開くだけで、

外部ファイルの読み込みを許可し、foolib.ps1の関数を読み込んだPowerShellコンソールが表示される。

この場合、一時的なポリシー変更なので、特に確認画面も表示されない。

こうして開いたPowerShellのコンソールが標準と異なる設定がされていることは全く気づかない。

実行ポリシーをRemoteSigned、ローカルファイルか署名されたリモートファイルを許可する程度であれば、

あまり危ないという印象は受けないし、むしろそれが標準設定でいいのでは? という内容だが、

何の制限もしない ByPass に設定するとしても、特に何も確認されないのだから驚きだ。

恒常的に変更する場合は仰々しい確認画面が出るのに。

意図を知って使う分には問題ないんですけどね。

今回の場合、デバッグコマンドを構築したライブラリを読み込んで、ローカルにある各種スクリプトを実行可にするという目的は明確なので。

そもそも信用できないバッチファイルは実行しちゃいけないですから。

ダウンロードしてきたバッチファイルは実行時に確認される仕組みになってるわけだし。

だから特別に危険ではないってことなんでしょうけどね。

じゃあ、なんでそもそもPowerShellの実行ポリシーの初期値が Restricted(一切の外部ファイル実行禁止)なんだよって話だけど。

実行ポリシーの問題がなければ全部PowerShellスクリプトだけでよかったのかもしれないけど、

実行ポリシーの問題を解決して、ファイルを読み込むためにバッチファイルを1つ用意する必要があるのはちょっと中途半端。

それでも、WSHのJScriptで作ってたときよりはスマートになったからいいか。

発電用ダムから砂を運び出すために

あれ? と思ったニュース。

国、トンネル新設検討　大町・高瀬ダム湖の土砂搬出のため (中日新聞)

ダムの土砂を運び出すためにトンネルを建設するの? というのはそういうものかなと思ったけど、

あれ? と思ったのは高瀬ダムは東京電力所有のダムなのに、なんで国がトンネルを作るの? ということ。

勘違いじゃないよね? と思って調べたら、確かに高瀬ダムの所有者は東京電力だった。

そもそも、ダムの堆砂ってご存じですかね?

ダムがない場合、山から流れ出した土砂は海にたどりつき、それがさらに陸に流れて砂浜ができる。

海岸線にきれいな砂浜があるというのは、近くの川から砂が流れてきているからこそである。

もっともよいことばかりではなく、河口付近が砂で埋まって、港の機能を阻害するようなこともある。

大和川付け替えで、大和川流域から大阪港に流れ込んでいた土砂が、堺港に流れ込むようになり、

当時は南蛮貿易(鎖国前だった)などで栄えていた堺港の機能は衰退していった。

一方の大阪港は土砂流入が軽減された後、明治以降に貯まった土砂を浚渫して埋め立て、港湾機能を拡大。現在では日本有数の貿易港である。

ダムができると、もともと海に流れ込んでいた砂の一部がダム湖に貯まることになる。

これにより2つの問題が生じる。1つは海に砂が流れ込まなくなり海岸線が維持できなくなること。もう1つは単純にダム湖が埋まること。

ダム湖が埋まるという点については、もともとそれを見越して堆砂容量を確保してあるので問題ないという説明も出来る。

ただ、水系によっては土砂の流入が多く、ダム湖への影響、海岸線への影響ともに大きい場合があり、

そのような場合は積極的な対策が行われているケースもあるようだ。

さて、ここで最初の話に戻るわけだが、高瀬ダムは信濃川水系に属する。

信濃川水系は比較的土砂の流入が多い水系で、高瀬ダムの上流は土砂崩れの影響で特に流入が多いようで、

そのため総貯水容量の半分が土砂で埋まっているとのこと。

それでも機能が維持できていると言えればよいのだが、問題は高瀬ダムが揚水発電の上池を構成するダムであるということ。

揚水発電は電気を蓄えるのが目的だが、蓄えられる電力量は上池と下池の高低差と貯水容量で決まる。

ということは高瀬ダムが砂で埋まってしまうと蓄えられる電力量が減り、揚水発電の効果が減少してしまう。

そのため東京電力も高瀬ダムの土砂を取り除いて、揚水発電の機能を維持しようとしているが、土砂の行き場に困ってなかなか進まないようだ。

土砂の本来の行き先は海、というわけで取り除いた砂は下流の川に流せばよい。

といっても高瀬ダムのすぐ下だと、下流の七倉ダムに貯まるだけだから意味がない。さらに下流に大町ダムがあるから、その下流に流す必要がある。

そこで高瀬ダムから大町ダム下流へ継続的に土砂を流せるようにトンネルを整備し、ベルトコンベアで輸送するとのこと。

なるほどと確かにという対策ではあるが、気になるのは、このトンネルを作るのが東京電力ではなく国だということ。

調べたところ、土砂を削って確保した容量を洪水調整にあててもらおうという意図があるようだ。

大町ダム等再編事業の概要 (千曲川河川事務所)

本来、電力会社所有の発電用ダムは洪水調整機能を持たない。

なので、洪水時は上流から来た水量と同じ水量を下流に流せばよいが、電力会社が洪水調整に協力する場合もある。

実際、高瀬ダム・七倉ダムも空き容量の範囲で洪水調整に応じたことがあったとのこと。

それをさらに推し進め、電力会社所有の発電用ダムではあるが、一部を洪水調整用に割りあてるわけだ。

そのためには堆砂を取り除いて容量を確保する必要があり、そのための設備は国が整備するということ。

具体的にどういう運用になるのかは不明だけど。

堆砂対策としては、いろいろな方法があるが、削った土砂を下流に流すという方法だけでなく、

平時から土砂を多く含んだ水は直接下流に流す、ダムに土砂ごと流せるゲートを用意するという方法もある。

土砂を多く含んだ水は直接下流に流すというのは、ダムの入口でより分けて、土砂を含む部分は土砂バイパストンネルに流す。

確かにこの方法であれば、ダムが必要以上に土砂をため込むことがないのでよさそう。下流の環境改善にも役立っているようだ。

土砂ごと流すゲートを用意するというのはこういうこと。

ダム排砂設備 (黒部河川事務所)

黒部川は土砂が貯まりやすく、通常の考え方では莫大な堆砂容量が必要になるが、それではなかなかダムが成立しない。

そこで時々、ダムを空っぽにして、土砂を押し流す機能を持たせたわけ。最近は年1回程度、洪水に乗じて押し流しているらしい。

ちなみに堆砂が必ず問題なのかというと、そうでもないらしい。

総貯水容量に対する堆砂量が多いダムの多くは水力発電用で、

特に調整池式の水力発電であれば、高低差を稼ぐことと、短期間の水量の変化に対応できればよい。

そのため、堆砂量が総貯水容量の98%にも達するダムもあるが、それでも運用上は問題ないらしい。

ただ、治水目的では問題だし、発電目的でも揚水発電では問題だ。想定の範囲内ならばよいが、想定を超えると対策が必要になる。それが高瀬ダムということ。

どう引っ越しても狭くなる

先々週、現在住んでいる社宅が閉鎖されることとなり、約2ヶ月後に退去するようにと通知された。

理由は老朽化のため。

心当たりはあって、CATVの宅内配線が劣化して、インターネットが使えないという問題があって、

CATV会社営業が大家に働きかけても、未だに対策は取られていない。(なぜCATVはまだ来ない)

この社宅には会社とは別に大家がいて、大家から会社が1棟丸々借りて、それを従業員に又貸ししている。

おそらく、大家にしてもれば、老朽化した社宅を修理するよりは、壊して新しく建て替えた方がメリットが大きいと考えたのだろう。

そのため、老朽化対策を行わず、会社から返却してもらうというにしたのだろう。

この場合、会社都合で新しい社宅に転居するという扱いになる。

入居者は代替となる社宅に応募する権利を有し、転居費用は会社負担となる。

近距離の転勤と同じ扱いで1日の特別休暇が与えられ、幾ばくかの手当もある。

代替物件のリストを見てみると比較的近くで用意してくれたようだ。

その中で2つピックアップして、下見に行くことにした。

ピックアップした物件の1つ目は、現在と同じ1棟すべて社宅というもの。

この地域で会社が1棟すべて占有する社宅は2つしかない。1つが現在住んでいるところで、もう1つがここ。

現在の社宅の近所で通勤距離もほぼ同じ、家賃も同じ、設備面もほぼ同じ。

設備面でほぼ同じというのは、洗濯機が共用、エアコンの設備なしという、一般的に短所と思われることもほぼ同じということになる。

でも、エアコンは現在使っているものを会社負担で引っ越してくれるので、エアコンの設備なしというのはデメリットにならない。

ただ、1つだけ大きな違いがあって、それが部屋の広さ。現在の社宅はワンルームにしては広いのだが、この社宅はかなりミニマムな構成になっている。

メジャーを持っていろいろ寸法を測っていたが、現在に比べると窮屈な配置にはなるが、なんとかなるかなという感じ。

もう1つの物件は、現在よりも会社から遠くなるが、環境面からよさそうな物件。

こちらは部屋単位で会社で借りているようだが、それなりにまとまった入居者がいるという噂。

リストにあった中では比較的新しい物件で、といっても築20年弱なんだけど。

部屋を見てみると、なかなか洗練された作りに見える。

とはいえ、ちょっと気になるのが台所周り、現在の台所からは差が多い。

全体的に狭くて、コンロが1口になり、今使っている食器干しも、シンクの上にかけている作業台も使えない。

工夫次第かなとは思うんだけど、現状とはかなり運用を変える必要がある。

通勤手段は自転車だろうなと思って、通勤経路を想定して歩いていたのだが、大した問題はないが殺風景な印象を受けた。

自転車じゃなければバスかなと思ったけど、利便性はいかほどですかね。調べたら本数が多い系統が使えるようだけど。

いずれにしても思ったのはこの社宅の部屋は本当に広いということ。

家具の配置も想定しながら測定してたけど、どこを取っても今より詰めないと入らない。

あと、押し入れのサイズも現状の半分以下になりますからね。

現状パンパンというわけではないが、さすがに半分になると工夫が必要になる。

というわけで引越までに整理を進めて、必要に応じて収納具を買い足すなどしないといけない。

入居する社宅だけでなく部屋まで指定して、応募者が多い場合は抽選となるようだ。

部屋なんてどうせどれも大差ないんだし、とは思うけど、そこまで指定するみたいね。

確かに階数、部屋の向き、押し入れの大きさや備え付け設備の多少の差があるので、そこが争いにならないようにということか。

本命は最初に見た社宅、部屋が狭くなる以外では現状の社宅との条件差が小さいのはやはりメリットだ。

どの部屋でもよいとは思うが、本命の部屋も決まった。ここなら絶妙かなとか考えてるんだけどね。

どういう形で競争になるんだろうかね。なかなか読めないところがあるけど、どっちかには収まるでしょう。

WSHよりはPowerShell

製品に組み込まれたモジュールとマニュアルで通信する方法を調査していたのだが、

有識者に聞いたら、正攻法でやる方法はないという返答が返ってきて、うーん。

その後、いろいろな資料を調査した結果、システムを停止させて、特定の機能だけ動作する状態にした上で、

メンテナンスツールを使って、内部レジスタに読み書きするという方法でできることが確認できた。

とりあえずこれで最低限の実験は出来たのだが、レジスタの読み書き1つずつを手操作で行うのは大変だ。

これらの操作はWindowsのコマンドライン上で動くメンテナンスツールを操作するので、

操作をまとめてバッチファイルにすればよさそうなのだが……

  • レジスタへの書き込み操作はメンテナンスツール上のプロンプトにデータを入力する必要がある
  • レジスタのリード結果の表示が冗長なので整形が必要

ということで何らかの工夫が必要そう。

そこで共有ディレクトリを検索していたら、JScriptで書かれたスクリプトが出てきた。

目的は違うのだが、同メンテナンスツールを使って、レジスタの読み書きを行うという点では共通している。

これを見てみるとレジスタへの書き込みは、データをパイプで標準入力から入力してやっていた。

ご存じの方もおられるだろうけど、プログラムには標準入力(stdin), 標準出力(stdout), 標準エラー出力(stdout) がある。

通常は、stdout, stderrはコンソール画面に、stdinはキーボードに繋がれている。

これをつなぎ替えて、stdoutをファイルに出力したり、他のプログラムのstdinに繋いだり出来る。

stdoutを他のプログラムのstdinにつなぐ方法をパイプといい、これで書き込みデータを送り込んでいたのだ。

さらに出力データの整形も行っており、かなり参考になった。

ところでJScriptってなんやねんと。JavaScriptのMicrosoftの呼び名といえばそうなのだが……

ただ、それ以上に重要なのが、これがWindows Script Host(WSH)で動くスクリプトであることだ。

WSHはJScriptまたはVisual Basic Script(VBS)で記述されたスクリプトを実行することができ、Windowsの各種機能へのアクセスができる。

コマンド実行、ファイル入出力、レジストリアクセス、そしてJScriptが標準的に備えている文字列処理などを使うことができる。

単純なバッチファイルではできない操作をJScriptに記述して、それを呼び出すバッチファイルを作るような使い方をしていた。

cscript //nologo fooexec.js param1 param2

これでマニュアル通信に必要な操作をJScriptで一括して実行できるようになったわけだけど、なんとなく使いにくい。

それでいろいろ調べていたが、Windows 7以降だとWindows PowerShellが標準搭載されるようになったので、

WSHよりもこちらを使った方がよさそうだとわかった。PowerShellはWSHの事実上の後継となっているようだし。

PowerShellの特徴は .NET Frameworkベースで、.NETのオブジェクトを取り扱うことができるということ。

その上でスクリプト言語としての特徴を備えており、PowerShell専用のコマンドレットを多数備えている。

ところが実際にPowerShellを使ってみて思ったのは「なんてめんどくさい!」ということ。

というのも、コマンドを実行して、標準入力をPowerShellから入れる、ということを書こうとすると、

.NET Frameworkのオブジェクトを直接操作する必要があり、ほとんどC#のプログラムを書いているような感じ。

PowerShellの名に違わぬパワフルさだが、スクリプト言語としてはどうなの? という感じ。

記法も独特で、制御構文はC#っぽいけど、改行の記述方法が “`n” だったり、比較演算子が –lt, –eq だったり。

外面はとっつきやすそうだが、なんでこうなるんだよ、というのが続出するのがPowerShellという感じ。

あと、PowerShellは再利用性も高くて、簡単に他のスクリプトを読み込める。

. .\foolib.ps1

これだけで foolib.ps1 というPowerShellスクリプトを読み込める。(PowerShellのスクリプトは拡張子ps1を使うのが通例とのこと)

これでスクリプト内で定義した関数を再利用できるわけだ。

ところが、初期状態のPowerShellでこのコマンドを実行すると失敗する。

というのも初期設定ではPowerShellは一切のスクリプトの読み込みができない。安全性を考慮してのことらしいが。

なんでそんな厳しいの? と思ったのだが、WSHがセキュリティ上の問題を引き起こしてきた反省らしい。

PowerShell / about_Execution_Policies (Microsoft)

1回設定すれば以後は大丈夫なんだけどね。

LinuxだったらPerlで書いたんだろうけどなぁ。

そもそもUNIX系のOSでは、シェルスクリプトがそれなりに強力だ。

シェルスクリプトでawkとかsedのような文字列処理コマンドを補助的に呼び出して使うこともよく行われてきたようだ。

そして、Perlのようなスクリプト言語の活用もよく行われていた。

Perlはシェルスクリプト内などで補助的に使われることもあるけど。ワンライナーで使っても強力なので。

今どきはPerlというよりPythonなのかなという気はするけど、僕はPerlで慣れてるからPerlを使うかなと。

いずれにせよLinuxならば、標準で使えるものですから。

Windowsでも別途インストールすれば、他のスクリプト言語も使えるんですけどね。

職場でもActive Perlを入れて使ってる人もいるようだけど。今どきActive Perlかよって思うけど。

でもやっぱり標準で入ってる方がよいわけで、これまでWSHで動くJScriptまたはVBSが重用されてきたのもそういうことでしょう。

今後は PowerShell がこの立ち位置になるということだろう。

確かにPowerShellにできないことはないなと思った。書きやすいかはさておき。

全体的にWSHより素性がよいのは間違いないので、乗り換えて行こうとは思ったけど。

新名神経由のバスはうまくいってる?

JR西日本のWebサイトを見てたら、こんなリリースが出ていた。

三宮・大阪～四日市・ナガシマリゾート線 開設！「ナガシマリゾートライナー」 「四日市ライナー大阪号」7月21日から運行開始！ (JR西日本)

西日本JRバスが新路線を開設するという話なのだが、

実はこれは三重交通の既存路線の増発・延長で、増発になる便を西日本JRバスが受け持つということらしい。

これに伴い、従来から運行されていた便も大阪側の発着地がJRバス合わせになるらしい。(従来は近鉄バスのバス停を使っていた)

2008年に新名神高速道路の草津～亀山が開通した。もう10年になるんだね。

このとき、三重交通は新名神経由で京都へ向かう路線を開設した。

それ以後、三重交通は関西方面の路線を充実させていったのだが……

ところが全てが好調というわけでもなく、減便・廃止になった路線もある。

  • 伊賀～大阪 : 2005年新設(毎日4往復・三重交通単独)→現在は休日のみ4往復
  • 四日市～京都 : 2008年新設(毎日6往復・京阪バスと共同運行)→現在も 毎日6往復・共同運行も継続
  • 津～京都 : 2008年新設(毎日4往復・近鉄バスと共同運行)→現在は 平日1往復・休日2往復で三重交通単独
  • 伊勢～京都 : 2008年新設(毎日4往復・近鉄バスと共同運行)→2014年廃止
  • 四日市～大阪 : 2009年新設(毎日6往復・近鉄バスと共同運行)→現在は平日1往復・休日2往復で三重交通単独
  • 長島・四日市～奈良 : 2014年新設(毎日4往復・奈良交通と共同運行)→2015年廃止
  • 伊賀～京都 : 2016年新設(毎日2往復・三重交通単独)→現在は休日のみ2往復

ずっと好調なのは、四日市～京都ぐらいですかね。

ちなみに、伊賀～大阪、長島・四日市～奈良は新名神経由ではなく名阪国道経由のバスなので念のため。

三重県内から大阪・京都へ行く場合、バス以外の手段としては近鉄電車がある。

当初、三重交通が目を付けたのは、近鉄特急を使ったとしても、京都へは乗り換え無しで行けないというところ。

というのも、京都～伊勢志摩 は直通の特急があるが(2008年当時は毎時1本程度は走っていた)、津・四日市からだと使えない。

新名神が開通したことで、三重県内から京都までの高速道路での所要時間は大幅に短縮されることになる。そこに目を付けたわけだ。

直通の近鉄特急にある中にぶつけた 伊勢～京都 は特に不調で廃止となったが、四日市からは好調、津からもぼちぼちという感じ。

ちなみに四日市～京都は近鉄特急だと乗換1～2回で2時間半を切るぐらい、一方のバスは時刻表通りなら2時間を切る。

本当に時刻表通りに走るのかはよくわからないけど。(新名神開通以来、東名阪自動車道の渋滞が慢性化しているので)

一方の大阪路線だが、こちらは三重県各地から近鉄特急が直通で走っている。

一番最初に開設された伊賀～大阪線だが、これは伊賀市中心部(上野)から直通というのがポイントだったのだろう。

というのも、上野からだと、伊賀線で伊賀神戸まで行って乗り換えてとなるのでめんどくさい。伊賀神戸駅にパーク&ライドする場合もあるようだが。

でも、名阪国道を走るバスなら、上野車庫(駐車場あり)・上野市駅で乗り込めば、すぐに上野東ICから名阪国道に入って、大阪を目指せる。

2016年開設の伊賀～京都線もポイントは同じだろう。(こちらは名阪国道 壬生野IC～新名神 甲南ICを15km程度一般道走行するが)

もう1つのポイントが、大阪側の発着地で、梅田・新大阪となっている。

近鉄で梅田・新大阪へ行く場合は大阪市内で乗換が必要となる。すなわち両側で乗換の手間が省けるのがこの路線のウリだったわけだ。

四日市～大阪は、単に都市間を移動するだけなら近鉄特急が本数が多くて速いが、梅田まで直通という点では差別化できる。

というわけで、(京都～伊勢線を別としては)近鉄特急と共存共栄できるように考えられた路線だったわけだ。

とはいえ、やっぱり乗換は不都合としても、やっぱり近鉄特急は本数多いですからね。なかなかバスの立場は難しい。

開設当初から現在まで当初の本数を維持できているのが 四日市～京都 の1路線だけであることからもそんな実情がわかる。

別に近鉄といがみ合っても仕方ないですからね。だって三重交通も近鉄グループだし。

そんな中で、JRバスが三重交通の四日市～大阪線に目を付けたわけだ。

現在、三重交通の四日市～大阪線は朝に四日市を出て、夕方に大阪を出る便だけになっている。

JRバスは大阪・神戸から長島温泉へ向かう客を狙って、朝に神戸・大阪を出て、夕方に長島温泉・四日市を出る便を運行する。

路線延長というのは、四日市～長島温泉と、大阪～神戸である。

2社共同運行って言っても両者の狙いは全く違うわけだけど、形式上は同じ区間を走る路線なので共同運行にしているのだろう。

三重交通にしてみれば、近鉄バスの梅田バス停(路上)を使っていたのが、JR大阪駅高速バスターミナルを使うのが一番大きな差ですかね。

あと予約システムもJRバスの高速バスネットになるようで。

確かに長島温泉を目指すのは賢いなと思った。長島温泉は駅から離れてるからね。

名古屋からは三重交通・名鉄バス共同運行の短距離高速バスが頻発している。

大阪方面からだと、桑名駅まで近鉄で行って、そこから路線バスということになる。

これが乗り換え無しとなれば便利だよね。関西でもファンが多いリゾートでしょうから。

平日も持つかというのは気になるところだけど。とりあえずは夏休みだから平日の利用者も稼げそうだけど。

ところで、新名神の開通以来、慢性的な渋滞が続いている東名阪自動車道だが、

今年度中に四日市～亀山の新名神が開通することで解消する予定だ。

この区間を通り抜ける車にとっても、三重県発着の車にとっても困る渋滞だが、開通から10年経ってやっと解消する。

高速バスだと、時刻表通りなら休憩なしで走りきれるはずだが、渋滞のため休憩を追加せざるを得ないようなことも出ていると聞いているので、