車両管理のコンピュータ化とナンバリング

鉄道車両は、鉄道事業者が「輸送」という業務を遂行するための資産である。資産であるから、当然ながら資産管理を行わなければならないし、それ以外にも管理しなければならない情報がいろいろある。

昔ならそれを紙の台帳で行っていたところだが、それをコンピュータ化して効率化を図ろう、というのは誰しも考えるところ。ところがそうすると、車両の形式・付番にまで影響してしまうことがある、というのが今回のお話。

車両の管理とナンバリング

ここでいうナンバリングとは、車両の形式や、形式の中で個別の車両に対して番号を付与する際のルールのことである。

車両の管理に必要な情報としては、「形式」「番号」「製造日・納入日」「検査履歴」「走行履歴」「修理・改造などの履歴」といったものが考えられる。

鉄道車両の検査は一定の期間、あるいは走行距離に達する前に行うのが基本だから、検査履歴や走行履歴のデータは重要だ。ときにはダイヤが乱れて運用変更がかかることもあるから、予定ではなく実績に基づいたデータが要る。ともあれ、そういった膨大なデータを管理するのであれば、紙よりもコンピュータの方が効率的だ。

手元にある「鉄道ジャーナル」誌の1971年1月号に「われら誇り高き私鉄マン」という座談会記事が載っていて、その中で帝都高速度交通営団(当時。現在は東京メトロ)のO氏が「こんど出てきた問題はコンピューターによる集中管理です。1桁ふえるとおカネも手数もふえるのでナンバーリングをどうするかというのが、改番のウワサの出たもとじゃないかと思います」と発言している。

これは、コンピュータで管理するにはそれに適したナンバリングがあるのだが、現場の日常業務では、コンピュータ向きのナンバリングが必ずしもそぐわない場合がある、という趣旨の話であった。今なら一笑に付してしまいそうな話ではあるが、なにしろ1970年の話である。コンピュータの能力も、そこで扱うことができる文字種などのデータも限りがある。

そういえば、新幹線電車の形式は在来線のそれとは異なり、数字だけで構成している。これは「コンピュータで管理するのに都合がよい」という理由だったと記憶しているが、これも当時のコンピューティング事情を反映したものといえるかも知れない。なにしろ、東海道新幹線の開業は1964年の話である。

今はJR東日本の新幹線電車が頭に「E」を付けるようになったが、JR東海・JR西日本・JR九州の新幹線電車は相変わらず、数字だけである(「N700系」というのがあるが、あれは総称であって、個別の形式に「N」が付くわけではない)。

車両管理システムの仕様に起因する珍事

ところが、コンピュータで扱うのに適したナンバリングを、というだけでなく、そのコンピュータ・ベースの車両管理システムで当初に規定した仕様が、後になって面倒を引き起こすこともある。その中でも有名な事例が、東急電鉄のそれではないだろうか。

東急電鉄には8500系という電車がある。両先頭車が「デハ8500」「デハ8600」、中間電動車が「デハ8700」「デハ8800」、付随車(モーターなし)が「サハ8900」である。そして、それぞれの形式ごとに「1」からスタートする付番を行ったので、たとえばデハ8700であれば「8701」「8702」となる。

問題は、ひとつの形式が99両を超えてしまった場合である。常識的に考えれば「8799」の次は「8800」だが、すでに「デハ8800」という形式があるからダブってしまう。両先頭車はそれぞれ42両ずつで済んだから問題ないが、中間電動車は10両編成なら1編成中に3両ずつ入るので、99両を超えてしまった。

そこでどうしたのかというと、こうなった。

8798 → 8799 → 0700 → 0701 →…
8898 → 8899 → 0800 → 0801 →…

車両管理システムの都合で桁数を増やせなかったらしく、苦肉の策として1000の位の数字をゼロにしたわけだ。システムの仕様がナンバリングにトバッチリをもたらした一例である。システムを変えれば工数も費用もかかるから、ナンバリングに工夫をして済ませたということだろうか。

余談だが、東急ではこれ以外に「8098 → 8099 → 8080 → 8081」という逆戻り事例もある。

余談をもうひとつ書くと、同じような問題に見舞われたときに桁数を増やして対処したのが東武8000系である。こちらの車両管理システムでは、桁数を増やすことに問題はなかったらしい。

たとえば「クハ8100」が100両を超えて「モハ8200」とバッティングしたときには、8200番台に突入させる代わりに「クハ81100」とした。ただし、読み方が珍無類で「はちまんいっせんひゃく」ではなくて「はっせんひゃくのひゃく」である。

コンピュータ化すれば便利になることは多いが、コンピュータの能力(正確にはソフトウェアの能力か)やシステム設計時の仕様次第では、後世になっていろいろと困ったことが起きる、という一例かも知れない。いわゆる2000年問題もそうだが、仕様の策定というのは後々になって影響してくることがあるので難しい。

執筆者紹介

井上孝司

IT分野から鉄道・航空といった各種交通機関や軍事分野に進出して著述活動を展開中のテクニカルライター。マイクロソフト株式会社を経て1999年春に独立。「戦うコンピュータ2011」(潮書房光人社)のように情報通信技術を切口にする展開に加えて、さまざまな分野の記事を手掛ける。マイナビニュースに加えて「軍事研究」「丸」「Jwings」「エアワールド」「新幹線EX」などに寄稿しているほか、最新刊「現代ミリタリー・ロジスティクス入門」(潮書房光人社)がある。