RPAというと、「PC作業を自動化して効率化に繋げる」というイメージがあるかもしれません。しかし、DBやexcelといったデータソースを活用することで、一歩踏み込んだ業務効率化および自動化が実現します。

本記事では、「RPA」とデータ活用基盤の構築に不可欠な「ETL」を用いた業務効率向上および自動化の施策を紹介いたします。

目次

• RPAとETLとは何か
  • RPAとは
  • ETLとは
• RPAとETLを用いた業務効率を考える
  • 請求データの照合（売掛金管理）自動化
  • 定例会議用のレポート作成自動化
• 「データ活用基盤」を中心に自動化や効率化を考える

RPAとETLとは何か

そもそもRPAとETLとは、どのようなものでしょうか？

ここでは、それぞれの概要を解説しましょう。

RPAとは

RPAとは「Robotic Process Automation」の略で、人間の作業をプログラムによって自動化する技術のことです。RPAでは、AIや機械学習の技術を活用した自動化も実現しています。

例えば、あるシステムから出力されるCSVファイルを別のシステムに取り込むといった処理を毎朝実施しているとします。このケースでは、RPAに以下の行動を学習させます。

• システムへアクセスする
• システムからCSVを出力する
• CSVを別のシステムにインポートする

これらの行動を学習させることで、RPAが毎朝定期的に実施してくれます。つまり、RPAは決められたプロセスを実行するのに優れており、日次処理や週次処理などの定期的な作業への活用がおすすめです。

ETLとは

ETLとは「Extract （抽出）、Transform （変換）、Load （書き出し）」の頭文字を取った言葉で、データの効果的な処理における必要な機能を持っています。

Extractでは、データの収集先となるデータソースにアクセスし必要なデータを取得します。続いて、取得したデータを決められたフォーマットに整えていく必要があり、Transformがこの役割を果たしています。最後に、Loadの機能でDWHなどの大規模データベースへ格納します。

ETLを導入することで、社内または社外のデータと接続・統合し、一元的な処理が行なえます。現在は、多くのデータに対して効率的に接続できるETLツールを利用し、導入により、データソースへのアクセスや集約を効率的に実現できるのです。

RPAとETLを用いた業務効率を考える

PC作業を効率化するRPAとデータ整備を行うETLでは、一見遠い存在のように見えるかもしれません。しかし、この2つのツールをうまく活用することで業務効率を最大化させることが可能です。

ここでは、具体的な業務効率化の例を2つご紹介します。

請求データの照合（売掛金管理）自動化

1つ目は、RPAとETLを組み合わせて、膨大な手動処理の自動化を実現した例です。ここでは、取引先に送付した請求書が、請求書記載の内容、条件で正しく入金されているかを確認する業務（売掛金管理）があります。

このケースでは、大きく以下の作業フローが想定されます。

1. 経理システムのデータを、自動でダウンロードする（RPAが担当）
2. オンラインバンキングの入金履歴をダウンロードする（RPAが担当）
3. ダウンロードした２つのデータを、照合可能な状態に加工する（ETLが担当）
4. ２つのデータを照合する（ETLが担当）
5. 結果をメール添付して関係者に送付する（RPAが担当）

売掛金情報と、入金情報を付け合わせて、取引先から予定通り入金されているかを自動で確認することで、手動業務の削減による正確性の向上ならびに残業などの人件費削減が見込めます。

定例会議用のレポート作成自動化

2つ目は、会議などで利用するレポートや営業資料の自動化です。

例えば、マーケティングの会議を想定してみましょう。必要なデータソースは、「Salesforce」「マーケティングオートメーションツール」「Google Analytics」「Google Search Console」「ExcelやGoogleスプレッドシート」など多岐にわたります。

このケースでは、以下の作業フローが想定されます。

• 各ツールのデータを自動ダウンロード（RPAが担当）
• ダウンロードしたデータを、整形ならびに自動計算（ETLが担当）
• 作成したファイルを、指定フォルダにアップロード（ETLが担当）
• 会議開始前に関係者にメール送付（RPAが担当）

特に工数がかかるデータの整形と計算ロジックの適用が自動で実施されるだけでなく、ETLを用いてヒューマンエラーが激減するため、効率化、迅速化、人件費の削減が見込めます。

そして、レポート自動化が効果的なのは、横展開のニーズが高いことです。例えば、マーケティング部門以外でも、営業部門、サポート部門、企画部門など、それぞれの業務でレポートを作成する業務があります。

また、同じ部門内でも「レポートが１つだけあればよい」わけではなく、部門内のさらに小さな単位でレポートが必要になります。例えば、「東京営業部」「大阪営業第一課」といった部や課単位であったり、「A製品販売レポート」「B製品販売レポート」といった製品単位などの製品単位などです。

こうした組織内における「多種多様なレポート作成ニーズ」の多くを吸収できる点が、レポート作成自動化のメリットといえます。

「データ活用基盤」を中心に自動化や効率化を考える

これまでRPAとETLを用いた業務効率化、自動化について解説してきましたが、データビジネスの基本は「データ活用基盤の構築」です。データ活用基盤が整っていないと、すぐにデータ活用ができないためです。

しかし、基盤の構築はデータがサイロ化しやすく、適切な形で一元管理するのが難しいためなかなか進められない企業様が多いでしょう。そこで、データ活用を考えている企業様は構築のプロにお任せするのがおすすめです。

弊社3shakeは、データ統合基盤の戦略策定から運用までを総合的に支援しています。インフラやセキュリティに強い設計も提供できるため、安定稼働も実現できます。これからデータ基盤の構築を考えている企業様は、ぜひ3shakeまでご相談ください。
ETLツールについて詳しく知りたい、ETLツールの選び方を知りたいという方はこちらの「ETLツールとは？選び方やメリットを解説」をぜひご覧ください。

The post RPAとETLを用いた業務効率向上の施策 first appeared on Reckoner.

しかし扱うツールが増えれば増えるほど、マーケターの仕事量や責任は増えていく一方。マーケターがカバーすべき業務領域も徐々に拡大しているように感じます。

そこで本記事では、マーケターがETLツールを活用してどのように仕事を効率化し負荷を減らしていけるのかを考えていきます。

目次

• 企業がマーケターに求めること

• Web広告におけるETLツールの活用
  • 複数の広告媒体プラットフォームを一元管理する
  • 各広告の表記形式、表示項目を統一

• ETLツールを利用したマーケティングツールの統合
  • 各ツールのダッシュボードを簡略化して統一する
  • データの連携や資料作成の自動化も可能

• 散らばったデータを一括管理し、見える化するReckoner

企業がマーケターに求めること

まずは企業がマーケターに何を求めているかを見ていきましょう。

【マーケターに求められている3つのポイント】
①適切なデータの収集・分析
②①から導き出す改善案の提示やマーケティングプランの立案　
③①②を繰り返しPDCAを回すこと

上記の3つが企業側がマーケターに求めていることです。その中でも特に、②の「改善案の提示やマーケティングプランの立案」が最も注力すべきポイントです。データを収集したり、分析することは本来の目的ではなく、分析結果をもとにどのように改善するのか、というのが本質的な課題解決に繋がるからです。

しかし、いざ現場のマーケターまで目線を落としてみると、マーケティングプランの立案に時間を割けているかというと、そうではありません。サイロ化したデータを収集（ツールのダッシュボードを眺める、SQLを書いてデータを抽出、データを変換…など）して、レポートを作成する作業ばかりに時間を取られているのでは無いでしょうか。

皮肉なことに、マーケティングツールや分析ツールが増えれば増えるほど、企業のマーケターは本来注力すべきポイントに工数を割くことができなくなっているのです。

蓄積された膨大なデータを最大限に活用するのであれば、収集や分析にかける工数を削減し、分析結果から導き出すマーケティングプランの立案に時間をかけられる環境を作るのがベストだと言えるのでは無いでしょうか。

次項より、データ収集や分析をする手間を減らすための具体的な施策を紹介していきます。

Web広告におけるETLツールの活用

本項では、Web広告のデータ収集および分析の効率化を提案していきます。あくまでひとつの例ですので、導入する際はぜひ自社の要件に合った形式を考えて取り組んでみてください。

複数の広告媒体プラットフォームを一元管理する

Web広告を集客・販売の軸としている企業様も多いですが、ひと口にWeb広告といっても

• Facebook広告
• Yahoo広告
• Google広告

といったように、複数のチャネル・プラットフォームが存在するため、それぞれの広告データを適切に管理するのが非常に難しくなってきています。さらにいえばWeb広告の中にもリスティング広告・ディスプレイ広告・動画広告・SNS広告など、種類も様々です。これらのデータを各媒体ごとに日々確認し、分析・レポートを作成することは非常に非効率な作業と言えるでしょう。

ここで提案する手法としては、広告媒体（n個）に対してETLツールを利用した集計を実施し一元管理する方法です。たったこれだけで複数媒体間での行き来を無くし、効率的な分析が行える環境が整います。

もし広告媒体側で項目の変更や取得情報に変更があった場合でも、ETLを使用していればGUI上で容易に対応できるため、自社のエンジニアに頼んでコードを修正する、といった手間もかかりません。

各広告の表記形式、表示項目を統一

広告媒体によって、表記や標準で表示される項目に違いがあります。それぞれの項目を都度エクセル上で修正し、社内の標準形に変更してレポートを作成しているという話も耳にしますが、これもまた非効率な作業です。

複数のチャネルやプラットフォームを一元管理する際には、こういった取得項目の修正や表記の変更、扱う数値の有効桁数修正なども含めて統一することが可能です。また、広告の良し悪しの判断材料として使用しない数値は表示する必要はありませんので、導入の際に必要項目を絞って簡略化することも大切です。

例えば、

• クリエイティブ文章
• クリエイティブ画像
• 広告費
• ROAS
• ROI
• CV
• CTR
• CVR
• IMP
• Frequency
• CPM
• CPC
• CPV

といったように項目を絞り、全ての広告媒体の数値を一元管理すれば、各媒体のダッシュボードを跨いで確認するという作業は不要になります。もちろん、自社独自の計算をかませて算出する指標がある場合は、表示項目に加えても良いでしょう。ETLツールを挟むことで計算の自動化も可能です。

また、キャンペーンごとや日ごと、リンク先ごとなど、好きな形式でデータを形成することもできるでしょう。数値をまとめて管理することで、効果の高い広告を瞬時に判断でき、感覚に頼った広告運用を避け、無駄なコストを省くことが可能になります。

ETLツールを利用したマーケティングツールの統合

次に、BtoB企業で使われることの多い3つのツール「Google Analytics」「Marketo」「Salesforce」を、ETLツールを使って一元管理するというアイディアです。マーケティングツールや分析ツールはマーケターしか触ることができないという、属人化した状況を改善する施策としても有効です。

各ツールのダッシュボードを簡略化して統一する

【それぞれのツールの主な用途】

・Google Analytics：アクセス解析
→PV、UU、CV、セッション数など

・Marketo：購買情報の管理
→購買データ、メルマガの数値解析、スコアリング管理、過去施策のデータストックなど

・Salesforce：取引先情報の管理
→取引先一覧、商談ログ、引き上げ状況など

先に挙げた広告の一元管理とは違い、それぞれのツールが持つデータに互換性が無い場合でも一元管理は有効です。理由としては

• 一元管理によりツール横断の手間を省く（効率化）
• 簡略化により誰でも使用できる環境を整える（脱属人化&データドリブンな組織の形成）
• 過去データやログを管理する（過去データの蓄積）

といった事が考えられます。各ツールのダッシュボードは非常に優秀ですが、ツール間の行き来は面倒なうえに、それぞれのツールの操作感も大きく異なるため、ツールごとに属人化しやすいという問題があります。

また、ツールによっては過去データを蓄積できないケースもあるため、ETLツールを使ってデータを適切な形に再形成し、ヒストリーテーブルとしてデータを保管しておくというのも重要です。

データの扱いに慣れていない社員の方でもデータを見れるように、ツールを簡略化することも目的のひとつです。マーケターからすれば、データ抽出やレポート作成を頼まれる頻度は激減しますし、会社全体としてはデータドリブンな組織を形成しやすくなるというメリットが挙げられます。

データの連携や資料作成の自動化も可能

もちろん、Webサイト上の行動データ（Google Analytics）や購買データ（Marketo）、顧客のリード状況（Salesforce）を一元管理しデータを関連付け、マーケティング施策に活用することも可能です。

一元管理された状態であれば異なるツール間でデータを連携させることも容易です。3つのマーケティングツールを一元管理するだけで、下記のような分析が容易に行えるようになります。

• Google Analyticsで計測したユーザー層とMarketoの購買データを比較してユーザー層の乖離を確認しマーケティング戦略に落とし込む
• Google AnalyticsのutmパラメータをMarketo→Salesforceに連携し、商談に繋がったリードの経由を探り注力するポイントを探る
• 各ツールのデータを一元管理し、Googleデータポータルで可視化することで営業資料や定例MTGの資料作りの工数を削減する

サイトの分析情報や顧客情報、購買データを見れる環境を社内に展開することで、データに強い部隊を形成し、数字に基づいた営業活動・マーケティング施策が行えるようになるのではないでしょうか。

散らばったデータを一括管理し、見える化するReckoner

本記事では、「Web広告におけるETLツールの活用」と「ETLツールを利用したマーケティングツールの統合」のアイディアを提供させていただきましたが、ETLを使ったマーケティングアイディアはまだまだ存在します。

もしマーケティングを強化するためにETLを利用したいという企業様やマーケター様がいらっしゃいましたら、気軽にお問い合わせください。

当社のETLツールである「Reckoner（レコナー）」は、GUIからの直観的な操作を実現し、プログラミング知識なくETL（Export, Transform, Loadを意味する、データの自動一括抽出・変換・投入サービス）を利用できます。

マーケティングの柱として、データの活用をご検討の企業・組織に14日間無料トライアルをご提供しておりますので、ぜひご活用ください。

ETLツールについて詳しく知りたい、ETLツールの選び方を知りたいという方はこちらの「ETLツールとは？選び方やメリットを解説」をぜひご覧ください。

The post 【Webマーケター向け】ETLツールを使ったデータ変換で業務効率化 first appeared on Reckoner.

以下では、GCPユーザーが具体的にどのようにETLを利用して業務を効率化しているかについて、ETL製品「Reckoner」開発元である当社ならびユーザー企業様の経験を踏まえて、「5つのシナリオ」をご紹介いたします。

目次

• (1)BigQuery→ETL→Cloud SQL (MySQL, PostgreSQL)
• (2)Cloud SQL (MySQL, PostgreSQL)→ETL→BigQuery
• (3)Cloud Storage → ETL → BigQuery
• (4)BigQuery→ETL→Excel, CSV
• (5)Excel, CSV→ETL→BigQuery
• マルチクラウド＋SaaS＋オンプレミスのデータ統合にETLが貢献
  • マルチクラウドを「手動バッチ」でデータ統合するのは正解か？
  • マルチクラウド＋SaaS＋オンプレこそETLを使うべき
• ETL「Reckoner」でGCPのデータをさらに活用

(1)BigQuery→ETL→Cloud SQL (MySQL, PostgreSQL)

GCPのDWHであるBigQuery上のデータを、ETLで抽出・変換、そしてGCPのRDBサービスであるCloud SQL (MySQL, PostgreSQL, SQL Server) にロードするというシナリオです。

例えば、BigQuery上にある各所から集められたデータの中から、必要なデータのみを切り出してRDBに載せ、システム・サービスを構築するイメージです。

具体的には、高速なBigQueryでデータの取捨選択・分析を行い、欠かせないデータを特定、その後当該システム・サービスで利用するフォーマットにデータを変換したうえでロードする、という流れです。

高速なBigQueryの活用、高速なETLデータ処理により、短時間で大量のデータが準備可能となります。これにより、新規システム・サービス稼働までの時間を短縮できます。

(2)Cloud SQL (MySQL, PostgreSQL)→ETL→BigQuery

次は、上記1とは逆に、RDB上のデータをETLで変換した上で、BigQueryにロードするというシナリオです。

各システム・サービスに点在している多数のデータベース上のデータを、必要なデータ変換をETLで行った上で、BigQueryにロードし、データを集約するイメージです。

BigQueryをメインのDWHとして利用し、多数のRDBを接続させているユーザーからすると、最も多く利用され、またコスト効果やデータ変換効率が分かりやすいシナリオの1つです。

(3)Cloud Storage → ETL → BigQuery

オブジェクトストレージであるCloud Storage上のデータを、ETLで変換したうえで、BigQueryに集約するというシナリオです。

これは、上記2のRDB→ETL→BigQueryという「DWHに分析用データを集約する」のと同じ用途になりますが、データベースではなくオブジェクトストレージである点が異なります。

多くのETLでは、オブジェクトストレージも問題なく取り扱うことができます。これによりユーザーは、その都度データの取得方式やデータ変換の違いを意識する必要がなくなります。そして、BigQuery上にロードされたデータを一元的に取り扱うことが可能となります。

(4)BigQuery→ETL→Excel, CSV

BigQuery上のデータを、ETLで変換した後に、ExcelやCSVにロードするシナリオがこちらです。

DWH上のデータの中から、特に重要な項目のみを抽出し、表形式でデータを保持します。必要なデータのみをわかりやすく共有し、「経営会議」「営業会議」などの場で議論や検討する際に多用されます。また、特定の領域におけるデータを定型フォーマットで都度出力し「定点観測」するのも有効です。

(5)Excel, CSV→ETL→BigQuery

ExcelやCSVで取得した比較的小規模なデータを、ETLで変換した後にBigQueryにロードするシナリオです。

例えば、「セミナー参加者情報」「協業企業から共有された見込み客リスト」「担当者が短時間で分析したデータセット」などを、DWHに投入する際に利用されます。

ExcelやCSVで作成されたデータの多くは、DWHに格納されているフォーマットに最適化されていないため、ETLで変換してからロードします。

マルチクラウド＋SaaS＋オンプレミスのデータ統合にETLが貢献

一般的なデータ統合業務は、GCPだけでは完結しない場合が多いです。つまり、AWS、Azure、SaaS、オンプレなどの他のプラットフォームを含めてのデータ統合が必要となります。つまり、GCPの中だけを考えるのではなく、他プラットフォームを含めた統合を考えなければ、真の意味でデータの基盤構築は成し遂げられません。

また、たとえ上記で挙げたようなデータ統合を行っていたとしても、データ統合に「手動バッチ」を用いているケースが非常に多いです。しかしバッチには下記で解説するようなデメリットがあるため、透明性を持ってデータ統合を実現するには適しません。

この章ではマルチクラウドにおいて手動バッチが適切ではない理由と、それに代わる代替案として「ETL」を利用すべき理由を述べていきます。

マルチクラウドを「手動バッチ」でデータ統合するのは正解か？

先に述べたように、マルチクラウドの統合に手動バッチを利用するのは適していないと考えられます。ここでは3点、手動バッチのデメリットを挙げて解説していきます。

まず1点目に、「クラウドやSaaSの接続に関する仕様変更が生じた場合、バッチごとに対応が必要になってしまう」という点です。これは接続するデータソースが多ければ多いほどその工数は肥大化し、さらに作業ミスや作業漏れも発生しやすくなります。

2点目は、「バッチはブラックボックス化しやすい」という点です。特に社内エンジニアに頼んで内省した場合にブラックボックス化が生じやすく、エンジニアが多忙でドキュメントを作成せず、特定のエンジニアしか中身を理解できないといったケースがあります。またそのエンジニアが退職した場合、内容の理解が引き継がれないというリスクもあります。これもまた、バッチの数や内容が肥大化するたびに、大きなリスクとなり得ます。

最後に3点目は、「バッチのパフォーマンス低下のリスク」という点です。バッチは自由度が高い反面、データの処理速度はプログラム自体のパフォーマンスに依存します。データ処理速度が低下した場合、バッチを稼働させている環境のリソース配分に問題があるのか、もしくはバッチプログラム自体に問題があるかを切り分けないといけません。しかし、バッチがブラックボックス化している箇所の切り分けが行えず、かといってバッチを止めることもできないため、根本的な解決をすることが困難になります。バッチのパフォーマンス低下で困るのはエンドユーザーであり、データを使った経営判断や意思決定の速度や質に影響してしまう恐れがあります。

これら3点から考えても、マルチクラウドに手動のバッチを使用することはおすすめできません。

マルチクラウド＋SaaS＋オンプレこそETLを使うべき

すでにデータ統合された基盤を持っている組織の多くは、大量で巨大なバッチプログラムに支えられているケースが多いのが現状。データ基盤に対して抜本的なテコ入れを行うのは大きなリスクが伴う為、新しいデータソースを追加するだけで、根本となる基盤の改善を行なう組織は少ないでしょう。

しかしこれはリスクの見送りであり、生じるデメリットをデータを使用するユーザーに押し付けているとも言える状態です。結果として、意思決定の質の低下や判断の遅れ、データ取得にかかる工数の増加といった、生産性の低下を招いているかもしれません。

データ統合ならびにデータ基盤の構築は、クラウドに対応するETLやDataOpsなどの登場により、より洗練した形で行えるようになっています。

UI/UXの優れたETLは、エンドユーザーのETL操作、データ操作を容易にします。DataOpsの登場により、「個別最適化されたサイロを多く作り、そこの橋渡しする形でのデータアクセス、データ統合を行う」といったデータ運用ではなく、より抜本的なデータ基盤の見直しが可能となっているのです。

DataOpsとは？

このように、データを取り巻く環境は常に進化し、最適な環境を構築できるツールや知識は備わっています。手動でバッチで組んた膨大なリスクを内包した脆いデータ基盤は、ETLを用いることで強固で安全なデータ基盤へと移行することができるでしょう。

本記事で紹介しているGCPとの連携も同様です。GCPだけで完結しないSaaSやオンプレの統合もETLを利用することで、よりスムーズで管理に手がかからない形で統合できるはずです。

ETL「Reckoner」でGCPのデータをさらに活用

GCPユーザーがETLを利用する5つのシナリオについてご紹介しました。5シナリオともにBigQueryが用いられており、GCPにおけるBigQueryの存在感がいかに強いかが、改めて思い知らされます。

BigQueryは、各データソースからデータを集約する場所として、またデータ出力元として、多くの企業で多用されています。ETLを利用することで、都度データ変換を指定する必要がなくなるため、正確かつ効率的なデータ処理が可能となります。

当社が開発するETL「Reckoner」は、BigQueryユーザーから多くの支持を得ている、強力なETL基盤です。上記でご説明差し上げたようなデータ抽出・変換・ロードのシナリオは、Reckonerを利用することで、エンジニアでなくても構築可能です。

ぜひ、Reckonerの資料をダウンロードいただき、ご検討いただければ幸いです。

ETLツールについて詳しく知りたい、ETLツールの選び方を知りたいという方はこちらの「ETLツールとは？選び方やメリットを解説」をぜひご覧ください。

The post GCPユーザーがETLを利用する5つのシナリオ first appeared on Reckoner.

しかし、企業ではオンプレでシステムを運用しているケースが未だに多く、マルチクラウドの実現まで至っていないのが現状です。その結果、クラウド基盤とオンプレ基盤の間をバッチによって繋いでいるケースが多くなり、運用コストが高まってしまいます。

本記事では、システム運用基盤の分散によってシステム間を手動バッチで連携している企業の方へ向けて、ETLツールを活用した新たなデータ基盤の考え方である「DataOps」について解説します。

目次

• 分散するデータを連携・統合させているのは「手動バッチ」？
• 目指すべきは「DevOps」に基づく「DataOps」
• DataOpsを支えるのはETL

分散するデータを連携・統合させているのは「手動バッチ」？

多くの企業では、クラウドとオンプレミスを併用してシステムやデータ運用をし、これらのシステム間の連携のために「手動バッチ」（各社で個別に作成するバッチ処理用プログラム）を利用しています。

なお、「クラウド」には、AWSやGoogle CloudなどのIaaSやPaaSだけではなく、SalesforceやMarketo、SansanといったSaaS（Software as a Service）も加わってきます。

手動バッチを用いた運用は以下のようなものとなります。

• 自社独自のシステムをIaaSやPaaS上に構築し、SaaSからのデータ抽出やオンプレミスのシステムのデータを連携するためのバッチを作成・運用し、夜間などを用いて日々の集計業務やレポーティング業務を行う。

手動バッチは、エンジニアが1名いれば、情報を調べながら作成できるという点、またエンジニアの人件費以外の費用（サービス利用料）がかからないというメリットがあります。しかし、データソース側の変更に伴って発生する修正対応や、データ増大時のバッチパフォーマンス劣化に対する対応など、継続して利用する場合にかかる工数は大きくなります。また、バッチプログラム自体がブラックボックス化し、担当していたエンジニアが休職・退職した場合に継続した利用が難しくなるといったリスクもあります。

こうしたリスクを回避するため、現在では「DevOps」をデータ分野において適用する「DataOps」という言葉が出ています。

目指すべきは「DevOps」に基づく「DataOps」

DevOpsとは、システムを開発する担当者（Dev）と運用する担当者（Op）がスムーズに連携しながら一つのサービスを作り上げていく運用形態を意味します。

DevOpsが登場した背景として、開発と運用の分断があります。これまで、サービス開発側はシステムの機能追加や改修を重視し、運用側はシステムを停止させずに安定稼働を目的とすることをそれぞれ目指していました。結果、多くの組織において、開発側とインフラ側が一体となった全体の最適化が実現しないという問題が発生しました。

DevOpsは、途中で発生する方向性のズレを防止するために「組織サイロ化の削減」「一定程度のエラー許容」「計画的な変更」「ツールや自動化の活用」「あらゆるデータの収集」といった5つの要素が必要とされています。

組織サイロ化とは開発側と運用側が独立しており、情報の連携がうまくできていない状態を意味します。DevOpsでは、組織のサイロ化を防止するために情報共有をスムーズに行うのが大切です。

システム開発では要件定義を詳細に実施していきますが、ほとんどのケースで設計通りにいかないものです。そのため、一定程度のエラーを許容するのを前提として取り組んでいく必要があります。

計画的な変更とは、システム開発や運用をしているときに発生する仕様変更について、変更に伴うエラーの考慮や段階的に進めることを重視する考え方です。例えば、システムの画面変更が生じたときに、いきなり本番環境でアップロードするのではなく、テスト環境を活用してあらゆるリスクに対応できる状況を作っておくなどがあげられます。

開発や運用の効率化を実現するためには、ツールや自動化の活用が欠かせません。特に、人的ミスが発生しやすい部分については、プログラムによる自動化を活用していくのが効果的です。

あらゆるデータとは、システム運用で出力されるログやエラー検知などを指しており、こうしたデータを活用できるように数値化するのが重要です。

ここまで解説したDevOpsの思想に基づいてデータ基盤を最適化するのが「DataOps」です。2022年時点では、日本においてDataOpsはまだ聞きなれない言葉ですが、アメリカでは書籍の刊行やDataOpsを積極的に推進する企業が創業されるなど、大きな注目を集めています。

企業でDataOpsに取り組むことで、組織内のデータ基盤が整理されて効率的にデータ連携や統合を図っていけます。さらに、データソースが各クラウド基盤やオンプレに分散していたとしても、データ統合や連携が自動化され、データ処理にかかる工数の削減や正確性の向上につながるでしょう。

DataOpsを支えるのはETL

DataOps、特にデータ統合を実現するためのプロセスとして、ETLツールの利用は欠かすことができません。ETLとは「Extract（抽出）/Transform（変換）/Load（格納）」の略で、組織におけるデータ連携と統合の中核を担うものです。

具体的には、ETLツールによって組織内で点在しているデータソースを一箇所に集約し、その後、集約したデータソースをBIツールなどを使ってユーザー自身が自由に情報取得をしていくのです。

しかし、どのETLツールを選ぶべきか悩む企業の方も多いでしょう。当社の「Reckoner」は、非エンジニアのユーザー自身が簡単に操作できるETLツールのため、必要なデータをいつでも「抽出・変換・格納」できます。

そのため、情報システム部門だけではなく、業務部門自らがデータへのアクセスが可能となり、手動バッチも不要となります。業務部門自身がデータアクセスをしていくことにより、データの意味を正しく理解しながら統合を図っていけるため、データの鮮度・分析力・意思決定力が向上して企業の成長に繋がるでしょう。

ETLツールでデータ連携や統合を進めていきたい企業様は、ぜひ一度お問い合わせください。

ETLツールについて詳しく知りたい、ETLツールの選び方を知りたいという方はこちらの「ETLツールとは？選び方やメリットを解説」をぜひご覧ください。

The post マルチクラウドのデータ連携・統合をETLで実現 [手動バッチからの脱却] first appeared on Reckoner.

そこで活用できるのがETLツールです。ETLツールは、複数のデータソースに接続し、データを抽出（Extract）し、使用用途に応じて変換（Transform）、そして変換されたデータを格納（Load）することができるツールです。

今回は、ETLツールが「データのハブ」となる本当のメリットについて解説します。

目次

• ETLツールがデータのハブとなるメリット
  • 雑務の簡略化と人的ミスの削減
  • 顧客データの統合
  • マーケティングでの活用
  • 高いスケーラビリティへの対応
  • データの集中加工

• ETL導入時のポイント
  • 使いやすさとサポート
  • 接続可能なデータソース
  • スケーラビリティへの対応

• 「Reckoner」でデータ統合・活用を実現する

ETLツールがデータのハブとなるメリット

ETLツールがデータのハブとなるメリットについて、ここでは5つ紹介します。

• 雑務の簡略化と人的ミスの削減
• 顧客データの統合
• マーケティングでの活用
• 高いスケーラビリティへの対応
• データの集中加工

雑務の簡略化と人的ミスの削減

各ツール・システムに紐づくデータベースが増加すると、各データソースの仕様に合わせてデータを抽出する必要があります。別々なデータソースに、別々な接続を行い、API変更などにも対応するためには、大きな工数が必要となります。

多数のデータソースへの接続・データ抽出を効率化するうえで有用なのが、ETLツールです。ETLツールでは、各データソースへの接続があらかじめ提供されており、個別に開発を行う必要がありません。また、接続の仕様変更への対応もETLツール側で実施してくれます。

さらに、各データソースから取得したデータの加工も、指示した条件に従って正確かつ大量に処理されるため、人的ミスが少なくなります。そのため、不正確なデータをもとにした間違った判断を下すリスクも回避できます。

顧客データの統合

複数のデータベースで顧客情報を保有する企業においては、顧客データの統合は必要不可欠です。しかし顧客データを有するデータベースが増加するに従い、多数のデータソースからのデータ統合は困難なものになってしまいます。

多数のデータベースに接続し、必要な顧客データを抽出し、顧客カットでの深い分析を行う上で、ETLを利用した顧客データの統合は不可欠です。ETLを利用することで、必要なデータソースから、必要なデータを抽出し、必要な加工を行った上で、分析に適した形でロードする、という一連のデータ統合作業を自動化できます。

マーケティングでの活用

散在していたデータの統合が可能になったことで、これらのデータをマーケティングで活用することも可能になります。

顧客情報の把握はもちろん、統合されたデータを分析することで経営戦略を立てられます。マーケティングの施策を立てるには多くのデータが必要です。ETLはそのデータを統合し、さらに形式を整えて格納してくれるため、データの扱いを容易にします。膨大なデータを分析できるようになれば、データを用いた戦略的なマーケティングを可能にし、企業に大きなメリットをもたらすでしょう。

高いスケーラビリティへの対応

データ量が増加するに従い、データ抽出や加工にかかる時間は増加します。データ量が増加した結果、想定の時間内にデータ処理が完了しないケースも増加します。このため、かつては「高いスケーラビリティが求められるデータ量を処理するには、データ処理のインフラ自体を作り直さねばならない」というケースもありました。

クラウド型のETLは、データ量に応じたリソースの割り当てが可能です。例えば、少ないデータ量であれば、少ないリソースを割り当て、データ量が増加するごとに、割当リソースを増加させて、速度をあげるというものです。オンプレミスのETLと比べて、クラウド型のETLはこの点に強みがあります。

データの集中加工

データソースが多数ある環境において、「複数の箇所でデータ加工を行う」ケースがあります。これは、負荷の分散などを考慮した上での設計ですが、複数箇所でデータ加工を行った結果、データ処理プロセスに変更が生じた場合、複数の加工箇所で処理の修正が必要になり、工数増加のリスクがあります。

スケーラビリティがあるETLを用いることで、一箇所のETLにデータを集中させて加工が実施できます。これにより、データソース追加時、データ加工の変更時などにおいて、変更工数を最小化できます。

ETL導入時のポイント

次に　ETLツール導入時のポイントを3つ解説します。

• 使いやすさとサポート
• 接続可能なデータソース
• スケーラビリティへの対応

それぞれ解説していきます。

使いやすさとサポート

ETLツールには大きく分けて、「プログラムを書くエンジニアが操作することを前提にした製品」と、「非エンジニアでも利用できるわかりやすいUI/UXを提供する製品」の2つがあります。

もし、BIツールによるデータ分析だけでなく、データ加工についても現場手動で進めるのであれば、非エンジニア向けのUI/UXに優れた製品を選択すべきです。また、組織によっては、ツールのUIにおいて日本語が利用可能か、問題が生じたときに日本語でのサポートが受けられるかといった点も考慮すべきでしょう。

接続可能なデータソース

ETLを利用する大きなメリットの一つは、データソースへの接続にかかる工数を、ETLツール側でカバーされているという点です。これにより、必要な情報を設定項目に入力するだけで、データソースとETLが接続され、工数が大幅に削減できます。

ETLツールを導入検討する際は、自社で利用するツール（データベース、CRM、SFA、MA、解析ツールなど）にETLが対応しているかどうかを確認する必要があります。使用しているツールが全て対応している場合、接続工数がほぼゼロになりますが、対応していないものがある場合は、接続のための工数が別途必要になるため要注意です。

スケーラビリティへの対応

抽出、加工を行いたいデータの量が「今後も現在と同程度で推移」するか、「今後データ量が爆発的に増加する可能性がある」かで、選ぶべきETLツールが異なってきます。データ量が劇的に増加する場合は、当初用意したリソースでは不十分になる可能性が高いため、リソース追加が不可欠です。

将来の急激なデータ増加が見込まれる場合は、リソース追加が容易なクラウド型ETLを選択すべきです。逆に、データ量がさほど増加しない場合は、スケーラビリティに関してはオンプレ型・クラウド型のいずれでも問題ありません。

「Reckoner」でデータ統合・活用を実現する

複数のデータソースに、業務遂行上必要なデータが散在する組織において、ETLは力を発揮します。

当社が提供するETLツール「Reckoner」は、非エンジニアでも使える日本語UIで日本語サポート対応が可能、多数のデータソースに簡単に接続、そしてクラウドETLという特性を生かしたスケーラビリティ、といった点が強みです。

ETLによるデータ抽出、加工、ロードの自動化による工数削減を検討される場合は、ぜひお問い合わせください。

ETLツールについて詳しく知りたい、ETLツールの選び方を知りたいという方はこちらの「ETLツールとは？選び方やメリットを解説」をぜひご覧ください。

The post ETLツールが「データのハブ」となる本当のメリット  first appeared on Reckoner.

Salesforceが事実上、顧客や案件情報のマスターデータとなっている企業は多いかと思います。そのため、SalesforceのデータをSalesforce上で利用するだけでなく、Salesforceから抽出したデータを別のシステム上で利用することも多いのではないでしょうか。

当社はETL製品である「Reckoner」の開発元として、どのような場面でETLを用いてデータを抽出・変換・ロードすればよいかについて、豊富なノウハウを有しています。以下では、ETLを利用しSalesforceのデータを管理する、5つの具体的な利用シナリオをお伝えします。

目次

• シナリオ１ Salesforce から別のシステムへ
  • 1.Salesforceのデータを変形後、基幹システムにロード
  • 2.SFDCの案件情報、個人情報などのデータを変形したのちに、DWHにロード

• シナリオ2 別のシステムからSalesforceへ
  • 3.新規で取得した個人情報を変換したのちに、Salesforceにロード
  • 4.既存の会社情報・個人情報を変換した後に、Salesforceにロード
  • 5.様々なフォーマットの受注データを変換した後に、Salesforceにロード

• データ一括処理を効率化、プロセスを見える化するReckoner

シナリオ１ Salesforce から別のシステムへ

では、Salesforceにあるデータを変換した後に、別のシステムで利用する場合のETL利用シナリオを見てみましょう。ERPや会計製品といったパッケージ製品、または自社独自の基幹システムに対して、Salesforceのデータを変換・ロードする場合です。

1.Salesforceのデータを変形後、基幹システムにロード

リモートワークが当たり前になっている昨今において、社内でサイロ化されているデータが日に日々増えている会社も多いのではないでしょうか。このシナリオでは、以下のようなケースが想定されます。

• Salesforce上の受注データを変形したのちにロードし、ERP・基幹システムが製品の生産開始を指示する
• Salesforce上の未発注売上見込み情報を変形したのちにロードし、会計システム上の情報を随時更新する
• Salesforce上の受注済情報を変換したのちにロードし、請求書発行を毎月自動で行う

SalesforceとAPI連携が可能な製品を除くと、「データの抽出」「データの変換」「データのロード」といった一連の処理を、自作のマクロなどを利用して半自動で行っている企業が多いのではないかと思います。こうした自作のマクロ処理は、システム側での変更があるたびに更新が必要であること、またマクロ作成のノウハウが属人的であることが多いため、安定的に継続稼働させるにはリスクがあります。

Reckonerを利用すると、あらかじめ定められた条件に従い、抽出・変換・ロードを全自動で実施できるほか、ノンプログラミングで利用できるため、エンジニアでないユーザーでも処理を作成できます。処理が属人的になることもありません。

2.SFDCの案件情報、個人情報などのデータを変形したのちに、DWHにロード

Salesforce自身はDWHではないため、Salesforce内にある顧客情報、商談情報、受注情報などをDWHに格納している例は多いかと思います。

• Salesforce上にある個人情報を、データ変換した後にマーケティング分析用DWHにロードし、次のマーケティングキャンペーンの分析に利用する
• Salesforce上にある商談情報を、データ変換した後に営業管理用DWHにロードし、全国の営業担当者の活動評価に利用する
• Salesforce上にある受注情報を、データ変換した後にプロジェクト管理用DWHにロードし、各事業部のプロジェクト管理用マスターとして利用する

Salesforceは主要なDWHとAPI連携していますが、詳細な連携にはプログラミングが必要になるケースがあり、開発コストやメンテナンスコストがかかります。また、担当者が「こうしたデータが欲しい」「データ取得頻度を変えたい」と変更リクエストを出すたびに、新たな開発が必要となるため、営業やマーケティング活動のスピード感が損なわれるというデメリットがあります。

Reckonerは、AWS Redshift や BigQuery といった主要DWHに対応し、スムーズな連携と詳細なデータ変換をノンプログラミングで実現できます。

シナリオ2 別のシステムからSalesforceへ

別のシステム上にあるデータを、変換した後にSalesforceに登録・更新する場合のETL利用シナリオを見てみましょう。

3.新規で取得した個人情報を変換したのちに、Salesforceにロード

• セミナー、イベント、展示会、商談時の名刺交換といった対面での営業マーケティング活動後に、取得した個人情報を、Salesforceの形式に合わせて変換したのちにロードし、今後の活動に用いる
• オンラインセミナー、ホワイトペーパーのダウンロード、問い合わせといった非対面のマーケティング活動で取得した個人情報を、Salesforceの形式に合わせて変換したのちにロードし、今後の活動に用いる

一時的であっても、暗号化されていないExcelやCSVファイル、または担当者個人のGoogleスプレッドシートなどで、個人情報が管理されることは、個人情報漏えいのリスクが高いため非常に危険です。よって、Salesforceのように「権限がある人以外は個人情報を操作できない」「作業のログが全て保存される」といった安全な場所で管理する必要があります。

様々な方法で取得したデータを、都度フォーマットを変換してSalesforceにロードするのは大変面倒な作業であるだけでなく、ヒューマンエラー（データ漏れや変換ミス）が発生しがちです。

各所から取得してきた個人情報を、Reckonerを利用してどのように変換するかをあらかじめ定義しておけば、「指定されたタイミングで個人情報のフォーマットを変換したうえで、Salesforceにロード」する作業が全て自動で実施されます。

4.既存の会社情報・個人情報を変換した後に、Salesforceにロード

上記3.は、「新たに入手した情報の変換・ロード」ですが、4.は「既存情報メンテナンス目的での変換・ロード」です。

• 既存顧客の会社情報や個人情報（会社名、住所、部署名、電話番号など）が変更となった
• マーケティング属性 (DM可/不可、メルマガ可/不可など）の変更希望があった

上記のような既存の情報は、誤って変更すると大きな影響を及ぼしかねません。そのため、「ユーザーは直接変更できない」「ユーザーは情報システム部に対して変更申請を行い、情報システム部で確認後一括変更」しているケースが多いかと存じます。

こうした処理を行う際、情報システム部のSalesforce管理者が、ユーザーが入力したExcelファイルやCSVファイルを都度アップロードするのは手間がかかります。

自動化しようとマクロを組んだ場合、Salesforceの仕様変更のタイミングがあるごとに修正が必要になり、またマクロは知識がある担当者が片手間で作成されることも多いため、「マクロ自体、またはマクロの運用がブラックボックス化しやすい」というデメリットがあります。

Reckonerを利用すれば、Salesforce上の既存情報のメンテナンスもノンプログラミングで、全ての関係者に処理が可視化される形で行うことができます。

5.様々なフォーマットの受注データを変換した後に、Salesforceにロード

販売窓口を自社ECサイトのみに絞っているようなケースを除き、ほとんどの企業では「電話」「メール」「フォーム」「チャットツール」「発注書（PDF）」「発注書（紙）」「FAX」など、様々なチャネルで注文を受けています。

これらのデータをまとめて同じフォーマットで「受注情報」としてSalesforceに登録する際、全てのチャネルを同じ方法で登録するのは非効率です。フォーム入力であれば、直接Salesforceに取り込む方が早いですが、「顧客企業テンプレートの紙の発注書」となると、直接Salesforceに取り込むことができず、いったん人手を介する必要があるためです。

「受注データを目視で確認し、手で転記する」場合や、「OCRやRPAで半自動処理する」場合など、それぞれのケースで作成された受注データ（Excel, CSVなど）をできるだけ早くSalesforceに反映しようとすると、この反映処理のために多くの工数が割かれる場合があります。

Reckonerを利用した場合、複数のチャネルから別々に出力された受注データであっても、定められた条件や頻度に従い、変換・ロード処理を完全自動で行えます。

データ一括処理を効率化、プロセスを見える化するReckoner

Reckonerを利用する理由は、「効率的な自動データ処理をプログラミングなしで実現する」ことに加えて、「属人的な処理をなくし、処理を可視化する」ことです。

データ登録・更新処理をマクロで自動化していたが、担当していた従業員が退社した後で「担当者しかわからない部分が多数あり、処理に問題が発生した」という例は、非常に多いのが実情です。

安定してトラブルが起こらない処理を実現するには、「プロセスを属人的なものとせずに、見える化する」ことが大切です。Reckonerは、この「データ処理の見える化」を実現します。

ETLツールについて詳しく知りたい、ETLツールの選び方を知りたいという方はこちらの「ETLツールとは？選び方やメリットを解説」をせひご覧ください。

The post SalesforceユーザーがETLを利用する5つのシナリオ first appeared on Reckoner.

しかし、ETLツールの具体的なメリットやデメリットが分からず、導入までに進まないと悩む企業も多く見られます。

そこで本記事では、ETLツールの概要について解説し、選び方のポイントや成功事例もご紹介します。

目次

• ETLツールとは？
  • Extract – 抽出
  • Transform – 変換・加工
  • Load – 格納
• ETLツールを活用する5つのメリット
  • 1. 専門的な知識がなくても利用できる
  • 2.データの変換・加工時のヒューマンエラーがなくなる
  • 3.データソースとの連携に必要な開発工数がゼロになる
  • 4.データ連携先の仕様変更への対応工数がゼロになる
  • 5. [サブスク型ETL] コストを平準化でき、トータルコストも節約できる
• ETLツールを活用する2つのデメリット
  • ある程度のITリテラシーを必要とする
  • 導入するコストがかかる
• ETLツールを活用すべき企業の特徴
  • 社内データを活用することができていない企業
  • データが多すぎて整理できていない企業
• 【失敗しない】ETLツールの選び方を紹介
  • 導入コストが見合っているか
  • 専門知識を必要としないか
  • GUIが洗練されているか
  • 技術的なサポートの有無
  • SaaSへの対応をしているか
• ETLツールを導入した成功事例を紹介
  • kintoneデータの自動連携により、業務効率化を実現
  • プロダクトの質・業務効率を高めたデータ基盤
  • データ連携処理にかかっていた時間を約40%削減
• ETLツール「Reckoner」は無料トライアルを受付中！

ETLツールとは？

ETLツールとは、「Extract （抽出）、Transform（変換・加工）、Load（格納）」の機能を持ったツールです。

ここでは、それぞれの機能について解説していきます。

Extract – 抽出

Extractでは、元となるデータソース（顧客情報、販売情報、開発情報など）を抽出します。データソースは、組織で使用している各種システムやクラウド上のサービス、その他データベースやCSVファイルまで幅広く該当します。ETLツールでは、こういったデータソースへ簡単に接続できるようコネクタを保持しており、GUI上から直感的に接続が可能です。

Transform – 変換・加工

Transformでは、抽出したデータを変換・加工し、データベースへ格納するための準備を行います。抽出した段階のデータは、同じ情報であったとしても形式や表現方法がバラバラであるため、同じフォーマットに統一しなければなりません。そのため、変換・加工では決められたフォーマットへ整形するために、文字の変換や空白の除去などを実施していきます。変換・加工をスムーズに実施するためには、最終的なデータの表示形式を定めておくのが大切です。

Load – 格納

Loadでは、変換・加工されたデータをDWH（データウェアハウス）などの大規模データベースへと格納します。格納方法には、データを全て入れ替える「フルロード」や増えた分だけを格納する「増分ロード」があります。

格納までの一連のデータフローが決まってからは、データの更新頻度をスケジュールします。格納時にエラーが発生する可能性も考えて、Slackやメールと連携しておくと常時監視することができます。

ETLツールを活用する5つのメリット

ETLツールには、主に以下5つのメリットがあります。

1. 専門的な知識がなくても利用できる
2. データの変換・加工時のヒューマンエラーがなくなる
3. データソースとの連携に必要な開発工数がゼロになる
4. データ連携先の仕様変更への対応工数がゼロになる
5. [サブスク型ETL] コストを平準化でき、トータルコストも節約できる

1. 専門的な知識がなくても利用できる

ETLツールは直感的な操作でデータフローを作成できるため、専門的な知識がなくても利用可能です。なぜなら、Extract /Transform/Loadの流れを、GUI上でマウスでのクリックやドラッグ&ドロップの操作で実施できるためです。

ツールを利用しない場合は、データソースへの接続部分から作り込みが必要となり、データに対する深い理解が必要となります。

2.データの変換・加工時のヒューマンエラーがなくなる

ETLツールは、ツール内でデータフローの流れを管理できるため、人の手を介さずにデータを正しく処理できます。

もし、ツールを利用せずに人の手でデータ連携を実現する場合には、どこかでヒューマンエラーが発生する可能性を常に持つことになります。ヒューマンエラーの発生により、見た目上は成功していたとしても、実際には違う形式のデータが連携されてしまうといったケースもあるでしょう。その結果、間違ったデータで経営の重大な判断をしてしまうケースもあるため、ETLツールによるヒューマンエラーの防止は効果的です。

3.データソースとの連携に必要な開発工数がゼロになる

ETLツールは、幅広いデータソースとの連携コネクタが提供されているため、連携部分の開発工数が必要ありません。自力でデータソースとの連携をする場合、連携を行うための開発が必要です。

例えば、クラウドサービスからオンプレミスで運用しているデータベースへ連携するとします。この場合、APIを活用してクラウドサービスからデータベースへ接続し、データベース側もAPIの接続を受け入れるといった開発が発生します。

また、データ連携は対象のシステムごとに実装しなければならないため、開発工数やテスト工数など、膨大なコストがかかってしまうでしょう。この点、ETLツールを活用すれば開発工数をゼロに抑えられます。

4.データ連携先の仕様変更への対応工数がゼロになる

ETLツールは、データ連携先の仕様変更があっても対応する必要がありません。なぜなら、サービスを提供している企業側で修正対応をしてくれるためです。

もしETLツールを利用せずに自社でデータ連携の開発を行っていた場合、連携先の仕様変更に対応する作業が都度発生することになります。

5. [サブスク型ETL] コストを平準化でき、トータルコストも節約できる

ETLツールの中でも、サブスク型を選択することでトータルコストの削減につながります。

• 導入コストが低い
• 解約が容易
• インフラ構築コストがゼロ

サブスク型はSaaS形式のサービスとなるため、ライセンスの費用を支払えばすぐにでも利用可能です。導入時にかかる費用も安価で済むことが多く、導入コストも抑えられます。

また、サブスク型は月単位での契約形態が多いため、解約も比較的容易にできるケースが多いでしょう。実際に導入してみると、「使い勝手が悪くユーザー部門からの反対意見が多い」「細かい設定が思ったよりもできない」というケースが考えられるため、解約しやすいというのも利点となります。

最後に、SaaSサービスであるためサーバー等のインフラ構築が不要です。インフラの構築は、サーバ等の費用に加え、エンジニアの作業工数も発生します。サブスク型であれば、こうした構築作業を省けるため、トータルコストの節約にも大きく貢献するでしょう。

ETLツールを活用する2つのデメリット

ETLツールには、以下のデメリットもあります。

• ある程度のITリテラシーを必要とする
• 導入するコストがかかる

ある程度のITリテラシーを必要とする

ETLツールは、データベース等の専門的な知識が不要なものの、ツールを使いこなすためのITリテラシーが求められます。 そのため、パソコンを全く扱えない人や、普段からITシステムに触れていない人には利用が難しいでしょう。

導入するコストがかかる

ETLツールには、当然ながら導入費用が発生します。ETLツールの利用形態にもよりますが、サブスク型であれば月額数万円以上のコストが発生するとみていた方が良いでしょう。そのため、コストに見合う導入効果が期待できるかを見極める必要があります。

ETLツールを活用すべき企業の特徴

ETLツールを活用すべき企業の特徴には、主に以下の2つがあげられます。

• 社内データを活用することができていない企業
• データが多すぎて整理できていない企業

社内データを活用することができていない企業

「社内のデータはあるけど、活用するための基盤作りまで進んでいない」といった、社内データの活用ができていない企業にETLツールは向いています。社内データの活用には、データ基盤を構築する必要がありますが、その作業に充てるリソースが足りないことで進められていないケースが多くみられます。

そこで、ETLツールで導入コストを下げることにより、データ基盤の構築をスムーズに実施し、データ活用するための準備を進められるでしょう。

データが多すぎて整理できていない企業

社内データがさまざまな場所に格納されており、整理できていない企業にもETLツールの導入がおすすめです。近年、利用するシステム数の増加に伴い、企業で扱うデータも増えています。そのため、人の手で全てのデータを統合的に管理していくのが難しくなっているのです。

ETLツールの導入は、手動での管理と比べて圧倒的に工数を削減できます。さらに、ヒューマンエラーも防止できるため、障害時の対応コストも減らせるでしょう。

組織内のデータがサイロ化して整理できていないという企業にとっては、ETLツールは救世主になり得るツールだと言えます。

【失敗しない】ETLツールの選び方を紹介

ETLツールを選ぶときには、以下5つのポイントが大切です。

1. 導入コストが見合っているか
2. 専門知識を必要としないか
3. GUIが洗練されているか
4. 技術的なサポートの有無
5. SaaSへの対応をしているか

導入コストが見合っているか

ツールの導入時には、費用対効果が高いかどうかの判断が重要です。なぜなら、導入をしても使われないツールでは費用が無駄になってしまうためです。

導入コストは、「買い切り型」か「サブスク型」で大きく変わってきます。前述した通り、サブスク型の方が柔軟に導入を進めていけるため、導入後が不安な場合にはサブスク型がおすすめです。

専門知識を必要としないか

メリットの中で専門的な知識が不要と記載しましたが、ETLツールの中にはSQLやデータベースの知識を必要としているものも存在します。そのため、できる限りGUI上で直感的に操作できるツールを選択しましょう。また、データソースへの接続数や連携先へのテンプレートの有無なども確認しておくと安心です。

GUIが洗練されているか

ETLツールはGUI上でデータフローの作成を実施するため、できるだけ洗練された直感的に使えるGUIがおすすめです。ツールの中には、GUIがわかりにくいため、ユーザーに使われないシステムになってしまう可能性があります。多くのETLツールにはトライアル期間が設けられているため、その期間内に操作感を見極めるのも重要です。

技術的なサポートの有無

ETLツールでの実装は、直感的に操作ができたとしても、使い始めや開発時に悩むケースが多いです。そのため、サポート対応が優れているツールの選定が良いでしょう。特に、技術的なサポート体制が手厚くなっているツールを選択するのが効果的です。ETLツールは外国企業が提供しているものも多いですが、そういった点では国産のETLツールを選ぶと安心でしょう。

SaaSへの対応をしているか

SaaS形式のETLツールを選択することで、自社内の環境構築が不要になり、その後のアップデート作業も提供業者に任せられて運用にかかる工数を減らせます。また、ハードウェアの故障によるシステム停止がないため、可用性の向上にも期待できます。

ETLツールを導入した成功事例を紹介

実際に、以下の3社ではETLツールの導入に成功しました。

• kintoneデータの自動連携により、業務効率化を実現
• プロダクトの質・業務効率を高めたデータ基盤
• データ連携処理にかかっていた時間を約40%削減

それぞれの事例を紹介しましょう。

kintoneデータの自動連携により、業務効率化を実現

株式会社サンプロシードでは、kintoneデータとELTツールを連携させることで、Excelによる属人的な管理からkintone内での統合的な管理を実現させました。

導入前は、個人ごとにExcelシートで管理しており、同じデータを二重で管理しているケースが多くみられました。導入後は、kintone上でデータの管理が可能となったため、二重管理の排除や素早いデータ確認によって業務効率化につながったのです。

（参考：kintoneデータの自動連携により、業務効率化を実現 ～スリーシェイクとの二人三脚で更なるデータ活用へ～）

プロダクトの質・業務効率を高めたデータ基盤

BRANU株式会社では、ETLツールの導入によってリアルタイムなデータ解析が可能となりました。その結果、マーケティング業務が効率化され、プロダクトの質も向上したのです。

導入当時は、データ活用の重要性を理解していたものの、データ基盤の構築を社内で実現するのが難しい状況でした。そこで、ETLツールの導入により、サイロ化されたデータを一元管理できるようになってリアルタイムな解析も実現できたのです。

（参考：プロダクトの質・業務効率を高めたデータ基盤。まさか新サービス創出まで実現するとは思いませんでした。）

データ連携処理にかかっていた時間を約40%削減

auコマース＆ライフ株式会社では、これまで多くの工数をかけていたデータ連携の処理が、ETLツールの導入によって約40%も作業工数を削減することができました。

導入前は、外注で開発したデータ連携の仕組みを活用していました。しかし、週に数回のエラーによって毎回数時間のリカバリー処理が必要とされていたのです。

導入後は、データ連携にかかる処理時間の短縮や、エラーの発生回数がゼロになり、処理にかける工数を大幅に削減できました。

（参考：独自開発のオンプレETLをReckonerに移行しデータ連携エラーがゼロに。データ連携処理にかかっていた時間を約40%削減）

ETLツール「Reckoner」は無料トライアルを受付中！

本記事では、データ連携を効率的に実施できるETLツールについて解説しました。

ETLツールは、データソースへの接続から大規模データベースへの格納までをサポートしています。多くのツールは、直感的な操作でデータフローの構築を実現できるため、今までよりもデータ連携にかけていた工数を大幅に削減できます。

しかし、実際にETLツールを導入しようと思っても、どのツールを選ぶべきか悩む方も多いでしょう。

そこでおすすめしたいのが「Reckoner」です。Reckonerはプログラム不要、GUI上で全てを完結できるため、データフローの構築をスムーズに実現できます。さらに、SaaSでの提供となるため、インフラ構築が不要でサーバー等の管理も必要ありません。

現在Reckonerでは無料トライアルを受け付けているため、これからETLツールを活用してデータ基盤の構築を検討している企業様はぜひご利用ください。

The post ETLツールとは？成功事例や選び方のポイント、メリットについて解説！ first appeared on Reckoner.

そして、収集と分析で用いるデータは、「即利用可能なデータ（見たい切り口のデータが日々更新される）」もあれば、「収集した後に、時間をかけて編集した後、分析できるデータ」もあるかと思います。

そんな企画職の方々が、データの収集と分析をどう効率化するかについて、ETLというキーワードを踏まえてお伝えします。

目次

• 企画職はエンジニアでない、故にETLが有効

• プログラミングなしでデータ取得ワークフローを作成
  • (1)ETLを導入
  • (2)ETLに各種データソースを連携
  • (3)ETL上で処理内容を入力し処理

• ETLを利用して行える具体的な処理

• 情報システム部門から見たETLの価値と注意点

• 情報システム部依存、マクロ依存からの脱却を

企画職はエンジニアでない、故にETLが有効

まずは、大前提としてですが、企画職スタッフの多くはエンジニアではありません。Excelや分析ツールを使うことには精通していますが、データの裏側にあるデータベースやデータウェアハウス (DWH) 、データレイクについては深い知識があるわけではありません。

また、営業職やマーケティング職、サポート職が利用するツールについてもある程度の理解がありますが、各ツールがどのようにデータを処理しているかについても、情報システム部門のエンジニア程度の理解は持っていません。

企画職の主たる業務は、「データを分析したうえで、戦略・戦術などを立案、そして担当部門を巻き込んで行う活動をリードする」ことです。餅は餅屋ですので、企画職がエンジニアと同程度の理解を持つ必要はありません。

しかし、企画担当者が、普段とは異なるデータ取得を行おうとするたびに、情報システム部のデータ基盤担当者に対して「このようなデータが欲しい」と依頼するのは、「依頼するほうも、依頼されるほうも、工数がかかる」「依頼からデータ取得までに時間がかかる」というデメリットが生じます。

これを乗り越えるのがETLです。ETLを用いると、社内で稼働しているデータベース、データウェアハウス、SFA、CRM、MAといったツール群に対して、GUIを経由してデータの取得、変換、ロードが行えます。つまり、企画職スタッフが、情報システム部門に都度依頼しなくても、データ分析用のデータを準備できるようになります。

プログラミングなしでデータ取得ワークフローを作成

ETLといっても、「プログラミングが必要な製品」もあれば、当社ETLのReckonerのように「プログラミング不要の製品」もあります。ここでは、当社Reckonerを例に、プログラミング不要でデータ取得ワークフローを作成する流れについてご紹介します。

(1)ETLを導入

現在、操作性の高いETLの多くはクラウドサービス (SaaS) として提供されています。このため、ETL製品のトライアル利用を申し込むのが最初のアクションとなります。

(2)ETLに各種データソースを連携

ETL製品上のGUIで、必要情報を入力すればすぐにデータ処理を開始できます。対応しているデータソースはETLごとに異なりますが、当社ETLのReckonerを例にご紹介すると、AWSやGCP上で動作するデータベース、データウェアハウスなどのサービス、SalesforceやKintone、hubstotといったSFA/CRM/MAプラットフォーム、Googleアナリティクスなどの分析ツールなど、多様なツールがカバーされています。

上記(1)と(2)は、情報システム部門と連携して、最初に行っておく処理となります。

(3)ETL上で処理内容を入力し処理

上記(1)(2)で設定を完了させておくと、企画職の担当者が必要なタイミングで、誰か別の人に依頼せずに、自身のみでデータ抽出・変換・ロードが完了できます。

例えば、「データウェアハウスA」にあるデータ項目を、ETL上で変換処理を行ったうえで、Excelにエクスポートする、といった処理内容を、SQL文を書かずに処理することが可能です。

企画職の観点からは、「誰かに依頼する工数が不要」「依頼ならび別部門担当者の作業完了待ちが不要のため、迅速にデータを入手できる」「手戻りが生じた場合も、自分ですぐに再度処理できる」といったメリットがあります。

ETLを利用して行える具体的な処理

ETLを利用すると、以下のような処理をプログラミングなしで行えるようになります。

• 指定したフィールドを取得
• 2つのフィールドを1つに結合
• 指定されたフィールドをCSVでパースする
• 指定フィールドをハッシュ化する
• 日付フォーマットを変更する
• 指定フィールドがnullのものだけを抽出する
• 指定したフィールドの型変更、削除、名前変更を行う、など

単にデータを取得するだけでなく、結合や変換といった処理まで、プログラミングなしで実施できる点が大きなメリットです。

「これまでExcelマクロでこれらを実現してきた」という担当者もいるかと思いますが、Excelマクロは属人的でブラックボックス化しがちな方法で、複雑化すると「作成者しかマクロの中身が分からない」、いわゆるお化けExcelマクロとなってしまいます。ETLを利用することで、処理の属人化を防げます。

情報システム部門から見たETLの価値と注意点

ここまで、企画職がETLを利用するメリットをお伝えしてきましたが、実は「企画職にETL利用を許可する」側の情報システム部門にとってもメリットがあります。

まずは、「データが欲しい人が自分でデータを抽出・加工できる」ため、依頼があるたびに情報システム部門担当者の手を煩わせる必要がなく、工数の削減につながります。また、「昨日依頼したデータ処理の件、まだでしょうか」といった処理の催促をされることもなくなるため、担当者のストレス軽減にも寄与します。

情報システム部担当者がETLを利用するという前提で、最も注意が必要な点は「アクセス権」です。例えば、「自社の財務情報」「自社の既契約情報」「社員の給与情報」「人事評価情報」「キャンペーン登録者の個人情報」といったデータへのアクセスを無制限に認めるわけにはいきません。このため、「どのデータソースに、誰（またはどの部門の、どの職位の担当者）がアクセスしてよいか」を綿密に計画しなければなりません。

また、データは「戦略・戦術立案のための分析用として利用するデータか」「キャンペーンで実際に利用する個人情報全て含んだデータか」により、扱いが異なってきます。

よって、「データを積極的に活用して質の高い意思決定を支援する」というスタンスは崩さずに、かつ、「守るべきところは確実に守り、データ漏えいを引き起こさない」ための体制づくりが重要となります。

情報システム部依存、マクロ依存からの脱却を

企画職がデータ分析を行う際に、都度他部門の協力を得て、処理を行ってもらうのではなく、また自分でExcelマクロのブラックボックスを作るでもない方法を、ETLなら実現できます。

ETL利用で、企画部担当者は「依頼工数の削減」「即時のデータ入手」「処理プロセスの透明化」が実現でき、情報システム部担当者は「アドホックのデータ処理工数削減」「処理を急がせられるストレス軽減」が達成できます。

まずは、当社ETLであるReckonerをお試しいただき、ETLがもたらす価値を体感ください。現在、14日間無料でご提供しております。

ETLツールについて詳しく知りたい、ETLツールの選び方を知りたいという方はこちらの「ETLツールとは？選び方やメリットを解説」をぜひご覧ください。

The post 【企画職向け】ETLツールを使ったデータ変換で業務効率化 first appeared on Reckoner.

ここでは、iPaaS EAI ETL/ELT RPA と言ったデータ連携や活用の文脈でよく出てくるワードについて、大枠を掴んでもらい、自分が抱えている課題に対してどのカテゴリに属するサービスを選ぶのが適切なのか、判断する材料になることを目指します。

そもそも、「iPaaS EAI ETL/ELT RPAの各ワードの意味が曖昧だ」という方にも分かりやすく解説しているので、そういった方も最後までお付き合いください。

目次

• iPaaS = EAIやETL/ELTを指す
  • ETL/ELTサービスの呼び方

• ユースケースごとに知るiPaaS群とRPA
  • 様々なデータを統合して活用する
  • 様々なアプリケーション・ネットワーク・システムのデータを連携する
  • PCで手作業で行っている繰り返し作業を自動化する

• 目的にあったiPaaSを選ぶ

iPaaS = EAIやETL/ELTを指す

iPaaSは「Integration Platform As A Service」の略で、オンプレミス及びクラウドの様々なデータを連携でき、実行や管理ができるサービスのことを指します。「部署によって異なるシステムを利用している」「グループ間でオンプレミスとクラウド環境のどちらも利用している」など、企業によって状況は様々です。こういったデータの垣根を無くす為の橋渡し的な存在がiPaaSということになります。

EAI、ETL/ELT などのサービスは、上記の定義に当てはまるためiPaaSであると言えます。以下でEAI、ETL/ELTについて簡単に解説しておきます。

EAI（Enterprise Application Integration）は「社内アプリケーションの統合」という意味を持つ、データを統合する技術、またはその仕組みを指します。EAIの特徴は「リアルタイム」と「高速」での連携であり、イベント志向のデータ連携に向いている技術と言えます。在庫管理や受発注データ、マスタデータといった、常にデータの整合性を保つ必要があるデータの連携処理に使用されます

ETL（Extract Transform Load）は、データベースなどに格納されているデータを「Extract（抽出）」、用途に合わせて必要の形式に「Transform（変換・加工）」、データを「Load（格納）」するという機能、またはその工程を指します。ELT（Extract Load Transform）は文字からもわかる通り、ETLとはLoad（格納）するタイミングが異なる技術です（最終的な目的は同じ）。企業のシステムに蓄積されているデータを、ETLやELTを使用してBI（ビジネスインテリジェンス）で分析するといったケースに用いられます。

また、いわゆるレシピ型と言われる、IFTTT（イフト）やZapier（ザピアー）のようなWebサービス間やIoT機器を連動させるサービスもiPaaSです。レシピ型の連携サービスの使用例として、「SlackとDropboxを連携させてデータ共有をスムーズにする」「Googleスプレッドシートとタスク管理ツールを連携させて管理する」などの使い方ができます。

RPAは若干毛色が異なり、PCで行っている毎回同じことを繰り返すような定型的な業務を自動化することを目的としています。

ETL/ELTサービスの呼び方

先程の説明でETL/ELTサービスはiPaaSであると書きましたが、実際ETL/ELTの各社は自分たちのサービスのことをETLであったり、データパイプラインと呼ぶことも多いです。
ETL/ELTに限らず、それぞれのサービスが広義のiPaaSには含められるものの、実際は自分たちのサービスをiPaaSとは呼ばず、別の呼称を使っていることもよくあるので、そんなときはここのカテゴリ分けを思い出して混乱しないようにしましょう。

ユースケースごとに知るiPaaS群とRPA

ここからは、最適なデータ連携サービスを選ぶために、ユースケースごとに違いを見ていきます。

様々なデータを統合して活用する

これはETL/ELTが実現します。

特徴として、全レコードもしくは抽出してまとめた単位・大データ単位で、バッチ処理的であることが挙げられます。

これは日々生成される大量のデータの活用に主軸を置き、様々な場所にあるデータを収集し、加工してからDWH（データウェアハウス）のような大容量ストレージにデータを転送するような処理に最適です。

企業には、活用しきれていないが、活用すればビジネスの意思決定に大きな影響を及ぼすようなデータがたくさんあるはずです。その一つ一つのデータをつなげて集約し、活用しやすいようにまとめ上げるのがETL/ELTの役割です。

データウェアハウスにまとめられたデータは、可視化や機械学習、データマートの作成といった各種分析用途に用いられることが多いです。

また、既知のことかもしれませんが、ETL/ELTはクラウドが主流となっています。

クラウドサービスであれば、物理的なハードウェアが不要で「ハード調達コストもハードの破損によるメンテナンスコスト」「保管にかかるコスト」が全て不要です。

データソース側での修正対応もクラウドサービス提供者が行なってくれるため、変更対応にかかるコストも削減できます。そしてオンプレミスのように「調達したハードウェア性能＝処理性能」ではないため、より迅速な処理が可能（クラウドサービスや費用にもよって異なります）です。

様々なアプリケーション・ネットワーク・システムのデータを連携する

これはEAI・レシピ型が実現します。
特徴として、1レコード単位・少データ単位で、イベントドリブンであることが挙げられます。

これはリアルタイムのデータ連携に主軸を置き、複数のアプリケーション・ネットワーク・システムを繋ぐ用途に最適です。

各拠点のデータを集約して最新の在庫情報をチェックしたり、受注・発注のシステムと、会計や生産管理といったシステム、BIツールをそれぞれ連携させつつ、今後の受注予測や会計管理を可視化したりなど、リアルタイム性が求められる連携に最適です。

在庫管理、生産管理、受注管理、会計管理など、それぞれ独立したシステム間の連携は手動で行われていることもあり、自動でデータ連携させることによる効果は絶大です。データの入力コストは無くなり、手動で入力していたことによる人的ミスも起こらなくなります。

PCで手作業で行っている繰り返し作業を自動化する

これはRPAが実現します。
RPAは作業者がPC上で行っている操作を完全に再現して、作業を行うロボットのようなソフトウェアです。定常的に発生する入力業務や、ある資料の文章を別の資料にコピーアンドペーストしたり、メールで来た添付ファイルをExcelに貼り付けて資料を作成するなど、毎回全く同じ作業を行っており、自動化したいような定常業務に最適です。自動化可能なポイントは作業手順が毎回同じで形式化でき、PC上で完結する作業であることです。

目的にあったiPaaSを選ぶ

以上、本記事ではiPaaSについてお伝えしました。
重要なのは、用語の違いを正しく理解をした上で、目的に合致したツールを選択することです。そうすることで、手戻りによって浪費する時間や無駄な工数を減らすことができます。

当社ではクラウド型ETLツール「Reckoner」を提供し、お客様の大規模なデータ処理をクラウドサービスとしてご提供、ご支援しています。

手動によるデータ修正作業や、独自開発のデータ統合ツール、オンプレミスのデータ統合ツールをご利用のお客様は、ぜひお試しください。

ETLツールについて詳しく知りたい、ETLツールの選び方を知りたいという方はこちらの「ETLツールとは？選び方やメリットを解説」をぜひご覧ください。

The post iPaaS EAI ETL/ELT RPA それぞれの違いをユースケースごとに知り、適切なサービスを選ぶ first appeared on Reckoner.

以下では、入出金管理をETLを利用して自動化すべき5つの理由についてお伝えした上で、具体的にどのように自動化するかについてご紹介いたします。

目次

• なぜ「半自動処理」をやめてETLを利用すべきか
  • (1)保守性の低下
  • (2)担当者への業務負荷
  • (3)処理速度・安定性
  • (4)データ登録から共有までの速度
  • (5)担当者の退職など

• ETLで行われる処理はどのようなものか
  • データの抽出
  • データの変換　
  • データのロード

• ETLで5つの課題を解決

なぜ「半自動処理」をやめてETLを利用すべきか

では、早速「半自動処理をやめてETLを利用すべき5つの理由」をご紹介します。

(1)保守性の低下

Excelマクロの多くは、組織的にメンテナンスされておらず、Excelが得意な担当者が作り上げたものを「秘伝のタレ」のように、改修を繰り返して使われている場合が大半です。

つまり、Excelマクロはブラックボックス化されており、そのマクロの中を完全に理解しているのは、作った本人しかいません。これは会社業務の保守性という観点からは大きな問題となります。以下の(2)についても、ブラックボックス化による保守性の低下がその原因です。

(2)担当者への業務負荷

連携先のシステム変更やバージョンアップ、税率変更などが相次ぐと、半自動システムの担当者が処理を変更しなければならなくなります。きちんとシステム化されていない処理の場合、処理の変更対応を行う担当者はごく少数（多くの場合1名）であるため、担当者に負荷が集中することになります。

結果、担当者が長時間労働を強いられることになり、担当者の健康を損なうことになったり、担当者の就労環境に対する不満を高めることになります。

(3)処理速度・安定性

Excelマクロの処理速度は、「処理の複雑性」「Excelというアプリケーションの限界」ならび「Excelマクロを立ち上げている物理PC/サーバースペック」に依存します。処理件数が多くない、または処理が複雑でない場合は、短時間で処理は完了できますが、数千件、数万件、数十万件というように処理件数が増加すると、処理完了までに長い時間がかかります。担当者のPC上でこうした処理を行っている場合は、処理完了まで担当者はPCでの作業が行えなくなります。

また、処理件数が著しく多い、処理が重いといった条件が重なると、Excelマクロが正しく動作せずに異常終了する場合もあります。この場合は、ファイルを細かく分けて、処理を最初からやり直すといった手間が生じます。

(4)データ登録から共有までの速度

取引データを基幹システムだけではなく、他のシステムから確認したい場合についてです。Excelマクロでのデータ登録は、「経理会計の基幹システム」にのみ行われるのが一般的です。そして、基幹システムに登録されたデータを、日時バッチなどで出力して社内で共有されます。

つまり、最新データを見たいと思っても、確認できるようになるには「基幹システムへのデータ登録」「基幹システムからのバッチ出力タイミング」を待たねばならず、時間がかかります。

(5)担当者の退職など

Excelマクロ等を利用して経理の半自動処理を実現した担当者は、会社の経理業務に貢献した従業員といえます。しかし、これは同時にリスクも背負い込んでしまいます。

半自動処理の担当者が退職する場合、円満退職であれば正しく引き継ぎが行われ、Excelマクロの中身に関しても正しい説明が行われます。しかし、円満退職でない場合は、引き継ぎなしで退職ということもありえます。この場合、「当面の業務は回るが、システム変更や税率の変更などがあると、変更に対応できない」という事態が発生します。

さらに悪いケースとしては、担当者が退社時に「最新のExcelマクロを会社に残さず、全て引き上げてしまう」ことです。業務時間内に作成したExcelマクロであれば、当然会社に所有権がありますが、権利を主張して争っていても、その間、経理処理は止まってしまいます。

また、担当者の退職以外にも「担当者が急逝してしまい処理に関して何も引き継がれない」という問題や、「担当者が『自分が会社の処理を回している』と増長しトラブルを引き起こす」といった問題もあります。

ETLで行われる処理はどのようなものか

次に、ETLで何を行うかについてです。ETLは「抽出したデータを、出力先システムに適合するように変換した上で、ロードする」処理を一元的に行います。

「半自動処理」を行っていた場合は、各決済サイトで決済情報をダウンロードし、これをExcelマクロで処理を行い、最終的には手動で各出力先にロードする（インポートする）というやり方でした。

ETLを利用すると、以下のようになります。

データの抽出

各決済企業からデータを取得する方法は、データの提供方法により自動化できる場合と、自動化出来ない場合があります。

例えば、「データ取得方法は、『ウェブサイトから期間を指定してCSVファイルをダウンロード』のみ」という場合は、そのままでは自動化できないため、自動化するためには「RPAを利用する」など追加の方法が必要となります。

データの変換

データを取得後の処理は、ExcelマクロとETLで大きく異なります。ETLがデータを抽出し、あらかじめ定められた処理に基づきデータを処理します。Excelマクロと大きく違う点は、「データをどのように処理するか」がETL上で分かりやすく可視化されているため、ブラックボックス化が起こりにくいことです。

このため、担当者が処理を抱え込むことが発生しにくくなると同時に、将来必要な変更が生じても「処理の全体像を把握しやすく、修正も行いやすい」点が利点です。

また、当社のETL製品「Reckoner」のように、処理をクラウド上で行っている場合は、「億単位のデータ処理」が可能です。クラウドの膨大なリソースを利用して、Excelマクロと比べて高速かつ安定した処理が可能となります。データ処理中に担当者のPCリソースを消費することはないため、担当者はデータ処理中に別な業務を並行して行えるため、効率的に時間を使えます。

データのロード

Excelマクロでデータを変換した後のデータ登録処理は、会計や経理の基幹システムに対してのみ実施するのが一般的です。これに対してETLでは、複数の出力先に対して別々なデータフォーマットでのデータ出力が可能です。

これにより、「他システムを利用する従業員が、必要なデータをよりリアルタイムで入手」しやすくなり、「鮮度の高いデータをもとにした意思決定」が促進されます。

ETLで5つの課題を解決

出入金管理は、その業務の特殊性から特定の事務スタッフが長期間担当する場合が多いです。このため、「任せられるスタッフ」に長期間任せっきりにしていた結果、ブラックボックス化による問題が多数生じることになります。

ブラックボックス化を防ぎ、処理内容を誰でも見ることができ、かつ別な人が代替できる処理を行うには、ETLの利用が最も望ましいといえます。もし、Excelマクロのような「属人的な半自動処理」を行っている場合は、ぜひETLをご検討ください。

当社ELTの「Reckoner」は、クラウドネイティブのETLであり、プログラミング不要で非エンジニアの方でもご利用頂くことが可能です。

ぜひ、Reckonerの資料をダウンロードいただき、ご検討ください。

ETLツールについて詳しく知りたい、ETLツールの選び方を知りたいという方はこちらの「ETLツールとは？選び方やメリットを解説」をぜひご覧ください。

The post 【経理部門向け】入出金管理でETLを利用すべき5つの理由 first appeared on Reckoner.