Technical SupportチームからCustomer Experienceチームへ

太田さんがCEOとして会社にカムバックし、ソフトバンクからの投資も受けて、ビジネスや組織にいろいろな刺激的な変化を起こしている。

Reflecting on Treasure Data in 2021 - Treasure Data Blog

そうした中の小さな変化で、プロダクトチームに所属していたドキュメンテーションチームが自分のレポートラインに組み込まれることになり、より実態に即したCustomer Experienceチームという形に名前を変えることにした。これは下記で以前述べている役割をロールとして明確化したものだと考えている。

トレジャーデータのテクニカルサポートエンジニアの役割とは - Secret Ninja Blog

チームには、サポートエンジニア、テクニカルライター、CRE、オペレーション、などのメンバーがいて、多様な取り組みを見せている。特に、@satoshihiroseさんには従来サポートチームでやりたくてもリソース不足で注力ができていなかったTDのデータを使った施策をいろんなチームと柔軟にやってもらえていて、良い成果が出せている。

CREを一年やってみたサマリー - satoshihirose.log

再編当時はテクニカルライターのメンバーも色々不安もあったようだが、種々の取り組みを一緒に進める中で、最終的にはチームの一員になれてよかった、というフィードバックももらえていたようなので、鞭と飴を使い分けてビシバシやっていきたい。

チームのミッションである"We are all about ensuring/creating the best value ever through an amazing Customer Experience and becoming the cultural ambassador of relentless customer-driven execution"を体現して、成果を今後も出していけるようにしたい。

採用活動

毎年書いてる気もするが日本におけるサポートエンジニアの採用というのは、候補者の獲得が非常に難しい。グローバルではSaaSを提供する企業が多くあり、その中でサポートエンジニアも当たり前のポジションだが、日本ではまだまだサポートエンジニアがいわゆるソフトウェアのサポートだったり、データセンターなどでの運用・サポートみたいなイメージが強い。そのため、サポートエンジニアが何をするかを知らなかったり、そもそもポジションの選択肢として入っていないケースが多い。また、社内的な都合でエンジニア職の採用担当にUSオフィスのTalent Acquisitionがアサインされていたため、日本向けの採用活動や初回のカジュアル面談を全て自分で対応していた。

そのため、チーム内やマーケチーム含めて色々協力してもらい、コンテンツ作りやイベント活動をして、サポートエンジニアの話題作りをした。

とはいえ、そもそもトレジャーデータを知らない人ような潜在的な候補者層にはなかなかリーチできないので、ひたすらビズリーチを眺めたり、Twitterを徘徊して良さそうな人にDMをしたりしていた。

片手間でやるには限界を感じていたが、エンジニア職の採用担当が日本にも新しく入社してくれたので、来年からは日本チーム全体で戦略を持って採用ブランディングをしていきたい。

メンバーのキャリア育成

キャリア育成といっても僕自身は普段大層なことをしているわけではないが、サポートメンバーの下記のお手伝いした。

Ugandaでリモートで働いていたメンバーのUSへリローケーション
サポートチームからSREチームへの6ヶ月間のテンポラリ移籍
Tokyo -> UKへのリロケーション

といっても、どれもOKOKって言って、必要な人と話したくらいだし、Tokyo -> UKのリロケーションについてはまだ終わっていない。とはいえ、メンバー一人一人にとっては大きな決断であり、それに対してOKOKと言ってあげれるというのも大事だと思っている。あとは、そうした決断をサポートしてくれる会社に感謝したい。

ドキュメント周り

日本語化

Wovn.ioを使ってプロダクトドキュメンテーションの日本語化を提供し始めた。なぜやり始めたかは下記の事例紹介で説明している。

WOVN.io | Case study page

ほぼ手をかけずに日本語ページを提供できているのでありがたい。

ドキュメントとは関係ないが、日本語化という観点で、顧客が利用するWebコンソールの日本語化については手作業で翻訳をしていたり、直近だとLog4jの対応内容について、英語ブログで出した記事を翻訳して日本ブログで出したりもしている。

Developer Portal

Customer Experienceチームとして、ドキュメンテーションチームを抱えたので、Redoc.ly(https://redoc.ly/)を使って、開発者向けドキュメンテーションを作り始めた。

Treasure Data API Developer Portal

狙いとしては、技術者向けとマーケター向けのコンテンツを分離して、ユーザペルソナに合わせたコンテンツを提供していきたいと考えている。歴史的な経緯からドキュメンテーションが混沌としているので、今年はその整理と方向性決め、サポートチーム含めて品質改善に取り組み始めた。来年は、顧客から良いドキュメントだねって言われるくらいに改善したいし、Webコンソールから柔軟に利用方法を探せるドキュメンテーションAPIなどを準備していきたい。

その一方で、開発者向けドキュメントは可能な限り開発チームに余計な負担をかけずに実現したいところだが、実際には諸々対応してもらっているので、来年にでも寿司をご馳走して誤魔化していきたい。

オペレーション周り

Salesforceのデータ管理

サービスのデータ分析をする上で、契約情報を管理するSalesforceは重要なデータソースだ。しかし、Salesforce上にある契約情報をデータ分析のために利用するのは結構難しい。それはSalesforceが営業、リーガル、ファイナンスなどのエンジニアリング以外のメンバが管理するプラットフォームであり、そしてスタートアップにおいてプライスプランというのは継続的にアップデートされていくものだからだ。つまり、SalesforceをRDBだと思ってもらうとわかりやすいが、マスターテーブルの構造が非エンジニアによって任意のタイミングで高頻度で更新されていくようなものであり、なおかつ契約情報とシステム上の定義がプライスプランを更新していくたびに乖離していく。

そのため、契約情報とシステム情報をマッピングするためのテーブルが必要になるわけで、これをSalesforce上で現状はマニュアル管理をしている。つまり、新規契約があり顧客にリソースを提供するために、そのマッピングテーブルの更新なんかもあわせてやったりするのが現状で、ここらへんのマニュアルオペレーションの自動化をするための取り組みなんかをしている。

フューチャーフラグのライフサイクル管理

フューチャーフラグがTwitterのトレンドで最近見ることが多かった気がするが、TDでもフューチャーフラグを多用している。これもオペレーションをする上で極めてやっかいな存在だ。

プロダクトがどんどんフューチャーフラグを作っていくと、それぞれのフューチャーフラグのライフサイクルが適切に管理することができず、最終的にはこれってなんでフューチャーフラグを作っているんだっけ・・・？ってなりがちだ。その一つの要因としてはUSテック企業の平均勤続年数が2年くらいっていうのもあると思う（Ref. テック企業の勤続年数と社員の学歴 – アメリカ生活の知恵）つまり、中途半端な感じで提供した機能っていうのが時間経過と人の入れ替わりと共に負債化していく。そういったフューチャーフラグを定期的に利用状況とか含めて棚卸して、いるいらないの判断をプロダクトに依頼したりこっちで判断したりっていうのを年1くらいの頻度でやって、オペレーション側の負担を減らすようにしている。

サポート周り

最近、複数チームを跨ぐような問題を解決するための草案作りをはじめた。

TDは10年も経過した複雑な分散システムだ。そのため、過去の経緯があったり、複数サービスの様々なシステムを跨ぐような問題がある時に緊急度が高くない問題は優先度が付けにくいことがある。これは、修正のために多くのチームの優先度付けが必要だったりで主体性が失われてしまったりなどで諸々のコストが大きいことが要因としてある。サポートとして、じゃあそのうちと言って放置すると忘れてしまいがちなので、問題背景やどのようなシステムが関わっていて、そしてどうやって問題をモニタリングできるか、などを一つのレポートにして、定期的にレビューできるようにしようとしている。僕自身はふと思い出してソースコード含めて一通り書き出すことができるが、僕以外の人も同じようなことができるような仕組みづくりを作っていきたいところである。

そのほかにも一年を通して、色々やった気もするが、サポートエンジニアチームは僕以外のリーダーが阿吽の呼吸でなんでも頑張ってくれるので頼りっぱなしで、個人的にはリソース的に薄い時間帯のフォローや複雑な問題系をフォローするとかをやっている。思い出して色々書こうと思ったが長くなったのでここまでで。