CLOMOサービスのエスカレーション業務についてのご紹介

アイキューブドシステムズで製品開発運用本部のプラットフォーム運用部に所属している nakano-i3 です。

プラットフォーム運用部は、サービスのシステム運用業務（CLOMOサービスのシステム運用・監視）をしていますが、私はカスタマーサポート部門などからの技術的問い合わせを受けるエスカレーション業務を担当しています。

今回は、エスカレーション業務において、お客様（ご検討中のお客様を含む）から問い合わせを受けて、社内でどのようなルートを通り、どのような対応をしているか書いていきたいと思います。

お客様からの問い合わせ

弊社サービスは、モバイル管理のCLOMO MDMおよび、ビジネスアプリのCLOMO SECURED APPsを提供しております。

お客様からの問い合わせを大きくカテゴリーに分けると、以下となります。

「ユーザーはどうすれば登録できるの？」などサービスの利用方法に関すること
「ユーザー登録操作をしたけども画面に表示されない」などサービス利用時の挙動
「デバイスはどんな種類が登録できるの？」などサービスの仕様確認
管理している iOS、macOS、Android、Windows のデバイスの挙動
管理画面のセキュリティ対策の確認

問い合わせを受けてからの流れ

お客様から問い合わせを受ける部署は、新卒採用サイト - Q.どんなことをする部署ですか？（業務内容）やキャリア採用サイト - 私たちの組織に書いてある「カスタマーサクセス本部」ならびに、「営業本部」のメンバーが対応します。

問い合わせを受けた部署で、一次調査を行っても原因が特定できない場合に「製品開発運用本部」へエスカレーションが行われます。

エスカレーションの内容は、調査依頼・作業依頼・社外ベンダーへの問い合わせ・仕様確認があります。エスカレーションの内容によって製品開発運用本部の中で担当が別れており、仕様確認については「製品開発部」で対応しますが、調査依頼・作業依頼・社外ベンダーへの問い合わせについては「プラットフォーム運用部」で対応しています。

対応フローのイメージ

プラットフォーム運用部の対応

プラットフォーム運用部では、ユーザー登録操作をしたけども管理画面に表示されないなどサービス利用時の挙動を確認する「調査依頼」、データベースに登録されているデータのメンテナンスなどを行う「作業依頼」、「社外ベンダーへの問い合わせ」を担当していますので、どんな風に進めているのかなどを書いていきます。

年間の依頼状況推移

2020年依頼状況

2020年の依頼状況のグラフにはなりますが、グラフを見ると、3月から依頼件数が上昇しており、次に6月に大きな上昇が見られます。例年3月は、部署異動や4月からの新入社員を迎える準備があり、カスタマーサクセス本部へお問い合わせの件数が増えることで、調査依頼も増える傾向にあります。

例年と異なるのは6月に大きく依頼件数が上昇していることです。例年6月はあまり依頼件数が増えないのですが、2020年はコロナ禍で本格的に在宅勤務を導入されるお客様が増えたこともあり、カスタマーサクセス本部へのお問い合わせ件数が増えたと推測しております。また、ありがたいことに新規にCLOMOをお使いいただくお客様が増えたこともあり、調査依頼件数も6月以降右肩上がりのグラフになっております。グラフの説明

どんな内容の調査依頼が来るのか

調査依頼の内容は、意図した挙動にならない場合に依頼がありますが、例を挙げると以下の様な内容です。

手順通りに操作したのに意図した検索結果が表示されない
管理画面から情報をエクスポートしたのに終了しない
デバイスの登録操作をしたのに管理画面に表示されない

社外ベンダーへの問い合わせはどんなことをするのか

調査を進めると社外ベンダー（Apple社、Google社、Microsoft社）へ問い合わせが必要なことがあります。例えば、弊社エンジニアブログにkentaroh-momiyamaさんが書いたAndroid Enterprise Recommended 2020 の一環として EMM 通知受信に対応した話の中で説明されているEnterprise Mobility Managementを利用したデバイス管理についてなどをGoogle社へ問い合わせすることもあります。

社外へ問い合わせする場合、対象のデバイス情報とWebアプリのログから社外ベンダーサーバーとのリクエスト&レスポンス結果を確認して、社外ベンダーのサポート部門へ問い合わせを実施しています。（社外ベンダーへの問い合わせは自体は製品開発部から行うこともあります。）

エスカレーション業務を担当して思うこと

私は入社してからCLOMO MDMとCLOMO SECURED APPsのWebアプリ開発、カスタマーサポート、サービスのリリース作業などに従事しつつ、兼務する形でエスカレーション業務も担当して来ました。それらの経験からエスカレーション業務を担当して思うことを書いていきたいと思います。

エスカレーション業務で必要なこと

エスカレーション業務を行うにあたり、必要なことはお客様の利用シーンや他部署のことを意識し、理解しようとすることと考えています。サービスの挙動やソースを見て仕様や実装の意図を理解しないと正しい挙動であるか、不具合であるか判断ができません。また、お客様の利用シーンや実現したいことを理解し、現在の仕様と照らし合わせて改善が必要なのか、お客さまの運用でカバーできるのか判断することも必要です。操作したけど意図した挙動にならない場合、「操作方法が誤っていた」のか「UIが良くなかった」のかを考えることで、その後の使いやすさが変わってきます。機能を実装するときに気が付けなかったことを開発者に提案していくことはエスカレーション業務では大切なことです。

そして、カスタマーサポート部門や営業部門へ回答する内容についても「条件分岐の判定がおかしかった」など開発者と同じレベルで回答すると９０%ぐらいは「何言っているか分かりません」となります。カスタマーサポート部門の方が知りたいのは、「どうやったら正しい挙動になるか」であり、「操作手順が間違っているのか」、「ソースコードの改修が必要なのか」、「データメンテナンスで解消されるのか」を知りたいということです。お客様にソースコードの作りがどうなっているか回答してもお客様は次に何をしたら良いか分からないですよね。

エスカレーション業務を経験することで得られること

エスカレーション業務を担当することで、得られたことを書いていきたいと思います。改めてエスカレーション業務を振り返ってみると、製品仕様やソースコードを把握しているだけではなく、幅広い知識が必要なんだなと思いました。

1. サービス全体の機能と機能や機能とデータの関連が把握できる

毎日ソースコードとデータベースを見ているのでソースコードとデータベースの関連が把握できる様になります。また、Webアプリの挙動も見ているので、どのデータが登録されていないと、この機能は使えないなどサービス全体の機能と機能の関連や機能とデータの関連も把握できます。

機能の関連が把握できていないと、改善を行ったことで機能Aとしては改善されたけど、機能Bの挙動が変わってしまい、お客様からお問い合わせを受けるということに繋がります。改善の提案を行う上で影響範囲を把握することはとても大切だと思います。

2. お客様の利点になる改善や機能要望が提案できる

お客様からの問い合わせ内容を見ることで、お客様が実現したいことや利用シーンをイメージしやすくなります。エスカレーション業務で必要なことに書いた「操作方法が誤っていた」のか「UIが良くなかった」のかを考えることであったり、お問い合わせの内容から現在の機能ではお客様の要望が実現できないと判断したりすることを経験して、よりお客様の利点になる改善や機能要望が提案できる様になると考えています。

3. 幅広い知識を得ることができる

自社の製品仕様やソースコード、インフラストラクチャ、ネットワークなどについての知識が無いと事象が発生している原因の特定ができません。私がエスカレーション業務を担当し始めたころ、知識がないことで調査に行き詰まることが多くあり、事象が発生している原因を特定できず、データベースやソースコードを見て彷徨っている状況でした。

全てを把握し理解することは難しいので、開発者に確認したり、有識者に確認したりすることが必要になりますが、幅広い知識を得られる様になります。また、弊社サービスがモバイル管理ということもありますが、iOSやAndroid、Windowsと各種OSの仕様や、プロトコルについても調べる必要があるので、知識として得られることになります。

各種OSの仕様や、プロトコルを調べた結果、お客様の要望を満たせないことはあります。その上で、製品仕様やソースコードを把握していることで、弊社サービス側の改善によってお客様の要望に近づけることができないか、考えられるようになります。

幅広い知識を得る

エスカレーション業務を行う時に困ったこと

エスカレーション業務を行う時に困ることは結構あったりします。調査の経験やプログラミング言語および利用しているフレームワークの知識が無いから困ることもあれば、調査依頼の内容が曖昧で依頼者に確認が必要なこともあります。ここからは、実際に私がエスカレーション業務で調査や作業を行った際に困ったことを紹介して行きます。

1. 実装する時に便利でも調査では不便なことがある

弊社サービスのWebアプリはRuby on Railsで実装されていますので、ControllerからModelへと順を追ってデータの流れを確認することが多いです。確認を行う際は、IDEのジャンプ機能で確認したいメソッドへ移動して行きます。場合によっては、Webアプリのログからエラーメッセージを出力している例外判定の箇所（raiseしている箇所）を特定して調査を開始することもあります。その場合、例外判定をしているメソッドがどこから呼ばれているかを特定しますが、メソッドの呼び方によっては、特定に時間がかかることがあります。

例の様にメソッド名を動的に変更して呼び出す実装は確かに便利なんですが、Controllerから順を追って確認している場合は特定できるけども、例外判定しているメソッドから遡って確認を進める時にソースコードを「ios_device_data_create」でgrepしてもなかなか特定できず時間がかかることがあります。そして、IDEでControllerから順を追って進んでも、該当のメソッドにジャンプすることができません。

例)

# デバイス情報を作成
def device_data_create(device_type, device_data)
  # デバイスの種類毎に異なる情報を作成
  send("#{device_type}_device_data_create", device_data)
end

# iOS 用
def ios_device_data_create(device_data)
  ios_device_data = IosDeviceData.new
  
  raise Hoge1
end

# Android 用
def android_device_data_create(device_data)
  android_device_data = AndroidDeviceData.new
  
  raise Hoge2
end

実装する時に調査やリリース後のメンテナンスを意識して「1年後に覚えてるかな？」って考えたり、「ソースコードをメンテナンスするのは他者」と考えて実装するのも大切だと思います。

また、Controllerから確認を進めても、「device_data_create」の引数にある「device_type」にどんな値が入っているのかを把握しておかないと、呼び出したいメソッドを特定できなくなります。そういう意味では、引数の名前から格納される値を想定できることも大切です。

2. ソースコードのコメントの内容を読んでメソッドの内容を勘違い

ソースコードにコメントを残すと思いますが、コメントの内容を見てメソッドやロジックが実現したいことが分かる内容になっていることが大切です。

デバイス情報を作るメソッドを実装した時に例1のコメントと例2のコメントでは、どちらが理解しやすいでしょうか。

例1：
# デバイス情報を作成

例2：
# パラメータ情報からデバイスタイプを判定して、デバイスタイプ別にデバイス情報を作成

例1は、デバイス情報を作ることは分かるけども、作られたデバイス情報がどんなものであるか、メソッドはどんな処理をするのかイメージしにくいと思います。例2の様なコメントであれば、どんなパラメータが来て、どんな情報が作られて、どんな処理がされているかイメージしやすいと思います。

調査する時にコメントからメソッドの内容やどんな処理結果を意図しているのかを推測してソースコードを見ていることもあり、コメント内容とメソッドの処理内容に乖離があると不具合箇所の特定に時間がかかったりします。ソースコードのメンテナンスをする場合も改修箇所や影響範囲を正しく確認しにくいと思います。

ここでも「1年後に覚えてるかな？」、「ソースコードをメンテナンスするのは他者」の意識だと思います。

3. 新しい機能への追従が大変

CLOMO MDMやCLOMO SECURED APPsへ新しい機能が実装されてリリースされますが、私は開発に関わっていないこともあり新しい機能についてエスカレーションが来た時に調査に時間がかかる問題があります。

弊社の場合、新しい機能が実装されてリリースするまでにエンジニアを対象とした設計説明会とサポート部門などを対象とした設計説明会の2回、設計説明会が開催されます。その中で、不明点を質問して機能を理解したり、改善した方が良い点などを挙げています。

設計説明会で説明してもらっただけで全てを理解することは難しく、ソースコードを見ても分からないことがあれば都度、開発担当者へ質問する様にしています。また、社外ベンダー（Apple社、Google社、Microsoft社）が新たに提供を始めた機能を利用できるように、CLOMO MDMやCLOMO SECURED APPsへ新しく機能が実装されますので、それぞれのベンダーのプロトコルなど、一次情報を確認することも必要になってきます。

新機能のリリース後、初めて問い合わせがあった時には調査に時間がかかるため、それまでに機能の仕様・ソースコードのロジック、外部ベンダーとの連携について理解してスムーズに調査を行える様にすることが必要ですが、現状できていないのが課題となっています。

4. 新規・既存アプリの調査は、製品開発部へお願いしている

Android向けアプリやiOS向けアプリなど、リリース済みのアプリや弊社エンジニアブログのAndroidアプリ新製品リリースプロジェクトの話でt-yusakuさんが書いたCLOMO Launcherなど新しいアプリがリリースされた後、アプリの挙動についてエスカレーションが来た場合には、製品開発部へ更にエスカレーションします。製品開発部へエスカレーションする場合でも、CLOMO MDMやCLOMO SECURED APPsからどんな設定プロファイルを設定しているかなど関係する部分の確認を行ってエスカレーションを行ったります。

プラットフォーム運用部でエスカレーション対応を行なっているメンバーは製品開発部のWebアプリ開発者が異動してきて対応していることもあり、Android向けアプリやiOS向けアプリの経験がなく調査は製品開発部にすぐにエスカレーションしているため、製品開発部に負担がかかっているのは、課題となっています。

まとめ

弊社のエスカレーション業務についてご紹介いたしました。

弊社サービスを利用する上で、問い合わせからご回答までに、どのような部署や人が関わってどんな風に対応しているのか少しでも伝えることができればと思います。

また、エスカレーション業務は会社毎に対応の進め方があると思いますが、弊社の進め方や対応に困った事例が少しでもブログを読んでくださった方の参考になれば幸いです。

最後に、アイキューブドシステムズでは継続的な採用活動を行っています。このブログを通して興味を持たれたみなさまの応募を歓迎しています！

2022年度新卒採用：https://www.i3-systems.com/new-graduates/
キャリア採用：https://www.i3-systems.com/careers/

まとめ

i Cubed Systems Engineering blog

株式会社アイキューブドシステムズの製品開発メンバーが、日頃のCLOMO開発の様子などを紹介します。