こんにちは。CDataの桑島です。師走となりAdventCalendarの季節がやってきましたね! 本記事は、CData Software User Group Advent Calendar 2019 2日目の記事です。
さて、今年のAdventCalendarでは「CDataまるわかりシリーズ」と題して、CDataSoftwareが提供する製品について製品毎の特徴や得意なことを説明していくシリーズ記事をお届けいたします。
- CDataが生まれた背景 (本記事)
- CDataの製品ライン
- CData Drivers - SaaSデータにSQLアクセス!?
- CData Sync - まるっとSaaSデータをDBに複製!?
- CData SQL Gateway - 仮想MySQL/SQLServerインスタンス!?
- CData API Server - RDBやCSVファイルからWebAPIを生成!?
本記事では第一弾としてCData製品が生まれた背景について私の考察も含めてお送りします。
CDataが生まれた背景
長年の間、企業で扱うデータベースといえば、データベース（DB）＝RDBと言っても良いぐらいRDBMS（リレーショナルデータベース管理システム）が不動の地位を築いてきました。Oracle、SQLServer、DB2、PostgreSQL、MySQLなどです。これらのDBには、OLTP（業務用DB）とOLAP（分析用DB）という切り口があり、分析用DBはデータウェアハウス（DWH）と呼ばれ、TeradataやExadata、Netezzaなどのハードウェア一体型のデータウェアハウスアプライアンス、MPPやカラムストア型といった方式でソフトウェアで大量の検索リクエストを捌くように工夫されたVerticaやGreenPlumとものが利用されてきました。
一方で、システム間のデータの連携は、CSVフォーマット、よりレガシーなシステムだとSAM/VSAMといったいわゆるファイルを、JP1やTivoli、AーAutoといった商用もしくはCronやWindowsタスクスケジューラといったOS付属のジョブスケジューリングソフトウェアとHULFTに代表されるファイル転送ソフトウェアを組み合わせて行われていました。
社内のファイル共有といえば、NASと呼ばれる共有ディスクをネットワークドライブとして接続してローカルファイルのバックアップや社内の共有に使われてきました。
企業で利用されるアプリケーションは、大きく（スクラッチとも呼ばれる）カスタムアプリケーションとパッケージソフトウェアに分類されます。基幹系システムとなると、ベンダー固有のレガシーなハードウェアにCOBOLやCといったプログラミング言語でカスタムアプリケーションとして組まれているものが長年利用されてきました。一部では、オープン化やレガシーマイグレーション、リフト＆シフトという名前で中の業務ロジックはそのままで、新しい基盤に載せ替えることでシステム寿命を延命するというも行われています。一方でパッケージソフトウェアの活用もSAPや国産のERPや会計パッケージも多く利用されてきましたが、Fit&Gap分析から入り実業務をパッケージに合わせるのではなく実業務に合わない（Gap）部分をアドオン開発してそれがスパゲッティ化してソフトウェアのバージョンアップを妨げてしまい塩漬けシステムになってしまい、パッケージの保守メンテナンスが切れる2025年問題という言葉が出て問題にもなっているようです。
そんな中、企業が扱うデータベースやアプリケーションのムーブメントとしてといったグラビティーシフト（主流といった物事の重心の変化）が起こっています。「ビッグデータ」「クラウド」「ノーコード/ローコード」です。これにより企業が扱うデータベースやアプリケーションは急速に多様化しています。
データベースの世界では、NoSQLといったRDBMSの特徴であるメタデータを管理せずスキーマレスと呼ばれるメタデータがなくてもデータベースに格納・検索できるデータストア、大量に発生するデータを高速に捌くデータ処理基盤であるHadoop/Sparkといったデータプラットフォームが利用され始めました。分析用DBとして利用されてきたDWHもよりスケールが容易なクラウドサービスのタイプが主流になってきました。BigqueryやRedShift、新しいところでいうとSnowflakeといったプロダクトです。
ファイル管理も従来は、boxやGoogleDrive、OneDrive、Dropbox、S3といった様々なクラウドストレージが利用されるようになり、グループウェアやCRM/ERPなどの業務アプリケーションと密に連携することでオフィスワーカーの生産性を向上しています。
アプリケーションをみてみると、第三の選択肢として、SaaS（Software As A Service）と呼ばれる業務アプリケーションをサービスとして利用出来るものが多く出てきており、サービスを契約すればすぐ利用出来るというメリットだけでなく、業界（Vertical）や業務（Horizontal）に特化されているものが多いため、コアコンピタンスとなりうる部分以外のコモディティ化された業務はアプリケーション側に業務を併せることで業界標準な業務フローを構築出来ることも魅力です。
アプリケーションを構築する基盤も、SQLがわからなくてもドラッグ＆ドロップ操作でデータを抽出・分析出来る、ビジネスインテリジェンスなどのアナリティクスツール、データの連携もグラフィカルな画面で処理フローをつなげていくことで作成出来るETL/EAI、最近だとiPaaSと呼ばれるツールやサービス、VBAなどの処理の自動化をGUIから可能なRPAといったプログラミング不要な「ノーコード/ローコード」なツールが多く出てきたこともありITにちょっと詳しい非IT部門の担当者側で業務アプリケーションを作成する（＝シチズンディベロッパーともいう）という昔でいうEUC（エンドユーザコンピューティング）が多くなってきているという流れも感じます。
このようにデータベースやアプリケーションが多様化すると「データの利用」を切り口にみたときにどのようなことが起きるでしょうか？それぞれのデータのフォーマットやデータにアクセスするためのプロトコルの違いによって様々な弊害が発生します。
例えば、新しく導入したSaaSからのデータのダウンロード、もしくはSaaSへのアップロードが手作業で実施している、既存の基幹システムのマスタデータと二重管理が発生しているといった問題です。これらの問題を解決しようとデータ連携機能を開発しようとしても、既存の社内のデータ連携プラットフォームやフレームワークが対応していないため、インタフェース部分を個別開発する必要がある、開発してもSaaS側のAPIのアップデート変更が短いサイクルで行われるため個別開発部分を都度メンテナンスが必要となる。特にSaaS / NoSQL / Hadoopエコシステムのデータは、個別にインタフェースや仕様が大きく異なるため都度の設計および実装が必要となってしまいます。これでは、業務の生産性やスピードを格段にあげることが出来る便利なサービスやアプリケーションの活用サイクルが回らなくなってしまいます。この問題は「データアクセスのインタフェースが統一されていない」ことに起因します。
次回
次回は、CData製品が「データベースやアプリケーションの多様化による弊害」を解決するプロダクトとなりうるものなのか、CData製品にはどのような製品ラインがあり、どのような違いがあるのかについて「第二弾 CDataの製品ライン」と題してお送りします。
関連コンテンツ
