続編です。
ネタは自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（中編）より。
いよいよ、本題の運賃計算です。
運賃というのは最短（最安）経路で計算されるのが当たり前と思いがちですが、本来は運賃は乗車した（する）経路で計算するのが基本です。都市圏のJRは例外的に最短経路で運賃計算するルールになっていたのです。ICカードになる前は乗り入れ先で自動精算機を使うと自己申告制とはいえ、乗車経路を選択させて精算金額をだしていたので、それなりに乗車経路は重視されていたのです。
ICカードは自動改札機へのタッチアンドゴーなので、事前に切符を買うという行為もなければ、精算という行為もありません。あるのはチャージだけです。そうなると、乗車経路を確認する機会はなくなります。だからなのかは分かりませんが、ICカードが首都圏の私鉄でも導入されるときに、乗車駅と降車駅の最短（最安）経路運賃が自動的に徴収されるという形になりました。パンフレットなどでも「実際の乗車区間の運賃と異なる場合があります」とハッキリ書かれるようになりました。
さて、そうなると自動改札機には瞬時に運賃計算をするという機能が求められます。首都圏は相互乗り入れの存在により、改札機を通らずに何社もの路線を乗り継ぐことが出来ます。利用者には楽なこの制度もテストをする側からすれば過酷な条件であることでしょう。テストであれば当然すべてのケースを尽くすべきとなるのでしょうが、妥当な絞り込みを行っても10の26乗通りという、人間にはよく把握できなような大きな数になります。
そして、泣く泣くさらに削って、実行可能な数まで減らすのだと本文では述べられています。これはある意味では、衝撃的です。テストが網羅性より実現（実行）可能性で行われているということです。つまり、漏れがあるからバグはつぶしきれないと認めています。「絶対○○」という絶対神話が好きな日本人には受け入れられない考え方かもしれません。しかし、現実としてムリなものはムリなのですから、そこは費用対効果を考えつつ妥当なラインを選択するというのはエンジニアらしい合理的な考えです。しかし、何を削ったかは分かっているから、割り切ることができる、と。
この考え方はアナログたる連続値を、人間にとってそう問題のないレベルまでは情報を捨てて離散値にするデジタル化の発想と似ているのが非常に興味深いものがあります。