――ご自身はどのような役割・業務を担当していますか？

インフラエンジニアとして、社内のサーバーの保守・運用・構築など、インフラ全般を担当しています。
もともとデータ連携基盤の運用は別の担当者が担っていたのですが、組織体制の変更により、私が引き継ぐことになりました。そのため、現在は本来のインフラ業務に加えて、ETLツールやデータ連携基盤の運用・移行も担当しています。

――Reckoner導入前はどのような課題がありましたか？

以前は、「kintone」や「請求管理ロボ」のデータを取得し、経理業務向けCSVを作成するためのデータ連携基盤を運用していました。その環境は情報システム部の担当者が中心となって構築・運用していましたが、組織体制の変更を機に、見直しを進めることになりました。

しかし、実際に引き継いでみると、運用環境には長大なSQLによる処理が複数存在し、既存環境の保守や運用にはエンジニアリングの知識が必要でした。また、管理負荷も高く、「導入当時とは環境が異なり、現在のフェーズでは運用しやすい環境とは言えない」と感じました。
費用面でも、毎月多額のランニングコストが発生していました。
そこで、より運用しやすく、コストも抑えられる移行先のETLツールを検討することになりました。

複数製品を比較した結果、Reckonerを選定

――Reckonerを知ったきっかけを教えてください。

当初は、DWHを活用したデータ基盤の構築を検討していました。ただ、調査を進める中で、まずは各システムからデータを集約するためのETLツールが必要だと分かり、ETLツールの選定から着手することになりました。

公開情報や製品資料を参照しながら情報収集を行い、「Reckoner」を含む複数のETLツールを比較検討しました。その後、各社との打ち合わせを重ねながら、自社の要件に合う製品を選定していきました。

――Reckonerを選んだ決め手は何でしたか？

「請求管理ロボ」のデータをAPI経由で取得することが要件の一つだったのですが、ある製品はHTTP API連携に追加費用が発生するうえ、専用コネクターも用意されていませんでした。また、別の製品は要件自体は満たせるものの、「kintone」や「請求管理ロボ」といったSaaS連携よりもデータベース連携を得意としており、コスト面でもやや高い印象がありました。

その点、「Reckoner」はHTTPコネクターが標準で利用できました。
また、実際に触ってみると、画面が非常に分かりやすく、直感的に操作できる点も魅力でした。ワークフローをビジュアルベースで構築できるため、専門的な知識がなくても全体像を把握しやすく、非エンジニアでも運用しやすいと感じました。
この使いやすさも「Reckoner」を選定した大きな理由の一つです。

「まずはDWH」が覆った、Reckonerによる要件実現

――当初はDWH構築を検討されていたとのことですが、最終的に不要と判断された経緯を教えてください。

当初は、DWHを活用したデータ基盤の構築を検討していました。ただ、その時点ではETLツールやDWHに関する知識が十分にあったわけではなく、「まずはDWHにデータを集約する必要があるだろう」と考えていました。

その後、「Reckoner」の担当者から、「Reckoner」単体でもデータの加工・整形まで対応できることを伺い、改めて既存環境で行っている処理を見直しました。
その結果、対象業務については「Reckoner」のワークフローで十分に実現できることが分かり、当初想定していたDWH構築を行わずに要件を満たせるという結論に至りました。

結果として、対象業務では「Reckoner」で必要なデータ連携と加工を実現でき、DWHを導入することなく目的を達成することができました。

――どのようなワークフローを構築されたのですか？

現在、合計4本のワークフローを構築しています。

まず2本は、「kintone」の複数アプリのデータを組み合わせ、フィールド変換や日付変換などを行ったうえでCSVを生成するワークフローです。これまで利用していたシステムで出力していたものと同じ内容のCSVを作成しており、経理業務で利用する3種類のCSVを自動生成しています。

残りの2本は「Amazon S3」へのデータ連携用です。1本は「kintone」のデータをそのまま「Amazon S3」へ格納するもので、もう1本は「請求管理ロボ」のデータをHTTP API経由で取得し、必要なデータ加工や結合処理を行ったうえで「Amazon S3」へ格納するものになっています。

経理業務の自動化から、全社データ活用へ

――導入後、どのような効果がありましたか？

まずは、経理担当者が行っていた手作業を削減できました。

以前は、「請求管理ロボ」へログインして複数のCSVをダウンロードし、それを別システムへ取り込む作業を毎月行っていました。
現在は「Reckoner」のスケジュール実行機能を活用し、必要なデータが自動的に所定の保存先へ連携されるため、ログインやダウンロード、取り込みといった作業が不要になりました。現在は一部の業務で先行して運用を切り替えていますが、経理担当者からは「楽になった」という声も上がっています。

加えて、従来利用していた環境をリプレースできたことで、運用負荷の軽減だけでなく、コスト削減にもつながっています。

――今後の活用についてどのようにお考えですか？

現在は経理業務向けのデータ連携を中心に活用していますが、今後は全社的なデータ活用のための基盤整備への展開も検討していきたいと考えています。

当社では、営業やマーケティング、カスタマーサクセスなど各部門で利用するデータが複数システムに分散しており、分析の効率化が課題となっています。AI活用やDXを進めていくためにも、まずはデータを一元的に集約できる基盤が必要だと考えています。

その中で、「Reckoner」には各システムのデータを集約するためのパイプラインとしての役割を期待しています。今後検討するデータ基盤とも連携しながら、部門横断でデータを活用できる環境づくりを進めていきたいと思っています。

――お忙しい中、貴重なお話をお聞かせいただきありがとうございました。

※本インタビューは2026年6月に実施

The post 「DWHなしで実現できた」多額の保守費と手作業から脱却。3社比較でReckonerを選んだ理由 first appeared on Reckoner.

――ご自身はどのような役割・業務を担当していますか？

私は現在、人事部に所属し、人事企画やDX推進を担当しています。
もともとはITエンジニアとしてキャリアをスタートし、その後、ITコンサルタント、人事コンサルタントを経験してきました。とくにタレントマネジメントシステムをはじめとする人事システム領域には20年以上携わっています。
現在の人事部は約30名体制で、採用、給与厚生など、各業務領域を担当する複数のチームで構成されています。私自身は特定の業務領域を担当するというよりも、人事部門全体を横断しながら、人事企画やシステム化、DX推進を担う立場です。
3年後、5年後を見据えながら、人事としてどのような取り組みを進めるべきかを考え、人事システムの企画や活用推進に取り組んでいます。

――Reckoner導入前はどのような課題がありましたか？

私が入社した当時、人事システム全体で複数のシステムのリプレースが必要な状況でした。サービス終了が予定されているものもあり、人事システム全体を今後どのような構成にしていくべきかを改めて検討する必要がありました。
その際、私としては1つのオールインワン型システムに集約するのではなく、それぞれの領域に強みを持つサービスを組み合わせて活用する方針を考えていました。
一方で、複数のシステムを組み合わせる場合、必ず課題になるのがデータ連携です。人事システムの将来像を検討する中で、「システム間のデータをどうつなぐか」が大きなテーマになりました。

「人事部門が主体的に運用できること」を重視したツール選定

――Reckonerを検討されたきっかけを教えてください。

実は社内にはすでに別のETLツールが導入されていました。
そのため当初は、「既存のツールを活用できないだろうか」と考えていました。ただ、そのツールの設定や運用はシステム部門で管理されており、人事部門が主体的に活用できる環境ではありませんでした。

人事部門として利用することはできても、設定変更や連携内容の追加を柔軟に行える状況ではなかったため、「人事部門で活用するデータ連携基盤として本当に適しているのか」という課題を感じていました。

――なぜ「自分たちで運用できること」を重視されたのでしょうか？

人事システムの刷新は、一度にすべてを入れ替えられるものではありません。
例えば、評価システムとして「カオナビ」を導入し、その後に手続き領域で「SmartHR」を導入するといったように、数年単位で段階的に進めていくことになります。そうすると、その都度新しいデータ連携が必要になったり、「この項目も連携したい」といった要望が発生します。

また、実際に運用が始まると、「カオナビ」側で管理したい情報が増えることもあります。そうした変更に対応するたびに他部門へ依頼する形では、どうしてもスピードや柔軟性に限界があります。そのため、人事部門自身が構築内容を理解し、必要に応じて対応できる環境が重要だと考えていました。

――Reckonerを選んだ決め手は何でしたか？

実際にさまざまなツールを検討しましたが、将来的な運用まで考えると、特定の担当者だけでなく、人事部門の他のメンバーも継続的に運用できることが重要だと考えていました。
その点、Reckonerは画面上で処理内容を把握しやすく、設定や運用のイメージも持ちやすかったため、人事部門でも主体的に運用していけると感じました。

「カオナビ」×「COMPANY」で、人事データの精度・鮮度向上と運用負荷の軽減を実現

――どのような連携フローを構築されたのですか？

現在メインで運用しているのは、人事管理システム「COMPANY」に登録されている各種人事情報を、タレントマネジメントシステム「カオナビ」へ連携するワークフローです。

連携しているのは、従業員の基本情報や異動情報など、人事管理システムで管理しているデータのうち、「カオナビ」で活用したい情報のほぼ全てです。
「COMPANY」で更新された最新情報を日次で取り込み、「カオナビ」上でも常に最新の状態を維持できるようにしています。

また、勤怠管理システムの利用者情報を月1回自動で取得し、Boxへ出力する仕組みも構築しました。

――導入後、どのような効果がありましたか？

まず大きいのは、人事データを漏れなく、鮮度の高い状態で連携できるようになったことです。

人事領域では、入社・退職・異動といった情報が日々発生します。とくにタレントマネジメントシステムでは、情報の精度と鮮度が非常に重要です。せっかくシステムを導入しても、データが更新されていなければ利用者から信頼されなくなってしまいます。その点、Reckonerによって毎日自動でデータを反映できるようになり、常に最新の状態を維持できるようになりました。

また、従来は「COMPANY」からデータを手動出力し、加工して「カオナビ」へ取り込み、エラーが発生すれば修正して再度インポートするといった作業が必要でした。現在はこうした処理を自動化できており、手作業による負荷は大きく軽減されています。

組織改編への対応も改善しました。以前は異動や組織変更の反映に数日かかることもありましたが、現在は事前に新しい組織情報を登録しておけば、異動日に合わせて自動的に反映されます。運用負荷の軽減だけでなく、より正確な組織情報をタイムリーに反映できるようになりました。
さらに、人事データ活用についても、システム部門に依存することなく、人事部門主導で取り組みを進められるようになっています。

「SmartHR」との双方向連携へ。人事データ基盤をさらに拡張

――今後の活用についてどのようにお考えですか？

現在は、「COMPANY」から「カオナビ」へのデータ連携が中心ですが、今後は「SmartHR」との連携をさらに拡張していきたいと考えています。具体的には、従業員が「SmartHR」上で住所変更や通勤経路変更などを申請した際、その情報を人事システムへ反映する仕組みの構築を予定しています。
また、それ以外にも連携したいシステムは数多くあります。例えば研修管理システムや勤怠管理システムなど、人事領域で利用している各種システムとの連携も進めていきたいと考えています。

基本的には、「つなげられるものはつなげたい」という考えです。今後も必要に応じてワークフローを追加しながら、人事業務におけるデータ連携の仕組みを拡張していきたいと思っています。

――お忙しい中、貴重なお話をお聞かせいただきありがとうございました。

※本インタビューは2026年5月に実施

The post 「カオナビ」×「COMPANY」をつなぎ、人事部門主導のデータ連携基盤を構築─ 人事データの精度・鮮度向上と運用負荷の軽減を実現 first appeared on Reckoner.

――ご自身はどのような役割・業務を担当していますか？

ソリューションシステム部に所属しています。いわゆる情報システム部門にあたりますが、運用・保守に加えて、DX推進も含めた役割を担っています。
もともとは社内のシステム対応を中心とした体制でしたが、経営方針の転換によりDX領域への取り組みが進み、組織としても拡大しています。現在は11名規模の体制となっており、アプリケーションとインフラの2つの領域に分かれて対応しています。
業務としては、社内システムの運用・管理に加えて、データ活用やDXに関する企画立案なども行っています。

――Reckoner導入前はどのような課題がありましたか？

データ共通基盤の構築にあたり、社内に分散しているデータを集約し、利活用していきたいという背景がありました。
オンプレミスの基幹システムやSaaSなど、複数のシステムにデータが点在しており、それらをどのように統合して活用していくかが課題でした。

複数ツールを比較する中で問われた「実運用で成立するか」──最終的な決定打とは

――Reckonerを選んだ決め手は何でしたか？

複数のETLツールを比較検討する中で、オンプレミス環境とSaaSが混在する構成においても、既存環境を変更することなく連携できる点が最終的な決定打となりました。
基幹システムがオンプレミスで稼働している一方で、SaaSやクラウドサービスも併用しており、制約のある環境の中で現実的に運用可能な連携方式を構築できるかが重要なポイントとなっていました。
その中で、既存の構成や運用を前提としたまま、データ連携を実現できる点が評価され、最終的な選定に至りました。

また、オンプレミスに限らず、既存SaaSとの連携についても柔軟に検証を進めることができ、短期間で実運用を見据えた形の連携可否を確認できた点も、導入判断を後押ししました。
さらに、非エンジニアも含めてデータ活用ができる操作性や、日本語でのサポートが受けられる点、スモールスタートが可能で、利用規模に応じてコストを最適化できる柔軟なプラン設計も評価ポイントとなりました。

既存環境を維持したまま、短期間で実現した連携検証と構築

――導入プロセスについて教えてください。

今回のプロジェクトでは、オンプレミスの基幹システムとSaaSの両方を前提に、最終的にデータウェアハウスへデータを集約する構成を目指していました。
そのため、既存の業務フローやシステム構成に合わせて、無理なくデータ連携ができるかという点を重視して検証を進めました。とくにオンプレミス環境との連携については、Reckonerのオンプレエージェントを利用することで、既存環境を変更することなくスムーズに接続することができました。

また、ZendeskやSalesforceといった既存のSaaSについても、APIを活用した連携が可能だったため、早い段階から具体的な検証を進めることができました。トライアル環境を利用して早期に操作できたこともあり、実際の運用をイメージしながら検証を進めることができた点は大きかったと感じています。
結果として、期間としては長くはない中でも、必要な動作確認をしっかり行いながら導入を進めることができました。

――Reckonerを実際に触ってみての感想を教えてください。

基幹システムや各種SaaSのデータをデータウェアハウスに集約する必要がありましたが、コネクターやAPI連携が柔軟に用意されていたため、パイプラインの構築はスムーズに進めることができました。
また、UIも分かりやすく、慣れてくれば非エンジニアにもパイプラインを組み立てられると感じました。
データの変換や連携を直感的に構築できる点は、操作面においても大きなメリットです。

オンプレミス基幹・SaaSデータをDWHに集約し、データ活用基盤を確立

――どのようなワークフローを構築されたのですか？

大きく3つのワークフローを構築しています。

まず1点目は、基幹システムからのデータ連携です。
オンプレミスで稼働している基幹システムのデータを、Reckonerのオンプレエージェントを通じて取得し、データウェアハウスへ取り込むワークフローを構築しました。これにより、オンプレ環境のデータをクラウド上のデータウェアハウスに連携できるようになりました。

2点目は、ZendeskやSalesforceといった各業務SaaSとの連携です。
これらのサービスについては、公開されているAPIをReckonerから実行することでデータ連携を実現しており、早い段階から検証・構築を進めることができました。

3点目は、データウェアハウス上で加工したデータの活用です。
データウェアハウス側でデータの整形・加工を行った後、そのデータをSalesforceへ連携する仕組みを構築しています。いわゆるリバースETLの形で、データウェアハウス上で加工したデータを業務システムへ戻し、実際の業務に活用できる流れを構築しています。

既存環境を維持したデータ統合──リバースETLによる活用フェーズへの接続

――導入後、どのような効果がありましたか？

今後の活用を見据えた際に、大きな変化として感じているのは、オンプレミスで稼働している基幹システムのデータを、クラウドのデータウェアハウスに自動連携できるようになった点です。
これまではオンプレミス環境に閉じていたデータを、Reckonerのオンプレエージェントを活用することで、ファイルサーバー上のデータを取得し、データウェアハウスへスムーズに自動連携できるようになりました。

また、SalesforceへのリバースETLという観点では、これまで一方のシステムに入力したデータを改めてSalesforceにも入力する必要があり、二重入力が発生していました。
今後、このリバースETLが運用に乗ることで、こうした手間は解消されていくと考えています。
さらに、データを統合して扱えるようになることで、IDの一貫性が担保され、データの質の向上にもつながると見ています。

――今後の活用についてどのようにお考えですか？

現在はデータ基盤の構築を進めている段階ですが、今後はその活用領域を広げていきたいと考えています。
まず、現在一部の処理をRPAで対応しているケースがあり、データのフォーマット変換などはETLであるReckonerに置き換えることで、より効率的に運用できると考えています。
今後は、RPAとReckonerを組み合わせながら、業務全体の自動化・効率化を進めていきたいです。

また、人事労務・勤怠管理システムのデータ活用にも取り組んでいく予定です。
現在は、人事データや勤怠・給与データを分析する際に、手作業でのデータ出力・取り込みが発生しているため、こうしたプロセスについても自動化を進めていきたいと考えています。
今後は、こうしたマスターデータを各システムで横断的に活用できるようにしながら、運用の効率化とデータ活用の高度化の両立を目指していきます。

さらに将来的には、IoT機器から取得できるデータや、各種サービスの利用データなども連携し、より広い範囲でデータを活用できる環境の構築を目指しています。

――お忙しい中、貴重なお話をお聞かせいただきありがとうございました。

※本インタビューは2026年4月に実施

The post 【製造業DX】オンプレミス基幹とSaaSデータをDWHに集約 ─ 既存環境をそのままに実現したデータ基盤構築とは first appeared on Reckoner.

――Reckoner導入前はどのような課題がありましたか？

最大の課題は、利用者様の情報が複数のシステムに分散し、管理が追いつかなくなっていたことです。訪問介護、訪問看護、付帯サービス記録、施設スケジュール管理と、主に4つのシステムを利用していましたが、システム間で利用者IDがバラバラで、利用者様一人ひとりがどのサービスを利用しているかを正しく紐付けて管理するのが難しい状況でした。

導入前は、各事業所の事務スタッフが同一の利用者情報を、それぞれのシステムに個別に登録しており、結果として同じ情報を何度も入力する状態になっていました。
また、全角・半角の違いや、ひらがな・カタカナの違い、苗字の表記揺れなどが頻発し、名寄せ作業に多くの手間がかかっていました。

さらに深刻だったのが、マスター登録漏れによる影響です。
現場スタッフは訪問後に記録を入力しますが、システム上に利用者名が表示されないと、「名前がないから」と入力が後回しになり、結果として記録漏れが発生していました。
記録漏れが発覚すると、そこから1〜2日かけて過去の記録を掘り起こすという、非常に非効率な事態が起きていました。

――Reckonerを知ったきっかけを教えてください。

Salesforce導入を検討していたのがきっかけです。
既存のKintoneや他システムと、どのように外部連携するかが課題でした。
調べる中でETLツールの存在を知り検索したところ、あるETLツールのランキングサイトでReckonerが1位になっているのを見つけました。

直感的な操作性と双方向連携がReckonerを選んだ決め手

――Reckonerを実際に触ってみての感想を教えてください。

他社ツールはSQL前提（データを取得・加工するために、専門的なクエリ言語を書く必要がある）という印象が強かったのですが、Reckonerは完全にGUIベース（画面操作だけで設定できる）で、設定が非常に簡単でした。
「これなら、限られた人だけでなく、触れる人が増えそうだな」と感じました。
また、触っているうちにSQLも直接書けることが分かり、より高度な処理にも対応できる点も良かったですね。

導入当時は、プレビュー実行に時間がかかる場面がありストレスを感じましたが、現在は処理速度が向上し、日常の運用でもストレスを感じることはありません。

――Reckonerを選んだ決め手は何でしたか？

決め手は「使いやすさ」と「双方向連携」です。
先ほども触れましたが、ReckonerはGUIベースなので、画面で確認しながらブロックを組み立てるように設定できるため、直感的に操作できました。

もう一つの大きなポイントが、Salesforceとの双方向連携です。
Reckonerは、ソース（データの抽出元）としても、シンク（データの書き込み先）としてもSalesforceに対応しており、データの取得と登録の両方が可能でした。
結果として、要件を満たせるツールはReckonerしかなく、実質的に一択という判断になりました。

「あおぞらデータハブ」を構築し、正しいデータを全システムへ自動連携

――具体的にどのようなワークフローを運用していますか？

全サービスの利用者情報を一元管理する「あおぞらデータハブ（ADH）」というデータベース（MySQL）を中心に据えた構成にしました。
まず、AppSheetで作成した入力フォームから利用者情報が Google スプレッドシートに登録されます。
Reckonerはこのスプレッドシートからデータを吸い上げ、15分に1回の頻度でMySQL（ADH）へ統合・蓄積します。

そして、このADHにある「正しいマスターデータ」を、Reckonerが1日3回、訪問看護（MySQL）、訪問介護（MySQL）、付帯サービス記録（Google スプレッドシート）、施設スケジュール管理（PostgreSQL）といった各業務システムへ自動的に連携しています。これにより、どのシステムを見ても最新かつ正確な利用者情報が存在する状態を実現しました。

また、Kintone間の連携にも活用しており、営業のコンタクト記録で「手応えが3以上」だった場合に、1週間後に自動的に再訪問リストに追加するといった処理なども行っています。

――導入後、どのような効果がありましたか？

最も大きな効果は、「マスターにデータがない」という業務上のボトルネックが解消されたことです。
利用者情報を一元管理できるようになったことで、これまで各システムごとに個別登録していた状態がなくなり、利用者全量が確実にシステム上に担保されるようになりました。
その結果、現場スタッフが「名前がないから記録できない」といった理由で入力を止めてしまうケースがなくなりました。

業務面では、マスターのメンテナンスにかかっていた作業時間を、月あたり約10時間削減できています。
それ以上に大きかったのは、記録漏れが発覚した際に1〜2日かけて対応していた作業そのものが不要になったことです。事後対応に追われることがなくなり、業務全体の安定性が大きく向上しました。

事務スタッフにとっても、これまで4つのシステムそれぞれに同じ情報を入力していた手間が1回で済むようになり、作業負荷が大きく軽減されました。

――今後の活用についてどのようにお考えですか？

介護業界はまだFAX文化が残っていたりと、データ連携の障壁が多い業界です。
しかし、一部の介護ソフトはAPIを公開し始めています。
今後はそうした外部ソフトともReckonerを介して連携し、さらなる業務自動化とデータ活用を進めていきたいと考えています。

――お忙しい中、貴重なお話をお聞かせいただきありがとうございました。

※本インタビューは2025年12月に実施

The post 【介護DX】4つのシステムに分散した利用者情報を統合！多重登録・記録漏れを防いだデータ基盤構築事例 first appeared on Reckoner.

――ご自身はどのような役割・業務を担当していますか？

マーケティング本部内で新設された「データアナライズグループ」に所属し、社内データを扱う専門部署として、kintoneに蓄積されたデータの整備と活用に取り組んできました。
基本的に社内のすべてのデータがkintoneに蓄積されているため、「まずはそのデータをしっかり整備し、きちんと活用できる状態にしていこう」という方針で、2名体制で取り組みを進めていました。

その後、2025年7月の組織再編に伴いグループ自体は統廃合されましたが、データ整備・活用という役割は継続しており、部署の所属にかかわらず、現在もReckonerを中心としたデータ基盤の運用を続けています。

――Reckoner導入前はどのような課題がありましたか？

まず1点目は、社内のすべてのデータがkintoneに格納されている一方で、データ分析時に利用されることの多いkintoneアプリが製品×情報ごとに約40個に分散しており、kintone上で統合して扱うことが困難だったため、全体を横断したデータ分析がしづらかったという点です。

2点目は、分析前のデータ書き出し・加工が大きな負担になっていたことです。
どのアプリから、どの条件で、どのフィールドを書き出すかを毎回担当者が判断し、1日あたり約40個のアプリからCSVを出力してGoogle Driveにアップロードし、プログラムを走らせるといった作業を手動で行っていました。

3点目は、手作業とスプレッドシート前提の運用による属人化とミスのリスクです。
書き出し条件や対象アプリの選定を人がその都度判断していたため、処理が特定メンバーに依存し、属人化・工数増加・抜け漏れのリスクが常にありました。
特定製品のアプリを書き出し忘れる、別の製品名で追加してしまうといったミスも発生しやすく、「気づかないままレポーティング・分析してしまう」リスクを抱えていました。
また、こうした属人化により、休職や異動が発生した際に運用が止まってしまう恐れもありました。

――Reckonerを知ったきっかけを教えてください。

「kintone データ連携」や「ETL」などのキーワードでネット検索したことです。
最初に他社のサービスを見つけて、その後さらに調べていく中で、Reckonerでもkintoneをデータソースとして使えることが分かり、比較検討の候補に加えました。

GUIだけでデータ転送まで完結できる ― 「わかる人しか触れない世界」からの脱却

――Reckonerを実際に触ってみての感想を教えてください。

直感的に操作できるUIで、設定に迷う場面はほとんどありませんでした。
とくに使いやすいと感じたのが、各項目にマウスオーバーした際に、その場で説明が表示される仕組みです。
わざわざヘルプページを開かなくても、「この設定は何を意味しているのか」「どんな値を入れればよいのか」がすぐに把握できるため、試しながらフローを組み立てていくような場面でも、ストレスなく作業を進めることができました。

――Reckonerを選んだ決め手は何でしたか？

一番の決め手は、ノーコードでデータ分析の前処理を標準化できることです。
検討段階では他社ツールも候補に挙がっていましたが、「SQL前提の世界観だと、結局わかる人にしか触れない」という懸念がありました。
その点、ReckonerはGUI前提の設計になっており、見ればわかる・触ればなんとなく理解できるくらい直感的に扱えると感じました。
GUIベースで前処理・結合や統合・転送まで幅広いデータ処理を構築できることで、処理が特定の人に集中するのを防ぎつつ、運用担当の習熟に必要な時間も最小限に抑えられると判断しました。

また、お問い合わせ時のレスポンスが非常に早く、こちらの質問に対して実際に動くサンプルワークフローまで用意してもらえたことで、導入後の運用イメージが具体的に持てた点も大きな安心材料でした。

（写真左から）マーケティング本部の市川さん、森さん。

――導入プロセスについて教えてください。

まずはトライアルを利用し、自分たちが実現したいデータ連携や前処理フローが、Reckoner上で問題なく再現できるかを検証するところから始めました。
この期間の検証や要件整理は、森・市川の2名体制で進めています。
検証結果を踏まえて導入を決定し、トライアル開始から契約締結まではおよそ1か月程度でした。
契約後は、必要なワークフローを順次構築・追加しながら、段階的に運用範囲を整えていきました。

バラバラのkintoneアプリを「横断分析の起点となる1つのデータ基盤」に

――どのようなワークフローを構築されたのですか？

製品×情報ごとに約40個に分散しているkintoneアプリから、データをReckoner上で整形・集約し、そのうえでGoogle Driveやkintoneに転送するワークフローを構築しました。
また、あわせて

• kintoneからGoogle Driveへのデータ転送を行い、転送後のデータを用いて分析を実施
• kintoneからGoogle スプレッドシートへの自動転送を行い、毎日自動更新される集計・可視化用データを生成

といった処理もReckonerで自動化しています。
ワークフローの実行頻度はおおよそ1日おきで、マーケティング本部配下の各チームで以下のように活用されています。

• CS：問い合わせ情報を集約したダッシュボードの作成・運用に利用
• プロモーション：全製品のお試し申込数を日次でモニタリングするための基礎データとして活用
• 分析担当者（チーム問わず）：統合データを用いた製品利用傾向や契約に関わる分析など、深掘り分析のために活用

――導入後、どのような効果がありましたか？

まず、定量的な作業工数の削減です。
以前は、約40個あるkintoneアプリの全てを対象に、CSVを書き出してGoogle Driveにアップロードし、プログラムを実行する作業を行っていました。
この一連の作業に月約20時間（1日あたり約1時間）を費やしていましたが、現在は同じ処理をReckonerで自動化できており、その分の工数がまるごと削減できています。
また、実際には、導入当初は予定していなかった他部署・他用途での活用も含めると、削減できている工数はさらに大きいと考えています。

続いて、「誰でも同じ土台から横断分析できる」環境を整えられたことです。
バラバラに点在していたkintoneアプリのデータを一度Reckoner上で統合・標準化し、そのうえで各チームが使いやすい形でkintoneやGoogle Drive、スプレッドシートに戻していくことで、どのチームも同じ前処理済みデータを起点に分析できる状態を実現しました。

さらに、ミスの予防と安定運用の面でも大きな改善がありました。
以前は、複数アプリからの手動ダウンロードやスプレッドシートでの結合作業の中で、「どの条件で絞り込むか」「どの項目を出力するか」を毎回選択する必要があり、人為的なミスが起こりやすい状況でした。
気づかないまま分析・レポーティングまで進んでしまうリスクもありましたが、Reckonerでこのプロセスを自動化したことで、手作業によるミスや作業漏れが発生しなくなり、社内からも「非常に助かっている」という声が上がっています。

――今後の活用についてどのようにお考えですか？

これまでは主に「データ分析の前処理ツール」として活用していましたが、今後はそれに加えて、売上向上や顧客満足度向上に直結する顧客フォロー領域でのデータ整備・分析にも活用していきたいと考えています。
具体的には、顧客接点となる各種データの自動集約や、フォロー施策に必要な指標のモニタリングなどにも展開していきたいです。

――お忙しい中、貴重なお話をお聞かせいただきありがとうございました。

※本インタビューは2025年12月に実施

The post kintoneの複数アプリをまたいだ統合ダッシュボードを実現！マーケデータの集計属人化とミスのリスクをなくし「誰でも同じ土台から横断分析できる」環境を整備 first appeared on Reckoner.

頻発するエラーがRPA見直しのきっかけに

――ご自身はどのような役割・業務を担当していますか？

アシスト本部の経営管理グループに所属し、全社システムの運用管理やDX推進を担っています。
日々の業務改善から新しい仕組みづくりも含め、組織全体を横断的に支える役割を担っています。

――Reckoner導入前はどのような課題がありましたか？

注文書の電子契約送付をRPAで自動化していたものの、頻繁にエラーが発生していました。
Windowsのポップアップやブラウザのアップデートなどの影響で処理が止まってしまい、そのたびに対応に追われる状況が続いていました。

エラー修正には毎回1〜2時間を要し、発生頻度は週に2〜3回。
さらに、注文書の件数が増える月末には修正と処理にほぼ丸一日かかることもありました。
対応に時間を奪われる状況が続いたことが、RPAを見直す大きなきっかけとなりました。

――Reckonerを知ったきっかけを教えてください。

電子契約サービスWAN-Sign（ワンサイン）を提供する、株式会社ＮＸワンビシアーカイブズ様から紹介を受けたのがきっかけです。
RPAでは画面の変化に振り回されるため、API連携で安定的に稼働できる点に魅力を感じました。

（写真左から）アシスト本部 経営管理グループの山下さん、ネハさん。

デモサンプルとサポート対応で導入をスムーズに

――Reckonerを選んだ決め手は何でしたか？

テスト期間中は「本当に動くのか」「自分たちで構築できるのか」という不安がありました。
そんな中で、まず最初にReckonerのご担当者にヒアリングを行っていただき、デモバージョンのようなサンプルを作っていただけたことで、スムーズにスタートできたのがとても良かった点です。

その後、社内の担当者が実際に開発を進める中で多くの疑問が出てきましたが、その一つひとつに丁寧に回答いただきました。
その結果、「これなら大丈夫だ」と手応えを感じ、安心して進めることができました。

――導入プロセスについて教えてください。

開発担当者、前RPAシステムの作成者、そして責任者の3名体制で検証から導入を進めました。
トライアルを活用しながら段階的に進め、最終的な契約までおよそ3か月で移行することができました。

注文書データを自動送信するワークフローを構築

――どのようなワークフローを構築されたのですか？

具体的な流れは、まずGoogle Driveから注文書PDFと注文書一覧CSVを取得します。
注文書一覧の中からメールアドレスが含まれているファイルだけを抽出し、大阪本店か東京本店に応じてフラグを付与。
その後、電子契約サービスWAN-Signにアップロードして自動的に送信する仕組みです。

ワークフローは毎営業日8時30分に自動実行され、処理は通常であれば約15分、多い場合でも30分程度で完了します。

6時間の処理が30分に、誤送信も解消

――導入後、どのような効果がありましたか？

最大で6時間かかっていた処理が、今では15〜30分ほどで完了するようになりました。
処理速度が大幅に改善されたことが、最も大きな効果です。
加えて、月末には修正と処理に丸一日を費やすこともありましたが、導入後はエラーがゼロに。
以前のように5〜6時間を費やして修正対応に追われるというようなこともなくなりました。

さらに、従来はエラー修正の過程で人手による誤送信が発生するケースもありましたが、Reckoner導入後は人の手を介さず安定稼働するため、誤送信はなくなり、業務精度も確実に向上しました。

――Reckonerを実際に触ってみての感想を教えてください。

非エンジニアには少し難しい部分もあるため、将来的にはUIがより直感的になれば、さらに使いやすくなると感じています。
また、プログラミングの知識がある方が扱いやすい場面もあるので、知識のないユーザーでもスムーズに活用できるような工夫が増えると、さらにありがたいですね。

自社開発のシステムやGmailとの連携でさらなる活用へ

――今後の活用についてどのようにお考えですか？

まず、当社が自社開発しているシステムとの連携を検討しています。
現状では一部の操作を人手に頼っているため、Reckonerを活用して自動化できないかを模索しています。
次に、Gmailとの連携です。現在はWAN-Signとの連携で注文書処理を自動化していますが、それ以外の注文についてもメール送信までを完全自動化することで、さらなる効率化を実現したいと考えています。

また、Reckonerに対しては、連携できる外部アプリケーションをさらに増やしてほしいと期待しています。
社内ではさまざまなシステムが稼働していますが、まだAPI連携ができないものもあります。
連携可能なアプリが増えれば、より幅広い業務でReckonerを活用できると考えています。

――お忙しい中、貴重なお話をお聞かせいただきありがとうございました。

※本インタビューは2025年9月に実施

The post 電子契約の毎日運用を安定自動化！頻発するエラーと誤送信から脱却し、3時間の処理を30分に短縮・最大6時間のエラー修正業務もゼロに first appeared on Reckoner.

株式会社マイナビは、「一人ひとりの可能性と向き合い、未来が見える世界をつくる。」をパーパスに掲げ、人々の人生に寄り添い、サポートする多様な事業を展開しています。人材ビジネスや生活情報メディアを通して、ユーザーの可能性を広げ、新しい未来が見えるようなサービスを提供しています。

主力事業である人材ビジネス領域においては、就職、転職、アルバイト等を中心とした情報サービスや人材紹介サービスを展開しています。また、進学、ウエディング、ニュース、農業など、多数の生活情報メディアを運営しています。

人生のさまざまなシーンに寄り添う総合情報サービス企業として、常に変化と進化を続けています。

――ご自身はどのような役割・業務を担当していますか？

私たちデータ活用推進1課は、社内のデータ民主化を実現することをミッションとして業務に取り掛かっております。職種問わずマイナビ社員全員が社内データを活用してもらえるよう、安心安全かつローコード・ノーコードで敷居が低いデータ活用基盤の構築と、データ活用を行う社員のスキルアップサポートやデータ活用推進のためのユーザー会などのイベント企画運営などを行っております。

――Reckonerの導入前にどのような課題がありましたか？

弊社では、非エンジニア社員にもデータを活用・分析してもらうために、セルフBI分析基盤の整備を行っておりました。
その基盤の中に、データ準備を行うデータプレパレーションツールの提供も行っていたのですが、そのツールがEOS（販売 / サポート終了）となってしまったことがきっかけで、新しいデータプレパレーションツールを探す必要が出てきました。

Reckoner導入の決め手は、非エンジニア向けのUI/UXと献身的なサポート

――Reckonerを導入することにした経緯・理由を教えてください。

当初、我々は以下の基準で製品検討を行っていました。

1. 既存のデータプレパレーションツールと同程度の機能がそろっていること
   1. データ結合や集計ができる
   2. 置換やレコード分割、フィルター、カラムの調整ができる
   3. 弊社内で管理しているDBへの接続ができる
   4. 加工した結果データをあらゆるツールに出力ができる
   5. 加工フローを自動実行することができる
   6. 作成者だけでなくアクセス権限を持った人が加工フローを実行、編集することができる
2. 非エンジニア社員が使いやすい製品であること
   1. UIなどが日本語対応されている
   2. 直感的な操作ができる
   3. ノーコーダーで加工ができる
   4. Webブラウザから操作ができる
3. SaaSであること
4. ライセンス形態がユーザー単位ではないこと
   1. データ民主化実現の観点から、Reckonerを利用できるユーザーの数に制限をかけたくなかった
5. データガバナンスが利かせられること
6. サポート体制がしっかりしていること

中々要件に見合うツールが見つからない状況の中、データプレパレーションツールとして提供されているツールではなく、ETL・ELTに幅を広げて探したところ見つかったツールがReckonerでした。
最初は、ETLツールってエンジニア向けかなと思ったんですが、UIが見やすくて、非エンジニアでも比較的使いやすそうだと感じました。最終的には12サービスを比較検討し、3サービスでPoC検証を行った結果、Reckonerに決めました。

始めは、Reckonerにおいても導入する上で解決しなければならない課題はたくさんありました。しかし、スリーシェイクさんが課題に対して真剣に向き合ってくれて、新機能の実装や解決策の提案、事業部門からの問い合わせに対する手厚いサポートをしてくれたんです。最終的に、既存のプレパレーションツールと同程度の機能が揃ったので導入を決めました。弊社の課題に対して一番向き合ってくれたというのが、今思うと一番の決め手だったのかなと思っています。

少人数で推進した検証から活用支援まで

――どのようなプロセスでReckonerを導入しましたか？

まず、課の3人が中心になって、検証、導入、活用推進を進めました。検証からルール整備、導入、初回利用のハンズオンコンテンツ作成、ドキュメント作成、ユーザーサポートや活用促進を、ほぼ3人で回しました。ユーザーからの問い合わせ対応では、スリーシェイクのカスタマーサポートの方にも協力してもらいました。

1時間の作業が5分で完了

――具体的に、どのようなワークフローを構築したか教えてください。

様々な方々に活用をしてもらっていますが、今回は弊社マーケティング部門で作成されたWebサイトのデータ分析レポートのデータ加工ワークフローについてお話します。
本レポートは社内システムから抽出したデータを使っているのですが、そのデータをGoogleDriveに格納し、あとはReckonerで1回実行ボタンをクリックするだけで、レポート用データが作成されるというワークフローを構築しました。
以前はExcelで手作業で行っていた複雑なデータ加工の作業を、GoogleDriveにデータを格納するだけのシンプルなオペレーションにしたことで、作業ミスと作業工数を大幅削減することに成功しました。

UIの分かりやすさと処理速度に高評価

――実際に使ってみて、Reckonerの性能やサービスの品質についてどう感じていますか？

以前使っていたプレパレーションツールと比べて、UIが分かりやすいと利用者からも好評です。ReckonerがSaaSなので、加工処理に時間がかかるかと思ったのですが、思った以上にサクサク動いていて驚きました。

データ加工時間の短縮と全社的なDX推進

――Reckonerの導入により、どのような効果・変化がありましたか？

先ほど説明したワークフローでは、データ加工作業に1回1時間かかっていたのですが、1回わずか5分までに短縮できました。オペレーションもシンプルになったため、作業ミス削減はもちろんのこと、誰でもデータ更新作業が可能になり、属人化も解消されました。

他にも、非エンジニアの方がReckonerを積極的に活用してくれていて、構築されたワークフローは1,300を超えています。Reckonerの導入によって、全社的にデータ活用や業務の効率化が進んでいると感じます。

また、ユーザー単位のライセンスではないので、使いたい人全員が利用できるのが大きいですね。以前プレパレーションツールを使っていた組織だけでなく、新しく使いたいという組織にも活用してもらうことができました。今では、大小合わせて69の組織で利用されています。Reckonerの導入で、全社のDX促進に貢献できたと思っています。

データ民主化の深化と新たな課題への挑戦

――今後どのようにReckonerを活用していくか、展望をお聞かせください。

これからも社内利用を増やし、エンジニアに頼らずとも全社員がデータを活用できる環境を整えていきたいです。データ民主化が進んだことで、新しい課題も見えてきました。扱うデータが大きくなったので、よりデータが扱いやすいシンク先を用意したり、自分たちで加工できるようになったことでデータの統一性がなくなってきたので、セマンティックレイヤーのような共通化できる仕組みを作りたいと考えています。

さらに、社内で活用を進めているLLMを利用して、データのカテゴライズなど、これまで人間が判断していた部分を任せることで、より効率的にデータ活用できる環境も整えていきたいです。

――最後に、スリーシェイクやReckonerに今後期待することがあればお聞かせください。

チーム全体の「利用」状況を把握したい時に、「管理画面上」得られる情報の粒度が大きいので、ドリルダウンして、より細かい粒度で把握できるようになると嬉しいです。

また、ワークフロー単体で見れば、どのソースがどのシンクにつながっているか分かりますが、データカタログと連携するなどしてデータリネージが見れるようになると、別の組織・プロジェクトで同じものを使っていた、ということに気づきやすくなり、コラボレーションが生まれやすくなると思います。

今後も、Reckonerの進化と、手厚いサポートに期待しています。

――お忙しいところお話をお聞かせいただきありがとうございました！

※本インタビューは2025年4月に実施

The post 69の組織を巻き込み、全グループ会社で加速するDX戦略！ Reckoner導入で1300以上のワークフロー構築、作業時間も90％短縮！ first appeared on Reckoner.

The post AI-OCR連携からSalesforce投入までを自動化！ first appeared on Reckoner.

The post kintone、freee…SaaS連携で業務効率を変える！ first appeared on Reckoner.

課題と導入効果

課　題

自社開発アプリのデータベースがスプレッドシートであることの限界
・データ登録行に限界があり、定期的にデータを削除する必要があった。この作業工数が負担になっていた。
・自社開発アプリの動作が遅くなっていた。

スプレッドシートからPostgreSQLへ変更する際の改修コスト
・自社のエンジニアが行うには開発工数や今後の運用コストが継続的に発生する
・スプレッドシートの既存データもPostgreSQLへ移行する手間が発生する

効　果

最小限のシステム改修
・CSVへ変換した「.geojson形式」のファイル出力先をGoogle Driveへ出力する変更だけで済んだ。
・スプレッドシートの既存データを、少ない工数でPostgreSQLへデータ移行できた。

無駄の無いデータ連携
・Webhook機能により、タイムリーかつ無駄の無いデータ連携を実行することができた。

売上貢献
・土地の仕入れ量が増加したことで、提案先の増加に繋がり、売上向上に貢献
・従来の方法では見つけることのできなかった土地情報の発見にも繋がり、新たなビジネスチャンスの創出にも貢献

――はじめに、御社の事業内容を教えてください。

グリーン・トランスフォーメーション（GX）を推進するため、ゼロエネルギーハウスの開発・販売と、グリーンエネルギー発電施設の開発・販売、発電設備の運用・保守管理、この3つの事業を展開しています。特徴は、個人の方が参加しやすいグリーンエネルギー事業を行っている点です。弊社のシンボルマークは「太陽と地球の最適な関係」を表現しています。これからの時代の変化を予測し、最先端のテクノロジーを活用することで、サプライチェーン全体のDX推進を図り、社会に貢献できる新たな価値を創出し、クリーンエネルギーの普及をより一層加速させていきます。

――ご自身はどのような役割・業務を担当していますか？

私たちは2人ともデジタルトランスフォーメーション部（以下、DX部）に所属しています。弊社は経済産業省が定める「DX認定事業者」認定を取得しており、DX部は社内のDX推進を担う中心的な部署となります。約1年半前から、本格的に社内の業務改善やシステム化等の社内改革に力を入れています。

※本インタビューは2024年9月に実施

土地データの保存先をスプレッドシートからPostgreSQLへ変更することが喫緊の課題に

――Reckonerの導入前にどのような課題がありましたか？

時系列でお話ししますと、まず、太陽光発電設備の土地仕入れ業務において、外部システムにある土地データを手作業でスプレッドシートへ転記していました。そのため、作業工数の負担が大きく、転記ミスや漏れのリスクもありました。また、扱えるデータ量が少ないことも問題点でした。

これを解決するために、外部システムの土地データを自動で登録する自社アプリをノーコードツールを利用して開発しました。

結果、土地データの登録において、手作業がゼロになったことで、ヒューマンエラー発生のリスクを撲滅。扱えるデータ量も増えました。

Reckonerを導入検討するきっかけとなったのは、この自社開発アプリのデータベースをスプレッドシートで構築していたため、登録行の限界とそれに伴う手動でのデータ退避の工数、アプリの動作遅延が喫緊の課題となったことでした。

もともと、土地データの保存先はスプレッドシートではなく、PostgreSQLにする構想はありましたが、スピード優先でまずはスプレッドシートで運用を行っていました。

しかし、スプレッドシートへのデータ登録に滞りが生じ、自社開発アプリの処理パフォーマンスが許容できる範囲を超えはじめたため、土地データの保存先をPostgreSQLへ変更することが急務となったのです。

Reckonerの決め手は「Webhookトリガーによるワークフローの起動」

――Reckonerを導入することにした経緯・理由を教えてください。

PostgreSQLへの変更に伴い、既存の自社開発アプリの改修と、スプレッドシートに蓄積された土地データをPostgreSQLに移行する必要性が生じました。これらの対応を自社のエンジニアが行うという選択肢もありましたが、今後の運用コストも継続的に発生することや、短期間で成果を出すには、外部ツールの活用が最適だと判断しました。

そこで、Reckonerを含む3社のETLツールを比較検討しました。従来から利用している国産ETLツール、海外製のETLツール、そしてReckonerです。

従来の国産ETLツールは連携コネクタを増やす際に追加料金が発生するため（当時契約のプランにおいて）、コスト面を考慮して他の安価なサービスも検討対象に含めました。

比較検討のポイントは、月額費用、要件適合性、操作性、処理速度、イベント起動、機能評価、コストです。

Reckonerは初めて扱うツールだったため、操作性において学習コストがかかる点や、処理速度の面で他社ツールに優位性がある部分が多くありました。しかし、以下の点を総合的に評価し、導入を決定しました。

• 複数コネクタが使用でき、安価に導入できる
• 自社で利用しているGoogleサービスへReckonerがアクセスする際の設定が簡単
• サービス同士の連携だけでなく、CSVやJSONなどのファイル形式のデータも取り込める
• エラーメッセージが解読しやすい
• GUI上で簡単なマウス操作で直感的にワークフローが構築できる
• Webhook機能により、任意のタイミングでワークフローが起動できるため、リアルタイムに近いデータ連携が可能

実は、外部システムにある土地データが「.geojson形式」のファイルだった点が課題でした。Reckonerも他社ツールもこれに対応していなかったためです。しかし、Google DriveへCSV形式で出力する形であればカバーできる範囲だと判断し、Reckonerの利用価値がそれを上回ると判断しました。

中でも決め手となったのは「Webhookトリガーによるワークフローの起動」です。この機能がない場合、1日1回や1時間に1回などの定期実行となり、ファイル取得からPostgreSQLへ連携されるまでに時間がかかってしまいます。そして、データ取得が無い場合でもワークフローが実行されてしまうため、余計なコストがかかります。Webhook機能があることで、ファイルが取得されたタイミングでワークフローを実行できるため、リアルタイム性の高いデータ活用が可能になります。このスピード感こそが、Reckonerを選んだ最大の理由です。

内製でエンジニアが開発する場合と比べてReckonerはコスト削減効果があると総合的に試算

――どのようなプロセスでReckonerを導入しましたか？

Reckonerは、トライアル環境を利用して検証し、約1ヶ月で本格導入しました。問い合わせ後すぐにトライアルを開始できたこともあり、社内では「一刻も早く導入したい」という機運が高まっていました。トライアルは私一人（中尾）で検証を行い、その後、稟議資料を作成し、本部長決裁を経て導入が決定しました。

Reckoner導入は、DX部が主導しました。現場の課題を把握し、データ活用方法やデータ自動連携の仕組みづくりを提案しました。

自社にもシステム開発のスキルを持つメンバーはいるため、稟議を通すためには、内製と外注の比較検討が不可欠でした。そこで、それぞれの方法における工数やコストを算出し、Reckoner導入による費用対効果を明確化しました。

具体的には、時給×（開発工数、運用工数、開発コスト、運用コスト、サービス利用料）を、月間と年間でそれぞれ算出し、総合的に比較しました。

エンジニアが開発する場合、月額のサービス利用料は発生しませんが、開発工数や運用コストは属人的な対応になるため、Reckonerよりも大きくなってしまうと予想されました。

内製でエンジニアが開発する場合と比べて、Reckonerはコスト削減効果があると試算し、これらの結果を踏まえ、Reckonerの導入を決定しました。

Google DriveとPostgreSQLを連携、太陽光発電設備の土地仕入れ業務で活用

――具体的に、どのようなワークフローを構築したか教えてください。

Reckonerは、太陽光発電設備の土地仕入れ業務で活用し、Google DriveとPostgreSQLを連携させています。

具体的には、外部システムから取得した土地データ（.geojson形式）を、Google Driveにアップロードすると、自動でCSVに変換、土地データのチェックを終えた後、Google Driveへ再出力されます。その後、Webhookを利用してReckonerのワークフローを起動、Google Drive上のCSVファイルを取得し、仕入れDBであるPostgreSQLが読み込めるデータ型に変換したり、マスタを作成したりといった処理を行います。そして、PostgreSQLに土地データを自動登録します。

視覚的にわかりやすく、エンジニアにとっても扱いやすい

――実際に使ってみて、Reckonerの性能やサービスの品質についてどう感じていますか？

Reckonerは、ワークフローの流れが視覚的に分かりやすく、非常に使いやすいツールだと感じています。国産ツールという点も安心感がありますね。

ノーコードツールでありながら、BigQuery SQLを使ってコーディングができる点も魅力です。Reckoner標準の機能ではデータ加工や連携が難しい場合でも、BigQuery SQLで自由に記述できるので、エンジニアにとっても扱いやすいツールだと感じています。

サポート体制が充実している点も高く評価しています。問い合わせへのレスポンスが早く、問題解決までの時間が短縮できます。実際に、過去にデータ連携でつまづいた際に問い合わせをしたのですが、迅速な対応のおかげで、すぐにワークフロー構築を再開することができました。

特に印象的だったのは、土地データのJSONファイルが「.geojson形式」のため、Reckonerで読み込めるかどうか検証した時のことです。結果は対応していなかったのですが、検証中も親身になって相談に乗っていただき、まるで二人三脚で課題解決に取り組んでいるような感覚で、非常に心強かったです。

また、データの結合処理や適切なタスクの組み合わせに迷っていた際には、ワークフローのサンプルを提供していただきました。そのおかげで、自力で試行錯誤する必要がなく、スムーズにデータ連携を実現できました。

最小限のシステム改修、無駄の無いデータ連携、売上貢献

――Reckonerの導入により、どのような効果・変化がありましたか？

自社開発アプリの改修を最小限に抑えることができました。具体的には、「.geojson形式」のファイルをCSVに変換し、Google Driveに出力する」仕組みを構築するだけで済みました。

スプレッドシートに蓄積されていた既存データも、Reckonerを用いることでスムーズにPostgreSQLへ移行することができました。

そして、ReckonerのWebhook機能のおかげで、タイムリーかつ無駄のないデータ連携も実現しました。データが更新されたタイミングでのみワークフローが実行されるため、システムへの負荷も軽減されました。

これらの結果、土地データの保存先がPostgreSQLへ変更されたことで、土地の仕入れ量が増加し、提案先の増加、そして売上向上に貢献しています。

また、仕入開発営業の方から、「地主様から『よく見つけたね』と仰っていただけました」という嬉しいお話が共有されたこともありました。Reckoner導入によって大量のデータを一括で自動処理できるようになったため、これまで見つけることができなかったような土地情報も発見できるようになったのです。

必要なデータを必要な時にすぐに入手できる環境を構築できたことは、DX部として大きな成果だと感じています。

新しいツールともスピーディーに連携可能

――今後どのようにReckonerを活用していくか、展望をお聞かせください。

Reckonerは、新しい用途での活用や、新しいツールとの連携も容易に実現できる点が魅力です。開発工数が少ないため、スピード感を持って対応できます。

今後は、様々な業務で発生するデータ連携や活用ニーズに対してReckonerを活用していきたいと考えています。

――最後に、スリーシェイクやReckonerに今後期待することがあればお聞かせください。

Reckonerは非常に使いやすく、大変満足しています。日々の業務効率化と売上増加に大きく貢献してくれています。

より一層の使い勝手を追求するとすれば、GUI上で複数の出力先を設定している場合、ワークフローの実行順番を任意で指定できると、さらに便利になると感じています。

また、タスク処理のステータス表示については、現状でも問題なく利用できていますが、画面を開きっぱなしの状態でもリアルタイムでタスクの進行状況が分かれば、よりスムーズにワークフローの構築を進められると感じます。

今後も、Reckonerの進化と、手厚いサポートに期待しています。

――お忙しいところお話しをお聞かせいただきありがとうございました！

The post 最小限の既存システム改修で実現！
グリーンエネルギー企業の売上拡大・DX推進を支えるReckonerはエンジニアにとっても扱いやすい first appeared on Reckoner.