問い合わせは設計の敗北

昔、隣の部署のチームリーダーが行った言葉です。
問い合わせが発生しているということは設計として何らかの落ち度があったから、問い合わせが発生していると。

よくある問い合わせされる項目やシチュエーション

ぱっと思いつくのは以下の項目です。
よくあるものから上から順に並べてみました。

・説明書、ユーザーマニュアル、仕様書に書いてあることを質問する
・仕様からかけ離れた使い方をしていることに自覚がない
・定型手順や保守交換で対応が可能なもの
・障害発生（2次対応が必要なエスカレーション）
・初動対応に何らかの不備があり、対応が難しくなっているもの
・SIやサービスの都合に合わせたカスタマイズをしてほしい
・製品に不具合があり、ソフトウェア的な修正が必要なもの

どの問い合わせでも共通して言えることは、利用者側は「今」使っており、何らか困っており助けてほしい状況が発生しているということです。

いくら製品の設計が良くても、運用の設計やマニュアルの設計などが悪いと、問い合わせが発生するもと個人的には思っています。

なので、サポート役に回るときは製品が使われている証拠。
今日もお仕事頑張るぞー！という気持ちで対応することが多いです。

サポートする側の立ち回り

サポートする側は、1次対応の専用窓口、営業（プリセールス含める）、2次対応のエンジニア、サポート専用窓口、問い合わせ統括、開発チームのエンジニア、情シスのヘルプデスクなど立場が様々だと思います。

大まかな流れは、

----- ここからが初動対応  -----
1.  発生している事象の確認（ログ、コンフィグ等含める）
2. 解決してもらいたい内容の確認
3. 類似案件の確認および解決案の提示や対応
4. 解決しなかった場合は、いつまでに対応してほしいかの確認
----- ここまでが初動対応 、以下2次対応 -----
5. エンジニア等へのエスカレーション
6. 事象に関しての技術的な切り分け（仕様の範囲内外の確認）
7. 対応方針の検討と調整（合意形成）
    - いつまでに最終的に何を対応するか
    - 誰がいつまでに何をするか（分担と期限の設定）
    - 遅れが発生した時のフォロー体制の決定
8. 対応の実施と随時フォロー開始
9. クローズに向けた動き（合意形成）

ぐらいだと思っています。

特に 1 ~ 5 については、マニュアル化、システム化が可能な領域であり、対人トラブルを避けることが主眼になるかと思っています。

サポートで、ありがちなトラブルは、対人関係、初動対応のミスの2つかなーと思っています。
それらを極力避ける形は作るべきだと思いますが、個人の能力関係ないところなので、組織を運営する側がどう取り組むかにかかっている気がします。

私は、1 ~ 5 の形が決まっている企業に所属し、 5 ~ 9 を対応することが多く、パケット、ログ、コンフィグを見て技術的にどうなんだろう、誰をアサインしようか、いつまでに対応しおうか、遅れているタスクをどうフォローしようか、暫定対応と恒久対応についてどう提示しようか、だけを考えていたので、ストレス的には少ない方でした。

利用者側の立ち回り

利用者側がやれることは以下の内容かと思います。

・説明書、ユーザーマニュアル、仕様書を読む
・コンフィグ、ログを読んで、トラブルシュートをやった上で事象を伝える
・起きている事象について、時系列で伝える
・過去に同じような問い合わせがあったか確認するよう伝える
・製品がハードウェアの場合、別の機体か別の機種を手配するように伝える
・いつまでに対応してほしいか伝える
・ダメだったの代替手段（別のベンダーに切り替える）などを計画しておく

そんなにやれることは多くないです。
最終手段は、その製品を使わないということになるかと思います。

クラウド製品を使っていたりすると、その状態がいつくるかわからず、利用者側は、冗長化およびバックアップ&リストアの設計・構築を念入りにせざる得なくなる認識です。

どのようなれレベルでやればいいのか指標がわからないという人は、IPAにある非機能要件に関する資料を読むといいかもれません。レベルを高く設定するとお金がかかってしまうため、作りたいサービスが黒字になるラインでレベルを設定し、その上でシステムやサービスの設計すると、問い合わせに依存することが減るかと思います。

問われる人間性

問い合わせ対応をやると、人間は感情の生き物であることを痛感させられます。電話、チャット、電子メール、手紙、方法は、様々ですが、相手は困っているという状況を必死に伝えてきます。

問い合わせする側も、問い合わせを受ける側も人間なので、感情というものが存在します。

過去に経験した感情がむき出しになっていた問い合わせ一覧
・担当者が次々といなくなるシステムで、3日連続で深夜2時にエスカレーションが掛かってきて怒り狂う
・利用者から辛辣なお手紙を頂きクレームを分析し対応する
・営業から雑な扱いを受けて、ファームの開発部隊にリアルに泣きつく

問い合わせする側も、問い合わせ受ける側も、これを毎日やると、非常に体に悪く、日常生活に支障が出ます。

問い合わせ対応をやる上でのモチベーションの保ち方

感情的になりやすく疲弊しやすい仕事ですが、やりがいがないわけではありません。以下は、私が経験したモチベーションとなっていた事項です。

・他人ができない、長期間放置されている問い合わせを解決した
・短時間での問い合わせを解決した
・解決した問い合わせ件数の上昇
・類似事象に関する問い合わせ件数の減少
・ユーザー、関係者、開発者からのありがとうの言葉
・同じチームにいる人たちの人間性

これらは、問い合わせの仕事をやる上で自分を支えてくれていた内容です。

特に同じチームにいる人たちがどれだけ感情を抑えるようにお互いが作用するかは重要でした。感情を抑えるのに1日の中で3〜4時間話し合うこともありました。
倫理的にどう考えて対応を進めるべきか、理不尽な対応に怒るべきところは一緒に怒ったり、関連する組織や事前にある枠組みなどについて共有されたり、色々、助かった部分が多かったです。

また、私にとって問い合わせの実績が記録されているのは非常によかったです。サラリーマン的に通信簿をつけるタイミングのとき、定量的に上司に説明ができるため、毎回、目標面談で悩まなくなりました。
そして、早く問い合わせ対応を解決してやろうというモチベーションにも繋がりました。

最後に

問い合わせ対応は、今の利益を確保する作業であり、次の信頼を勝ち取る作業であると私は考えています。

問い合わせする側は、非常に困っています。
感情的にもなりやすい状態です。

それらを想定し、問い合わせ対応する側は、動く必要があります。
それは個人だけではなく組織の作り方に大きく依存すると考えています。

想像してみてください。

チームにキツイ人がいて、辛辣な言葉を常に受けて、お客様のトラブル対応もしなければいけないし、上司からも評価を受けないシチュエーション。

長く仕事をやるには難しそうに聞こえると思います。

だから、普段から組織でどのようにサポートにあたるか形を作ったり、見合った報酬を支払らったり、労いの言葉をかけたりということは、非常に大事なのではないかと考えています。

もし問い合わせ対応で疲弊している人がいるなら、「多分そいつ、今ごろパフェとか食ってるよ。」の精神で乗り切るか、早めにその会社からは離れる選択肢をすると良いと思います。

そして、問い合わせる側も、問い合わせてダメだなと感じたら、別の手段を使うことを検討しておく必要があると思います。
社内政治的に逃げられない場合も多々あるかもしれませんが、手段と目的を履き違えてはいけません。

ずっと問い合わせして理不尽な対応する会社とお付き合いしても、お互いの工数が無駄になったり、精神をすり減らしたりするだけなので、そういうときは、そっと離れるのが正解だと思ってたりします。