※ この「trocco体験記」は全4回の連載となります。
- 第1回：trocco®︎を使ってみた
- 第2回：trocco®︎を使った所感（本記事）
- 第3回：利用事例リサーチ
- 第4回：運営者ぶっちゃけQ&A
はじめに
こんにちは。ゆずたそ（@yuzutas0）と申します。
前回はtrocco®️を使ってkintoneからBigQueryに営業活動データを転送しました。株式会社primeNumber 取締役執行役員CPOの小林さん（@hiro_koba_jp）や@giwaさん、某社ソフトウェアエンジニア（A氏）のサポートのもと、無事に成功しました。
今回はtrocco®️を使ってみた感想を、座談会形式でディスカッションします。仕事の合間の気分転換がてら、podcastを聞くつもりで読んでいただければと思います。
もう自社開発しなくて良いですか？
ゆずたそ 簡単に終わりましたね。思ったよりしっかりしている、というのが率直な感想です。
A氏 むしろtrocco®️での作業を始める前が長かったですね。社内のセキュリティチェックを通したり、kintoneへのアクセス権限を営業部に発行してもらったり……。
ゆずたそ データ連携業務は思っている以上にタスクが多いですよね。今回はSaaS（kintone）からSaaS（BigQuery）へのデータ連携をSaaS（trocco®️）で実現しているので、まだ簡単な方だと思います。独自システムが多ければ多いほど、話は厄介になるのではないでしょうか。
A氏 そうですね。
ゆずたそ そう考えると、せめてデータ転送のシステムくらいはSaaS（trocco®️）に寄せていく、で良さそうですかね。
A氏 いえ、データ連携を自社管理したいニーズは残ると思います。デイリーで数百TBの、個人情報を含むデータを、オンプレミスのDBから、インターネットを経由して、SaaS経由で抽出する、というのは想像できません。
ゆずたそ なるほど。
A氏 2000年頃にDWH（データウェアハウス）やBI（ビジネスインテリジェンス）という言葉が流行したり、2010年頃にビッグデータやデータサイエンティストという言葉が流行して、似たようなソリューションはこれまで沢山作られてきました。
ゆずたそ ほうほう。
A氏 WEB業界だと知る機会は少ないですが、昔からデータ転送の特化ベンダーはいくつか存在しています。にも関わらず、未だに大手IT企業がデータ連携の自社開発部隊を抱えるのには、それなりの理由や経緯があるんですよ。
ゆずたそ デイリーで数百TBの、個人情報を含むデータを、オンプレミスのDBから取得するなら、まぁ自社開発のほうが安心ですかね。
A氏 間違いないと思います。
troccoに任せるべきデータ転送は？
ゆずたそ では、例えば、どのデータがどのくらい使われるか分からない初期フェーズは trocco®️で実現して、利用が本格化したら社内のデータパイプラインに乗せ換える。そういった使い分けが出来ると、スピードと品質を良い意味で両立できるのではないでしょうか。
A氏 賛成です。一生懸命データを連携したのに、全然使われていない、ということは何度かありました。そういうのは減らしたいです。ツール活用で減らせると思います。
ゆずたそ あと、マーケティングやセールス用途の外部システムで、スピード感が求められるようなデータ連携はtrocco®️で行う。自社バックエンドシステムとの連携は社内で構築する。そういった使い分けも良いかもしれませんね。
A氏 それも賛成です。マーケティング部門が新しいツールを試して、突然データ連携を依頼されることがあるのですが「いちいち対応できないよ」と言いたくなりました。一方で、基幹システムのデータは、さすがにSaaSで連携するのは難しいでしょうね。
小林さん 基幹システムとのデータ連携の場合は、CSVファイルをクラウドストレージに出力してもらう、といった形でお願いしています。そのストレージからデータ転送を行います。
ゆずたそ なるほど。ネットワークのInは開けられないけど、Outは開けやすいだろうということですね。CSVファイルをアップロードするにはスクリプトの開発が必要になりますが、そこは仕方ないですね。
A氏 まぁそのくらいなら兼任のインフラエンジニアでも現実的に対応可能だと思います。
ゆずたそ 自社でデータ連携専任のソフトウェアエンジニアを抱えていない会社にとっては心強いですね。
A氏 そうですね。私も副業の相談を受けることがあるのですが、ちょっとしたベンチャーなら「troccoを導入しませんか？」で解決しそうなイメージはあります。
ゆずたそ 懸念点を挙げていた割には、けっこう気に入っているじゃないですか。
A氏 毎回スクラッチで作って、夜間や休日に障害対応するのが、徐々に苦しくなってきました。もう少しプライベートに時間を割きたいと思っています。実は先日、子供が生まれまして……。
ゆずたそ A氏〜〜〜！！！！！！！
自社構築ならEmbulkプラグイン？
ゆずたそ ちなみにtrocco®️を使わずに自分で開発する場合はどんな感じにしますか。
A氏 うちはAirflowを使っているので、AirflowからEmbulkを実行するのが良いだろうと思っています。
ゆずたそ 安定のEmbulkですね。
A氏 ここ2-3年は Apache Beam をメインのETLツールとして使っていましたが、kintoneのような国内ツールとの連携だと、Embulkが便利ですね。Embulkにはkintone-inputのpluginがあるらしいので、これを使うつもりです。
ゆずたそ このリポジトリ（trocco-io/embulk-input-kintone）ですね。
小林さん うちのやつですね。
A氏 本当だ・・・。そのpluginが置いてあるの、よく見たら trocco®️さんのリポジトリだ・・・。
ゆずたそ OSSにしているのは安心感があるし、好感が持てますね。ブラックボックスだと、ベンダーロックインが怖くて、いざというときに困るので。
A氏 はい。実装が見えるのはソフトウェアエンジニア観点でも信頼できます。
ゆずたそ 時間をかけてリサーチしても、結果として同じものを作ることになりそうですね。だったら最初からtrocco®️さんに乗っかってしまえば良いのではないかとは思いました。
A氏 それは、たしかに。
おわりに
ゆずたそ まとめると、
[code]- クリティカルな用途で使うのは正直まだ難しいと感じる人もいる
- まずはマーケティングや営業の外部データ連携で使ってみてはどうか
- やろうと思えば基幹システムとの連携も現実的なスコープに入る
- プラグイン実装は公開されているので気になるなら見てみよう
- 効果が実感できたら trocco の利用比重を段階的に高めていくのが良いのではないか
といったところでしょうか。
A氏 いいですね。まだ私は半信半疑派なので、そのような進め方にしていただけると安心感があります。自社で開発せずに、trocco®️に寄せている事例をネットで見かけたことがあるので、企業によってはフィットするのだろうとは思いますが。
ゆずたそ では、せっかくなので次回は「自社開発せずに trocco®️に寄せている事例」を見てみたいと思います。
次回に続く！
