サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
今月の「かわいい」
blog.torut.tokyo
機能リリースにあたって”フィーチャーフラグ”を使って、特定のユーザにのみリリースをしたりするやり方が一般的になってきたように思う。 また、launchdarklyのようなフィーチャーフラグに特化したサービスなども出てきている。 https://launchdarkly.com/ トレジャーデータでもフィーチャーフラグを利用して顧客にサービス提供を行なっているが、今まで経験してきた中で、こんなフィーチャーフラグを作ってしまうと後々困るから気をつけようね。って話をしてみる。 ちなみにここではオペレーションの観点からフィーチャーフラグの気をつけないといけない点を挙げる。 また、下記でいうところの"Experiment"または"Permission"に当たることが多い。 Feature Toggle Types | Unleash 1 - え、PMが機能リリース後にやめちゃった。 正確なデータがあ
コンテキストが共有されていないことによって、質問の意図が汲み取れず、回答にたどり着くまでに非常に時間や手間がかかってしまう様子が散見されてたので、下記のツイートをしたところ、それなりに皆さん困っているんだな・・・っていうのが見受けられたので、社内向けに英語で書いた内容をDeepLとかを使って日本語にざっくり直したので、言葉の揺らぎなどもあるが記事として残しておく。 質問の仕方が悪い人は、最終的に実現したいことを言わずに、目の前の問題とか自分が今やってトラブってることしか言わないんだよな。会社に行きたいけど、途中の道が通行止めです他にどうやったらいけますか?ってきけばいいのに、通行止めの道を通りたいんだけど通れない、なぜ??って言う感じ。— Toru Takahashi (@nora96o) March 10, 2021 そもそもなぜ良い質問の仕方を学ばないといけないのか? 当たり前のことか
ビッグデータというバズワードが囁かれ早幾数年がたち、どの企業でも当たり前に数十億数百億数千億というデータを扱える時代になりました。 その一方で、Garbage in, Garbage outのように使えないデータを集めても意味がないみたいな話もあります。 プラットフォームのサポートをしていると、様々な顧客がいて、当たり前のように巨大なログデータや顧客データを扱い、そうした顧客の複雑な問題やクエリの書き方のような初歩的な質問だったりを解決してきました。 問題を日々解決していると、たまにマンネリになるときもあり、回答が雑になってしまいそうなときもあります。 しかし、そんなときはいつもとある顧客のプレゼンを思い出し、顧客が問題を解決しデータをちゃんと使えるようになることで生まれるデータの価値を考え、気を引き締めてサポートしています。 その顧客のプレゼンとは、2018年のPlazmaのイベントで登
*自分の整理も兼ねて トレジャーデータのテクニカルサポートエンジニアには、大きく分けて4つの役割がある。 Customerの問題解決 Developerの問題解決 Productの問題解決 Customer Successの問題解決 これらの4つの問題解決の役割を通して、 顧客体験の向上 サービスの利用促進 顧客との信頼関係の確立 を実現している。 それぞれの問題解決について説明していく。 顧客の問題解決 顧客はサポートに対して、Email / Online Chatなどを介して問い合わせができる。 問い合わせの内容は、使い方の質問、エラーの解決方法、パフォーマンスチューニング、アーキテクチャの相談など様々である。 サービスの機能も多種多様であり、外部サービスとのコネクタだけでも200以上存在している。各種コネクタの外部サービスの仕様を把握しつつ、調査や質問に回答しなければならない、という
adventar.org トレジャーデータは、グローバルにビジネスを展開するB2Bのクラウドサービスを提供しています。 現在グローバルで400社以上のお客様が利用しています。 よくあるSaaSのサポートでは、ドキュメントベースでの回答を行うL1サポートと技術力を持ったテクニカルサポート、さらにサポートでは解決できない場合にはデベロッパーへのエスカレーションが行われるような構成を取ることが一般的です。 しかし、トレジャーデータでは、全てのお客様に迅速に・適切に問題が解決できるように、L1サポートを持たず、全てテクニカルサポートエンジニアによって問い合わせへの対応を行なっています。 そこで、B2Bのサービスにおいてトレジャーデータのような顧客数・サポート体制のときにどの程度の問い合わせがあるのか、といったサポートに関連したメトリクスの内容についてはあまり紹介されることがすくないため、今回はいく
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は全てグローバルでの数値になっています。それは僕がグローバルのサポートエンジニアリングマネージャだからです。) 新規チケット数 今年は1年間で約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サービスを提供するサポートエンジニアを中心としたミートアップです。 この記事ではなぜサポートエンジニアを中心としたイベントを始めたかについて書いていきます。 みなさんのサポートエンジニアのイメージってどうですか? 皆さんは、”サポートエンジニア”という職種を聞くと、どんなイメージを思い浮かべますか? 電話とかでお客さんとかのトラブル対応して辛そう デベロッパーの前の足掛けの職種? そもそもサポートって響きがなんか・・・ こんなイメージでしょうか? もしくは、そもそもサポートエンジニアという職種が何をしているかそもそもよくわからない、そういったことはないでしょうか? こうしたイメージはベンダーとユーザ企業の間に挟まれてエスカレーションだけをするサポートや、コールセンターのサポートといった非エンジニアの職種から派生してきて生まれているイメージなのではないか
TreasureDataというBtoBのSaaSで、10数人の頃から100人規模になるまでTechnical Support Engineer (今は、Support Engineering Managerだが。)として社会人1年目から関与し、かれこれ4年がたった。その中で、最初期は人数も少なかったので、Sales Engineerのようなこともしたりしていた。日本のエンジニア界隈では、上記のような経験をしている人はそんなに多くないように思うので、BtoBのSaaSにおけるSE/Supportにおける顧客のサービス導入時の役割についてとりとめもなく書いてみる。 (書いている途中で力尽きたのでそのうちちゃんと改めてまとめたい。) 前提 初めに、SaaSのポジションで、SEといったらSales Engineerを指す。どんなことをしているかは、Clouderaの方が書いたブログを参照すると良い
背景 トレジャーデータのテクニカルサポートでは、問い合わせ対応・不具合調査・クエリパフォーマンス改善・ドキュメンテーション追加などトレジャーデータに関わる困ったことを何でもサポートしている。 そこでサポートを通して、より良いサービスを提供できるように、サポートの活動状況・問い合わせ傾向などを知ることが必要になる。 そのため、サポートのKPIダッシュボードを種々用意し、KPIを元にデータドリブンより良いサポートを提供できるようにするための取り組みを進めている。 また、サポートのためだけでなく、エンジニア・セールス・プロダクトなどそれぞれのチームに合わせたサポートKPIダッシュボードを用意することでより良い効果が得られると考え、種々取り組みを行なっている。 ざっくりと下記のようなことを実現できると良いと考えている。 エンジニアのチケットエスカレーション数を見て、特にエスカレーションが多い機能に
Toru Takahashi Secret Ninja - ToruTakahashi - Support Engineering Manager @ TreasureData, Inc. twitter rss
背景 トレジャーデータのテクニカルサポートでは、問い合わせ対応・不具合調査・クエリパフォーマンス改善・ドキュメンテーション追加などトレジャーデータに関わる困ったことを何でもサポートしている。 そこでサポートを通して、より良いサービスを提供できるように、サポートの活動状況・問い合わせ傾向などを知ることが必要になる。 そのため、サポートのKPIダッシュボードを種々用意し、KPIを元にデータドリブンより良いサポートを提供できるようにするための取り組みを進めている。 また、サポートのためだけでなく、エンジニア・セールス・プロダクトなどそれぞれのチームに合わせたサポートKPIダッシュボードを用意することでより良い効果が得られると考え、種々取り組みを行なっている。 ざっくりと下記のようなことを実現できると良いと考えている。 エンジニアのチケットエスカレーション数を見て、特にエスカレーションが多い機能
このページを最初にブックマークしてみませんか?
『blog.torut.tokyo』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く