●誤差を知らせる

　2000年も押し迫ったころ、インターネットグループでは、KDDIに置かれたサーバー「ロケーション・サーバー」からサービス提供会社に渡すデータの詳細を決める作業が煮詰まっていった。

　番組内容によっては、提供会社のほうで、利用者のピンポイントの現在位置情報がほしいのか、大まかでいいのか、というのは千差万別だ。

　しかし、サービス全体を運営するシステムをつくるためには、どれにも対応していなければならない。

　当初、インターネットグループでは、細かい誤差情報を提供会社に明示するようにしていた。しかし、メンバーから、「サービスを提供する側としても、『何メートルの誤差でした』という情報をもらっても扱いづらいんじゃないかな」といった声が出た。

　そのため、急きょ、「だいたいでいいから、どのくらいの精度だったのか、というのがわかる項目があればいいんじゃない」という意見について考えることにした。

　並行して、KDDIの別の部署では、端末の試作版を使って、設計どおりの基本性能が実現できているかどうか、確認していた。

　試作機を手に高速道路を運転したり、あちこちの地区で実験する一方、地方では、KDDIの全国各支店の携帯電話営業担当が受け持つ地域で同様の作業にかかわっていた。

●仕事納めの日

　その結果を集計すると、「GPS衛星が3つ見えたら、誤差は何メートル」、「衛星は見えないけど、基地局が3つつかめていたら、何十メートル」、「基地局が1つだったら…」など、だいたいの誤差の範囲をつかむことができた。

　インターネットグループでは、それを受け、提供会社側に渡す「だいたいの精度」というデータ項目の是非について、「誤差情報を、『何メートルから何メートル』という感じでいくつかのパターンに分ければ、提供会社側で自由に料理できるのではないか」と結論づけた。

　東京・渋谷のピンポイント情報であれば、「正確な情報が取れるまでやり直してください」と利用者に伝えればよい。

　天気予報だったら、「何でもいいから大まかに場所がわかればいい」というわけだ。

　KDDIとサービス提供会社でどんなデータを何種類やり取りするか、といった運営上の細かい規則からサービスの大枠が定まり、システム全体の仕様が固まっていく。

　ここで遅れれば、全体の作業日程にも影響がでる。

　「今年中に決めなきゃいけない」。メンバーたちは、作業を進めていくなか、そう意気込んでいた。

　そして、2000年の仕事納めの12月28日。

　周囲の部屋から納会とおぼしき笑い声が聞こえてくるなか、打ち合わせを続け、ようやく、提供会社側に通知するデータ項目の最終決定をみた。