AI時代にも揺るがない。25年以上現場で磨かれたETLツールが手放せない理由【Waha! Transformer】

1. 開発の前史：直感的なデータ検索・抽出をかなえた「DB-Front」と、日本語文字コード変換の壁を越えた「DBTrans」

製品系統図

「Waha! Transformer」の原点は、 データベースの導入現場における「データ移行業務」 にありました。

「DB-Front」の誕生と現場主導のデータ抽出の実現

1990年代前半、私たちは、メインフレーム向け超高性能データベースを販売していました。

その販売を大きく後押ししていたのが、MS-DOS向けのビジネス用統合ソフトウェア（総合オフィスソフト）「INTES（インテス）」です。

「INTES」は、メインフレームのデータを端末エミュレーター経由でPCに取り込み、活用できる製品でした。当時のデモンストレーションの威力について、開発関係者は次のように振り返ります。

「エミュレーターでF5キーを『ターン！』と押すとメインフレームのデータを貼り付けたPCの表計算ソフトに『スパン！』と切り替わる、それを見ただけで大型商談を即決してもらえたんです。それぐらい当時は画期的だったんです」

イーサネットの普及前でメインフレームとのデータ交換が極めて困難だった時代に、「INTES」のデモンストレーションのインパクトは大きく、大規模なデータベース導入の決断を後押しする強力な製品となっていました。

その後、「INTES」に内蔵されていた端末エミュレーター機能は、各社メインフレームにマルチ対応した「EXTES（エクステス）」として独立・製品化されました。

また、「INTES」の中の汎用データ検索機能もWindowsのGUIを得て、「DB-Front」へと進化・製品化されます。

時代はWindows黎明期。まだ満足な開発環境もなかったWindowsアプリケーション開発について、開発関係者は当時の苦労をこう明かします。

「『Windowsのプログラムなんて作ったことないっすよ』って（笑）。分厚い英語のマニュアルを見ながら『これ使えるのかな？』と手探りで作りました。インターネットもないのに、本当にみんな苦労して作り上げたんです」

この苦労が、のちの自社開発への自信につながっていきます。

「DB-Front」は、UNIXやWindowsをサーバーとしたバージョンへと拡張し、さらにさまざまなRDB（リレーショナルデータベース）で稼働するようになり、汎用検索アプリケーションとして広くお客様にご利用いただきました。

これら「INTES」、「EXTES」、「DB-Front」の開発と提供を通じて培われた、さまざまなOS、文字コード、ハードウェアの壁を越える深い知見とノウハウが、のちに誕生する「Waha! Transformer」の強力な土台となっていったのです。

ダウンサイジングの流行と日本語文字コード変換の壁、「DBTrans」の登場

当時は、メインフレームからUNIXやWindowsなどのオープン環境へ基幹システムを移行しようという ダウンサイジング が大流行していました。メインフレームと完全互換のUNIX版、Windows版の製品群を販売していたユニリタ（当時の社名：株式会社ビーコンインフォメーションテクノロジー、以下、ビーコンIT）も、このような流れの中で数多くのダウンサイジングを手がけました。

しかし、現場では大きな課題が発生していました。それは、オープン環境へシステムを拡張・移行する際の 日本語文字コード変換 という高いハードルです。

「DB-Front」やエミュレーターなどはあくまで人間がデータを「見る・抽出するためのツール」であり、別システムへ大量のデータを連携・移行するには、データそのものの形式やコードをシステムに合わせて変換する必要があったのです。

データ移行の現場では、メインフレームからUNIXなどのオープン環境へデータを移行する際、メーカーの仕様書通りに作業してもデータがそのまま移行できないケースが多発していました。

具体的には、海外製アプリケーションによる「全角・半角スペース」の認識違いでデータが欠落したり、JISコードの規格違い（「はしご高」などの入れ替わり）や大量の「外字」により、別システムに持っていくと文字化けだらけになったりするケースがありました。

このようなデータ移行時の課題を回避するには、一部データ移行ミスを容認するか、メインフレーム側に莫大な費用をかけて、移行するデータごとに文字コード変換プログラムを作成するしか方法がなかったのです。

「メーカーの独自仕様だらけの状況を、プログラミングなしで乗り越えられないか？」

現場のエンジニアたちが「やってられない」と頭を抱える中、立ち上がったのが当時のサポートSE（後の「Waha! Transformer」開発責任者）でした。

「『一週間あればツールを作れますよ』と上司にたんかを切ってしまったんです。そこから意地で、なんとか1カ月ほどで開発したのが『DBTrans （デービートランス） 』でした」

こうしてSEのお助けツールとして誕生した「DBTrans」。これにより、データ移行時の文字コード変換が、はるかに容易に、費用を抑えてできるようになりました。

そして、この泥臭い現場の課題解決から生まれた文字コード変換ツールこそが、「Waha! Transformer」の原点となったのです。

2. 「Data Warehouse Automation（Waha!）」構想と「Waha! Transformer」の誕生

1990年代半ば、クライアント・サーバー時代への移行に伴い、企業内でデータを分析・活用するニーズが急増しました。

「データウェアハウスのビーコンIT」と呼ばれた時代

この時、ユニリタ（ビーコンIT）は日本市場におけるデータウェアハウス（以下、DWH）の普及を強力にけん引していた存在でした。

1995年には、当時の社長がDWH関連書籍「データ・ウェアハウス」を出版。多次元データベースや超高速RDBMS（リレーショナルデータベース管理システム）を組み合わせたDWHのパッケージ製品を展開し、業界では「DWHのビーコンIT」と呼ばれるほどの存在感を示していました。

ETLニーズの爆発と海外製データ連携ツールの輸入断念

DWHの台頭に伴い、これら一連の処理を自動化する 「ETL（Extract、Transform、Load）」 という分野が、まさに求められようとしていたのです。

「DB-Front」などがあればデータの「抽出」は簡単でしたが、ユーザーからは

• 取ってくるだけでなく、DWHに入るように加工がしたい
• 夜間に加工をすべて完了したい

という強い要望が寄せられるようになりました。

この声に応えるため、「DB-Front」の機能拡張が提案されましたが、その企画会議の中で、当時の社長が提唱していた、データ処理全体を自動化する「Data Warehouse Automation（Waha!）」構想が合流することになります。

このようなETL機能の需要に対して、当時は海外製データ連携ツールの輸入販売も検討し、開発担当者はシリコンバレーまで交渉に飛びました。しかし、当時の海外製品はユーザーにSQLの知識が必須であり、日本の現場に導入するには難易度が高いことがわかりました。

海外では、IT部門以外でもSQLの基礎知識を持つ層が多く、「ユーザーが直接SQLを記述して加工する」仕様でも問題ありませんでしたが、当時の日本のDWH導入企業にとって、それは現実的ではありませんでした。加えて日本独自の複雑な漢字コード変換への対応も難しかったことから、開発チームは海外製品の輸入を断念したのです。

海外製品の導入が現実的ではないと判断した開発責任者は、当時の上層部からの 「輸入か、自社開発か」と決断を迫られたことで覚悟を決め、「自分たちで作ります」と自社開発を宣言したのです。

こうしてチームは、日本の現場のニーズに合致した純国産のETLツールを、自らの手で作り上げる道へと力強く舵を切ったのです。

「Waha! Transformer」の誕生

当時の「Waha!」構想には、すでに抽出（Extractor）、転送（Transfer）、スケジュール管理（Scheduler）という3つのコンポーネントが揃っていましたが、連携の肝となる、取り出したデータを「変換・加工・ロード」する機能だけが足りませんでした。

このDWH自動化を完成させるものとして、前述の文字コード変換ツール「DBTrans」の技術をベースとして、独自のデータ加工エンジンが開発されました。そして、 「Waha!」構想の4つめのコンポーネントとして、「Waha! Transformer」が誕生したのです。

開発チームは当初、「ETL」という海外の流行を意識して製品を企画したわけではありません。あくまで当時の社長が提唱したDWH理論を実現するために、現場で必要だったコンポーネントを独自に開発した結果、誕生したものだったのです。

しかし、自社の理論と必要性に基づいて誕生したこの製品は、結果として、当時世界的に確立されようとしていた「ETL」という新しいツールジャンルと完全に合致していました。 流行を後追いするのではなく、データ活用の本質を追求した結果が、くしくも時代の先端を行く純国産ETLツールの誕生につながったのです。

3. 他社製品を圧倒した強みと販売戦略

1999年4月に正式販売が開始された「Waha! Transformer」は、当時のデータ連携市場において、異例のスピードで多くの企業に導入されていきました。その成功を支えたのは、次の3つの強みです。

①COBOL技術者にも刺さった直感的なGUI

アイコンをドラッグ＆ドロップでつなぐ画期的なGUIは、経験の浅い若手営業でも「細かい説明なしに画面を見せるだけでお客様にご理解いただける」ほどのわかりやすさでした。

さらに、このUIはIT部門の課長や部長といった管理者層に深く刺さりました。かつてメインフレームでCOBOLを使ってバッチ処理を組んでいた熟練の技術者の方々にとって、ジョブをアイコンでつなぐフローは、COBOLのショートプログラムをJCLでつないでいくメインフレームの構築プロセスと、非常に近いものがあったのです。

「今さらC言語は組めないが、どうデータを加工すればいいかというノウハウはすべて頭に入っている」という熟練技術者の方々にとって、「Waha! Transformer」は自分の知識をそのまま活かせる理想的なツールとして絶賛されました。

② お客様のニーズに合った、現実的な価格設定

当時、競合製品として日本市場に存在した海外製ツールの価格は、ETLだけで数千万円となるのも珍しくない時代でした。

DWHサーバー本体と同等の費用がデータ加工ツールにかかるのは非現実的であり、お客様の真の課題解決にはつながりません。そんな中、「Waha! Transformer」は、他社にならった高額設定という業界の常識をやめ、お客様が現実的に購入できる価格に設定しました（※1999年当時の価格で本体300万円、アダプター込みのパックで500万円）。

この顧客視点を貫いた姿勢が、結果的に現場への普及を後押ししたのです。

③お客様が迷わず導入でき、確実な活用につながるDWHソリューションパック

「Waha! Transformer」は単体で売るだけでなく、当時すでに大ヒットしていた多次元データベースや、自社の検索GUIツール「DB-Front」と組み合わせたDWHのパッケージ製品として販売されました。

DWHの構築にはデータの取り込みや加工処理が必須ですが、製品選定の段階では導入担当者が社内でその重要性を説明することが難しく、「ETLの導入ハードルが高い」という課題があったのです。

DWHのソリューションパックの中に、データ加工を担う「Waha! Transformer」を必須機能としてあらかじめ組み込んで提供することで、お客様が迷わず導入できるようになっただけでなく、構築時に確実に活用されることで「使われない無駄な投資」になることを防ぎ、結果として全体的な普及を後押ししました。

4. 基幹系の血を引く「25年以上磨かれた堅牢なエンジン」

「Waha! Transformer」が、1999年の発売から25年以上経った今でも多くの企業で安定して動き続けている理由は、単純なものではありません。

その根底には、開発チームが 「メインフレームの基幹系データベース」の過酷なサポート現場で培った、泥臭い運用ノウハウと揺るぎない設計思想が深く息づいています。

メインフレームの「絶対に止められない」文化と徹底した品質管理

時代がWindowsへと移行し始めた当時、メインフレームの技術者から見れば、当時のパソコン（WindowsやDOS）は不安定であり「調子が悪ければリセットする」という感覚の別世界でした。

しかし、「Waha! Transformer」の開発チームには、メインフレームの過酷な現場で「システムは絶対に安全に運用されなければならない（リセットなどあり得ない）」という厳格な文化で育った職人気質のエンジニアたちがいました。彼らは、パソコン向けのツールであっても、基幹系と同等の堅牢性を求めました。

その堅牢性を長年維持できている理由の1つが、開発後機能検証の自動テストを取り入れたことです。OSやデータベースなどは、環境との連動など、自動テストシナリオの選定に手間がかかり、自動テストだけで製品品質を担保するのは困難です。しかし、ETLは、データ入出力に対するテストが主であるため、製品のほとんどのルートを自動テストでカバーできたのです。

「Waha! Transformer」は現在（2026年5月時点）、バージョン6.1ですが、 バージョン2の頃からリリースのたびに自動テストを積み上げており、現在は3万項目以上の正常・異常の動作テストをリリース前に自動で行い、動作品質を担保しています。 テスト項目は過去のバージョンの頃のものもそのまま稼働しており、互換性の維持についても検証されています。

大容量データをさばく「ストリーム処理」と、メインフレーム由来の「高速化ノウハウ」

「Waha! Transformer」は、独自のアーキテクチャと、机上の空論ではない実践的な高速化ノウハウの結晶です。

大容量のデータを処理する際、すべてをメモリに溜め込もうとすると、スワップ（メモリ不足によるディスクへの退避）が発生し、処理が遅延したり停止したりして、基幹系システム的な考え方では使い物になりません。

「Waha! Transformer」では、主に必要最低限のデータだけを読み込みながら、同時に加工・書き込みを行う「ストリーム処理」を行うことで、大量データ処理のメモリ依存性を減らし、処理の中断を抑止しています。

さらに、「Waha! Transformer」のデータ加工処理には、かつての基幹系開発のノウハウやテクニックが反映されています。

たとえばデータ結合においても、処理方法の異なる「結合」と「参照」が用意されており、ユーザーは状況によって処理を選べます。

「結合」はSQLと同様に集合の理論において処理を行うため、2つの入力データをすべて結合キーでソートして、上からぶつけるようなコストの大きい処理が必要ですが、「参照」はマスタ側の入力データのみソート＆インデクシングを行い、トランザクション側はソートせずにそのまま使用することで、大容量データにおけるDWHのスタースキーマのようなマスタ参照処理をより高速に効率的に行うことが可能です。

かつて現場のプログラマーがデータ加工プログラムを組む際に当たり前に行っていた 「実践的で高速な処理パターン」そのものが、メソッドとして最初から組み込まれているのです。

そして、 基幹系データベースを提供していた時代からの約50年にもおよぶ「24時間対応のサポート体制」 が、ETLツールにも変わらず提供されていることも、重要なポイントと言えます。

5. あらゆる業種の現場で稼働し続ける導入事例

2,600ライセンス以上が稼働する現場では、具体的にどのような課題が解決されているのでしょうか。「Waha! Transformer」の堅牢なデータ加工技術は、規模や業種を問わず、今も現場で手放せない連携基盤として活躍しています。

※各導入事例の詳細は文末でご紹介するリンク先をご参照ください。

このように、規模も業種も異なる現場で、「Waha! Transformer」は今も欠かせない連携基盤として稼働し続けています。

6. 最後に：なぜ、一度導入したお客様は「Waha! Transformer」を手放せなくなるのか？

開発チームはこう語ります。

「『どこでもつながります』と声高にアピールするのは、今の時代どのツールでも当たり前であり、本質的な価値ではない」

真に求められるのは、つながった先でデータを安定して処理し続ける力です。そしてその答えこそが、「Waha! Transformer」が25年間かけて磨き上げてきたものです。

カタログスペック上の接続先の多さや、見た目の新しさが優れたツールは他にもたくさんあります。しかし、「Waha! Transformer」の真の強みは、25年以上にわたり、日本の過酷なデータ処理現場から寄せられた「かゆいところに手が届く」ような細かなフィードバックを実直に吸収し続けてきた点にあります。

長年の知見が反映された豊富なデータ加工メソッドに加え、開発チームが初期から貫いてきた「妥協を許さない徹底した品質管理」によって、極めてバグが少なく圧倒的に安定して動くエンジンが作り上げられました。

こうした「安心感」という真の価値は、導入前にはなかなか伝わりにくいかもしれません。

しかし、実際に現場で使い始め、日々の過酷なデータ処理を「Waha! Transformer」に任せたIT部門担当者は、その安定性に気づきます。たとえば長くご利用いただいているお客様からは、

「他のツールでは途中で止まってしまうような複雑で重い処理でも、『Waha! Transformer』なら止まらずに確実にこなし続けてくれる」

という確かな実績が、最大の評価ポイントとして挙げられています。

さらに、アイコンをつなぐ直感的なGUIは「誰が見ても処理の流れがわかる」ため、担当者の異動や退職に伴う引き継ぎが容易であり、システムがブラックボックス化しない点も、長く現場で愛される大きな理由です。

「派手さはないが、日々の膨大なデータ処理を安定してこなし続ける」。だからこそ、 一度導入したお客様は何年も何十年も「Waha! Transformer」を手放せなくなるのです。

「Waha! Transformer」は日本のデータ活用の歴史と共に歩み、現場の理不尽な課題を解決し続けてきた熟練の職人の道具です。AIがジョブを自動生成する時代が来ても、安定してデータを処理し続けるこのコアエンジンの真価は、これからもお客様のビジネスの根底を支え続けます。