タクシー配車システム

　シリコンバレーから戻り、新規の企画に着手したが、引き継いだプロジェクトもあった。タクシーの配車システムである。過労で入院したプロジェクトリーダのピンチヒッターだった。
　タクシーにＧＰＳ受信機を取り付け（まだ弁当箱くらいあった）、位置を会社に送るのにタクシー無線を使う。そこまでは既製品。受信した位置情報をパソコンの地図に表示し、電話してきたお客様に近い車両を探す。地図表示部分のパッケージソフトだ。ファーストユーザへの納入が一カ月後に迫っていた。
　プロジェクトのメンバ五人はトラブル続きで疲れ果てていた。全員とにかく一日完全休養をとろう。私も一日、どう立て直すか考えてみたかった。
　この製品のファーストユーザ、大阪のタクシー会社に連日呼び出されていた。操作を改良しろ、地図表示がおかしいぞ。熱心な社長さんからのクレームだ。プログラムを直し、ＣＤに焼いて新幹線。製品に不信感を抱き始めていると営業が心配していた。全員一日休ませると伝えると、露骨に驚かれた。「二十四時間戦え」的昭和の空気だ。初のＮＴＴ外からの受注に営業も必死だった。
　信頼回復のために副リーダを現地常駐とした。プログラミングは得意ではない。客との緩衝材になってもらい、残りの若手で問題解決に当たろう。教科書的作戦を立てた。
　リーダが交代したのだから大阪に来てお客様に会ってくれと営業が言ってきたが断った。私はまだ仕様も把握できていない。うかつに頭を下げに行くと、理不尽な要求を呑んでしまう危険がある。これはパッケージソフトで、受注開発ではないのだ。開発に一千万円以上投じたソフトをたった百万円で売るのだ。
　地図はゼンリンから買った。Ｇｏｏｇｌｅマップなどない時代だ。ＶＢからゼンリンのライブラリを呼び出す。売値のかなりの部分がゼンリンライセンスだった。
　すでにタクシーにはＧＰＳ受信機を搭載済で、パソコンも社長室と電話受付席に設置し終わっていた。東京でテストするとうまく表示されるのに、大阪でタクシーが走り出すと表示がおかしくなる。大阪の何かが悪さしている？会社を出たところに池があるぞ、この寺か？暗中模索の試行錯誤。地図データは階層化されており、地形、道路、行政区画、住宅のように分かれていた。階層を絞り、データ量を減らし、表示を高速化していたのだが、他階層にリンクしている箇所があってトリッキーだった。マニュアルのサンプル通りではうまくいかない。
　地図不具合がなんとか収まったと思った翌朝、パソコンがフリーズしていると連絡がきた。メモリが枯渇していた。しばらくシャットダウンしなかったら、ＶＢがメモリを食いつぶしていた。すぐにマイクロソフトのサポートに電話した。その一方で、メモリを増やしたら、フリーズまでの日数を延ばせるか計算してみた。最大搭載メモリなら一週間連続運用できそうだ。とりあえず増設メモリを買って大阪に行かせた。
　「特別にパッチを作りました」とマイクロソフトが言ってきたのは夕方。「すぐ持って来い」と怒鳴った。「え、今からですか」一晩テストして明日大阪へ持って行く。調布のサポートセンタから品川まで、ＣＤが届いたのは深夜だった。朝、メモリを測定してみると、枯渇がむしろ加速されているではないか。
　無償でメモリを増設し、毎週リブートの運用を前提に納入する。さあ、実際の電話受付嬢に試してもらおう。すると、いきなり「車両番号は？」タクシー会社では車両に番号を振って管理していた。「三号車、○○ホテルへ向かってください」とやるのだ。しかし、開発側はナンバープレートと勘違いしていた。
「車両番号がない配車システムってありえへんわ」
　車両番号の追加自体は、そう難しくない。それより、配車という業務の実際を開発メンバの誰も理解していないことに背筋が凍った。今後まだ何が飛び出すか分からない。もぐら叩きである。
　出張を繰り返せば開発コストは膨らむ。累積赤字三年解消が課せられていたが、すでに計画の原価を越えている。販売計画の三年百本では足りない。それが見えてきて、メンバの士気は急速に下がり、これまで息を詰めるようにして結束していたチームが分裂してしまった。
　私は納入までのピンチヒッターだ。事業計画を立てたのは私ではない。データセンタ事業やＡＳＰコンソーシアムをやらねばならない。ファーストユーザの納入まででサヨナラする手もある。そこへ、東北の営業から受注の連絡が入る。
　子会社になって、地元の小さな会社を回る営業たちは、安くて導入が簡単な製品を待ち望んでいた。百万円台のパッケージソフトは手頃な商材だった。しかし、ＶＢのバグもゼンリンの謎も根本解決できていない。そもタクシー会社の実態を知らない。ファーストユーザの言うなりの仕様で、果たして百本以上売れるのか。一年、二年、赤字の泥沼でもがくより、いま撤退し、開発要員を他に振り向けるべきではないか。
　タクシー無線の老舗メーカの門を叩いた。お恥ずかしい限りだが、撤退することになった。弊社の顧客を引き受けてもらえないだろうか、と頭を下げた。「タクシー会社は大変なんですよ」と部長さんは話してくれた。ワンマン社長が多い。運転手は導入に反対だ。現在位置を監視され、さぼれなくなる。「三号車」「あ、いま賃走中です」嘘をつくようになる。しかし、日誌と突き合せればバレてしまう。そこで運転手は無線が届かないふりをする。「うちにクレームが来るんですよ」そうならないように、無線が届くエリアを事前に確認してもらうのが肝要だ。東北のタクシー会社の住所を伝えると、「あそこは地形がすり鉢状だからアンテナは一本で大丈夫」さすがプロである。
　納入まで一カ月のピンチヒッターだったが、撤退には三カ月かかった。その間、開発要員は遊ばせたくない。並行して賃貸住宅の検索サイトを企画し、特許もとった。サイトに地図を組み込みたかったが、インターネット経由での使用をゼンリンは許してくれなかった。
　タクシー配車システムの撤退には勇気がいった。一本は売れた製品を公式に終了とする。コムウェア初だったと思う。ＮＴＴはサービスを終了しない会社だ。たとえば「共同電話」は、一本の電話線を二軒で共同利用する、電話線が不足していた時代の苦肉の策だ。完全終了は二〇一六年だった。
　撤退は早いうちに決断すべし。これは妻から学んだ。東芝でフロッピーディスクドライブの輸出を担当していた妻は、撤退が決まるまで一年以上営業できない日々を経験していた。技術部隊も悶々としただろう。（どうしてもＦＤＤを続けたい技術者は競合に移籍したそうだ）
　フロッピーは価格や新技術との競争で撤退したが、タクシーは全く違う。既製のパーツを組み合わせた「ベスト・オブ・ブリード」の商品企画だった。それまでの同種製品は桁違いに高額か、地図が貧弱だった。ゼンリンがパソコン用のライブラリを出したので、それを使ってシステム化すれば安価なパッケージソフトができる。ここまでは開発の視点だ。
　ゼンリンの問題やマイクロソフトの問題をクリアしたとしても、この比較的安価な商品を日本全国で百本以上売らなければならない。営業について事業計画は全く触れていなかった。もしタイムマシンで戻れるとしたら、事業計画から担当していたとしたら、どうすべきだったのだろう。
　タクシー無線と組み合わせて運用するシステムだが、彼らも配車システムを扱っているケースが多い。競合の製品とセットで売るのだから、自分たちで営業するしかない。タクシー無線のメーカにＯＥＭ提供する案もあるが、当時は一般市場への販売に燃えていたから、ＯＥＭの議論はどこにもなかった。では直営で百本をどうやって売るか、議論が必要だった。
　大きなタクシー会社の電話受付なら複数のオペレータがいて、コールセンタシステムを提案できるだろう。そのオプションに地図を加える案もある。だが、その規模のタクシー会社は全国に何社あるだろう。
　大都市では流しが多い。目の前を流しているのに電話をかける客はいない。呼出が必要なのは地方である。地方のタクシー会社は小規模。東北の案件がまさにそうだった。人口四十万にタクシー五社。どれも小規模で、三社は同じ呼び出し電話番号で共同運行していた。
　共同ってどうなんですか？タクシー運転手に聞いてみると「公平にやってくれとるか分からん」なるほど、電話もダイヤル自動式になったのは公平性が原因だった。
　自動交換機を発明したストロージャー氏は、カンザスシティーの葬儀屋だった。注文が来ないと思ったら、ケンカした町の交換手が別の葬儀屋につないでいたのだ。憤慨して自動交換機を発明した。それまで電話交換手に「葬儀屋につないで」と伝えていたものを、利用者が葬儀屋を決め、ダイヤルする、いまの電話の原型ができた。
　タクシー会社がそれぞれ受付電話を持てば公平だが、利用者には不便だ。どっちの葬儀屋でもいい。すぐ来てくれ。（どこのタクシーでもいい。すぐ来てくれ）その見える化を実現したのがＵｂｅｒだ。乗客の位置情報を使う点が画期的だ。電話だと配車先が分からないケースがある。スマホの普及で乗車位置を確認できるようになり、そこまでのルートを運転手に指示できる。土地勘のない運転手でも可能になる。（ただし、最適ルートを提示するソフトには大きな開発投資が必要だ）Ｇｏｏｇｌｅマップでも代表的なルートは出してくれるが、プロの運転手ならば、あそこは渋滞、あそこは工事中と知っている。
　さて、大阪のタクシー会社のねらいは、本当に配車の効率化だったのか。呼出より流しが圧倒的に多い。常駐した副リーダは「車両の位置を社長が知りたいだけ」とあとから述懐した。いつどこを流すかで売上が決まる。社長はパソコンにかじりつき「そこちゃうやろ」と怒っていたらしい。
　ベテラン運転手は知っていても同僚や後輩には教えない。社長は会社全体の売上を上げたい。それなら、社員研修という案もあった。ベテランの走行履歴を新人研修に使うのだ。ベテランはなぜこの時間ここを流すのか、それで売上はどうだったか。これならタクシー無線とは無関係に営業できた。ベテランの走行履歴と売上データを大量に集めていけば、ディープラーニングによって「この時間帯、どこを流すべき」を指南するＡＩができた。
　タクシーに乗ると運転手と話すことにしている。「月一で名古屋まで御供する旦那がいましてねえ」その運転手が話し始めた。三人で一日貸切って名古屋を往復すると新幹線より安いそうだ。新幹線では仕事の話ができない。「あんたと行くと商談が成功するから、次回も頼むよってことになりやした」この運転手は落語家のように面白い。気分もほぐれる。運転手も客の好みを知れば「曲はいつもの」「お土産はあそこのが」とサービスできる。予約であれば、最も近い車両である必要はなく、むしろ気に入った運転手を選びたい。
　この話を思い出して、マレーシアのペナン島でタクシーを一日貸切ってみた。「歴史的観光地を案内して」と頼むと、イギリス軍の砲台を日本軍がどうやって陥落したか、運転手は熱弁をふるった。（日本人に知って欲しかったらしい）そして、砲台跡からの帰りには電子部品の工場群を案内してくれた。工場と空港を往復するトラックの運転手だったそうだ。ペナンの歩んだ歴史を学ばせてもらった。（ランチまでご馳走になった）
　一人暮らしの伯母さんが車椅子生活になった。病院、銀行、そのたびタクシーを待つ。見かねたマンションの管理人さんが電話で呼んでくれるようになった。何度か同行してみた。あからさまに嫌な顔をする運転手がいる。反対に優しく、手際のいい人も。次回は指名したいものだ。名刺にＱＲコードを入れ、簡単な予約システムでもあったら、などと考えてしまう。（海外のタクシー運転手はすぐ名刺を渡してくる）
　妻のお母さんの出身地の釜石に家族で旅行した。旅館で「製鉄所の社宅はどの辺りにあったのでしょう」と聞いたら番頭さんが「案内しましょう」社宅で生まれ育った人だった。「この広場で盆踊りやったもんです」「あそこに防空壕ありましたね」お母さんは大感激だった。こういう感動を生むシステムができないものかと思った。（震災の前でした）
　さて、在宅医療はタクシー配車に似ていた。クリニックの規模はタクシー会社に近い。乗客は医師と看護師、一日貸切りだ。運転手には、道路事情や患者家族の都合に配慮したうえで、どう走ったら効率的か考える能力が求められる。診療は基本予約制だが、緊急往診の要請も飛び込むから機転も必要だ。最適経路探索は技術的には面白いが、運転手をロボットにしてしまってはいけない。
　そうそう、車両番号ではなく名前を付けられるようにした。愛称をつけるクリニックが多いのだ。