アカウント名:
パスワード:
運用で無効化するのは別に変なことでも理不尽でもない。
他社地域のカードを使えるようにするには、あらゆる駅での乗り降りで正しく運賃が計算できる必要があるし、そのためのテストには莫大なコストがかかる。
今回誤った運賃を請求された人がいなかったのは単なる幸運で、簡単に対応できるようになるものではないよ。
以下も参照。
自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説http://www.publickey1.jp/blog/12/_1040.html [publickey1.jp]
> 他社地域のカードを使えるようにするには、> あらゆる駅での乗り降りで正しく運賃が計算できる必要がある
乗換改札なしに乗り入れをするならその通りでしょうけど、バスの場合は車への乗降レベルで料金計算が完結してるんだから、そんな追加コストは発生しないでしょう。
すでにCI-CA/PiTaPa/ICOCAの料金収受システムは導入しているので、Felicaに対する引き落とし元データ領域として他の電子マネーに対応すればいいだけ。
問題となるのは、そこで電子マネー運営事業者に対して引き落とした分の運賃を請求するという経理処理のところでしょう。でも、関西の場合まさにそのために「スルッとKANSAI協議会」というハブ組織が既にあり、奈良交通も既に加盟しているわけですから、あとは技術的問題というより、政治的な問題がクリアされるかどうかの問題だと思います。
バス⇔バス、バス⇔電車での乗継割引もあるので、そう簡単にはいきません。
奈良交通の良くあるご質問 [narakotsu.co.jp]ページを見ましたが、奈良交通のバスがその点を全く考慮していない(他社路線のことなどしったこっちゃない)という理解で合ってますか?
乗り継ぎ割引については、奈良交通は実施していないようなので、元コメでは言及しませんでしたが、たとえ乗り継ぎ割引を実施している交通機関だったとしても、「既に自社独自の交通ICカードを導入している」ような事業者であれば、その段階で乗り継ぎ割り引きの計算システムは構築できてるわけです。
その上に「他社の交通ICカードを使えるようにするための追加コスト」を考える段階では、「運賃計算の複雑さ」は何の問題にならないでしょう。
バス停コードは知らないけど、駅コード [wikipedia.org]は地域毎にコードが振ってある。なので、新しい地域のカードに対応する場合はプログラムの改造が必要になる場合もあり得ます。無かったとしてもテストはやらなきゃいけないので、簡単に対応できるものではないですよ。
また、消費税改正に合わせた運賃1円単位化に絡む不具合のようなケースも考えないといけないし。(関東で1円単位の乗降をしたカードを関西で利用できないという不具合があった。)
えっと、「既に自社独自の交通ICカードを導入している」んだから運賃計算はできているんですよね。あとはその運賃分をSuicaから引き落とせるかどうかだけだと思うんですけど。"奈良交通で受けたサービス"の代金をSuicaで払えるようになるかだけなので、「新しい地域」かどうかなんて関係ないはず。「関東で1円単位の乗降をしたカードを関西で利用できない」なんてのが、どういう設計だとそういうことが起こるのか興味があります。10円単位の引き落とししか考えてなかったとかかな?
他者の交通系ICカードを受け入れるということは、お互いに記録する情報が衝突しない保証を求められる。例えばの話、自社Aの駅コードと他社Bの駅コードが重複してた場合(一応、日本鉄道サイバネティクス協議会が調整してるはずだが)、Bと相互利用が可能な交通系ICカードのIDだった時点で弾かないと何が起こるかわからない。その辺のやり取りもなく勝手に他者の交通系ICカードを書き換えたら不味いに決まってる。
コンビニで1円単位の決済はできるわけですし、運賃が1円単位かどうかがどう影響するんでしょうね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
規格上対応していても (スコア:0)
運用で無効化するのは別に変なことでも理不尽でもない。
他社地域のカードを使えるようにするには、
あらゆる駅での乗り降りで正しく運賃が計算できる必要があるし、
そのためのテストには莫大なコストがかかる。
今回誤った運賃を請求された人がいなかったのは単なる幸運で、
簡単に対応できるようになるものではないよ。
以下も参照。
自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説
http://www.publickey1.jp/blog/12/_1040.html [publickey1.jp]
Re: (スコア:1)
> 他社地域のカードを使えるようにするには、
> あらゆる駅での乗り降りで正しく運賃が計算できる必要がある
乗換改札なしに乗り入れをするならその通りでしょうけど、バスの場合は車への乗降レベルで料金計算が完結してるんだから、そんな追加コストは発生しないでしょう。
すでにCI-CA/PiTaPa/ICOCAの料金収受システムは導入しているので、Felicaに対する引き落とし元データ領域として他の電子マネーに対応すればいいだけ。
問題となるのは、そこで電子マネー運営事業者に対して引き落とした分の運賃を請求するという経理処理のところでしょう。でも、関西の場合まさにそのために「スルッとKANSAI協議会」というハブ組織が既にあり、奈良交通も既に加盟しているわけですから、あとは技術的問題というより、政治的な問題がクリアされるかどうかの問題だと思います。
Re:規格上対応していても (スコア:0)
バス⇔バス、バス⇔電車での乗継割引もあるので、そう簡単にはいきません。
Re:規格上対応していても (スコア:1)
奈良交通の良くあるご質問 [narakotsu.co.jp]ページを見ましたが、奈良交通のバスがその点を全く考慮していない(他社路線のことなどしったこっちゃない)という理解で合ってますか?
Re:規格上対応していても (スコア:1)
乗り継ぎ割引については、奈良交通は実施していないようなので、元コメでは言及しませんでしたが、
たとえ乗り継ぎ割引を実施している交通機関だったとしても、
「既に自社独自の交通ICカードを導入している」ような事業者であれば、
その段階で乗り継ぎ割り引きの計算システムは構築できてるわけです。
その上に「他社の交通ICカードを使えるようにするための追加コスト」を考える段階では、
「運賃計算の複雑さ」は何の問題にならないでしょう。
Re: (スコア:0)
バス停コードは知らないけど、駅コード [wikipedia.org]は地域毎にコードが振ってある。
なので、新しい地域のカードに対応する場合はプログラムの改造が必要になる場合もあり得ます。
無かったとしてもテストはやらなきゃいけないので、簡単に対応できるものではないですよ。
また、消費税改正に合わせた運賃1円単位化に絡む不具合のようなケースも考えないといけないし。
(関東で1円単位の乗降をしたカードを関西で利用できないという不具合があった。)
Re: (スコア:0)
えっと、「既に自社独自の交通ICカードを導入している」んだから運賃計算はできているんですよね。あとはその運賃分をSuicaから引き落とせるかどうかだけだと思うんですけど。
"奈良交通で受けたサービス"の代金をSuicaで払えるようになるかだけなので、「新しい地域」かどうかなんて関係ないはず。
「関東で1円単位の乗降をしたカードを関西で利用できない」なんてのが、どういう設計だとそういうことが起こるのか興味があります。
10円単位の引き落とししか考えてなかったとかかな?
Re: (スコア:0)
他者の交通系ICカードを受け入れるということは、お互いに記録する情報が衝突しない保証を求められる。
例えばの話、自社Aの駅コードと他社Bの駅コードが重複してた場合(一応、日本鉄道サイバネティクス協議会が調整してるはずだが)、
Bと相互利用が可能な交通系ICカードのIDだった時点で弾かないと何が起こるかわからない。
その辺のやり取りもなく勝手に他者の交通系ICカードを書き換えたら不味いに決まってる。
Re: (スコア:0)
コンビニで1円単位の決済はできるわけですし、運賃が1円単位かどうかがどう影響するんでしょうね。