掘割を使うメリット

最近、Cities:Skylines IIで今まで手が及んでいなかった島を開発している。

その中で掘割の線路や高速道路を敷設していた。けっこう便利だなと思った。


道路や線路の高さを7.5m以上にすると高架橋ができるが、

同じように-7.5m以下にすると擁壁が作られる。

-15m以下にすると地下トンネルになるのだが、トンネルじゃないので地上から見える。

重要なのは7.5m差あれば立体交差ができるということである。

地下トンネルで立体交差にする場合は12.5m以下に下らないといけないが、

掘割ならば7.5m下るだけで立体交差にできる。けっこう楽である。

もっとも地下トンネルと違って、その上に施設を置くことはできない。


これは海沿いを住宅中心、内陸に工業団地を作るにあたって、

工業団地の中に貨物駅(Bridges&Portsのカスタマイズ可能な貨物港で構築)、

海岸沿いの農地に囲まれた一角に鉄道と船の積み替えに特化した小さな港を作ったところから始まる。

農地の中を列車が横断する必要があり、農地の中を高架で走るのも違うよなと掘割にしたところから始まる。

もっとも鉄道と道路は踏切で交差することも可能なのだが。


どちらかというと高速道路の方が掘割の効果が大きい。

立体交差できるという点では高架でも掘割でも同じとは言えるが、

高速道路の騒音は高架の方が広がるという仕組みになっている。

平面にして防音壁を付けるのが一番影響が抑えられるのだが、掘割も比較的影響が抑えられる。

騒音のことを気にするなら地下トンネルにするのが一番いいんだけどね。

ただ、地下トンネルにするには高低差が大きくなり、それが配置上の大きな制約になる。


現実世界でも高速道路が掘割を通るのはよく見る光景ですからね。

Cities:Skylines2の中では高架にすると騒音の問題があるが、現実には日照の問題が大きい。

防音壁の一部を透明にしているのは日照対策である。

ともかく条件が許せば掘割の方がよいというのはそうなのだろう。


海沿いを住宅中心の利用にすることにしたが、当初は鉄道の敷設が難しく、

対岸の海沿いを走る地下鉄(地上走行だが)の駅とフェリーで結ぶことにした。

その船が少し内陸まで入れるように運河を作ることに。

このフェリーというのもBridges&Portsで追加された要素なのだけど、

そのフェリーが航行できる航路は通常の船の航路よりは細いし、橋の高さもそこまで必要はない。

でも思ったより幅は食うので運河を作ってまでというのはあまり割に合わないのかもなと。

そうやって作った運河は峡谷のようになってしまい、そのまま岸壁からフェリーを乗降すると相当な違和感が生じる。

そのため、フェリーの港付近はすり鉢状にすることに。けっこう大変である。

ただ、その甲斐もあってか船で対岸と往来する人は多く、それなりに活用されているようだった。


このゲーム、次の拡張パックとして Park Adventures というのがあるそうで、

カスタマイズ可能な公園として、遊園地・動物園・自然公園などが作られるようになるらしい。

前作のCities:Skylinesでもこういうのが人気があったらしい。

買うかどうかは知りませんが、そういうのもあるということで。

在宅勤務での深夜労働が多いらしい

会社と労働組合の協議の中で、在宅勤務での深夜労働が多い人がいるという話があった。

こういう形で深夜(22時以降)にシフトして働くというのは問題なんじゃないですかねということで、

労働組合としても基本的には深夜労働はもってのほかだろうという話で協議は進んだようだ。

現時点で会社との取り決めを変えることはないが、今後改定の必要があるかもしれないという話が書かれていた。


振り返れば在宅勤務制度ではもともとは深夜労働はできなかった。

在宅勤務制度の導入初期は時差を埋めるための利用の割合が高かったという。

当初、在宅勤務で深夜労働は想定していなかったが、

在宅勤務での深夜残業を認めた方が総合的によいと制度化されたり、

その深夜残業を昼間のフレックスタイムで相殺すると、制度上は欠勤扱いとなり賞与の計算で不利になると、

それを補正するための制度が導入されたり……いろいろあったんだよね。

(時差のため在宅勤務で残業)

このような時差を吸収するために在宅勤務での深夜労働を認めることになった。

そういう事情があっての深夜労働なら仕方がないのだけど……


おそらく会社との協議で問題となったのはそこまでの事情がなく、

すなわち本来は深夜労働以外でも対応できるような内容のはずなのに、

家庭の事情などで22時以降にシフトしているようなもののようだ。

そういう働き方を認めてしまう上司の問題では? というのはあるが、

深夜労働というのはそれなりに重い話であると自覚が必要であると。


人事から直接申し入れをするなどの対応もしているが、打開に至らないというような話も書かれていた。

それこそ上司が悪いのではないかと思うが……

ただ、そこで取り得る手立てを考えてみると、まずは深夜労働にならない範囲で対応すること。

定時内はきっちり働く、それ以上必要なら前後の夜業にならない範囲で対応すると。

でも、それは家庭の事情で対応できないというケースはある。

そうなれば仕事を減らして対応するしかない。他の人に仕事を振るということである。

そういうマネージメントを行うことも上司の責任ではあろうと思うが、

あまりにギャップが大きいとそういう対応はできないかもしれない。

そこで、本人も納得しているなら深夜労働でという考えはありうると。


というわけで人事と現場の管理職、労働組合と一部の組合員というギャップはけっこうあるのだと思う。

深夜労働はもってのほかだというのはおおよその組合員が共有していると信じているが、

家庭の事情など考えたとき、深夜労働でも働いた方がマシという考えを持つ人もいるだろう。

こういう働き方をするひとはおおよそ残業時間が多いので、

深夜労働が封じられて月の所定労働時間を満たせないということは考えにくいが、

もし所定労働時間が満たせない状況が続くなら退職することを迫られるだろう。

(時短勤務などの適用の余地があればその限りではないけど)

そういう状況になっては会社、とりわけ現場の管理職にとっては困るわけで……


外国の事業所を含む全社の懲戒事案というのは共有されているのだが、

その中には勤務について上司の指示に従わなかったことを理由に懲戒というのがしばしばある。

もっとも日本国内ではあまり見ないような気がするけど。

理屈の上では深夜労働からのシフトを上司が指示して、それを拒否すれば懲戒というのはありうる。

ただ、それだけを理由に懲戒というのは現実的ではないのかなと思う。

形式上は勤務の指示に従わなかったことを理由に懲戒されるケースも、

背景を見てみると、不正の疑いについて問いただそうとしても無断欠勤で問いただせず、

仕方なく懲戒解雇にしたようなケースがしばしばある。

特に日本だと不利益処分には相当な根拠が必要ですから、実害のない譴責ならともかく、それ以上は容易にはできない。


結局のところ、この問題についてあまりに厳しい立場を取ると、

最終的にいきつくのは、深夜労働をさせてまで使いたい戦力を喪失するということである。

そういう状況は会社、とりわけ現場の管理職にとっては嫌なわけで、

なかなか強硬策に出にくいという事情もあるのだと思う。

人事も困った結果として労働組合に申し入れをしているのだろう。

在宅勤務制度やフレックスタイム制度は会社と組合の取り決めによるもので、

これらの制度について会社との信頼関係を損ねるようなことをする組合員は問題だというのはある。

ただ、それを問題と思わない組合員とのギャップは埋まらないかもしれない。


会社と組合との正式な取り決めではないが、

在宅勤務制度の利用について少なくとも週に○回程度は出勤するようにという指針はある。

僕はこの指針は主に管理職に向けたものなのでは? と思っている。

確かに管理職以外にも指針はあるが、上司の判断による部分はある。

もともと仕事の内容によっては出勤して対応するように指示できるし、

逆に家庭の事情など考慮して、指針によらないことも可能である。

会社と労働組合の正式な取り決めになると、そこから逸脱できなくなる。

冒頭に書いた通り、現時点では会社との取り決めという話になっていないのは、

会社も厳密な制限を示すのは現状難しいという考えがあるようだ。


会社も在宅勤務制度について否定的なことは言いづらくて、

背景の1つには管理職が在宅勤務のインフラを活用しまくっていることがある。

さっきも書いたように管理職にはできるだけ出勤するように指針でも示されている。

定時内はできるだけ社内にいるように対応しているということだが、

一方で定時外や休日など、在宅で各種承認などして部下の仕事をバックアップする対応もみられる。

もともと在宅勤務制度は管理職限定で導入されたという背景もある。

確かに管理職とそれ以外では従うべき規範も異なり、在宅勤務制度の副作用も別々に考えるべき部分はある。

一方で制度全体としては有効に使われているという評価をせざるを得ない。

その中で深夜労働がクローズアップされたのはなるほどと思うけど、

それを問題として対処できない上司の問題がほとんどでは? とも思う。

京都市バスの赤字と黒字の元

京都市バスの均一運賃が市民は200円、それ以外は360円になるという話が出ている。

以前より観光客で混雑してバスに乗れなくては困るという話があり、

その中で市民優先の運賃制度を検討していたというが、なかなかの格差である。

京都市民以外でも通勤・通学のため市バスを利用する人はいる。

ただ、月16回以上利用する人は260円まで値引くような考えもあるよう。

それでも現状の230円よりは値上がりするが、260円ならば応分の負担ということなのだろう。


京都市バスにはいくつかの側面がある。

市外からすると観光客の混雑に手を焼く市バスの姿が思い浮かぶが、

それと同じか、場合によってはそれ以上に大変なのが通勤・通学客の混雑である。

このため市バスでは車両・乗務員を多く確保する必要がある。

一方で都心部の混雑路線では概ね黒字をたたき出している。

大もうけとはいかないものの、バス事業を支えているのはこれらの路線である。


そして生活路線としての側面で、その中には相当な不採算路線を抱えている。

そうはいっても鉄道の不便な地域が多い京都市、利用者は多い傾向にある。

そのため減便して赤字額を減らすという策には出にくい。

そこでふと気になったのである。京都市バスで赤字の絶対額が多い路線はなんだろうと。


京都市バスでは系統別の旅客数と営業係数が公表されている。

営業係数 (京都市交通局)

よく考えれば市バスは均一運賃がほとんど。利用者数×230円=運賃収入と近似できる。

(実際には小児運賃や障害者の割引運賃などあるので230円を使うのは不適切だが)

営業係数は運賃収入100円あたりの利用、(営業係数-100)が運賃収入100円あたりの赤字額である。

すなわち 利用者数×(営業係数-100) が赤字の絶対額を表す指標になりうる。


この 利用者数×(営業係数-100) という数字を計算して大きい系統が市バスの足を引っ張っていると言える。

で、その上位にあるのはこんな系統である。

  • 18 (二条駅西口~九条通~久我石原町・久世橋西詰)
  • 13 (四条烏丸~西大路通~久世工業団地前・久我石原町)
  • 西2 (桂駅西口~西竹の里町~洛西BT)
  • 西3 (桂駅西口~南福西町~洛西BT)
  • 84 (九条車庫~葛野大路通~太秦天神川駅)
  • 71 (九条車庫前・京都駅八条口~四条大宮~松尾橋)
  • 16 (京都駅八条口~十条通~京都駅前)
  • 南1 (竹田駅西口~久我~桂川駅前~桂駅東口)
  • 西5 (桂駅西口~新林センター~桂坂中央)
  • 西8 (桂駅西口~南福西町~洛西BT)

などなど……18系統と13系統がこの指標では若干突出している。

あと、京都駅~洛西ニュータウン方面の路線は細々分かれているが、

実は西8系統は西3系統・西1系統のルートを統合したもので、

西3・西8・西1の3系統を合計すると、これが一番大きくなる。


というわけでなるほどなぁという結果である。

最上位にいる18系統は大宮通・千本通を南下していくバスだが、路線図を見ても一見よくわからないバスである。

京都水族館へのアクセス系統に名前が挙がったこともあるが、

大宮通では207系統などのおこぼれをもらっている部分もあろう。

そしたら羅城門より南のユニークな区間はもっと散々では?

13系統はそれに比べれば四条通~西大路通の南側を結ぶ唯一のバスで意義はわかりやすいが、郊外の利用状況は悪いのだろう。

利用者数の多さがゆえに毎時4本程度と多いことも足を赤字額が多そうな要因である。

そして洛西ニュータウン方面、利用が多いのはそうだが、ニュータウン内をぐるぐる回る都合か、効率が悪いようだ。


列挙した中では84系統は小型バスで毎時1本というコミュニティバス的な路線で、

利用者の掘り起こしをしてこの数字なので、それはそれでいいのかなと。

コミュニティバス的なということで言えば16系統も大概だと思うのだが、

これは毎時2本程度、それに見合っているのかはよくわからない。


ということで、南区方面と洛西方面の赤字額が大きい傾向にある。

18系統・13系統は他の公共交通機関があまりない区間を走っていたり、

洛西方面は京阪京都交通・ヤサカバスなどある中で、分の悪い路線が市バスに集まっている側面もあるのかもしれない。

市バスの使命とはいえ、これが本当に持続可能なのか? と考えることも必要な時期が来るのかも知れない。

なお、洛西地区は市バスが京阪京都交通などの運賃に合わせている区間で均一運賃ではない。

こういう区間には市民優先の運賃設定は適用されないのでは?

複数社で分業しないと運びきれませんからね。どうなるか知らないけど。


京都市バスの均一運賃230円は使い方次第という側面はある。

ただ、地下鉄との乗継割引が一定の利用がある人だけが対象となり、

昔に比べると地下鉄とバスを組み合わせて移動するモチベーションが減っている。

都心でのバス折り返しが難しいとか、市電時代からの経緯もあって、

循環系統を筆頭に、都心部を貫通する長距離のバスが京都市バスの大きな部分を占めている。

乗客の入れ替わりも相当ある一方、長い距離を利用する人もいる。

どうせ均一運賃を払うなら、バス1本で長く移動できた方がよいという考えはあるのだろう。

ただ、それが市バスの混雑の原因ではないか。均一運賃が他都市に比べて高い原因ではないかというのはある。


地下鉄・バスを組み合わせた賢い利用を促すという点では バス・地下鉄1日券 というのがあるが、

一時は900円まで下がっていたが、全体的な見直しで1100円になった。

おそらく市民以外のバス運賃が値上がりすれば、これも上がるのだろう。

これはバスという点では洛北・嵐山の京都バス、山科・醍醐の京阪バス、栂尾までのJRバスをカバーする点では強いが、

鉄道という点では市営地下鉄2路線のみ、阪急や京阪の都心区間は使えない。

当然じゃないかといえばそうかもしれないけど、四条通・河原町通・東山通というバスの混雑区間の代替ルートである。

都度払いならば機動的に選びやすいが、1日券があるとその範囲でとなりがちである。

その点では バス・地下鉄1日券 にも欠点はあるのではないかと思う。


均一運賃360円払うなら、それでたくさん移動できた方がお得という考えも出てきそうで、

確かにこの値段でも鉄道より割安という区間は京都市内にはたくさんある。

そういう考えで利用されてしまうと、市バスのリソースは食い潰されるばかり。

京都市バスが均一運賃を基本としていることは仕方ないことではあるけど、

短距離利用であれば割安、鉄道との乗り継ぎであれば割安、というのを実現しないと持たないのでは?

constではなくstatic constが必要?

マイコンのとあるプログラムのビルド結果を確認していると、

なんかえらいスタックを確保しているところがある。

そんなスタックを使うような処理ではないはずと詳しく見てみると……

void func(unsigned long *ptr){
const unsigned short Tbl[]={0x0001, 0x0002, 0x0004 ... };

といった記述をした定数テーブルをわざわざスタックにコピーしているようだった。


Cにおけるconstの効力というのはかなり難しいのだが、

この場合はTbl[]の値を書き換えできないことを表す。

初期値から書き換えできない変数はROMに割り付けることができる。

なのでROM上にデータ構造を置きたいときは const を付けたグローバル変数として記述することが多い。

ローカル変数でもそうだと思ったのだが、なぜかそうならない。


この問題は “const” を “static const” にすることで解決する。

こうするとテーブルの値をROMに配置して直接アクセスするようになった。

ローカル変数にstaticと付けると、プログラムの実行中はずっと確保される。

staticを付けた変数の初期値は起動時に1回だけ初期化される。

よって初期値付きのグローバル変数と同様に処理されることになる。

ここにconstを付けることで初期化時から不変であることを示すので、

起動時から不変=ROMに割り付けることができるという判断になるよう。


確かに関数内のローカル変数の初期値は一般的には関数の中で初期化処理が行われる。

もしconstを付けない場合は、ROM上の値をスタックにコピーする挙動は妥当である。

constを付けた場合は、その関数内の初期化時から不変であることを表す。

ただ、関数が何度実行されても初期値が変わらないというならば、

それは起動時から不変=ROMに割り付けられるという判断は可能だし、

そのような判断を行うコンパイラも世の中にはあるはず。

でも、static constとconstで挙動差のあるコンパイラは多いらしい。


明確なところはわからないところはあるが、constを付けた配列を他のルーチンに渡す場合、

渡した先で不変であるというのが徹底されず、書き換えられることを心配しているのかもしれない。

ROMに配置すればどうやっても書換はできないが、

起動時にROM→RAMに展開するシステムだと書き換えようと思えば書換できてしまう。

そうなった場合でも、スタックへのコピーを行っていれば、次回関数呼び出し時には影響しない。

constを付けたのに書き換えされてしまうというリスクは static const でも同じだと思うが、

“static” と付けたことで、起動時に1回だけ初期化するよう明示されているので、

そのようなリスクはすでに受け入れられているという判断になるのだろう。

うーん、その懸念と回避策は妥当なのか? と気になるが、実務上はそのようにしていることが多いよう。


Cだと #define で定数を宣言することが多いが、こういう記法もある。

const unsigned int MASK = 0x00FFFFFFu;

ローカル変数でこのような書き方をする場合、コンパイラで定数として取り込まれてしまうことを期待している。

ROM上にこの値を置いて、それをレジスタにロードして使うようなこともあるだろう。

同様の理由で static const と記載した方がよいのかもしれないが、

ポインタとして使うことがなければ、おそらくは差は出ないだろう。

僕が扱っているところではこういうコードはないんですけどね。

マイナアプリの認証機能の謎

先日、とあるサービスでマイナアプリを使ったデジタル認証が走って、

その中で利用者証明用電子証明書と券面事項入力補助用暗証番号、

どちらも4桁なので同じにしている人が多いとは思うが、その2つを入力してカードを読み取るというフローがあった。

はて、これは一体何なんだろうと思ったのである。


最近、マイナポータルアプリがマイナアプリと名前が変わった。

理由は従来別に存在していたデジタル認証アプリの機能が統合されたから。

このデジタル認証アプリから引き継いだ機能が、認証機能と署名機能である。

署名機能は署名用電子証明書を使った署名で、以前はJPKI利用者ソフトというのを呼び出して対応していた。(今でも使われているかも)

今はマイナアプリを利用するように移行してるのかな?

この署名用電子証明書を使う場合は6文字以上のパスワードが求められる。

実印相当という事情があるからなのだが、けっこう厳密な仕組みである。


一方の利用者証明用電子証明書はマイナンバーカードの健康保険証利用、コンビニでの証明書取得、マイナポータルのログインなど、

マイナンバーカードで○○するというものの多くで使用されている。

ただ、この電子証明書には氏名などの情報は入っていない。

役所はシリアルナンバーと保険証情報、住民票などと対応関係が付くので、

それで必要な情報を取り出して、利用者は利用できる仕組みである。

デジタル認証サービスの認証機能では、各種サービスのユーザーアカウントとの紐付けはサービスごとに行う必要がある。

これだけでは誰のマイナンバーカードで認証したかわからないので、ほとんど使い物にならないように思う。


そこでオプション機能として券面事項入力補助APを使用して、住所・氏名・生年月日・性別を取得できるようにしている。

利用者証明用電子証明書の利用と、これらの情報の取得を1枚のカードから行えば、

それで本人確認ができるという仕組みだそうだが……

でも、それって法令上は認められてない本人確認方法なのでは?

マイナンバーの本人確認には不十分だが

このアプリはマイナンバーの申告に使うアプリではないのだが、

おおよそ法令上の本人確認の要件を満たすには署名用電子証明書の使用が求められている。


じゃあ、この認証機能での本人確認ってなんなんだよという疑問はあるが、

実用上は十分な確認能力があって、4桁の暗証番号の入力だけで事が済むというので提供されているのかなと。

デジタル庁はこの機能が法令上のどれに適合するかという書き方はしていない。

役所ならば、この機能は○○法施行規則の~に適合しますとか書いてほしいのだが。

何か法令上意味のある使い道があるのか? 僕には見いだせていない。

GIIIの数も重要

来年からJRAの5つのGIIIがGIIに格上げされるそう。

2027年度開催日割および重賞競走 (JRA)

対象となるのは下記のレースで、いずれもかっこ内のGIの前哨戦である。

根岸ステークス(フェブラリーステークス)
オーシャンステークス(高松宮記念)
キーンランドカップ(スプリンターズステークス)
みやこステークス、武蔵野ステークス (チャンピオンズカップ)

ダートとスプリントというのはGIの前哨戦をGIIとするという考えが追いついていない部分が多くあった。

最近はこれらの路線の活躍馬の国内外での評価が高まったということで、GIIへの格上げが可能になったのだろう。


というわけで、これは納得なのだが、同時にキャピタルステークスがGIIIになるという。

重賞格付けのないリステッドレースの中ではハイレベルであることなど考慮したものである。

それはそうだろうと思う。というのはこのレースは負担重量の決め方がグレード別定のGIIIと同じなのである。

どうしてそんなことになっているのか? それはこのレースがジャパンカップの週に行われるからである。

このレース、ジャパンカップの出走馬に帯同して遠征してくる馬の出走を想定したものなのである。

賞金水準が異なる外国の馬に収得賞金で負担重量を決めるルールは適用しにくい。

そのためグレード別定戦にしているというわけである。

もっともそれで外国馬が出走するのは稀なのだが、2024年にはGoliathに伴って来日したLe Nomadeが出走している。


というわけで格上げが可能なのはなるほどという感じだが、

年間スケジュールとしてはあまり重要なレースとは思えないところはある。

このレースは芝1600mだが、前週にマイルチャンピオンシップ(GI)、翌週に鳴尾記念(1800m, GIII)と近い条件の重賞が続く。

それだけ層が厚い条件とは言えるのだが、あまり重要ではなさそうなのはわかる。

背景の1つにはジャパンカップの週を平日月曜を含む3日間開催にすることがあり、

これは暑熱対策で7レース制で行われる分の付け替えである。

ジャパンカップ翌日の月曜のメインレースということになるそう。


決定的な理由ではないかもしれないがGIIへの格上げに伴い、GIIIの補充が必要になったというのもあるかもしれない。

というのも、重賞の格付けというのは GIよりGII、GIIよりGIIIの方がレース数を多くする必要がある。

5レースもGIIIからGIIに動くと数的なバランスはかなり変わる。

日本で国際格付けのある重賞(JRA重賞+東京大賞典)の数を数えると、

現在はGI:GII:GIII = 25:38:68 であるところ、GIIIからGIIに5レース動くと 25:43:63 となる。

まだバランスは保たれているが、まだGIの前哨戦でありながらGIIIというレースはいくつかあって、

長期的なことを考えればGIIIの補充は必要と考えたのかもしれない。


なお、この格付け別の数的な関係だが、条件別でバランスよくある必要はない。

実際、ダートグレード競走に着目すると GI+JpnI : GII+JpnII : GIII+JpnIII = 15:13:33 となっている。

芝・ダートあわせて、国際格付けと日本ローカルのJpnグレードを合わせて大小関係が成り立っていればよい。

今回、3つのダート重賞がGIIに格上げされると 15:16:30 になりこの問題はとりあえず解消する。

路線別にバランスよく配置する方が好ましいことは間違えない。


3歳戦はGIの前哨戦をGIIとするという考えがすでに多く適用されているが、

GIIIの一覧を見てみると、チャーチルダウンズカップ(NHKマイルカップ)、ユニコーンステークス(東京ダービー)、レパードステークス(ジャパンダートクラシック) とGIの前哨戦がまだけっこうある。

あと、葵ステークスは3歳重賞で唯一の芝1200m戦で、チャンピオン決定戦として重要度が高い。

重賞になったのが2018年、GIII格付けが付いたのが2022年と歴史は浅いが、位置づけ上はGIIでも不思議はない。

そういう状況からすると共同通信杯のように例年レースの評価は高くても格上げできないレースというのは出てくる。

本来、GIIでもよいのにGIIIであるレースを考えると、意外とGIIIは足りてないのかもしれない。


キャピタルステークスといえば2023年に現地で観戦している。

白毛図鑑と出世レース

このとき優勝したのがドーブネ、藤田晋オーナーが千葉サラブレッドセールで5.1億円で買ったという馬である。

馬主デビューのスタートダッシュを切るのに高額でも買ったという側面はある。

このキャピタルステークスがオープン3勝目というなかなか見ない戦績である。

どうしてそれができたのかというと、キャピタルステークスの負担重量の決め方も理由にあったのかもしれない。

重賞にも何度か出走するも重賞制覇はかなわず引退したが、立派な活躍である。

馬主デビュー間もない藤田オーナーにとっては賞金などで語れない価値はあったに違いない。

まぁ5.1億円という値段を見てはいけませんが……

フレームにくくりつけるバッグ

特定原付のバイク、もっともよく使うのは買い物のため。

ところがこのバイクには荷物を入れるカゴを常設していない。

自転車の後ろの荷台に付けるようなカゴを付けることはできるのだが、

それをすると折りたたむときに不便になるので、バッグを取り付けて対応している。

なかなかこれが難しいんだよなというので、3代目である。


これまで使っていたのは、バッグに鉄のフレームが入っていて、

これを起立させることで、箱形に安定するという仕組みである。

この状態で後ろ荷台に固定した金網の上に乗せると、それなりに安定する。

それで荷物もたくさん入るので便利に使っていたのだが……

この鉄のフレームが入っている布の部分が破れてしまい、崩れるように。

こうすると荷台の上でバランスが保てなくなり危ない状態になることもしばしば。

というのでさすがにこれはダメだと新たなものを探すことに。


新しいものは下と側面4面に堅いボードが入っており、これで面的に支えるようになっている。

側面を開いて出し入れできるという仕様なのだけど、これはバッグ自体を折りたたむための仕組みでもある。

輸送時はここを開いて折りたたまれた状態で届いている。

今回よかったなと思ったのは固定用の紐で、これをフレームにくくりつけておいて、

それでバッグと紐をバックルで固定すれば、それで安定して取り付く。

これで大丈夫なのかなと思ったが、すごく安定していた。


ちなみにこのバッグは横方向に拡張する機能を持っているのだが、

荷台から左右合計30cm以内のはみ出しに抑えるには拡張できない。

拡張しなければ荷台の幅+25cmぐらいなので問題ない。

もし買い物の量が多ければ、バッグの上に固定するような形になるのだろう。

ずっとそうですね。衣類や台所用品など買って荷物が多くなれば、いつも上にくくりつけて運んでいたので。

そういう使い方にも対応しやすいように作られている。


あと、バッグを手で運ぶための紐もついていて、肩掛けもできそうだなと。

これと折りたたんだバイクをセットで運ぶのもアリなのかもな。

今まで旅先ではリュックサックを背負って移動していたが、

旅行中の荷物を全部背負って移動するときは重くて仕方なかった。


前のバッグを買ったときにデリバリーの人みたいですねと言われたことがあるが、新しいのはなおさらである。

ただ、これは背負えないわけですけどね。

ちなみにあのデリバリー用のバッグ、ロゴ入りなのに誰でも買えるという話を聞いたことがある。

日常の買い物に使っている人もいるかもしれない。

陸上国境の走る沙頭角

日本と他の国の国境はすべて海上に引かれている。

なので陸上国境というのはどうにもなじみがないものである。

陸上の国境も川や湖など水域を隔てている場合もあるし、

山や原野などあまり人が住まないところにひかれるものが多い。

ただ、場合によっては市街地の中に引かれる国境というのもある。


日本にはどうにもなじみのない陸上国境、事実上もっとも近いのは香港である。

中華人民共和国の香港特別行政区は独自の出入境管理を行っている。

隣接する深圳市の間は陸続きだが、この境界は国境同様に扱われている。

イギリス統治下だった時代からの経緯もありかなり厳格な管理を行っている。

香港側では境界部付近を辺境禁区という許可を得なければ入れない地域にしており、

そのような事情もあり香港の中では自然豊かな地域だとされている。


そんな香港と深圳の間なのだが、1箇所だけ市街地にひかれた境界がある。

それが沙頭角である。陸上境界の東端にあたる。

イギリスが香港のうち新界を租借するとき、河口を境界に定めたのだが、

川が干上がってしまい陸地化、そこに市街地ができてしまったということだそう。

この境界部には中英街という、片側が中国(深圳)、片側が英国(香港)という通りができた。

さて、道路を挟んで片側が深圳、片側が香港ではどうやって管理しているのかと気になるところだが……


まず、沙頭角一帯は両地域とも許可を得なければ入れない地域になっている。

香港側は中英街を除く地域は近年は比較的許可を得やすいようである。

日本人でも手続きを踏めば入ることができるので観光で訪れている人の情報が見つかる。

というのも沙頭角を香港北部の海上観光の拠点にしようとしているようで、

その目的でまずは船着き場への往来を認めるようにして、まもなく中英街を除く地域の往来が容易に認められるようになったと。

ただ、中英街については香港側から許可を得て入るのはとても難しいことが知られている。

事実上は中英街に住む香港住民以外は許可が出ないということである。

中英街と出入りする部分には検問所が設けられている。


一方の深圳側なのだが、こちらは大陸住民は一定の制約のもと許可が出るそうである。

こちらで許可を得ると中英街の香港側まで往来できることになる。

さっき出てきた検問所は中国側で許可を得て入った人を通さないという目的もある。

と、考えると便宜上は中英街の香港側までは事実上は大陸側の管理下にあるとなりそうだが、

確かに出入境管理の点ではそうだが、もう1つ観点があってそれが税関である。

この中英街一帯は香港側の関税制度が適用されているとみられる。

香港は輸入品の関税はほぼ無税だそうなので、大陸からここに来て買い物すると免税ショッピングができる。

免税ということを抜きにしても香港で売っているようなものが買えると。

このため賑わったという経緯があるのだが、それをおおっぴらにやっては密輸である。

そこで深圳側から入った人は一定額以下のものしか持ち出せないようになっている。

また、地元住民を別としてはあまり頻繁には許可が出ないようである。


国境地域への立ち入りには特別な許可を要することや、関税制度で特別な扱いがあることは多いようだ。

逆に言えば、これらの制度が同制度とみなせる場合は往来を制限する必要はない。

オランダとベルギーの国境が入り組むバールレという町があるが、

1つの町にオランダとベルギーの2つの町の行政機関があるなど、

生活面では家屋の玄関のある国の制度に従う点で国境を意識する必要はある。

しかし、オランダ、ベルギー、ルクセンブルクの3国は以前よりベネルクスという関税同盟を結んでいた。

しかし、その前にはさらに歴史があって、それが1815年に成立したネーデルラント連合王国である。

ちょうど現在のオランダ・ベルギー・ルクセンブルクに相当する。

組織的には現在のオランダ王国の原型と言える。

(ブリュッセル・フランダース・ワロン地域とは?)

このためこの3ヶ国の間では出入国管理を行わないと取り決めがあったそうである。

現在ではEUの枠組みで当たり前に行われていることだが、この3ヶ国ではより古くからある。


ところで冒頭で日本から事実上もっとも近い陸上国境が香港・深圳間だと書いた。

しかし、おそらく境界を感じるという点では韓国と北朝鮮の間が最も近いのだと思う。

ただ、韓国の立場としてはここより北も自国の領土であって、あくまでも軍事境界線に過ぎないということである。

立入には特別な許可が必要で、ソウル近くでも開発が抑制されているのは似ているが。

以前は観光のため板門店一帯に立ち入ることができたが、現在は行われていないそう。

境界部には開城工業地区という両国共同運営の工業団地もあったが、運用停止されて長い。


距離的には中国・ロシア間の国境が近いのかなと思うが、これもなかなか往来が難しいですね。

なんて事情を考えると、香港ってことになるのかなと思った。

香港にしても深圳にしても日本から飛行機で直行できるし、

両地域の往来の激しさは世界的にも有数のものと知られている。

厳密には国境ではないですけど、事実上は国境だし。

アセンブラで書いてて思うこと

最近、仕事しながらふと思っていることがあって、

それはこのアセンブラで書いたコード、誰がレビューするんだろうということである。


ここ最近、いろいろ事情があってアセンブラでプログラムを書くことがある。

これはマイコンの初期化処理など、アセンブラでないと記述が難しい事情がある。

サンプルコードそのままで済めば楽だけど、なかなかそうもいかなくて、

そこそこ新規の記述が必要になっている。


Cで書けるものは書いた方がよいという話もあるのだが……

前にコンパイラのバージョンを変えたら動かないという問題があって、

調べたらCで書かれたコードに変数にレジスタ割当を強制する指示(当然コンパイラの独自拡張)があって、

ところがそのレジスタの選び方が悪くて、他の処理に影響してしまう可能性があった。

以前のバージョンの生成物は偶然この問題を回避できていたのだが、

ちょっと条件が変わると影響が出たということである。


どうしてこんな記述をしていたのかというと、特定の期間にメモリアクセスが発生するのを防ぐ必要があったからなのだが、

それを実現するにはアセンブラで書いた方がよかったよねと。

コンパイラの独自拡張の仕様を改めて見るとイマイチだったんですよね。

結局この問題はアセンブラで書き直すのではなく、Cのコードにちょっとした対策を入れることで解決したのだけど。

対策内容は妥当な内容だと思うので、今後は回避し続けられるだろうけど。


話を戻って、アセンブラでコードを記述すると使用するレジスタを厳密に指定したり、

使用する命令やその順序を厳密に指定したり、いろいろメリットはある。

そこまでしないといけないコードは全体からすればごく僅かだろうけど。

ただ、記述するにはスクラッチレジスタなどの仕様を知ってなければいけない。

一本道のプログラムならまだいいけど、ループや分岐があるとより複雑である。


で、冒頭の話に戻るわけですね。

記述した本人としては問題ないと思っているし、期待通りの結果になることはデバッグで見ているけど、

それをレビューするというプロセスは果たして回るんかねと。

どうも最近そういう仕事が僕に集中している気がして、いろいろ事情はあるけど。

複数人で並走してやるほど分量の多い仕事ではないわけだし。

当然、どういう意図を持っているとかコメント含めて資料は残しているけど、

細かく命令単位でフローチャートとかは書いていないわけだし。

なかなか作りながら不安になってくるところではある。


なんかいい方法はないのかなと考えているのだけど、難しいですね。

C言語もかなりハードウェアを意識した記述が可能ではあって、

それはゆえに注意が必要ではあるが、それなりの抽象度はある。

処理順序などもvolatile修飾子で制御可能な部分はあるが、

一方で偶然に任せて作られているコードもそれなりにあるような気がする。

既存のコードの修正をしながら、これは運任せっぽいなというのはあった。

ビルド結果を確認してねというコメントを付けておいたが。

都市の騒音がひどくならないように

この連休はCities:Skylines IIでいろいろ遊んでいた。

島の多いマップで、1つの島をやっと埋め尽くすぐらいまできた。

人口は25万人ほど、もうけっこうな規模ではある。

まだ開発の余地はだいぶあるけど、島が多いといっても平らだと単調か?

というわけでそろそろしまいかなと思う部分もあるが、いろいろ架橋したのを活用したい思いもある。


このゲームを遊んでいて困るのが騒音対策である。

いろいろな施設から騒音が放たれ、かなりの住居で「騒音公害がひどい」という減点が入る。

都市にはいろいろ騒音源があり、小学校の騒音もけっこう馬鹿にならない。

道路からの騒音もあるので道路沿いに公共施設を重ねると、重ね合わせで思いのほか騒音が大きくなることも。

まぁある程度までの騒音は大きな問題が無いという話もあるのだけど。


そんな騒音源でも別格に大きいのが工業地区である。

工場からの騒音は大きく、それが多く重なることでかなり広域に騒音が広がってしまう。

工場から住宅地までは騒音のためにそれなりに離す必要があり、

それがゆえに工場を細々分散して配置するのは難しく、工場は集中させざるを得ない。

農地や鉱業エリアを緩衝地帯にしたり、オフィスを緩衝地帯にしたり。

意外と鉱業は騒音源として密度が低いため住宅に隣接させてもなんとかなっている。

感覚的にはそっちの方が変ですけどね。


現実世界を考えれば低騒音・低公害の工業もけっこうあるのだけど、

このゲームのモデルでは工業というのはすべからず大きな公害源である。

かといって大きく隔離すると通勤が大変で人不足になってしまう。

ゆえに住宅と工業を緩衝地帯を挟んでサンドイッチのように重ねることになる。