私はソフトウェア開発の傍ら、そのソフトウェアに問題や不明点があったときの問い合わせにも対応してきました。その経験をもとに、本記事ではソフトウェアへの問い合わせ対応に関する私なりのプラクティスを集めました。
お客様を直接サポートする部門の担当者というよりは、主に彼らからのエスカレーションを受けて対応するような、開発組織内におけるサポート業務の担当者向けの内容になります。
1. いきなり問題を解こうとせず、問題に関する情報が足りているかを確かめよ
バグレポートとして成立しているか？
問い合わせの内容がバグレポートに相当する場合、解決のために必須となる情報があります。
バグレポートには、必ず次の3つのことを書く必要があります。
- バグの再現方法(できるだけ詐しく)と発生頻度
- 本来の仕様(バグがない場合の望ましい動作。こうあるべき、という自分の意見でかまわない)
- 実際の動作(完全でなくても、自分の記録した範囲で詳しく書く)
いずれかの情報が欠けている場合、いくら時間をかけても解決はできません。このため、まずはこれらの情報を手に入れるための行動をしましょう。
本当に解くべき問題か？
問い合わせ対応の仕事は、コンシェルジュの仕事に似ています。コンシェルジュの仕事は、聞かれたことに対する回答だけではなく、お客様の満足と快適さを追求するために、本当の課題を解決することです。
しかし、あなたに問い合わせた相手は、あなたのことを単にソフトウェア機能の仕様を回答する係であると認識しているかもしれません。その結果、あなたへの質問の内容には本当の課題に関する情報は含まれていない可能性があります。
聞かれていることは、お客様の満足のために本当に最初に解くべき問題であるか、見極めるための行動をしましょう。
2. 仮説を高速に検証せよ
先の見通しもなく時間を浪費せず、仮説を立てて確かめよ
問い合わせ対応の仕事は、探偵の仕事にも似ています。名探偵が活躍するアニメ・漫画を思い浮かべてみてください。彼らは現場を闇雲に引っかき回すのではなく、頭の中でいくつかの仮説を立てたうえで、その仮説から真実を絞り込んでいくために現場を捜査しています。
仮説思考を意識した行動習慣を身に着けましょう。仮説思考については、詳しくは下記の記事にまとめています。
ボールを抱えたままにせず、着手から1時間以内に返信せよ
問い合わせ対応の仕事は、少しずつ膨らんでいく風船にも似ています。何もせずに放置していると、どんどん問題が大きくなり、最終的には破裂してしまいます。
このため、一定の時間以内に打ち返せるようにしましょう。長い時間をかけても集中力が続きませんし、短期記憶も失われていきます。1時間を目安にそこまでわかった事実を文章に整理し、何らかの依頼や質問といった形式で相手に返信できるようにしましょう。
持ち時間が限られた将棋のように、完璧な一手だという確信がなくとも、指し続けて次の局面に備えましょう。
3. 冷静に事実と意見を見分けよ
一次情報やエビデンスのある事実とそれ以外の情報を見分けよ
問い合わせの情報には、思い込みや勘違いによる誤った情報も含まれている可能性があります。それらを盲信してしまうと、いつまで経っても正解に辿りつかないかもしれません。一次情報(自分自身が確かめた事実)やエビデンスのある事実とそれ以外を区別しましょう。
また、現場の環境でしか発生しないトラブルというのもしばしばあります。「百聞は一見に如かず」という言葉がありますが、かたくなに現場に足を運ばずに安楽椅子探偵を気取るのは、自ら目隠しをして遠隔ロボットを通して手術をするようなものです。
自ら事実を掴みに行きましょう。
失われた歴史にこだわらず、最新のあなたの意見を答えよ
問い合わせに対応していると、しばしば提供している機能の想定について質問されることがあります。あなた自身が直近で開発したソフトウェアであれば回答は簡単ですが、歴史のあるソフトウェアの場合、それらの情報が失われてしまっていることは往々にしてあります。
失われた歴史の復元は困難です。また、たとえ復元できたといっても、あくまでもそれは当時の想定に過ぎません。現在とは状況が異なり、役に立たない可能性もあります。
当時の様子を想像することにこだわるのではなく、最新の状況に触れているあなたはどのように考えるのかを回答するほうが建設的かもしれません。
4. 学びをソフトウェアに反映せよ
回答に満足せず、カイゼンに挑戦せよ
問い合わせ対応は、ソフトウェアを改善するチャンスです。対応の過程で得た気付きをソフトウェアに反映できるような隙間がないか、意識してみましょう。
喉元過ぎれば熱さを忘れます。時間が経てば経つほどモチベーションは下がるものです。まだ苦労の記憶が残っているうちに、同じような問い合わせの再発防止や、早期解決につなげられるようなアイデアを形にしてみましょう。
5. プラクティスを身体に覚え込ませよ
一人で取り組むのではなく、ペアで対応せよ
開発組織への問い合わせ対応の種類は多岐にわたります。これは、ドキュメントや直接のサポート部門では解決できなかったような、難易度の高い問題がエスカレーションされるためです。
そのような問題に対して、筋の良い仮説を立てるのには知識や経験が要ります。このため、プラクティスを身につけている先輩と伴走することで、悩んで時間を浪費することを防ぎましょう。
テンプレートを利用し、型を身につけよ
論理的な回答をまとめるコツは、自由に発想して情報を発散させることではありません。型を作り、それに当てはまるように事実と意見を並べていくことです。
このため、過去の成功例に学び、思考の流れや回答の文章の型を抽出し、テンプレートとして再利用できるとよいでしょう。
おわりに
問い合わせ対応は、ただのソフトウェアの失敗や想定不足により発生してしまったコストではありません。問い合わせはソフトウェアに対するフィードバックであり、それへの対応は成功への架け橋となる創造的な業務です。
取り組む姿勢次第でソフトウェアも個人も学びを活かせるため、有効な機会として活用できるようにしたいですね。