１９９４年（平成６年）８月３１日、東海テレビ様にて新ＳＰＯＴＤＥＳＫのデモを行いました。
２代目ＨＩＢＳを開発する事が１９９４年４月に決定し、前年の５月に発売されたＷｉｎｄｏｗｓ３．１をクライアントＰＣとし、Ｓｕｎのサーバとソケットインターフェースでデータ通信を行います。ＤＢはリレーショナルデータベース（ＲＤＢＭＳ）のｉｎｆｏｒｍｉｘを採用することにしました。
今ではＤＢといえばＲＤＢが当たり前ですが、当時のＲＤＢは遅い、高い、特にＯｒａｃｌｅはなんでこんなに高いの？って時代でした。その為安いＤＢの選択も有りました。ＰＣではＢｔｒｉｅｖｅが社内で良く使われていました。
初代ＨＩＢＳはサーバ、クライアントともにＳｕｎのワークステーションの為データ通信はマウント（今風に言えばフォルダ共有）すれば（通信なしで）簡単にデータの受渡、参照が出来ました。
新しく作成するＷｉｎｄｏｗｓ３．１版ではＵＮＩＸサーバとのデータ通信が必須、それも高い精度は当然ながらスピードが要求されていました。クライアントとサーバ間のソケットインターフェースは１９９２年１０月から川崎市の東芝小向工場の外注スタッフとして、ＲＫＫ熊本放送様のＢＥＳＴ１１－Ⅱ、ＭＢＣ南日本様のＤＬＳで放送機器とのデータ通信で培ったノウハウを駆使して中村元行君中心に作成しました。外注スタッフとして川崎と現地に何度も行って徹夜作業した経験がここに生きました。
ＲＫＫ様のＢＥＳＴ１１－Ⅱは、テレビ、ラジオのＣＭ素材登録とＡＰＣ用の制御データ作成システムです。ＤＢはＯｒａｃｌｅを使用しました。ＭＢＣ様のＤＬＳはラジオのデータサーバシステム（ＣＭバンク、番組バンク素材登録、ＡＰＣ用の制御データ作成システム）でＤＢはＥａｓｙＣａｌｌを使用しました。このＤＢＭＳの経験もデータサーバの経験も多いに役立ちました。
※営業の和田さんがいろいろと（やった事も無い）仕事を取ってきてくれ、非常に勉強になりました。
ＲＤＢＭＳについては、河原田さんがＨＰ様からｉｎｆｏｒｍｉｘを無償で借りてくれ、土谷君がセットアップと実際の検索スピードの検証を条件をいろいろと変えて行い、結果ｉｎｆｏｒｍｉｘはＯｒａｃｌｅと比較して安くて軽い（早い）と判断しＨＩＢＳのＤＢに決定しました。
新しいＳＰＯＴＤＥＳＫには大きな課題が二つ有りました。
一つは、時間取り時の販売枠の排他管理の問題です。クライアントＰＣで空枠をクリックした瞬間にクリックしたタイムテーブルの箇所の情報（販売枠キー、時間取り秒数等）をサーバに送り、販売枠のロック（ロック出来るまでリトライ）、ロック後販売枠のチェックを行い時間取り可能な（販売枠に空きがある）場合は時間取りを１件更新します。時間取り更新とは販売枠に１５秒か３０秒の時間取り秒数を加算し、且つ契約単位に時間取りデータを追加します。マウスの右クリック（キャンセル）の場合はこの逆の処理を行います。
その結果をクライアントＰＣに戻しタイムテーブルに表示（描画）します。時間取りの追加はタイムテーブルの曜日、時刻、ＰＴ／ＳＢに該当する箇所に、横線または斜め線（ＳＢかＰＴ）の直線か波線（１５秒か３０秒）を引き、日付をタイムテーブルに書込みそれより下側のタイムテーブル（描画）をずらします。正確にはずらしてから書き込みます。この間０．数秒、マウスの連続クリックに結果表示が追従出来るか課題でしたが、時間取り更新処理は横矢さん、タイムテーブルの結果表示は大谷さん中心で作成しほぼ構想通りの出来となりました。
この最終テスト用としてまた河原田さんに交渉して頂きＣＴＣ様からＳｕｎの１０００万円もする４ＣＰＵのサーバを無償で借用しました。（昔のサーバは高かった!!）メンバー１０数人で同時に時間取りと空枠表示を行い（終わった人がハイと言って手を上げます。ハイ、ハイ、ハイ、、）、排他制御に問題無いか空枠表示の表示スピードに問題無いか何度もテストした光景が今でも鮮明に浮かびます。
ここで採用したロック方式はＲＤＢＭＳのレコードロックを使用せず、ロック用のテーブルを別途用意しロックキーがインサート出来たらロック完了としました。ロック解除はロックキーの削除でＯＫとなります。現在のＤ－ＨＩＢＳも同じ方式のままです。ＲＤＢＭＳのレコードロックでは同一キーの処理で極まれにデッドロックが発生することがあります。デッドロックが発生すると該当レコードまたはテーブル全体が読めない状況になり、解除はタスクの確認やタスクのｋｉｌｌ等々非常に手間が掛かります。ネットでの運用管理では無理と判断しました。採用した方式ではデッドロックが発生しない事、どの端末から、だれが、どのキーで、何時にロックしたか簡単に管理する事が出来ます。状況によってはロック解除も出来ます。元々ＴＯＴＯエニコム様で採用されていましたが以前そこに出向していた春田君から提案され採用しました。
もう一つの課題は、空枠表示のスピードです。
マウスでタイムテーブルをクリックした箇所の枠時刻から指定された曜日（月－金または土日を含む１曜日）に従って横に表示出来る日付分×縦に表示出来る最大(max15行)の販売枠情報をサーバから取得しＰＣに表示します。１データは１２０バイトで最大４５０件ですからデータ量としては５４ＫＢにもなります。表示はたった１画面、１データで０～９の１桁の空枠本数しか表示しませんが内部的にはかなりのデータ量の通信が必要でした。この間約２．５秒。これでも遅いか．．．
８月になんとか空枠表示、時間取りのデモが出来る状態となり、業界では非常に影響力のある大ユーザ先にデモに行きました。デモはまずまずだったと思います。懸念していた空枠表示も余り問題とならず．．．
翌年１９９５年１月１７日、阪神大震災。東海テレビ様に打合せに行く日、新幹線が動かず、横山さんと飛行機で打合せに行きました．．．それ以降飛行機での出張となりました。（余談）
前年の８月以降何度かデモ、打合せを行った結果（なんと？）ＳＰＯＴＤＥＳＫの導入が決定しました。波多野さんと東海テレビのシステム窓口の担当者の方の息がピッタシ合った事も大きく貢献しました？ 東海テレビ様は早々にＮＥＣのサーバとＰＣの購入を決め、新ＳＰＯＴＤＥＳＫのインストールを行い、画面を見ながら打合せを進める事となりました。
打合せが始まるとデモの時より明らかに遅い、懸念していた空枠表示も遅い、平均的には３秒。こんな事では東京支社では全く使い物にならないとなり、打合せよりもこのスピードの解決が最優先課題となりました。デモに使ったＳｕｎのサーバ、ＤＥＬＬのＰＣを再度持ち込み並べて表示スピードの検証を行いました。やはりＮＥＣのサーバ、ＰＣは遅い．．．しかしスポンサード（ＣＭ出稿を沢山している）で元々ＮＥＣホストを使用している関係で今更他メーカに変えることは出来ない．．．
ＮＥＣの工場に行けとの命令を受け、東京府中にあるＮＥＣの工場に行きました。そこのサーバにｉｎｆｏｒｍｉｘをインストールしＳＰＯＴＤＥＳＫの環境を作り、持ち込んだＰＣで空枠表示を何度も行い、ＮＥＣのＯＳ担当者、ＲＤＢ担当者と徹夜作業でなぜＳｕｎのサーバより遅いかの解明を行いました。
結果はｉｎｆｏｒｍｉｘにＳｕｎサーバ用のチューニングが施されている事が判明しました。但しＮＥＣとしてはそのチューニングには問題が有り同じ事は出来ない（しない）との回答を東海テレビ様に送り付けました。結局、東海テレビ様は二回り性能の高いサーバへの交換を行う事にしました。ＣＰＵも２から４と強化し．．．それでも遅い．．．
この３秒が１．５秒程度にならないと折角ここまできたビックチャンスが無くなる、空枠取得３秒の壁が大きく立ちはだかりました。そんな時、ＮＥＣのシステム部長からＲＤＢを使っていたら６０分の処理も１分になる可能性があると（西コンは出来るかなって感じで言われ）大層なご指導を受けました？．．．そりゃインデックス張ってないからだろ．．．３秒を１．５秒にするのとは訳が違う．．．
原点に返りどの処理に時間が掛かるのか１ステップづつ解析を行いました。
①ＰＣから指定された販売枠キーが送られる、０．数秒
②指定された販売枠キーから指定曜日単位に販売枠のキー範囲を決定する、０．７秒
③そのキー範囲を使ってＤＢからデータ取得、０．９秒
④データを編集しサーバからＰＣへ転送、０．数秒
⑤ＰＣで空枠表示画面を起動し結果表示、０．数秒
⑥その他諸々の処理、計３秒
短く出来るところは有りません．．．？
③のＤＢからデータを取得する０．９秒はＳＱＬの世界でどうする事も出来ないが、②の指定された販売枠キーから指定曜日単位のキー範囲を決定する処理はＤＢを直接参照せず、サーバ起動時に(バッチ処理で)ＤＢを読み必要な項目を販売枠キー情報としてサーバの共有メモリに保持し、それをダイレクトに参照すれば早くなる．．．販売枠の更新や時間取りの更新時にはこの共有メモリも併せて更新すれば問題無いはず．．．早速仕様の整理、開発を行いました（処理名販売枠キーｍａｋｅ）。結果０．０１秒未満で取得可能となり、これでマイナス０．７秒、残り０．５秒強。まだまだ．．．
④の最大５４ＫＢのデータ転送は早くならないか？ 東京支社との通信はＩＮＳでなぜか２５６バイト単位で区切らないと旨く通信出来ない．．．生のデータを単純に送れば２１０回のＡＣＫ／ＮＡＫが必要となる．．．そうだデータ圧縮すれば良いんだ．．．圧縮って実際どうするの？．．．今では簡単にインターネットで調べられると思いますが、取りあえず書店へ。
ＬＺＨのソースが書かれた技術書がありその本を購入、その内容を組み込んでみました。当時のサーバ、ＰＣはパワーが無くＬＺＨ（移動辞書法とハフマン方式）の汎用圧縮では５４ＫＢの圧縮に０．３秒、解凍に０．３秒もかかりました。０．３秒は一瞬で終わるように思えますがＨＩＢＳの空枠処理では随分と長い、重たい処理でした。但し圧縮率は３０％弱でしたので通信部分は明らかに早くなりました。ただ前後に０．６秒も掛かれば本末転倒．．．使えない．．．
そこで汎用では無く専用圧縮のロジックを考えました。例えば販売枠キーが１９９５／９／１０ １２：００ＳＢ枠で有れば（実データは1995091012000と１３バイトですが）、年は１９と２０だから０か１で１ビットで表せる、年の下２桁は９９までだから７ビットで表せる、同じように各項目を分割してビットに置き換えて、先頭から詰めて８ビットづつキャラクタにキャストすれば良いのでは．．．Ｃ言語はビット操作が簡単ですから早速３００ステップ程の小さなサブルーティンを作成しテストしました。なんと０．３秒掛かっていたのが嘘のように０．０１秒も掛からないで圧縮出来るようになりした。圧縮率もほぼ同じ３０％弱。
ＮＨＫ風に言えば、その時歴史が変わった．．．
この小さなサブルーティンを整備し、ＰＣ側の解凍は逆にビットからテキストに展開するサブルーティンを作成し、東京支社からでも２秒弱で空枠が表示出来るようになりました。東京支社ではストップウォチを片手に何度も何度も空枠表示を計られ、「ついに」この業界で非常に影響力のある大ユーザからＯＫを頂きました。
この後はＨＩＢＳ開発に勢いが付き二十数社に納品を行いました。またラジオ版ＨＩＢＳの開発も行い、更に２００３年からはデジタル対応となり休む暇が無いほどの開発となりました。現在テレビ局４０社、ラジオ局１４社が稼働中です。
現在３代目のＤ－ＨＩＢＳとなりＰＣやＭＳ－Ｗｉｎｄｏｗｓの性能が格段とＵＰした事でこの空枠情報は、指定秒数間の差分情報をバックグラウンドで取得し空枠表示を行っています。勿論途中の圧縮、解凍も行っています。また東京支社では本社サーバから空枠情報を取得する中継ＰＣを設置し、支社のＰＣが１台づつ本社サーバを参照しないで良い仕組みとしています。これでネットワークは非常に軽くなりました。この新しい仕組みは福留さんを中心とした新しいメンバーで作成しました。この話は別途福留さんが投稿してくれると思いますが．．．
現在ニシコンを支えているシステムの一つ、ＨＩＢＳ開発にはこの他にもいろいろな技術を各担当者が知恵を絞り、汗を流し、開発に携わってきました。今後も素晴らしい未来があると思います。若い皆さんに期待しています。能力は無限です。自分の能力にチャレンジして下さい！
