こんにちは。ゆずたそ（@yuzutas0）と申します。
これまでの記事を書く過程で、troccoの利便性は分かりました。個人的には「ええやん」という気持ちです。そして「で、なんぼなん？」という気持ちです。そうなのです。価格がどこにも書いていないのです。
そう考えると、他にも気になる点はあります。データ転送ツール導入の意思決定に当たって、利用者ならびに決済者の関心は、主に以下4点だと思っています。
- 価格
- パフォーマンス
- セキュリティ
- サポート体制
これらについて「ぶっちゃけどうなんですか」と運営者の小林さんに聞いてみました。苦い表情で言葉を選びながら回答いただきました。小林さん……すいません……でも、ありがとうございます……。
※ この「trocco体験記」は全4回の連載となります。
- 第1回：trocco®︎を使ってみた
- 第2回：trocco®️を使った所感
- 第3回：trocco®️利用者の工夫（利用事例）
- 第4回：運営者ぶっちゃけQ&A（本記事）
Q. ぶっちゃけ、価格は？
ゆずたそ
あの〜、これだと周囲に勧めにくいんですけど……。
小林さん
値段設定が分かりにくい点は、誠に申し訳ありません。個別で見積もりを行っているのが現状です。
価格面が気になる方には、10万円〜で始められるStarterプランをご用意しています。ただ、Standardプランに比べて利用できる容量や接続可能なサービスの数に制限があるので、ご注意ください。
これらのプランは手厚いサポートを前提としていますが、より低価格でソフトウェアエンジニアが始めやすいプランも検討しています。このような形で、お客様のご要望を伺いながら、商品プランや提供サービスを日々アップデートしています。
ご利用いただきやすい形でのサービス提供を検討しますので、ぜひお問い合わせいただけると幸いです。
Q. ぶっちゃけ、パフォーマンスは？
ゆずたそ
これ実際どうなんですか。LPを作ったときにノリで業界最速クラスと書いたとか？
小林さん
海外の代表的な類似サービスに比べると、ベンチマークテストで倍〜16倍の計測結果が出ています。
実行環境はAWSです。スケールアップ（CPUのコア数増強）が可能で、スケールアウト（並列実行性）もお客様が不便なく使えるようにtrocco内部で最適化しています。ベストエフォートですが、50並列の実行くらいであれば耐えられるように設計しています。
インスタンスのスペックは実行ログの最初に出てくるので、興味のある方は直接ご確認いただければと思います。必要に応じて専任のサポートが対応しますので、お客様がインフラのチューニングに頭を悩ませる必要はありません。
1日1TB規模のデータ転送でしたら、既に運用実績がありますのでご安心ください。第2回の記事で会話されていたような、デイリーで数百TBといった大規模転送になる場合は、別途ご相談いただけると幸いです。
Q. ぶっちゃけ、セキュリティは？
ゆずたそ
……しっかりしてそうな感じがサイトから伝わってくるのですが、一応セキュリティについても聞かせていただけますか。
小林さん
trocco自体については以下のような設定が可能です。
- 管理画面へのアクセスをIPアドレスで制限
- ログイン時の二段階認証
- どのユーザーがどの接続先設定を見れるかグループ単位で権限管理
troccoから各システムへの接続については以下のような設定が可能です。
- SSL証明書を用いた暗号化通信（例：HTTPSでS3にアクセス）
- 3つの固定IPアドレスからアクセスするので、接続先のファイアフォール解除は不要
- AWSを使っているため、オプションでVPC/専用線の設定も対応可能
企業で一般的に求められるセキュリティ水準は担保できるようサービスを提供しています。
Q. ぶっちゃけ、サポート体制は？
ゆずたそ
（初期応答時間……？）あの、サポート体制について、差し支えなければ、ご案内いただくことは可能でしょうか？
小林さん
Slackのゲストチャンネルで会話することが多いです。お客様1社につき1人、担当のカスタマーサクセスが伴走して、以下のようなサポートを提供します。
1つ目はチャットでの相談対応です。営業時間内の問い合わせであれば、1時間以内に一次回答（受領連絡）を返すようにしています。内容や状況によりますが、二次回答（課題の切り分けや対応方針のご案内）は、おおむね当日中にお返しできています。
2つ目はオンボーディングです。導入時にHangoutで画面を共有しながらtroccoの使い方をご案内します。特に、初めてデータ基盤構築を担当される方は、弊社サポートの説明を聞きながらtroccoを使うことで、基盤構築・運用に必要な知識を抑えていただけると思います。
3つ目は保守運用の支援です。データ転送のエラーログを監視して「このジョブが失敗していますけど大丈夫ですか」といったお声掛けを行います。
いずれも自社開発であればデータエンジニアが社内コミュニケーションで苦労するような業務かと思います。弊社ではサポートに力を入れているので、ぜひご活用ください。
以上、私（ゆずたそ）と小林さんの押し問答でしたッ！
おわりに
全4回の連載で、様々な角度から trocco について見てきました。私（ゆずたそ）自身は1人のユーザーに過ぎないので、過度な宣伝を行うつもりはありませんが、使ってみて「良いツールだなぁ」とは思っています。
もし「導入を進めたいけど懸念や不安があるので後押ししてほしい」という方がいましたら、可能な範囲でサポートします。お気軽に @yuzutas0 にお声掛けください。
自社やベンダーでデータ転送の仕組みを作るのは、泥臭い作業の連続です。サーバを立て、Embulkをインストールして、動作プログラムや設定ファイルを作成し、期待通りの動作になるかテストし、サーバにプログラムを反映させる。さらに、システムを保守運用できるようにエラー通知のスクリプトを書いたり、セキュリティ担保のために固定IPアドレスを紐付けて連携先サーバに穴開けを依頼したり、やることは山積みです。
また、自社で開発者を雇ったりベンダーに発注する場合、1人月で数十万〜数百万といった相場感になると認識しています。そこに採用やインフラのコストが乗ります。しかもデータ転送の分野は、需要が多い割に、対応できる人材が少ないので、担当者を探すのも大変ですし、担当者を繋ぎ止めるのも大変です。本題以外の作業工程が意外と多いです。
「片手間の作業で十分回るぜ」「システムを構築するまでもないぜ」というフェーズだと「そこまで労力を掛ける必要ある？」「そこまでコストを掛ける必要ある？」と思ってしまうのですが、事業や組織がある程度のフェーズに進んでいるのであれば、そのくらいの規模感・予算感になってしまうのかなと思っています。
さらにレガシーな企業では1つ1つの作業工程に数週間を掛けてしまっても不思議ではありません。そのスピード感を見ていると、危機感を覚えます。本来の目的に辿り着く前に社内外の環境が変わってしまうのではないか。データ連携はゴールではありません。その先にある業務改善やデータ活用こそ、自社で頭を悩ませるべきポイントのはずです。
人事情報や経理、そして契約書など、これまで社内環境や基幹システムから出してはいけないと思われてきたデータについても、業務支援SaaSで扱われるようになってきました。2020年の新型コロナショックでその流れが加速したように思います。今後何かしらのビッグイベントが起きる度に、これまでの「当たり前」は少しずつ見直されていくのではないでしょうか。
今一度、社内外のデータ管理について見直してみると「これは外部ツールに任せてしまって良いのではないか」と思える箇所が多々見つかるはずです。業務の見直しとソフトウェアの活用による継続的改善こそが、日本企業のデータ活用を支える根幹なのだと思います。手段のための手段について長々と時間を掛けるのは、そろそろ終わりにしませんか。
最後までお読みいただき、誠にありがとうございました。
この記事が少しでもお役に立てると幸いです。
