データ変換は伝統的にEAIやETLと呼ばれるジャンルのパッケージソフトウェアによって担われてきました。その中でBIPROGY製のDTRはユニークな立ち位置にあります。このDTRを通してデータ変換の歴史を振り返ります。
目次
1980年代：オープン化への転換
1990年代：EAI/ETLパッケージ登場
2000年代：Integration Serverへの進化
2010年代：クラウドとビッグデータ
2020年代：iPaaSの台頭
まとめ
付録：DTR年表
1980年代：オープン化への転換
1980年代後半、情報処理の世界は大きな変革の波に揺れていました。メインフレームによる集中処理から、ネットワークを介した分散処理へ。
これまで商用コンピュータはメーカー独自のハードウェア、OS（オペレーティングシステム）、アプリケーションで構成されたメインフレームが主流でした。しかし、マイクロプロセッサ技術の急速な進歩により、相対的に小型のサーバがメインフレームに匹敵する、あるいはそれを上回る性能を持つようになりました。UNIXなどの汎用的なオペレーティングシステムや技術仕様が公開されたハードウェアを組み合わせたオープンシステムが普及し始めました。
メインフレームベンダーの日本法人であった日本ユニシス（現：BIPROGY）も1989年1月にオープンシステム対応のUNIXシステムU5000を販売開始し、オープン化への対応を加速させました。1
このオープン化は、異なるシステム間でのデータ交換を不可避の課題として浮上させました。そこでは文字コードやデータ形式の違いがシステム間の相互運用性を阻む大きな壁となりました。
文字コードは、文字とそれを表す数値（コードポイント）を対応付ける規則です。これにより、コンピュータは文字をデータとして扱うことができます。この文字コードには多くの種類があり、メインフレームで使用される文字コード（Unisys製メインフレームならばLETS-JやJBIS）と、オープンシステムで採用される文字コード（SJISやEUC）は、それぞれ異なります。この課題を解決するために必要とされたものが、文字コードを相互に変換する「翻訳者」の存在でした。
最初はメインフレームが主でオープンシステムが従でした。それ故にデータ変換ソフトウェアもメインフレーム上で実装されました。しかし、オープンシステムの普及が進むとオープン側でより安価に、より手軽にデータ変換を実施したいという要望が大きくなりました。そこでU5000で稼働するデータ変換ツールDTRが1989年7月1日に誕生しました。
オープン側でデータ変換ソフトウェアを開発することは大きな利点があります。メインフレーム上のデータ変換ソフトウェアは、そのメインフレームの文字コードとオープンシステムの文字コードを変換します。これに対してDTRはIBM、日立、NEC、富士通といった国内外の主要メーカーが独自に採用していた文字コード体系にも対応しました。DTRは各社メインフレームとオープンシステムのデータを変換するハブにもなります。
1990年代：EAI/ETLパッケージ登場
DTRはU5000の後継のU6000に移植され、続けてSolaris版U-DTR、HP/UX版DTR/JHPがリリースされました。1995年10月2日リリースのバージョン4R3D からWindows版「DTR/NT」をリリースしました。NTはWindows NTに由来します。
この1990年代にはEAIやETLというジャンルのパッケージソフトウェアが登場しました。
- EAI: Enterprise Application Integration：企業内外の異なるアプリケーションやシステム間でデータやプロセスを統合し、連携を実現する仕組み
- ETL: Extract, Transform, Load：データを抽出し、必要な形式に変換した上で、データウェアハウスなどのターゲットシステムにロードする仕組み
これらEAI/ETLツールは独自のGUI開発環境を提供し、ノンコードでデータ変換を実装できることをセールスポイントとしました。これに対してUNIXを出自とするDTRはコマンドラインで全て操作できるようにしています。項目変換やマッピングもパラメータ（文字）で表現します。
DTRの変換パラメータは以下のように定義します。
{c8,11c8 k10,1k10 s8,33s8 c2,"AB"}
これは以下のようにマッピングして出力レコードとすることを意味します。
- 入力レコード11バイト目からの文字8バイトを設定
- 入力レコード1バイト目からの漢字10バイトを設定 2
- 入力レコード33バイト目からの先頭符号10進数8バイトを設定
- 固定文字列"AB"を設定
非常に少ない情報量でマッピングが可能です。後にDTR/NTはDTRIIに改称され、GUIを導入しました。このGUI機能は、あくまでパラメータを生成するためのインタフェースであり、パラメータを文字で表現するというコンセプトは維持し続けていました。
GUI開発環境はノンコーディングで直感的に開発できる生産性の高さがセールスポイントですが、弱点もあります。
第一にGUIは常に人間が画面を開いて操作することを前提としています。企業システムでは似たような連携処理が何十本と存在することもあります。文字で表現されたパラメータならば作成したものをコピーし、修正箇所のみ修正することで新規作成になります。
第二に保守で共通の変更箇所が発生した場合もGUI開発環境ではエンジニアが一本一本画面を開いて編集しなければなりません。これに対して文字で表現されたパラメータならば一括変換が可能です。
いわばDTRはIaC: Infrastructure as Code（コードとしてのインフラストラクチャ）を先取りしていたとも言えるでしょう。
2000年代：Integration Serverへの進化
EAI/ETLツールは高機能化し、常時稼働するサーバ（サービス、デーモン）を持つIntegration Serverへと進化しました。Webサーバも内蔵し、連携処理をWeb APIとして公開できるものも登場しました。SOAの流行に乗ってESBという新たな製品ジャンルも確立しました。ここで培われた技術は後のiPaaSにつながっていきます。
- SOA: Service Oriented Architecture：サービス指向アーキテクチャ。ソフトウェアの機能を一つのサービスとしてコンポーネント化し、それらのサービスを組み合わせて処理を実現する設計手法
- ESB: Enterprise Service Bus：様々なアプリケーションやサービス間のデータを連携する仕組み。EAI/ETLと比べた特徴は標準プロトコル、疎結合、安価
DTRはアプローチが異なります。サーバプロセスを持たず、運管ツールなどから連携処理が必要な時にプログラムを実行し、変換処理中のみプロセスが起動します。この実行プログラム方式には以下のメリットがあります。
- プロセス監視が不要：常時稼働型サーバと異なり、シンプルな運用が可能
- 手軽さ：必要な時だけプロセスを起動するため、リソースの効率的な利用が可能
EAI/ETLツールとDTRは必ずしも競合する関係ではありません。EAI/ETLツールが対応できないメインフレームの文字コード変換や外字変換をDTRが行う補完関係も成立します。EAI/ETLツールからコマンドを発行し、DTRでファイルを変換します。そのファイルをEAI/ETLツールが読み込み、出力先システムに格納します。
2010年代：クラウドとビッグデータ
2010年代は、クラウドコンピューティングとビッグデータがIT業界を席巻した時代です。EAI/ETLツールはクラウドサービス向けのアダプタやコネクタを揃え、クラウド対応をセールスポイントとしていきました。
DTRもクラウドIaaSへの導入をサポートしています。クラウドサービスへの連携には直接対応していませんが、運管ツールとバッチジョブを組み合わせて対応した例があります。
- ジョブ1：DTRがファイルを変換して出力
- ジョブ2：DTRが出力したファイルをAmazon S3やAzure Blob Storageなどのオブジェクトストレージにアップロード
また、ビッグデータ活用の流れで大量データ連携が求められるようになりました。DTRはレコード単位で変換処理を行うため、データ量増加による性能劣化がほぼありません。GBクラスの固定長ファイルの変換を他ツールからリプレースして性能向上した事例があります。
2020年代：iPaaSの台頭
この時代になると、システム間でのデータ/プロセス連携処理をクラウドサービスとして提供するiPaaS: Integration Platform as a Service（サービスとしての統合プラットフォーム）が普及していきます。iPaaSはインターネット経由でアクセスでき、迅速なデリバリが可能です。新機能や不具合修正の反映は自動で行われますし、またiPaaSが連携を司る接続先のエンドポイントの仕様変更も自動的に対応が行われます。パッケージソフトウェアにとっては黒船のような存在です。
しかし、システム間の連携を司るiPaaSにとって、企業の閉域ネットワーク内に存在するシステムの連携制御を直接行うことができないという難点があります。iPaaSはインターネット上にあり、オンプレミス環境などプライベートネットワーク内のシステムとそのままでは連携できません。プライベートネットワーク内に入るためにはプライベートネットワークに入れるように設定してもらう必要があります。これはプライベートネットワーク側にとってはリスクが生じることを意味します。
また、社内システム間の連携であってもiPaaSで変換するならばデータがインターネットに出ることになります。暗号化などのセキュリティ対策をしていると言っても、本来インターネットに出す必要のない社内システム間連携でデータを外部に出すことへの抵抗感はあるでしょう。
このためにiPaaS製品には実行エンジンをプライベートネットワーク内のサーバに導入する方式を持つものがあります。連携処理の定義はブラウザで実施し、クラウドサービスが連携処理を管理します。
一方で以下の点はインストール型ソフトウェアと同じです。
- ユーザがサーバを用意する
- ユーザ側で実行エンジンやサーバの運用をする
- ユーザ側で冗長化など可用性を確保する工夫をする
クラウドが普及してもインストール型ソフトウェアは引き続き重要な役割を果たし続けるでしょう。
まとめ
1980年代のオープン化の中で、異なるシステム間でのデータ交換という課題が顕在化しました。その解決策として誕生したDTRは、メインフレームとオープンシステムの橋渡し役を担い、やがてオープンシステム間のデータ連携にも役割を広げていきます。
1990年代にはEAIやETLといったパッケージソフトウェアが登場し、GUIによるノンコーディング開発が主流となりました。これに対してDTRはパラメータを文字で表現する独自のアプローチを貫き、効率性と保守性を実現しました。
2000年代にはEAI/ETLはWebサーバを内包するIntegration Serverに進化しました。その中でもDTRは軽量な実行プログラム方式を維持し、シンプルな運用性を強みとしました。2010年代にはクラウドとビッグデータの時代を迎え、データ変換技術は大量データ処理やクラウド基盤への対応で存在感を高めていきます。
そして2020年代、iPaaSの普及によって連携の形はクラウドサービス中心にシフトしつつあります。しかし、閉域ネットワークとのセキュアな連携などで、インストール型ソフトウェアの役割も依然として重要です。クラウドとオンプレミスのハイブリッドな世界では、両者の強みを活かした連携が求められます。
付録：DTR年表
1989年7月1日、DTR誕生。
1995年10月2日、Windows版「DTR/NT」リリース。
1996年11月5日、バージョン4R4Eリリース。x型（16進数表現）追加。
2001年9月10日、バージョン4R5Gリリース。テープ、可変長ディスク追加。
2002年4月30日、バージョン4R6Hリリース。UHMDEファイル追加。
2005年12月26日、バージョン4R11Mリリース。q型（符号なしパック形式）追加、JIS90対応。
2006年10月30日、バージョン5R2Bリリース。Unicodeサポート。
2006年11月24日、DTR/Linuxリリース。
2007年9月28日、バージョン5R4Dリリース。JIS第3水準・JIS第4水準対応。
2009年4月6日、バージョン5R5Eリリース。Unicodeサポート拡充（Unicode → Unicode変換）。
2010年5月24日、DTR/Jリリース。
2011年11月25日、AIX版「DTR/A」リリース。
2012年6月22日、DTRIIリリース。
2013年4月15日、バージョン5R9Iリリース。DB連携機能追加。
2014年4月7日、バージョン5R10Jリリース。日付変換機能追加。
2015年4月20日、バージョン5R11Kリリース。COBOL登録集のメタデータインポート機能追加。
2016年4月11日、バージョン5R12Lリリース。DB連携のサポート対象追加（Excel, Access対応）。
2017年4月10日、バージョン5R13Mリリース。ディレクトリ変換追加。
2018年4月9日、バージョン5R14Nリリース。CSVの2byte区切り文字対応。
2019年4月22日、バージョン5R15Oリリース。Unicodeの数値項目の2byte出力対応。
2020年3月30日、バージョン5R16Pリリース。XML入出力機能追加。
2021年3月29日、バージョン5R17Qリリース。JSON入出力機能追加。
2022年4月8日、バージョン5R18Rリリース。Unicode多バイト文字外字対応。
2023年3月31日、バージョン5R19Sリリース。ハッシュ値出力機能追加。
2024年5月1日、バージョン5R20Tリリース。Unicode→他文字コードの多バイト文字外字対応。
2025年3月31日、バージョン5R21Uリリース。ディレクトリ変換拡張子対応。
We Are Hiring!