mixi engineer blog

*** 引っ越しました。最新の情報はこちら → https://medium.com/mixi-developers *** ミクシィ・グループで、実際に開発に携わっているエンジニア達が執筆している公式ブログです。様々なサービスの開発や運用を行っていく際に得た技術情報から採用情報まで、有益な情報を幅広く取り扱っています。

Zendeskの構成を管理するツール zenform を開発しました

※こちらの記事は過去のブログから転載したものです。

こんにちは!CREの上埜です。

ZendeskというCRMシステムの構成を管理するためのツールzenformを開発し、先日OSSとして公開したので紹介したいと思います。
zenformはGo実装の zenformRuby実装の zenform-rb の2つの実装があります。私が開発したのはRuby実装です。実装言語が異なるだけで基本的な機能は変わりませんので、好きな言語の実装を使ってみてください!

作った経緯

XFLAG スタジオでは各サービスごとにZendeskインスタンスを用意しています。つまり、新規サービスをリリースするたびにZendeskインスタンスの設定をしなければいけません。

そのなかでも特に設定が大変なのがチケットフィールドとトリガーの設定です。
Zendeskは、問い合わせをチケット単位で管理しています。チケットに紐づくユーザ情報や問い合わせ詳細などを保存するのがチケットフィールドです。
トリガーはその名の通りで、「チケットが作成された」や「チケットフィールドが更新された」などの特定の操作が行われた際に、実行する動作を定義するためのコンテンツです。

XFLAG スタジオではCSスタッフの専門性に応じて担当チケットを割り振るため、チケットのカテゴリ分けをしています。
「カテゴリ」というチケットフィールドを定義し、トリガーによって問い合わせ経路に応じて各チケットのカテゴリを変更します。CSスタッフは自分の担当しているカテゴリのチケットを選んで問い合わせ対応を始めます。

プロダクトによりますが、スマホアプリの「モンスターストライク」の場合、カテゴリが約300種類あります。トリガーはカテゴリ分け以外にも様々な設定があるので、さらに増えて約500種類になります。
もちろん最初からこれだけの数の設定が必要になるわけではありません。私がインスタンス設定したときは、カテゴリ約30個とトリガー50個で人手でも入力できる規模でした。しかし、単調な繰り返し作業を2時間続けるのは思ったよりつらく、エンジニアとしてはいの一番に効率化したいところでした。

開発の工夫

機能はミニマムに

ミニマムにするためにしたことは2つです。

1つは、zenformで設定できるZendeskコンテンツを3つに絞ったことです。
Zendeskコンテンツは様々ありますが、前述の通りXFLAG スタジオで特に負担となっているチケットフィールドとトリガー、そしてチケットフィールドと関連性の高いチケットフォームの3つを設定対象コンテンツとしました。
(※チケットフォームは、ユーザ向けの問い合わせフォームやCSスタッフ向けの管理ビューを作成するためのコンテンツです。)

もう1つは、初期設定のみに機能を限定したことです。
XFLAG スタジオにおいては、先述のとおりカテゴリの種類が多いため初期設定にかなりのコストがかかりますが、運用開始後は修正の頻度が低く設定の負担も小さいというのがその理由です。
そのため、設定ファイルを読み込み、その設定に従ってそのままZendeskコンテンツを作成するというシンプルな実装になっています。今のところ、zenformで各コンテンツの設定を更新・削除することはできません。

コンテンツの依存関係の扱い方

zenformで設定対象とした3コンテンツには依存関係があります。

例えば「チケットフォーム『ご意見・ご要望』から問い合わせが来たら、チケットフィールド『カテゴリ』を『ご意見・ご要望』に変更する」というトリガーを設定できるように、トリガーはチケットフィールドとチケットフォームの2つに依存しています。このトリガーを作成するには、チケットフォーム「ご意見・ご要望」とチケットフィールド「カテゴリ」のそれぞれのコンテンツのIDを知る必要がありますが、設定ファイルを作る時点ではどちらのコンテンツも作成されていないのでIDを知るすべがありません。

この問題を解決するために、Zendesk側のIDとは別にzenform側でも各コンテンツの設定を一意に識別できるように独自にslugという識別子を用意することにしました。
チケットフォーム、チケットフィールド作成時にzenform側の識別子であるslugとZendesk側のIDの関連付けを保持しておき、トリガー作成時は関連付けを用いてslugをIDに変換し、コンテンツ作成のリクエストを投げるようにしています。

おわりに

OSSとして公開はしたもののミニマムで作ったので、下記に挙げるとおり改善すべき点はたくさんあります。

  • チケットフィールド、チケットフォーム、トリガー以外のコンテンツを設定できるようにする
  • 設定ファイルが現在CSV形式のみの対応となっているので、他のフォーマット(JSON形式やYAML形式など)に対応する
  • 各コンテンツの更新・削除をできるようにする

今後も使いやすいようにCREでメンテナンス・改善して行きたいと思いますが、ぜひ皆様もバグや改善点など見つけましたらPRを投げていただけると嬉しいです。Issueでの問題報告だけでも大歓迎です!

今回のケースではZendeskインスタンスの設定作業をCREで行っていたため、課題発見からツール化までスムーズに進みましたが、CSスタッフが行う作業の中には、我々が認識できていないだけで効率化できる作業がまだまだたくさんあるはずです。
以前 jinが紹介した一括データ復旧システム も現場の課題解決の成果の1つです。
CREが現場の課題をエンジニアリングで解決・改善することで、CSスタッフの負担を減らし、ユーザ様に信頼いただけるより手厚いサポートができるよう、今後もカスタマーサポート・CRE一丸となって取り組んでいきたいと思います。