カスタマーサポートを支える開発者として考えた事

このエントリはパッケージソフトウェア開発 Advent Calendar 2014の18日目です。

昨日はアプレッソ開発部の広瀬さんによるSubversionからGitに移行してみる #3でした。

はじめに

私がパッケージソフトウェア開発に携わっていたのは数年前の事になり、
色々と現状とは異なる点があるかもしれない事を最初にお断りしておきます。

エンタープライズ向けパッケージ製品の開発に携わっていた頃の話をします。
そこでは製品の品質を高めるために、対面でのコミットレビューなどによるソースコードレベルでの品質向上や、
優秀なQAチームによる厚いテスト・品質チェックなどが行われていました。
私自身、レビューを通してリーダブルでメンテナブルなコードの書き方やそれを実現するために気をつける事を沢山学びました。
QAチームに発見してもらう事で不具合や互換性の無い状態を外部に出さず助けてもらった事も何度もあり、
またQAの視点を知る事によりコードを書くのみでは気付かなかった不具合を出さないために気にしないといけない事を学びました。

その組織ではエンドユーザーや代理店からの問い合わせを受けて適切に対応するサポートチームも強力で、
多くの問い合わせについてはサポートチームの保有するナレッジなどから適切な対応を取っていましたが、
ソースコードを読み実装からの調査が必要など一部の問い合わせに対しては開発チームが行う事になっており、
一時期そのような業務に携わっていた事があります。
そこで考えた事を紹介したいと思います。
(立派な事を書こうと頑張ってはみましたが、私自身数々の失敗を経て気付かされた事ばかりです。)

回答までの速度を気にする

エンドユーザー→代理店→サポートチーム→開発チームとエスカレーションされていく間に、
開発者視点では問い合わせ当日であっても
エンドユーザー視点では数日待たされているケースがありえます。
悠長に構えていると最初はそうでもなかったのに事態が良くない方向へ進んでいくかもしれません。
慌てて的はずれな対応をしても解決には向かわないため、迅速かつ正確な対応が必要です。

足りない情報は聞き返す

問い合わせ内容を見て、ログが揃っていたり発生状況が分かっていたりすれば
まず同一状況を作って再現を試みたりログのスタックトレースから該当箇所のソースコードを確認するのが
解決への近道だと思いますが、
それらの情報が足りず再現も困難であれば、なるべく早く「何が欲しいか」「何故それが欲しいか」を聞き返す事が大事だと思います。
何故それが欲しいか、というのは
「思い当たる原因として○○か□□かそれら以外かが挙げられるので、まずそれを切り分けるために」というような事です。
聞き返すのを怠って憶測で調査を進めても無駄に時間が過ぎ、問い合わせ元視点では何日も何の進展も無いと思われ、
時間が経ってから聞き返してももうログが残っていないなどという事もありえます。
とはいえ、時間稼ぎのために闇雲に適当な事を聞き返しても仕方がないので、その聞き返す内容があれば何が分かるのか、
物事がどう進展するのかを伝える事が大事だと思います。

問い合わせの字面だけを鵜呑みにしすぎない

「○○という機能を実現したいがどうすればよいか？」のような問い合わせに、
「今はできないので次期バージョン以降でその機能の追加を検討する」というのは簡単ですが、
実はよくよく聞いてみると○○を本当に実現したいわけではなくて、既存機能の組み合わせで代用可能だったり
何らかの思い違いがあったりするかもしれません。
○○に当てはまる部分が、その機能は確かにあるのが妥当だよなぁ、と思える事であれば上記回答で問題ないと思いますが、
何でそんな変な事がやりたいんだろう？　何か違和感あるな？　というような事であれば
本当は望まれてもいない無駄な機能の追加を行う事を避けるのを心掛けるのも大事だと思います。
また、同じ問い合わせ内容であっても「今は導入検討段階でこの問題が解決できれば受注が見込める」
「カットオーバー前で見つかった問題である」「すでに本藩稼働中で、発生した問題により業務に支障が出ている」など
状況によって取るべき対応や緊急度が変わる場合もあるかもしれません。
問い合わせがエスカレーションされていく間に抜け落ちた情報もあるかもしれません。

守りから攻めに転じる機会を狙う

問い合わせを受けて調査しているうちに再現できて、
ソースコードを見ると「ああ…ここの行書き換えるだけで解決できるぞ…」という事がたまにあったりします。
修正してもすぐにそれを提供できないのが辛いところですが、
せっかく修正したならローカルでもフィーチャーブランチでもいいので残しておきましょう。
リリースには様々な調整が必要ですが、
いざ次期バージョンに加える機能の検討に入ったときや同一箇所の別の修正のリリース機会があったときに
スッと修正したものを出せる状態にできていると理想的です。
開発者なら、コードを書いて問題を解決できるのであればそうしたいものです。

問い合わせ元や問い合わせ内容を敵視しない

非常に大事な事なので最後にもってきました。
サポートチームからの問い合わせが不具合を責められているような気がして、
つい「いや不具合じゃないです！」という態度になったり
開発者目線では当たり前の問い合わせに気を悪くして適当な対応であしらおうとしたりしても
事態がこじれるだけで解決には決して向かいません。
問い合わせの根幹には困っている人がいて、それを解決したいというのは
エンドユーザー・代理店・サポートチーム・開発チーム全てに共通の目的のはずです。
直接ソースコードを読み書きできる開発者が偉いように思ってしまうかもしれませんが、
サポートチームは顧客対応のプロですし発生した問題をどのように解決に導くかという能力ははるかに高いです。
また、ほとんどの問い合わせは開発チームに来る前の段階で防いでくれています。
開発のプロとして自身の技術力にプライドを持つのも大切な事ですが、
同時に顧客対応のプロに対する敬意を忘れてはいけません。
似たような話には、テスト中に検知した不具合を問い詰められているような気がして
QAチームを敵視してしまう、というような事がありますが
こちらも不具合を含んだまま製品を世に送り出さない、品質をより高めたいという共通した目的があるはずです。

味方と足並みを揃えて困難に立ち向かっていきましょう。

おわりに

カスタマーサポートを支える開発業務、なかなかにタフなものでした。
そもそも開発チームまで問い合わせが来る時点で、過去に事例がなかったり実装の奥深くに関わってきたりと
難易度が高いものが多くなります。
味方と足並み揃えて、と書いたばかりですが、
自分の保身を第一に考えて問題を相手に押し付けようとするような人や、
無茶な要求でも自分の言い分は当然通ると思い込んでいるような人が間に立ち塞がりややこしい事になったりもします。
しかし、ソースコードだけを相手に開発を行う時とはまた違った学びもあります。
例えば、開発者視点ではよかれと思って実装した機能が実は全然使われていなかったり、
逆にそんなに労力をかけず作ったものが凄く喜ばれたりといった事がありました。
また、複数の問題に対してどのように優先度をつけてどれだけ迅速に物事を進めていくかなど、
状況判断や問題解決の能力もずいぶん鍛えられました。
そうして得られた経験は私の以降の開発業務にも活きています。
もし同じような業務に携わられている人がこれを読まれているのであれば、
私がそうしてきたように、ぜひ全力で苦しみ、全力で楽しんでいただければと思います。

明日はアプレッソ開発部の伊藤さんによるQAのテストを支える「ガイドライン」とは？です。

併せて読みたい

サポートエンジニアから見たパッケージソフトウェアの開発とサポート