運行系統図といううらやましいノウハウ

　千葉のバス路線、運行系統図である。
　実にすっきりしている。うまいくあいに循環的なものが少ないとはいえ。しかしそれにしても見事なデザインだ。

　私はこれにあこがれている。「ジョブネット図」に見えて仕方がないのだ。
　「なぜか」って尋ねられることはないわな。バッチ処理のシステムを手掛けたことがある人間であれば、言われてみれば、と納得すると思う。
　この運行系統図においてターミナルや分岐点はデータベース。バスの始発はデータファイルの供給元。これがバス停というプログラムを経て、集まったり分離したりして、終点、つまりユーザーに渡す形表だったり、照会画面だったりに至る道に見えてくるのだ。データの流れが色分けされているので、このデータが届かなかったら影響がどこに及ぶか、停留所というプログラムが停止したらどこからやり直せばいいか、ものすごくわかりやすそうではないか。

　連想したのは、３年ほど前だったかにニュースで見た、地方自治体の障害訓練。ホワイトボードを出してはいるものの、あるべき姿と現状把握した状態がごちゃ混ぜに書かれており「これでは対応できないな。現状を誤認してしまう。」
　しかし、それを仕切るだけの人材なんて地方に行くといない（育つ環境がない）のだろうなあ。それなりに苦労すると自然にできるようになるのだが。
　影響先影響元を洗い出して、連絡体制を書く。いつどこから何の連絡が入った（現状把握）。いつどこに何の連絡をした（リカバリーの様態）。この２つは規模が大きければ運用部門宛と影響先部門に分けて把握。タイムリミットを書いて、次々とプランを再構築（「遅れたけど、データはできたから今送るよ」もあるし、「通常の送付期限である19時にはに間に合わない。20時に再度連絡するからそれまで待って」もある。場合によっては当局報告も必要ってこともある。調査中ならだれが何を調査しているか書いて、可能性のある原因を潰してゆく。こういうときあるべき状態、を示すジョブネット図は必須。だが、これを元にリカバリ計画を立てていくのだ。絶対に正しく、かつ分かりやすくなくてはならない。ジョブが止まったからと言って関係ないところまで止めておくわけにはいかんし、かといって関係ないと思ったら実は、というのがあってもよろしくない。たとえ印刷してホワイトボードの隅に貼っているだけとしても、だ。

　ポイントは

1. 障害時の対応のためにジョブネット図は必須である。
   （何時どこからなんという連絡を受けたかを蓄積してジョブネットのどこまで対応が済ん
2. ところがジョブネット図を作るのはある程度センスが必要でそういう人が育つ環境は地方にはあまりない。
3. しかしバス会社や、地方公共団体の直営バスの運行系統図を描くノウハウを持った人間は地方にもいることが分かった。ならばその人たちの力を活用できまいか。 ということである。

　こんな動きをしなければならないのはシステムの障害対応に限らない。天災で連絡が取れない地域があった場合の支援でも似たようなものであろう。道が見込み時刻までに復旧しなければヘリを飛ばして救援物資を送る、あるいは隣県からトラックを手配するといったプランを考えていかなくてはならない。そのためには「ええ、通じてたんじゃなかったの？」「いやそれは当初の復旧見込みで、そのあと連絡は来てません」なんてことが無いように仕切らなければならない。
　それこそ「交通図」が大事になってくるのである。特定の道が通行不能となった時にどうするか、それこそバス会社は誰よりも詳しかろう。