Scribble at 2024-06-20 12:04:31 Last modified: 2024-06-20 12:33:55

EU の後援もあって、路線図を設計するツールもオープン・ソースでリリースされているという。データもオープンになるようだから、考えようによっては鉄道会社だけではなく、他の物流や物販の事業でも応用はできそうだ。アイデアとしては面白いので、アプリケーションとしてのパターンやデータのフォーマットを共有して、日本国内向けに事業を展開する会社でも利用するチャンスになるのだろう。もっとも、日本国内向けのデータを、同じようにオープンでリリースするような経営者は、少なくとも僕ら以上の年齢では少ないと思うので、ぜひ三十代以下の人々に期待したい。とは言え、三十代のガキでもオープン・ソースなんて本当に理解してるかどうか、怪しいがね。

ただ、GitHub で公開されているソース・コードを眺めていると、ちょっと違和感をもつところがある。たとえば、開発に使っている言語として、TypeScript, Java, Python, Rust という、かなりバラバラな処理系が混在しており、見通しが非常に悪い。ふつう、僕らのような「システム・アーキテクト」と呼ばれる、処理系だけでなくデータベースやネットワークなどシステム全体を設計し統括する職能のエンジニアは（本来、「プログラマ」とは、このレベルの職能を指しており、メーカーで言う「プロダクト・マネージャ」に相当すると言ってもよい）、実装に採用する処理系の選定も行う。その場合に、もちろん与件に応じた適材適所というものは考慮するから、単一の処理系がベストだなんていう偏見はないのだけれど、しかしこれはちょっと奇妙な感じはする。僕としては、これだけバラバラな処理系を採用する合理性や妥当性を全く感じないからだ。

考えられる理由として、要件に合致する機能を提供する何らかの特定のライブラリが、そうした異なる処理系に対応してリリースされていて、要するに尻尾に犬が振り回されてる系のアーキテクチャ設計になってしまっている可能性がある。あとね、たまにいるんだけど、一つの処理系だけを使うと危ないっていうんだよね。その処理系一つに何か脆弱性があると全体を支配されるので危険だっていうわけ。でも、逆に複数の処理系を使うと、それぞれに別種の問題が生じるリスクが高まるから危険だという人もいる。何にしても、僕に言わせればどちらも未熟な発想だ。幾つの処理系を使って、どう組み立てようとリスクはあるわけで、単一の処理系を採用するならそれに応じた機能要件上のリスクと非機能要件上のリスクとを考慮して、たとえば処理系以外のサーバの機能を使ってサポートするとか、あるいは攻撃された場合を考えてコールド（あるいはホット）・スタンバイのサーバを並立するとか、処理系だけを見ていては解決しないところで設計なり対策を考えなくてはいけない。また、処理系を OSRD のように（実際にソース・コードを落としてみたら、それぞれの言語で書かれてるコードで、お互いに分別するほど複雑なことをやってるわけでもないんだよね）４つも５つも使うなら、その是非はともかくとして、処理系どうしのメッセージングは必ず疎結合になるのだから、API としてフェイル・セーフの仕様をしっかり定めておくといった対策が求められる。