モデリングの話は勉強としては必要（必須）なんだけど、実際のシステム化の際に、モデルが段々崩れていったり醜くくなってくことは良くある。なるべくすっきりしたままにするのが、交渉力だったりするけど、、、。で、今日そんなことを強く感じた事例に遭遇。 趣味で、トレラン（トレイルランニング）に行くけど、結構悩ましいのがバスの時刻。電車だと経路検索のソフトなどで判明するけど、路線バスは困ることが時々ある。特に奥多摩方向での西東京バス。携帯電話での検索でも、他と比べたら、結構操作が面倒に感じる。1時間に1本とかはザラなので、帰りのバスの時刻で別ルートのいくつかを検討するからだろうが。
今日知ろうとしたのは、武蔵五日市駅から、数馬や都民の森というポイントへのバス。行きと帰り。 http://www.nisitokyobus.co.jp/rosen/tominnomori.htmlでの時刻表を画像化したものが左。ここでは時刻そのものが重要じゃないので、画像的に細部が分かるようにはしてない。
そもそも、日によって運行するものとそうでないものが多い。グレーの所は、都民の森までは行きませんと言う意味。白＋黄色部分は、都民の森に行くけど、黄色部分は運休する時がありますという意味。運行する日が、表の上の方に書かれている。 経由地が3種類あって、急行と普通、都民の森に行くのに乗り換えるのと乗り換え不要とがある。当然、平日と土・日のダイヤの別も。 人間だと、予定している日にちを前提として、この表から探し出すのかな。ただし、この表の情報を元に、出発地と到着地、そして利用日を入力して運行時刻を表示するアプリケーションを考えると、データの持ち方や処理がそこそこ複雑に思える。あるいは、すっきりしない。また、そもそも利用日を入力するのは操作的に良いとも言えない。つまり、デフォルトを当日としたり、土日も直近の土日がありがたい。結果の表示でも到着時刻だけじゃなく、急行かどうかは当然として、乗り換えするのかは判明した方がありがたい。実装時には、他の時刻表のデータ（データベース）との整合性とか連携をどうするかも悩ましそうだ。 経路検索のサービスで、路線バスまで含めているのが少ない訳が分かった気がした。なお今回の事例での運行時刻表示するアプリケーションの必要性は微妙だけど、一般的にも単純なデータ構造にならないケースは少なくない。設計としては単純なデータ構造やロジックにしたいけど、実際の運用がそうでないケース。モデリングの勉強と同時に、そう単純にならないケースへの対応の勉強も必要だろうにと考える。 （念のためだけど、奥多摩に行った時には西東京バスにはお世話になってるので、そのこと自体には感謝。）
