回線かTAに瞬間的にでも「問題」が発生したということである。そのまま解析を続行したとしても「取得したデータの信頼性が損なわれているおそれ」があるんだよね。いったこともあって、エラーについては「発生させないセッティング」が第一であることには変わりない。スルーしてほしいこともある。いうとき、リスクや細かい背景は承知の上でなら、解析中に発生するエラーメッセージを表示させない方法はある。入れて、その下のDAブラックホールのエンブレムをクリックする。Yes/Noダイアログが表示される。エラーメッセージを非表示にする場合は、[はい(Y)]を選択する。レベルのエラーメッセージは表示されなくなる。DAブラックホールが掌握しているレベルのエラーは表示しなくなるけれど、OSが表示するエラー(データベース損傷など)は引き続き表示される、という理解を持ってもらえるといい。この操作は「通常の解析」(連続解析を含む)のエラーメッセージを対象としており、マルチタップや他の機能のエラーメッセージには影響しない。マルチタップによって発生するエラーメッセージも非表示にする場合は「6102」で同様の操作を行う。いずれも本来はユーザーサポートから指示があった場合に限って使ってほしい機能ではあるので、使用する場合はある程度の覚悟をもって行ってほしい。設定(P)→出荷時の設定に戻すである。DAブラックホールDAブラックホール1.8は1.7の時とは異なり、1.8の企画は2014年にすでに決まっていた。先述の「ひとつめの失敗」によって、マルチエンジンの実装がなされなかったからだ。実用化しているが、パッケージとしての販売には至っていない。IP網用はCPUへの負荷が非常に高く、当時のXeonマシンを要求するありさまだった。いまほどIP網は一般的ではなく、0AB-Jがやっと認可されたぐらいの頃だったので需要が薄かった。売る気がなく作ったものであったから、こちらはDA電研の「ドメインレーダー」で使用することになる。KONDERU-NDAとして再転用されることになるわけだが、それはまた別の機会に述べる。ホワイトなキャリアから発注を受け製造したものであったが、あまりに性能重視で作った結果、1システムでロッカー2個分の巨体になったこともあって最終的にはキャンセルになった。(このため1.4は欠番になってしまうことになる。)かように、高負荷になりやすい解析エンジンを、ひとつのPCで同時に動かすことは、様々な困難を伴う。CPU性能が上がったいまなら、15年前と違って、いま少し容易なのではないかと考える向きもあろうが、そうは単純じゃない。DAブラックホールの負荷は、主に「データベース」(分析と記録・すなわち読み込みと書き込み)が発生させているものであり、CPU性能が上がれば、負荷が下がるのではなく「データベース処理が速くなる」という方向でリソースを消費する。そのため、2つ以上の解析処理を同時に行えば、現在でもきっちり100%の瞬間負荷がかかる。いった状況で、多数の解析エンジンを同時に動かす場合は、解析するPCとデータベースのPCを分け、「負荷分散」を行う必要が出てくるかもしれない。DAブラックホールから、データベースを切り離そう、という魂胆である。DAブラックホール1.7で実装した「外部データ連結」は、その布石である。これまで見送られていた機能が実装されることになっている。DAブラックホール1.x系統の「総仕上げ」として位置付けられているのが1.8系であり、これが最後の1.x系統になる。DAブラックホールドライバの不具合に悩むふたつ目の大きな問題は、リリース後に表面化した。特定メーカーのdocomo端末を用いたときに、DAブラックホールが端末に接続できないケースが報告された。COMポートは認識しているが、接続だけができない(≒初期化もできない)という謎現象である。問題が生じた端末でも、Bluetooth対応機種でBluetooth接続を行えば、この現象は発生しない。問題は、きまって「USBケーブル接続」のときに起きていた。端末の問題ではなく、ドライバの問題であることが示唆されていた。そろってくると、その現象は64bitOS上に限り発生していることがわかった。特定メーカーの特定期間に販売された端末のUSBドライバだけで起きていることもわかってきた。WOW64(32bitエミュレーター)への対応が不完全だったため、32bit側の「MSCommコントロール」でエラーが生じ、ポートを開くことができないでいたことがわかった。同メーカーの32bit用USBドライバには、この問題はなかった。ドライバの不具合ではあるが、こちらも端末の検証用PCが「Windows7/32bit」であったことで、事前にこの問題を把握することができなかったのは、私のミスである。コントロールの内製(自作)にふみ切る不具合である以上、この問題を本質的に解決するなら、メーカーにドライバを改修してもらうのが筋である。ゴタゴタしてるメーカーだったので、あまり期待はできかなかった。Win32APIを経由してファイルストリームでシリアルポートを制御する方法をプログラミングすれば、エラーによる門前払いを防ぐことができることも実験の結果わかった。MSCommと互換性のある「DACommコントロール」を作成し実装することにした。VB6.0でできるの?と思う向きもあるかもしれないが、時間はかかるものの、人間ワザの範囲だった。いった理由でそういう実装になっていたか、よくわかった。して、次のようにクラスを再構成した。通信デバイスの設定この問題では、苦労もし、悩まされもしたが、有意義な時間を過ごさせてもらったような気がする実装につながった。VisualBasic6.0ひとつめの失敗DAブラックホール1.7に実装するキモのひとつに「ダブルタップ」があった。これは2つの回線(あるいはキャリア)を使って、同時にひとつの番号を解析する機能である。iナンバーやダイヤルインで割り当てられている回線数を見つけることができる。DA電研で使用している回線解析システム「KONDERU-NDA」に実装済みで、実績もあった。1回線ずつ解析(発呼)が実施される」という事態に直面した。Bの解析がはじまる、という具合だった。調べてみると、シリアルポートを制御するMSCommコントロール→Win32通信API→ドライバの経路のどこかで、片方の処理に待機がかけられていた。そのため片方の解析が進行し、終了すると、待機していた側の動作が再開するという状態だった。原因は、以下の2つが考えられた。コントロールのスレッド処理の不具合スレッドセーフでない部分がどこかにあるのだろう、と推測した。VB6.0ではクラス継承が事実上できない。インターフェースの継承はできるとされているが、実装の継承ができないのである。(それで継承っていえるのかな)それにもかかわらず、なぜか同じコントロールを複数配置することはできる。・1992年のVB2.0からあるコントロールで、つまり16bitだった頃から受け継がれている。時代背景を考えればスレッドセーフでなくても不思議ではない。いうか当然なのかもしれない。API(DLL)を自分で最初から作る必要があるかもしれなかった。それは時間的に現実的な解ではなかった。クラス(スレッドセーフ)を使っていたこともあって、この問題は生じていなかった。入力フォーム)は、そのまま残すことにした。「ダブルタップ」は、マルチタップに仕様を変えて実装されることになった。1.8系でも実装する予定はないが、別の機能としてそれに近い動作ができるようにしたいと考えている。Basic」(VB6.0)を用いて作られている。「クラス」を使うときは、いろいろ気を遣う言語仕様だからである。Windows95/98を使っている方が少なくないからである。INS64(ISDN)がOCNエコノミーによって大きく流行り始めたころを思い出してほしい。ISDNプロトコルモニターなど計測器の需要が爆発的に伸びたあのころ、世の中はWindows95/98で動いてるPCばかりであった。このため、ISDN用の計測機器ではWindows95/98を実装しているものが少なくない。I/Oドライバーは16bitネイティブを32bitに置き換えたもの、あるいは16/32bitが混在している機器もある。このため、これらの機器を動かすOSはWindows95/98でなければならない。DAブラックホールはこれらのシステムで動かなければならない。Basic」(VB6.0)は、1998年に完成した最後のWin32ネイティブであり、Windows10に至った現在においても、ほぼ問題なく動作する稀有なプラットフォームである。Applications)のメンテナンスが、現在もマイクロソフトで続いているということもあるだろう。DAブラックホール1.7各エディション(Windows2000以降用)が、そのままWindows95/98で動作するわけではないが、少しの手直しとDLLの交換で動作するようには作っている。経験的にはわりと有利であるかなとは思う。何度か致命的な失敗をしてしまうことになった。「キャリア判定(NTT・KDDI・SB・などなど)に使用する」ということは、利用者はかならずしも電話回線に詳しいわけではない。アウトバウンド(テレアポ)をしている営業担当者が、いきなり導入を命じられることだってあるだろう。利用者(対象)の想定が大きく変わることになるので、1.7ではサポート体制の変更も必要になった。「ハードウェアセットアップ」を新設して、宅配便でPCを送ってもらえば、セットアップして返すようにした。出張サポートも利用できるようにした。つぎに「アドバイザリー」を拡充して遠隔メンテナンスのサービスを行うようにした。1.7にパスコード(旧版の準裏コマンド)を入力すれば、リモートツールが起動し、担当者とチャット・通話・リモート操作が行えるようにした。この二段構えで、PCが不得手な人でも、導入可能な体制を整えた。DAブラックホールは、ユーザーに対して排他的なソフトウェアだっただけに、回線技術者以外でも使えるようにすることは、サポート体制を根底から見直さざるをえないということでもあった。ユーザー情報を破棄とはいえ、サポート量の増大にあわせてスタッフを増やすことは、人件費上のリスクを負い製品原価を上昇させてしまうので、これを変動費にするべくユーザーサポートを外部に委託する必要があった。なると販売情報(個人情報)も外部に提供しなければならない。これは懸念材料(クリティカルポイント)を増やしてしまうことであった。そこでダイアモンドアプリコットはユーザーの個人情報を原則・持たないことにした。これまでのデータも経理上の伝票(証憑書類)以外は破棄することにした。それでどうやってユーザーを識別するかというと、ユーザーはサポートを受ける際に、ダイアモンドアプリコット電話研究所のサイトで、ライセンスカードの内容を入力し、正規ユーザーの認証を受けるサポート会社には認証に成功した結果だけを通知するユーザーのメールアドレスは、フォーム入力時に使用したものを伝えるというデータフローにした。この順序をユーザーが意識することはない。質問をフォームに入力した時点で、自動的に処理されているからである。ハッシュ保存された記録と照合して、購入記録のないユーザーからの質問のみライセンスカードの内容を入力する必要がある。現在は、親会社の「ダイアモンドアプリコット」がサポートを担当しており、そこで手に余る内容の時には、「電話研究所」のテクニカルサポートが対応するようになっている。DAブラックホール仕様の策定DAブラックホール1.7では、現行版(1.6)で表面化した課題の解決が目標であったがゆえに、スクラッチからの企画とは異なり、仕様の策定は早く進んだ。以下はその主な優先順位と内容である。交換機からの応答時間の精度補正と、PC本体やTA(携帯電話)の速度のバラツキの補正の両面を行い、解析時間に反映することにした。キャリア判定が視野に入った機能である。Windows7への完全対応1.6ではXPモードまでの対応だったのに対し、Vista/7への対応(主にUAC)が必須であった。市場ではすでにWindows7が販売されており、Windows8の販売も目前の状態であった。Jetデータベースエンジン(*.mdb)を使用していたが、1.7ではADOを用いることにした。データベースファイルも*.accdbに変更とした。SQLやOracle、MySQLへの接続を利用者にも提供することを目指した。最終的には、ローカルファイルやネットワークファイルへの接続にとどめ、SQLサーバーへの直接接続は見送った。ダブルタップ異なるキャリアを使用して「同時」に解析する機能。組み合わせで使用する前提であった。この機能は、最終的に実装されず「マルチタップ」として、複数を順次解析する機能に変更した。その事情は別の機会に述べる。複数のライセンスをひとつのDAブラックホールにまとめ、同時運用できる機能。先述のダブルタップもこの機能によってアクチベートされる予定だったが、テスト段階で深刻なトラブルに見舞われ、1.7では対応を見送る結果になった。製品グレードの導入さらに仕様と関連して、売価設定に初めて「グレード(エディション)」を導入し、価格傾斜をつけた。FOMA+PHSなど)を購入するのは高くつく。それならと、全部入りにして安く好き放題にしてもらえるグレード「Professional」を設定した。ないとも考えたが、実際には業務利用の方に最も購入されるバージョンとなった。(バラで買うよりも圧倒的に安いというのもあろう)また正式に「2クライアント運用」をStandard/Professionalに認めることで、従来より実質値下げとした。ライセンス認証もこのエディションについては2本同時購入として取り扱っている。1.6の価格を据え置いたエディションも用意した。機能も1.6と同じだが、こちらは1.6の更新(Windows7移行)を目的とした方と、難関チケット攻略といった「趣味の方」に重宝されることになった。DAブラックホールDAブラックホール1.7とはなんだったのか2017年4月22日のアップデート・バージョン1.7.28をもって、1.7系で予定されていたすべての実装を完了した。現在進行中の1.8系は、1.7.26からブランチされている。今後も1.8系の継続によってバグがみつかったり、移行可能な改善点があれば、1.8系の恩恵というかたちで1.7に適用されていく予定だ。(1.7系のサポート終了まで)とはいえ、1.7系の積極的なストリームはこれで終了となるので、この時点で「1.7とはなんだったのか」をふりかえってみる。1.7は計画になかったもともと、DAブラックホールシリーズは1.6を最終版とする予定だった。PSTN網用のアナライザー開発を行うことは事業としては躊躇(ちゅうちょ)があった。1.7があるとしても、Windows7用のローカライズバージョンになるだろうとして、申し訳程度の計画を2014年のガントチャートに置いていた程度だった。企業カスタマイズ版である「docomo版」とPHS版の発注が予想を超えて多かった。これは携帯電話販売店が「自社の顧客リストから」「かつての顧客が現在どのキャリアを使っているか」を調べたい、という要求によるものである。MNPした顧客をDAブラックホールを使って探し出し、「もどってきなさい」「おかえりなさい」の営業をかけるといった用途などである。2011年にauがiPhoneを販売しはじめてからは、この用途が過熱していたという印象がある。FOMAキットですでに確立していたが、これが携帯電話販売店で細々と使用されていたにすぎなかった。それを、独立して営業をはじめた方々が、一斉に活用をはじめた恰好であった。この部分でヒットが起きるというのは驚きだったし、この出来事はモノづくりと販売力・提案力の考え方に大きな示唆を与えてくれた。携帯電話のキャリア判別を行うにあたっては、さらなる精度の向上が必要であった。1.6ではキャリア誤判定率が2割近くにのぼり、歩留まり向上のためには複数解析による精度補完が必須であった。これは利用現場のリソースを圧迫しかねなかった。そこで、1.6をベースに最小限のエンジン改変によって、「キャリア」「モバイルキャリア」の各切り分け・判定能力を向上させたバージョン「1.7」の全体像が決まった。