読者です 読者をやめる 読者になる 読者になる

け日記

SIerから転職したWebアプリエンジニアが最近のIT技術キャッチアップに四苦八苦するブログ

社内のQ&A対応で気をつけていること

インフラ担当者としての業務の一つに、社内のアプリケーション開発者からのQ&A対応があります。
私の場合は、自社製のライブラリやフレームワーク、導入しているソフトウェア製品などについてのQ&Aを担当しています。

サポートデスクやサポートエンジニアのような専任のスペシャリストではありませんが、普段から気をつけていることを整理しておきます。
同じような業務に携わる方の一助になれば幸いです。

問い合わせを受けた時(調査)に気をつけること

誰が問い合わせているのか

問い合わせを受けた際に、まず最初に問い合わせ主が誰なのかを確認します。
「当たり前だ」と思われるかもしれませんが、サポートデスクから対応を依頼された場合など、問い合わせ主と一切会話すること無く、問い合わせ票のみを受け取るケースもあります。
問い合わせ主がどの程度の経験・知識を持つのかを推し量って、詳しくヒアリングすべきかあるいは提供された情報のみで調査・回答すべきかどうか等を判断しています。

グループウェアで、主に以下の属性を事前に確認しています。

所属部署

部署によって内部ルールや文化・風土は様々です。 組織内で質問を整理・共有してそれでもダメならお伺いを立てるというところもあれば、「とりあえず聞いてしまってサクッとわかれば儲けもの」なスタンスで内容を精査せずに投げてみるというところもあります。
提供された情報の精度については、これら背景を勘案する必要があります。 当然後者に比べると前者の方がスクリーニングがかかっている分、情報の精度は高いです。

着任年数

大きな企業になればなるほど、社内独自の方針・ルール・組織構成・ツール等々があるかと思います。
新入社員や他部署から異動された方など、着任されてから間もない人はこうした「当たり前」を正しく理解していなかったり、そもそも存在を知らなかったりするため、かなり突拍子もない問い合わせをしてしまうことがあります。 「当然知っているだろう」という前提でこうした問い合わせを受けてしまうと、ドツボにハマることが多々あります。

役職

問い合わせ主の役職についてもチェックしています。
組織長など役職が上の人になればなるほど、概して将来の方針やルールにフォーカスしたものが多くなります。 一担当者として安易に答えられないレベルになることもありますので、適切なエスカレーションが必要となります。

勤務場所や連絡先

面着で話ができると、後述する事項もスムーズに確認できます。 電話を持っているのかもチェックしています。

どのくらい急ぎなのか

どんな些末な問い合わせでも「至急」「緊急」「なる早」と急かしてくる人もいます。
問い合わせ主が経験不足で焦っていたり、言ったもん勝ちに考えていることが多いので、ストレートに「実際のところどれくらいの急ぎですかね?」と実際のデッドライン聞いてみて、こちらの負荷度合いによっては納期の延長も相談します。

これとは逆に、本番環境での障害など本来急がないといけないにもかかわらず、標準納期を意識してわざわざ待ってしまっているケースもあります。
事情を聞いて問題の度合いを推し量り、優先度を上げて対応するようにしています。

どうすれば再現できるのか

「思った通りに動かない」「実行するとエラーになってしまうのですが」といった類の問い合わせは、こちらでの調査が必要となります。
その際に一番面倒なのは、事象を再現させることです。

手っ取り早く、問い合わせ主から事象が発生したときの情報(設定ファイルや入力ファイル、テストケース、環境設定など)を一式で提供してもらうようにしています。 問い合わせ主側でもある程度原因を推測して渡す情報を絞ろうとしますが、実際にはそれ以外に原因があることが大半であるため、可能な限り関係しそうなものは全て渡してもらいます。 (最初に問い合わせ主から自発的に提供される情報の多くは、「私たちはやるべきことをやっています、これで間違ってないよね?」というニュアンスを含みますので、当然ながらこの情報の中に誤りの原因が含まれることは稀です。)

また、再現環境の構築が難しい場合もありますので、その時は問い合わせ主側で準備してもらうようにしています。

問い合わせに答える時(回答)に気をつけること

情報の見せ方

「社内ポータル(あるいはエクセルファイル)のここに書いてあるじゃん」という回答になる場合、大抵の場合は情報の見せ方がわかりづらくなっています。
せっかくの機会なので、掲載場所やリンクの貼り方などを再検討して、同じ問い合わせを減らせないか検討します。

とはいえ、わかりやすくなるからと同じ情報を複数の場所で掲載するのは、更新が大変だったり、更新忘れがあった場合に混乱を招きますので、可能な限り一元化します。
また、わかりにくい社内ポータルやエクセルファイルでも、文句を言わずに馴染んで使っている人が大多数なので、大きな変更の場合は全体共有が必要となります。

責任分界点を明確に

責任分界点を明確にするためには、2つの視点があると思っています。

1つ目は「ここからは私の範疇ではない」と宣言する視点です。
問い合わせ主からすると、私や私の組織でコントロールできることとできないことは峻別できないものです。 なので、例えば「この製品は我々でメンテナンスしているわけではないので、ベンダに問い合わせることはできますが、仕様を変えることができません」といった具合に、こちらの責任範囲を都度伝えて、コントロールできない責任を被らないようにしています。

2つ目は「ここからはあなたの範疇ですよ」と説得する視点です。
「ライブラリの使い方がわからない」→「ここを見てください」→「こういったケースではどうやって使うのか」→「こう使います」→「こういう画面を作っているのだけど、このライブラリを使うとどうやって作れますか」→・・・と、Q&Aのやり取りが連綿と続いてしまうと、ついつい問い合わせ主の業務に足を突っ込みそうになります。 「私にもできるかもしれませんが、アプリケーションの開発・運用・保守についてはあなた方の業務なので、あなた方で責任を持って判断・採用してください」と、きっちり線引する必要があります。

伝書鳩にならない

自身や自身の部署で解決できない場合、他部署やベンダへの再問い合わせが必要となるケースもありますが、可能な限り、問い合わせ主と他部署・ベンダで直接やり取りしてもらうようにしています。
自身や自身の組織の持つ経験・知見が活かせないのであれば、やろうとしている意図や起こっている事象などの情報を正確に伝えることができる(かつ私自身の対応不可も減る)方が良いためです。
ただし、特にベンダ問い合わせの方法は様々ですので、困惑しないように問い合わせのマニュアルや過去の問い合わせ履歴なども共有しています。

まとめ

全体としては、調査では「正確に情報を引き出すこと」回答では「自身(と自身の組織)が持つ知見・経験を活かせるようにすること」を心がけるようにしています。

実はインフラ担当者にとってのQ&A対応は、アプリケーション開発者から直接お礼を言われる数少ない機会でもありますので、喧嘩することなくスムーズに解決して、好感度アップを目指しましょう。