インターネットの立ち上がりの時期は、まだまだ一部の研究者の道具という時代だった。この頃は、ネットでつながった仲間が、いろんなリソースを出し合って、より高度な、より便利なネットワーク機能を実現していこうという機運があった。開発したソフトウエアツールやデバイスドライバを公開したり、インターネット接続の相談に乗ったり、各研究者、各研究機関が、提供できるものを出し合っていた時代であった。
　私の所属する研究所は、これらの恩恵にあずかっているばかりであまり貢献ができていない、さて何か喜ばれることはないか、と考えたとき、まっさきに思い浮かんだのは時刻の供給。最初は、Web で時刻を表示するページを掲載した。当時は、まだ電波時計も携帯電話もない時代で、時刻を知るには有料の時報サービスに電話することも多かったので、無料でいつも時刻が見られると喜ばれた。時刻の表示には、当時使われ始めたばかりの JavaScript を使い、ブラウザ側で時刻表示が自走する仕組みとした。当時は、デバック環境もなかったため、短いプログラムではあったが、その開発はなかなか大変だった。この Web 時刻表示は、その後、JSONP 方式、さらには Ajax 方式と発展し、現在も提供されている。（https://www.nict.go.jp/JST/JST5.html）

　しばらくすると、NTPによる時刻供給への要望も感じるようになってきた。国内でもNTPサーバを公開するサイトもパラパラと出現していたが、それらの時刻源の確度はさまざまで、信頼して良いのか疑問符が付く。この頃、アメリカのNTPサービス（Wisconsin Internet time server）で、過負荷によるアクセス不能事件が発生した。これは、家庭用ルータの時刻合わせに、その時刻サーバが IP アドレス直打ちで指定され、さらに時刻情報が得られなかった場合には、1秒間隔で無限にアクセスを試みるという、とんでもない実装がされていた。あわれサーバは過負荷でサービス不能に陥り、それによって、大量のルータから１秒ごとにパケットが飛んできて、収拾がつかなくなった。そういった例もあり、公的な機関で ntp サービスを実施するのは、なかなかリスクが高い。我々の研究所でNTPサービスを実施しようという動きもあったが、こういったリスクの問題、運用コストの問題、セキュリティー攻撃に対する対策など、問題は山積していた。

　そういった時期に、時刻関係の研究室のリーダーになってくれという要請が来た。私は情報通信系の研究者で、この分野は専門外、しかも当時の役職からすると１段階下のポジションになるのだが、幹部の強い要請と、「降格は一時的なもの」、「１つの課題は必須だが、それ以外は、好きな研究を好きにやって良い。予算の一部（数百万円）は、好きに使って良い。」というアメにつられて、この話を飲んでしまった。（その後、幹部も交代したのだが、そのまま好きな研究を好きにやっていたら、さらに２段階降格させられてしまった）
　ともかく、好きなことができるというので、最初に手掛けたのがNTPサーバのハードウエア化。ワイアスピードで動作できれば、サーバが飽和することはないので過負荷対策や運用コストの削減が見込める。ハードウエアで実現する機能を絞れば、外部からのクラックも不可能で、セキュリティ対策のコストも削減できる。これならば、組織として運用するコスト（人的コストも含む）も認められる範囲になるのではないか。幸い、かつての研究室の後輩が、NTP サーバに転用できそうな機器を開発している。ファームウエアを入れ替えれば、とりあえずNTPサーバーの実証モデルにはできる。この後輩まで巻き込んで、NTPファームウエアの開発、NTPサーバに特化したハードウエアの開発、NTP サービスの試験運用と進んだ（https://jjy.nict.go.jp/tsp/PDF/j89-b_10_1867.pdf）。その後は、運用を得意とする部署に引き継いだが、その構成は、試験運用と同様のものであり、現在も継続的にサービスが提供されている（https://jjy.nict.go.jp/tsp/PubNtp/index.html）。