Webサービス事業会社で働いていると、カスタマーサポート への仕様回答をしたり、社内システムの仕様調査の依頼を受けることがあります。
世の中的にこの業務を何というのか良くわかりませんが、個人的には仕様調査、仕様回答 業務と呼んでいます。この業務について意識したほうが良いこと、注意点などを記載します。
仕様回答は高スキルが求められるタスク
直接エンドユーザー、社内のビジネス部門、サポート部門に回答を返すタスクは様々なジャンルの能力が求められ、経験の少ないエンジニアだと難しかったりします。具体的な作業の流れは以下になります。
- 他部門からの質問を受け付ける
- 質問の内容を把握する
- 現行システム調査
- システム観点での回答事項をまとめる
- 他部門向けに「4」の内容を変換して回答。
具体的に以下のような能力が求められます。
技術面でのスキルと、ビジネス面でのスキル(いわゆるコミュニケーションスキル)の両方ですね。
- ビジネス部門の質問、要望を把握する能力
- システムの仕様調査に関する能力
- ビジネス部門に対して回答を作る能力
作業の流れから考える意識すべきこと
1. 他部門からの質問を受け付ける
他部門からの質問を受け付けるフェーズでは以下のような意識すべきことが浮かびました。
-
問い合わせ発信元が誰なのかを把握する
問い合わせ発信元のチーム、所属部署から質問の背景、文脈の調整ができることがあります。
どの部署からの問い合わせなのかを把握しましょう。 -
回答納期がいつなのか？の確認と調整をする
回答納期の記載がない場合、且つすぐには答えられない質問の場合、回答納期を確認しましょう。 また、対して重要そうにも見えない問題が、クリティカルな問題と同様の回答納期が設定されている場合もあります。本当に優先度が高い問題なのか、期限設定の理由を確認しましょう。
-
関連FAQの存在を確認する
社内FAQや、公開されたFAQがある場合、FAQの内容を確認しましょう。 問い合わせ発信元がFAQの存在を知らないケース、FAQの対象情報を見つけられなかったケースがあります。
-
過去問い合わせ履歴を確認する
社内FAQと同様で過去の問い合わせ履歴を問合せ元が発見できないケースがあります。
過去に同様の問合せが発生していないかを確認しましょう。 -
時間がかかりそうなら、作業を始めた旨をまず返信する
まず、要求を受けとった旨と調査に取り組んでいる旨をすぐに返信した方がいいでしょう。
問い合わせ元が社内の人間とはいえ、顧客として捉えた方が良い関係を築けます。
2. 質問の内容を把握する
質問の内容を把握するフェーズだと、以下のような意識すべきことが浮かびました。
-
質問の文書の意味を理解できるか？
質問の文書に使われる言葉は、一般的なビジネス用語であったり、ある特定の業界ドメインに属する用語であったり、企業固有の用語であったりします。わからない言葉が多ければどの分類に属する情報なのか分析して、用語の学習をした方が良いです。
-
文章読解力
質問の内容の把握に基本的な文章の読解力が身についているのか、いないのかは重要に思います。 私自身があまり得意ではないのは置いておいて、読解力に自信がない人は読解力を身に付けることも検討した方が良いと思います。
3. 現行システム調査
調査対象の機能に関するドキュメントがあれば、ドキュメントを読解する。
IDEで質問に関連するプログラムの対象箇所を確認するフェーズです。
システムの分析手法や、ノウハウを知っておくと現行仕様がわからないケースでも、一歩一歩作業を進められるかと思います。 個人的に目についたWebの記事は以下になります。
- 書評『レガシーソフトウェア改善ガイド』を読んで - kenju’s blog
- 大規模な現行システムを効率的に見える化する技術
- 現行システムの分析あるいは考古学 - 勘と経験と読経
- 変更の影響範囲を特定するための「標準調査プロセス」の提案
4. システム観点での回答事項をまとめる
- と 5. は、実際の問い合わせ回答ですと、渾然一体となっていますが、敢えて分けました。 システム観点での回答事項をまとめる フェーズと、その内容をビジネス部門に説明するフェーズに分かれます。
-
技術文書の書き方を意識する
一般的な技術文書の書き方を知る。書き方を理解するのは重要に思います。
以下の文書が参考になります。 -
文書校正ツールを使用する
人間とは間違いを犯す生き物で、文書に誤字脱字はつきものです。文書校正ツールで文書の誤りを検知できないか試してみましょう。個人的にはtextlint、redpenを使うことをお勧めします。
-
調査報告書としてのフォーマットを意識する
仕様回答は、仕様調査報告と捉えることができます。調査報告というフォーマットを意識、テンプレートを持つことで、記載内容の抜け漏れは削減できます。
5. 他部門向けに「4」の内容を変換して回答。
最後のシステム観点での回答をビジネス部門向けに変換するフェーズです。
-
問い合わせ発信元の言葉を使う
無駄な認識齟齬の発生確率を下げるため、問い合わせ元の言葉に合わせて、文章を変更します。 また、同義語、類義語で幾つも同じ意味の言葉を使わないことも、認識齟齬の確率を下げるのに寄与します。同じ意味で使っている文言は同一文言を使います。
-
できるか否かの問い合わせでできない場合は、代案を提案する
できない旨の回答だけでは、問い合わせ元がその回答を受けて行動を起こすことができません。
問い合わせ元が次の行動を取れるように、代案を提案しましょう。 -
文書を見返して冗長な部分を削る
文書を読み直して、冗長な部分を削りましょう。
-
過去の関連問い合わせを参考にする
過去に関連する問い合わせがある場合は、その問い合わせを参考にすることで、回答作成時間を削減できます。過去に問い合わせ解決に至った実績のある文章ですので、直接参照してもらうことが可能であれば、URL自体を記載して参照を促せば文章自体の記載量の少なくなります。 -
問い合わせ元が必要とする情報を先に記載する
調査報告のフォーマットだと調査結果を最後に記載する場合があります。
仕様回答であれば、仕様の内容が先にあるべきで、込み入った仕様の場合は一言での説明と詳細な説明に記載を分けましょう。
また、問い合わせ元が必要としていない補足情報は思い切って削除でも良いかと思います。
システムの調査内容の詳細は、ビジネス部門にとっては不要な可能性が高いです。 -
システム用語などの技術的な専門用語を書き換える
回答を読む相手は技術的な専門用語がわからない可能性があります。専門用語は理解が容易な言葉に書き換えます。この辺りはアクセシビリティ 関連のWebページが参考になります。
実際にどのような言葉を使うべきかがわからない場愛は、ユーザー向けのFAQへヘルプページを確認してみましょう。技術的な用語が別の言葉に置き換えられて説明されていることが多いです。
参考
文書作成中に、 以下の記事を参考にしました。
- カスタマエンジニア - Wikipedia
- ［要件定義編］現行業務，現行システム調査を回避してはいけない | 日経クロステック（xTECH）
- カスタマーサポートのベストプラクティスガイド | ヘルプセンター
- Roll out and manage multiple service channels_ja.pd
- カスタマーサービスの「セルフサービス化」、「ノンボイス化」が企業にもたらす影響 - ソリューションバーチャレクス
- カスタマーサポートで使うメール定型文3選と10のポイント【テンプレートあり】 | Tayori Blog
改めて仕様回答の流れと意識するポイントをまとめてみて、勉強になりました。
自分も含めて誰かの参考になれば嬉しいです。
以上です。
コメント