昔に作ったプログラムの工夫

昔に作った評価用のプログラムを掘りだして、他の評価用プログラムに流用しようとすると、

「このプログラムはRAM上に配置すること」というコメントが。

自分で作ったコードなのだが、当時こんなこと書いたんだっけ? と考えてしまった。

そこで思い出したが、このプログラムはメモリアクセスの順序に制約があって、

それを満たすためにはROM上から実行すると不都合という事情があったのだった。


とはいえ、ROMのデータをRAMに展開する仕組みはないんだよな。

もともとROM上のプログラムはそのまま実行するのが前提のシステム、

なんと初期値付き変数すらないという構成である。

そこら辺の手当もなく「RAM上に配置すること」なんてよく書いたなと思ったが……

ちょっと考えたのだが、あくまでもデバッグ用のプログラムなので、

この関数のラッパーを作って、RAMにコピーして関数を実行というような形にした。

かなり横着した作りなのだが、期待通り動いたのでとりあえずこれでよいかなという感じ。


でも、なんで当時は安易にRAM上に配置することなんて言えたのだろう……

と気になって当時のビルド結果を掘り返すと真相がわかった。

この環境にはとある目的のためROMからRAMにプログラムを展開する仕組みがあったのである。

本来想定している使い方とは違うのだが、確かにそのように機能する。

当時よく思いついたなと今にして思う。なるほど、これなら簡単にRAM上に配置できるのか。


というわけで数年前の自分はいろいろ工夫してやってたんだなという話だった。

冒頭に「メモリアクセスの順序に制約があって」と書いたが、

当初は手順通りに書いたはずなのに意図通り動かず、ダミーアクセスをあれこれ加えたんですよね。

いろいろな工夫があり、その中にはRAM上から実行するという工夫もあったと。


そんなわけで流用したコードを適用するにはちょっと工夫が必要だったが、

無事動作し、意図したとおりの結果になることがわかった。

というかそもそも掘り返してきた当時の評価でほとんど確認できてるんですよね。

組み合わせの評価としてやる必要があるのか? という話ではあるのだが、

机上検討では全く問題ないが、懸念点がいくつかありましてね。

そこを立証するには実機評価する方がよいのでは? ということである。

iAEONアプリに株主優待が届いていた

買い物するときにWAON POINTの残高が表示されて、えらいあるなと思い、

iAEONアプリでWAON POINTの履歴を見ると、イオンの株主優待が先月付与されていた。

思っていたより早い? と思ったけど、先期分からiAEONアプリでの電子交付がスタートした影響もあるようだ。


もともとイオンの株主優待というのは、半年ごとに返金額を集計して、返金額が記載された返金引換証が届くので、

それを店舗に持参すると現金で返金されるという仕組みだったそう。

現在もこの方法はあるが、iAEONアプリにオーナーズカードを登録するとWAON POINTでの還元が原則になった。

これだと店舗で受取手続きをする必要がなく、自動的に還元される。

WAON POINTはWAONチャージすれば買い物に使えるので便利だし、

ウエルシアで毎月20日に使えば1.5倍の効力があるなど特有の用途もある。(cf. ウエル活する)


先期からiAEONアプリのオーナーズクラブ機能の電子交付機能が導入された。

もともとWAON POINTでの還元でも集計額を記載した書類は郵送されていた。

しかし、これをiAEONアプリ上で確認出来るようにしたので、電子交付の設定を行った場合は郵送されなくなった。

電子交付の場合は8月末までの買物分が9月28日にWAON POINTで還元されるとある。

郵送の場合は10月21日に付与、これは書類の郵送と同時期ということである。

なお、先期よりiAEONアプリに登録し、かつ現金受取も可能となり、

その中にも電子交付というパターンもあるが、これはおそらく店舗側の準備の都合か10月21日以降となっている。

電子交付により早くなるのはWAON POINTでの受取の場合のみである。


というわけで電子交付の場合は従来より1ヶ月程度早いサイクルとなったわけである。

ただ、なんでその情報がE-mailやアプリの通知で届かなかったのかという疑問はある。

株主優待の計算書類は別にどうでもいいわけだけど、この電子交付には議決権行使に関する機能もある。

そう、iAEONアプリから議決権が行使できるのである。

そこで気になってオーナーズクラブ機能の設定画面を見てみると、メールアドレスが設定されてなかった。

なぜか知らないが、オーナーズクラブ機能の登録にはメールアドレスが必須ではなかったようである。

本来は必須の登録事項のはずなのに、なぜかされてなかったと。

というわけで登録しておいた。これで今度からは届くのかな?


iAEONアプリに株主用の機能があるというのに気づいていた人はどれぐらいいるのだろうか?

イオンは個人株主が多い会社で、そのことを指して「お客さま株主」と言っている。

出資者かつ利用者という意味では生協と同じようなことを言っている。

生協では店の利用者を指して「組合員」って言うんですけどね。

ともあれイオンは店舗のデジタル化の中で株主事務のデジタル化を進めるモチベーションがあったわけである。

なかなかこういう会社はないんじゃないかなと思う。

基本的にこのあたりは信託銀行にお任せというところが多いだろうから。


そういえば生協も割戻金という配当金みたいな制度があって、

その中には利用割戻と出資配当金というのがあり、どのようにするかは生協による。

この利用割戻というのはまさにイオンの株主優待みたいな話で、

年間の利用額を集計して、それで割戻額が決まるというわけである。

共済だと割戻金は掛金口座に入金されるのが普通なのかなと思うが、

購買事業の場合は、店舗で受け取るか出資金に振り替えるかという選択肢があり、

多くの組合員は受取に行かず出資金に積み立てられているのではないかと思う。

その出資金に対しても出資配当金という割戻金が付く場合がある。

そのあたりもろとも脱退時に返金されることになる。

これは生協特有の制度ですね。割戻金をすぐ受け取らないことで生協の財政基盤強化に役立てられると。

長く生協の組合員をやっていると意外と出資金が積み重なっていることがあって……

県民共済のお引っ越しの後処理

イオンは生協ではないのでそういうわけにはいかないのですけどね。

アドバンテージがあるから消化試合ではない

NPBは両リーグとも優勝チームが決まった。

セ・リーグの方はいろいろあったが、1位・2位の両チームが敗れて阪神タイガースの優勝が決まるという結末だった。

ちなみに1位阪神・2位巨人の組み合わせは史上初なんだとか。

こういう接戦ではジャイアンツが強いというのが定説としてあったが、どうにも結果が出なかったようである。


今年からクライマックスシリーズに新ルールが導入された。

リーグ1位チームとファーストステージの勝者で争うファイナルステージ、

ファーストステージ勝者が勝利5割を切る場合、あるいは1位チームとのゲーム差が10以上ある場合、

リーグ1位チームには通常の1勝に加え、2勝分のアドバンテージが与えられるというものである。


この結果として生じたのが優勝決定後も消化試合とは言えないという話である。

そういうところでレギュラーシーズン終盤でも面白さがあると。

特に、パ・リーグは早々、ソフトバンクホークスが優勝を決めたわけで、

アドバンテージ確保のためにそれなりには気合いを入れてやっていたよう。


結果としては、ホークスは2位・3位ともに10ゲーム差以上が付いたため、

どちらが勝ち上がっても2勝のアドバンテージでスタートする。

一方のタイガースだが、2位のジャイアンツとはそんなに差が付かず、

3位のDeNAベイスターズは終盤の勢いがあり、勝率5割は確保、10ゲーム差も付かないようである。

よってどちらが勝ち上がっても1勝のアドバンテージとなるであろう。

どちらもそれはそうかという結果なんでしょうね。


ちなみに10/3の最終戦に敗れるまでジャイアンツは優勝の可能性を残していたが、

もし勝って優勝する場合、阪神が残りの日程で負け続けると優勝ということで、

負けて優勝のタイガースより散々な展開だったのではないかと思う。

そんな形での優勝は避けたかったのはそうだろうし、ファンも諦めムードだったのではないか。


クライマックスシリーズは日本シリーズの進出チームを決めるのが目的、

この結果によらずリーグ優勝の名誉が変わることはないが、日本一も当然目指したいところ。

セ・リーグにとってはソフトバンクが勝ち上がってくると苦しいなというのはあるでしょうけど、

だからといってやらないのは違うでしょうからね。

凱旋門賞のスポンサー

凱旋門賞が行われるパリロンシャン競馬場には、ウマ娘のオルフェーヴルとゴールドシップの等身大フィギュアが置かれているそう。

なぜ? と思うわけだが、Cygamesはプレミアムパートナーという上級のスポンサーになっている。

昨年よりパリ大賞典の冠スポンサーになるなどフランス競馬との関係を深めているが、

そこにはウマ娘のゲームの世界展開が背景にある。


そのプレミアムパートナーになったからか知らないけど、

Cygamesは「カタール凱旋門賞」という言い方をするようになった。

確かに凱旋門賞のフランス語表記を見ると”Qatar Prix de l’Arc de Triomphe”と表記されている。

さて、このカタールとは何なのか?

スポンサーの名前なのは言うまでもないが、ただのスポンサーではない。


凱旋門賞はヨーロッパではずば抜けた高額賞金レースとして知られる。

なんやかんや言っても日本からの遠征が絶えないのは賞金が高いからである。

フランス競馬はヨーロッパではお金がある方だと思うが、この高額賞金は普通には出せない。

これほどの高額賞金が出るようになったのは2008年、カタール競馬・馬術クラブとの提携を結んだことによる。

なんとフランスのレースにカタールの競馬統括機関が関わっているのである。

実際にはカタール競馬・馬術クラブのスポンサーであるカタール航空が凱旋門賞のスポンサーになっており、

レース名の “Qutar” はカタール航空のことである。同社のロゴと同じフォントだよね。


そのカタール競馬・馬事クラブとの提携の象徴とも言えるのが、

凱旋門賞と同日に行われる アラビアンワールドカップ という純血アラブのレースである。

このレースもそうなんだろうけど、カタールの王族はヨーロッパでも馬主をやっている。

そのあたりもフランスのレースをスポンサーとして支える動機になっているのではないかと思う。

外国の競馬統括団体と考えると変な話ではあるけど、そういう事情がある。


日本だと競馬のレースの冠スポンサーと言えば、マスメディアか鉄道会社かがほとんどで、

数少ない例外がジャパンカップのロンジンでしょうかね。

ジャパンカップを筆頭に高額賞金レースは多くあるわけだけど、

それを支えているのは馬券売上なので、スポンサーはほぼ名誉のためのものだろう。

凱旋門賞のスポンサー

凱旋門賞が行われるパリロンシャン競馬場には、ウマ娘のオルフェーヴルとゴールドシップの等身大フィギュアが置かれているそう。

なぜ? と思うわけだが、Cygamesはプレミアムパートナーという上級のスポンサーになっている。

昨年よりパリ大賞典の冠スポンサーになるなどフランス競馬との関係を深めているが、

そこにはウマ娘のゲームの世界展開が背景にある。


そのプレミアムパートナーになったからか知らないけど、

Cygamesは「カタール凱旋門賞」という言い方をするようになった。

確かに凱旋門賞のフランス語表記を見ると”Qatar Prix de l’Arc de Triomphe”と表記されている。

さて、このカタールとは何なのか?

スポンサーの名前なのは言うまでもないが、ただのスポンサーではない。


凱旋門賞はヨーロッパではずば抜けた高額賞金レースとして知られる。

なんやかんや言っても日本からの遠征が絶えないのは賞金が高いからである。

フランス競馬はヨーロッパではお金がある方だと思うが、この高額賞金は普通には出せない。

これほどの高額賞金が出るようになったのは2008年、カタール競馬・馬術クラブとの提携を結んだことによる。

なんとフランスのレースにカタールの競馬統括機関が関わっているのである。

実際にはカタール競馬・馬術クラブのスポンサーであるカタール航空が凱旋門賞のスポンサーになっており、

レース名の “Qutar” はカタール航空のことである。同社のロゴと同じフォントだよね。


そのカタール競馬・馬事クラブとの提携の象徴とも言えるのが、

凱旋門賞と同日に行われる アラビアンワールドカップ という純血アラブのレースである。

このレースもそうなんだろうけど、カタールの王族はヨーロッパでも馬主をやっている。

そのあたりもフランスのレースをスポンサーとして支える動機になっているのではないかと思う。

外国の競馬統括団体と考えると変な話ではあるけど、そういう事情がある。


日本だと競馬のレースの冠スポンサーと言えば、マスメディアか鉄道会社かがほとんどで、

数少ない例外がジャパンカップのロンジンでしょうかね。

ジャパンカップを筆頭に高額賞金レースは多くあるわけだけど、

それを支えているのは馬券売上なので、スポンサーはほぼ名誉のためのものだろう。

掘割を使うメリット

最近、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桁の暗証番号の入力だけで事が済むというので提供されているのかなと。

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

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

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