はてなブックマーク

ビッグデータというバズワードが囁かれ早幾数年がたち、どの企業でも当たり前に数十億数百億数千億というデータを扱える時代になりました。 その一方で、Garbage in, Garbage outのように使えないデータを集めても意味がないみたいな話もあります。 プラットフォームのサポートをしていると、様々な顧客がいて、当たり前のように巨大なログデータや顧客データを扱い、そうした顧客の複雑な問題やクエリの書き方のような初歩的な質問だったりを解決してきました。 問題を日々解決していると、たまにマンネリになるときもあり、回答が雑になってしまいそうなときもあります。 しかし、そんなときはいつもとある顧客のプレゼンを思い出し、顧客が問題を解決しデータをちゃんと使えるようになることで生まれるデータの価値を考え、気を引き締めてサポートしています。 その顧客のプレゼンとは、2018年のPlazmaのイベントで登

*自分の整理も兼ねて トレジャーデータのテクニカルサポートエンジニアには、大きく分けて4つの役割がある。 Customerの問題解決 Developerの問題解決 Productの問題解決 Customer Successの問題解決 これらの4つの問題解決の役割を通して、 顧客体験の向上 サービスの利用促進 顧客との信頼関係の確立 を実現している。 それぞれの問題解決について説明していく。 顧客の問題解決 顧客はサポートに対して、Email / Online Chatなどを介して問い合わせができる。 問い合わせの内容は、使い方の質問、エラーの解決方法、パフォーマンスチューニング、アーキテクチャの相談など様々である。 サービスの機能も多種多様であり、外部サービスとのコネクタだけでも200以上存在している。各種コネクタの外部サービスの仕様を把握しつつ、調査や質問に回答しなければならない、という

GitBucket はご存知、takezoeさんを中心に開発されている素晴らしい GitHub クローンです。 gitbucket.github.io 同僚が作ってるプロダクトをトレジャーデータと連携させた記事がないのはあかん！と、ふと思い立ったので、 GitBucketでTreasure Workflow (Hosted Digdag)のソースコードをGitBucketで管理しつつ、GitBucketにPushしたら自動でTreasure WorkflowにPushされるようにしてみます。 GitBucketの他に、これまたtakezoeさんのGitBucket CI Pluginを組み合わせてTreasure WorkflowへのPushを実現します。 github.com 注意: 下記ブログにもある通り、GitBucket CI Pluginを用いた連携はあくまでお試しの設定です。あ

3/9（土）にクラウドサポートエンジニアRecruiting Dayという、サポートエンジニアを世の中に増やしていくためのイベントを行いました。 クラウドサポートエンジニアRecruiting Day！ | Peatix 本記事では、開催に至るまでの背景や集客、イベントのアンケートについてのまとめなどを今後の知見のためにもまとめていきたいと思います。 謝辞 開催の背景 イベントの内容 イベント開催後のアンケート 託児サービス イベントをどうやって広めるか Twitterでの告知 Twitter広告での告知 ポッドキャストのスポンサ広告 その他 今後の活動 謝辞 イベントを開催するにあたり、登壇を快く引き受けてくださったGithub, CircleCI, Redhat, はてな, Fastlyのみなさまに感謝いたします。 また、Fastlyさんにはフードスポンサーをしていただきました。ありが

トレジャーデータは、Customer Data Platformをいうサービスを提供して、様々なプラットフォームとのデータ統合を可能にしています。 その中で、FacebookやTwitter、Instgram, Google Adsなどの広告配信のプラットフォームへの連携もしています。 僕自身はずっとトレジャーデータサポートのサポートとしてこうしたプラットフォーム連携時の不具合調査とかをしたりしてはいるものの、 サポートなので自分ではそもそも広告配信とかしたこととかがないわけです。 しかし、デジマのプロを支援するためには、自分もそれ以上のプロにもならないといかんなーとも思うわけです。というわけで、勉強も兼ねてTwitter広告でプロモツイートをしてみることにしました。 目的もなくプロモツイートをしてもしょうがないので、現在企画中の下記のクラウドサポートエンジニア転職イベントの集客を図ってみ

ELT(Extract Load Transformation)が一般的になり、データの整形を行ったり、名寄せをしたり、非正規化をしたり、といったことをクラウドのSQLエンジン（BigQuery, Redshift, TreasureData, EMRなど）上で行うことも普通になってきた。 このときにSQLで冪等にワークフローを組むことを考えると、中間テーブルをReplaceしつつ色んな処理をするのが手っ取り早い。そのため、テンポラリの中間テーブルを大量に作られていき、最終的には数十テーブルといった単位でテンポラリテーブルが作られるようになってきた。 また、データ分析も1つのサービスの分析だけでなく、複数のサービスを横断して分析する必要が出ており、またその時のログを集めるにも多種多様なSaaSを用いて収集するのが一般的になってきている。 ETL vs ELTのイメージ図（SAP Hanaの

もう少しで2018年も終わりますね。 トレジャーデータのサポートKPIを使って、2018年はどんなサポートだったかを簡単に振り返ってみます。 （KPIは全てグローバルでの数値になっています。それは僕がグローバルのサポートエンジニアリングマネージャだからです。） 新規チケット数 今年は１年間で約6500チケットが新規で発行されました。 2017年と比べて130%増えました。 一般的にサポートチケットというのは減っていかないといけないように思われがちですが、 SaaSのB2Bのビジネスにおいては、顧客数の増加や機能追加に伴う新規・既存顧客からの問い合わせも増えるので、チケット自体が増えること自体は悪いことではないです。 とはいえ、複数のお客さんから同じような内容をなんども聞かれないような仕組みというのをどんどん作っていきたいですね。 どんなコンポーネントに質問がきているか？ トレジャーデータに

Pixelaとは blog.a-know.me pixe.la そしてGemも sue445.hatenablog.com github.com だったら過去データ用にEmbulkかな というわけで作った。（あいかわずテスト無しjruby plugin...） 利用方法 ユーザ登録と登録対象となるグラフについては事前に作成の必要があります。 $ gem install pixela $ irb > require "pixela" > client = Pixela::Client.new(username: "YOURNAME", token: "YOURTOKEN") > client.create_user(agree_terms_of_service: true, not_minor: true) > client.create_graph(graph_id: "YOURIDNAM

サポートエンジニアNightは、B2Bサービスを提供するサポートエンジニアを中心としたミートアップです。 この記事ではなぜサポートエンジニアを中心としたイベントを始めたかについて書いていきます。 みなさんのサポートエンジニアのイメージってどうですか？ 皆さんは、”サポートエンジニア”という職種を聞くと、どんなイメージを思い浮かべますか？ 電話とかでお客さんとかのトラブル対応して辛そう デベロッパーの前の足掛けの職種？ そもそもサポートって響きがなんか・・・ こんなイメージでしょうか？ もしくは、そもそもサポートエンジニアという職種が何をしているかそもそもよくわからない、そういったことはないでしょうか？ こうしたイメージはベンダーとユーザ企業の間に挟まれてエスカレーションだけをするサポートや、コールセンターのサポートといった非エンジニアの職種から派生してきて生まれているイメージなのではないか

Toru Takahashi Secret Ninja - ToruTakahashi - Support Engineering Manager @ TreasureData, Inc. twitter rss