エスカレーション先を確認する

ヘルプデスク担当者として、あるいはサポート エンジニアとしてあなたがどれだけ優秀だとしても、すべての問題をあなた一人の力で解決できる訳ではない
より専門的な知識を持っている人の助けが必要な場合もあるだろうし、問題が起きているソフトウェアのベンダーの情報が必要な場合もある。あるいはベンダーが製品サポートを提供していてそれを利用できるなら、問題の調査と解決を丸投げできる場合だってある。
だから対応しなければならない課題について、別の誰か (どこか) にエスカレーションするパスを確認しておくことは、ヘルプデスクやサポートの業務において重要だ。

これは何も技術的な事に限った話ではなく、非技術的な事柄、例えばユーザーが「クレーマー」化してしまった場合の対処や、技術的な対応が業務としての合理的な範囲では困難である場合の対処など、あなた一人の対応や判断では事態を収束できない場合にも、会社としてより上位の権限や権能を持つ人 (や部署) に対処や判断を委ねる必要が出てくる。
だからこうした技術的 / 非技術的なエスカレーション先を常に確認し、適切に機能される事はあなたが仕事としてヘルプデスク業務や IT 担当者、サポート担当者としての業務を進める上での安全弁であり、セーフイーネットでもある。

技術的な面で言えば、あなたが大きな組織の中の一部分についてのヘルプ / サポート担当者であれば、組織全体の IT サービス部門やサポート部門が存在しているだろうし、(本来であれば) そうした部門とあなたのような現場担当者がどのように役割を分担し、どのように連携するのかを決めたルールが存在するはずだ。ルールがあるのならその内容をよく確認し、エスカレーションの方法や手続きを確認しておこう。もし (残念なことに)  ルールが存在しないのなら、そうした部門への (ある意味個人的な) コネクションを作る必要があるかもしれない。もちろん正しいのは「組織の正規の意思決定経路を通じてルールの制定を上申する」事なのだが、そうした意思決定が現実の問題に間に合うかどうかは分からないのだから。
正規のルールに則るにせよ、個人的なコネを活用にするにせよ、組織全体の IT サービス部門やサポート部門にエスカレーションができるようになれば、少なくとも一人では解決できそうにない問題やトラブルを際限なく抱え込む事態は避けられるはずだ。

あなたが組織内でたった一人の (またはごく少人数の同僚だけの) ヘルプ / サポート担当者の場合、上記のような組織内の技術的リソースに頼ることはできない。しかし問題の原因はあなたがスクラッチで作ったソフトウェア ツールであなた以外にそのツールの詳細を知る人が居ない…というのでもない限り、不明点があったりトラブルが起きていたりするシステムやソフトウェアには作成者または専門的な知識を持つ人 (組織) がどこかに居るはずだ。そうした人はエスカレーション先になり得る。
一般的な言い方をすれば、企業で使われているソフトウェアやシステムでは大抵の場合、何らかのサポートが得られるはずだ。市販のソフトウェアであればそのメーカーがサポートを提供しているし、SIer を通じて導入したソフトウェアやシステムであれば、その SIer がサポート窓口になっている場合が多い。「フリー ソフト」やオープンソース ソフトウェアでもコミュニティー ベースのサポートが得られたり、有償のサポートを提供している業者を見つけられる場合がある。こうしたサポートはあなたの問題解決に役立つはずだ。これは組織全体の IT サービス部門やサポート部門がある場合でも同様だ。

しかし「サポートが提供されている」という事と、「あなたがそのサポートを利用できる」という事は別だ。「フリー ランチはない」のと同様、まったく何の見返りも期待されないサポートは無い。コミュニティー ベースのサポートのようにお金を対価として要求されない場合もあるが、それでもコミュニティーへの貢献は常に期待されているのだから。
そこで「どのようなサポートが利用できるのか」「サポートを利用するためにはどうすればいいのか」を確認する事が必要になってくる。

メーカーやベンダーがサポートを提供している場合、サポートの利用条件は大きく別けて二つだ。一つ目は製品の購入で、要するに購入した製品にアフターサービスとして一定の期間や回数分のサポートが含まれているパターンだ。もう一つは有償のサポート契約で、これは製品価格にはサポート サービスは含まれておらず別途必要なサービスを購入してくださいというパターンになる。
こうした条件付きのサポートとは別に、最近ではほとんどのメーカー、ベンダーが無料で利用できる Web 上のサポート情報や Q & A を公開しているが、これは「エスカレーション先」にはならないのでここでは触れない。こうしたサービスからの情報収集については別に記事にしたいと思う。
製品に付属している場合でも別途契約する場合でも、今の時点でそのサービスが利用可能なのか、またそのサービスはどのような範囲で提供されるのかを知っておく事は、いざという場合のエスカレーション先の確保として重要だ。

市販の製品に付属するサービスの場合、大抵は製品自体のドキュメントに記載があるだろうし、メーカーやベンダーの Web サイトにもサービスの利用方法が掲載されている。利用している市販のソフトウェアのそれぞれについて、時間のある時にサポートの利用方法を確認し、エスカレーション先の資料としてまとめておくとあなたにとって便利なだけでなく、あなたの同僚や後継者にとっても有益だ。もちろん資料のメンテナンスは忘れず、またメンテナンスの必要性を後継者に伝えることもお忘れなく。
なお前述のような組織全体の IT サービス部門やサポート部門がある場合、組織として購入した製品に付属しているサポートの権利をそうした部署で一括して管理していて、ユーザーや個々の部署が個別に利用できないようにしている場合がある。全社的な担当部署がある場合は、その点についても確認しておこう。
また「フリー ソフト」やオープンソース ソフトウェアでコミュニティー ベースのサポートが得られる場合 (その多くは Web フォーラムや ML [メーリング リスト] だろう) も、どこでどのようにサポートが得られるのか確認しておく事は有益だ。前述のようにこうしたコミュニティー ベースのサポートの場合、単に質問するだけでなく貢献も期待されているので、質問したい時にフォーラムや ML に参加して質問し、解決したらされっきり無関係というパターンは歓迎されない。できれば (特に業務上重要な役割をそのソフトウェアが果たしているなら) 質問のあるなしにかかわらずコミュニティーへの参加・登録を行い、またもし自分が提供できる情報があれば回答者として投稿するなどしていると、自分が質問者になった際により大きなリターンも期待できるだろう。
もちろんこうしたエスカレーション先の情報 (どこの ML / フォーラムでどのソフトウェアの情報が得られるか) も資料として整理し、メンテナンスしておこう。

契約が必要なサポートの場合、まずそうした契約をしていないのかどうかの確認が必要だ。組織全体の IT を管理する部門があるような企業ではまず間違いなくその部門が契約を管理しており、契約が必要なサポートを利用する際は、その部門を通じて行う事になるだろう。
こうした全社的な管理部門が無い場合、サポート契約の有無が適切に管理されていない場合もある。ソフトウェアやシステムの調達を行った部署 (担当者) は、SIer やベンダーの勧めでサポート契約をしているのに、実際にそれを運用する人にその契約が正しく伝わらず、総務課のキャビネットにサポート契約書が眠っているという場合も実際にある。これを掘り出すのは (場合によっては社内政治的にも) 結構面倒な作業だが、いざという時に使えないのではお金の無駄でしかないし、ヘルプ / サポートを担当するあなた自身にも不幸だ。暇をみつけて少しずつでもよいから確認し、必要な時に利用できる状態にしておこう。

そして最後に、非技術的な問題のエスカレーション先の確保だ。ヘルプデスク / IT サポートの業務遂行上、技術的ではないトラブルや困難な判断に直面した場合、それを一人で抱え込むのはあなたにとっても (精神安定上、という以上に) 危険だし、会社の業務全体の効率を考えても問題だろう。あるいは対処自体は技術的な物であっても予算が必要になる場合、当然あなた一人の意思決定では済まないだろう。こうした問題を誰に (どこの部署に) 相談し、上申し、あるいは起案すれば良いのか、日頃から注意して確認しておこう。
大きな組織でヘルプデスク / IT サポートの専任であれば、その業務の直上の管理職が居るはずで、その管理職がプライマリーなエスカレーション先になるからあまり問題はないだろう。
問題は専任ではない場合だ。その場合、ヘルプデスク / IT サポートの業務は誰の管理下で行われているのか、あいまいになっている事も少なくない。直上の管理職とは別に、さらに上位の管理職 (たとえば部長とか社長とか) から「パソコンの面倒を見てくれ」と言われて対応をしている人も少なからずいるだろう。こうした場合責任の所在があいまいになりがちで、いざ (非技術的な) トラブルが起きた場合、誰がどう仕切るのか考えられていない事が多い。そうなると一番大変な目にあうのは担当者であるあなただ。
そうした事態を回避するためにも、ヘルプデスク / IT サポートの業務について誰が管理者であり、だれが最終責任者なのか、言い方は悪いけれど言質を取るよう心がけよう。もちろん正規の職制や業務規則に盛り込むチャンスがあるなら、ぜひそうするべきだ。最近は「コンプライアンス」という言葉が流行っていて、経営者や管理職はこの言葉に弱いようだから、「情報管理に密接にかかわる IT 関係の業務の責任体制がはっきりしないのはコンプライアンスにもとる」と説得すると良いかもしれない。

こうした準備や確認をして、使える物はずの物は実際に使える状態に常にメンテナンスしていく事は、企業内・組織内のヘルプ / サポート担当者に必要な仕事だ。

ゴールを定める

ヘルプデスク、あるいはサポート担当者としてユーザーの質問に答えたりトラブル対応を行う場合、重要なのはゴールの設定です。

ゴールとは、ユーザーの「ああしたい」「こうしたい」というニーズ (要求) と、担当者 (あなた) の提供できるサービスで実現できる事の一致点であり、ユーザーが得られる物と担当者が行うべき事の目標になります。
簡単な例では、ユーザーにある文書を特定の用紙枚数 (例えば 4 枚) 以内に印刷したいという質問がある場合、その一番妥当なゴールは「その方法の案内」になるでしょう。別の例として、ユーザーからあるソフトウェアでデータを袋とじ印刷したいが意図通り印刷されないというトラブルの相談があった場合、そのゴールは「必要なデータを袋とじ形式で印刷する事」になるでしょう。
ゴールを達成される事で、担当者はユーザーにヘルプやサポートで適切かつ十分な対応が得られたという満足感を与える事ができますし、また仕事の区切りをする事ができます。ゴールが明確でないため、ユーザーから次から次へと質問や苦情を突き付けられ、苦労した経験がある人も少なくないでしょう。
そのためユーザーからの質問やトラブル申告を整理し、ユーザーのニーズを把握し、それに適切に対応したゴールを設定する事は重要です。ゴールが明確であれば「ここまでちゃんとやりましたよ」とユーザーにも、またあなたの上司にも言えるわけです。

さてここで注意しなければならないのは、ゴールは明確であるべきだけれど、そのゴールを達成する手段が限定されるような設定にはしない事です。
例えば上の例の前者の場合、ユーザーは印刷を行うソフトウェアの印刷設定で印字用紙枚数を設定する事ができないかと思って質問しているかもしれません。しかしここでゴールを「そのソフトウェアの印刷設定で用紙枚数を設定する方法」にしてしまうと、もしそのソフトにそうした機能が無ければゴールは達成できない事になります。しかし「そのソフトウェア」と限定しないでゴールを設定しておけば、プリンターの機能で実現してもゴール達成となります。
また後者の場合もゴールを「あるソフトウェアの袋とじ印刷の正しい設定方法」にすると、もしトラブルの原因がソフトウェアの不具合 (特定の条件で袋とじ印刷が正しくできないバグ)だった場合、ゴールが達成されていてもユーザーの本来の希望 (袋とじ印刷を行う事) は実現できません。上と同様に手段を限定しないゴールを設定していれば、ソフトがバグで正しく機能しなくともプリンターの設定で袋とじが可能であればそれでゴールは達成でき、ユーザーの希望も叶います。
一つの目標を達成する手段は常に一つとは限りません。またコンピュータ システムの場合不具合 (バグ) で期待通りの動作ができないため「運用回避」や「代替手段」で問題に対処せざるを得ない場合も少なくありません。またセキュリティー上の規制などコンピュータを使っている環境 (企業、会社) でのルールによって手段が制約を受ける場合もあります。
「ゴール」で達成すべき課題は明確にするべきですが、手段を制約するような内容はできるだけ含まないようにする事、これが重要です。

もう一つ重要なのは、適切なゴールは必ずしもユーザーの (表面的、直接的な) 希望と同じではないという事です。
例えばユーザーのコンピュータでは定期的に原因不明で正体不明のエラー メッセージ ダイアログが表示され、これについてあなたに対応を求めてきたと考えてください。この場合正しいゴールは「エラーが表示されなくなる事」でしょうか。
もちろんユーザーの直接的な問題はエラー メッセージが表示されることです。しかしユーザーは「エラーが出る」という現象の裏側で、何か自分では理解できないコンピュータの異常が発生しているのではないかという不安を抱いているはずです。したがって単に「エラーは出なくなりました」というだけの対処ではそうしたユーザーの不安が十分に払拭されるとは言い難いのです。
ユーザーの本当のニーズは不安が取り除かれる事であり、安心して業務にコンピューターを使える事です。ですからゴールもそれにフォーカスした内容であるべきです。具体的にどのようなゴールが可能かは、エラーが発生している状況にもよりますし、またヘルプデスク業務、サポート業務についての組織 (会社) の方針、ポリシーによって変わってくるでしょう。しかしいずれにせよ「コンピュータが (その会社にとっての) 業務に利用しうる要件 (安定性、安全性) を持っているかどうかを確認する」ところまではゴールに含まれる必要があると思います。

そして最後に留意すべきなのは、できそうにない事、無理だとわかっている事についてユーザーの期待値をうまくコントロールし、期待値が高すぎないようなゴールを設定すべきだという事です。
実際にトラブル対応やヘルプデスクの仕事をしていると、ユーザーから繰り返し同じような質問への回答やトラブルへの対応を求められる事があります。そしてその大半は「残念ながらこのソフトではできません」とか「現在の我が社のシステムではできません」とか、あるいは「このトラブルは初期化 (リカバリー) 以外に確実な解決方法が確立されていません」だったりします。
当然ユーザーは希望が叶う答えが得られる事、問題が簡単に解決する事を期待している訳ですが、それをそりままゴールにしたのでは、最初から未達成になるのは目に見えています。だからと言って門前払いするような対応をすれば、ユーザーは不満に思うでしょうし、場合によっては納得しないでしょう。
そこでユーザーの期待通りの結果になるのは難しい事を誠意をもって伝えつつ、それならばどうするのが一番良いのか、例えば代替案を提示してユーザーがやりたかった事と極力同じ結果が得られるようにするのか、あるいは現時点ではユーザーが我慢するとして、将来的なソフトやシステムの改善を求めるアクションが必要なのか、ユーザーの気持ちを汲み取ったゴールを設定する必要があります。

つまり「ゴール設定」とは単にユーザーの言っている事を無条件に反映させる物ではなく、ユーザーの言っている事の裏側にある本当の希望やユーザーが直面している現象の状況をうまく引き出す作業であり、そうして引き出した物と担当者 (あなた) が「仕事として」できる範囲とをマッチングさせる作業なのです。

ゴールがうまく設定できれば、目標がはっきりするのでユーザーとのコミュニケーションも取りやすくなりますし、ユーザーも担当者は何のために何をやっているのか、理解しやすくなります。そういう相互疎通は作業を円滑にし、作業の切りや手離れを良くし、またどのような結果になっても (は言いすぎかもしれませんが) お互いに達成感め満足感が高くなるでしょう。

もしあなたがサポート業務、ヘルプデスク業務でいつもユーザーに振り回され、やらなくて良い事まで付き合わざるを得なくなる事が多いと思っているなら、それは最初のゴール設定に問題がある可能性が大きいと考え、ゴールの設定の仕方を見直すべきだと思います。