ヘルプデスクはシステム開発、運用、保守などの業務のレイヤーで、また機能要件から非機能要件までシステムの幅広い分野の知識が必要なオールラウンドな職種です。
ヘルプデスクというと、エンジニアの職種の中ではどちらかと言うと地味なイメージが付きまといます。
しかし、ヘルプデスクに求められる能力や知識と言うのはその他の職種に比べて非常に幅が広いというのは、自分の経験から感じているところです。
ヘルプデスクに求められる能力・知識や、その中での業務というのはどういったものがあるでしょうか。
1. チーム・組織を把握する
ヘルプデスク業務は、ユーザーからの問合せがトリガーになります。
その時にユーザー側で起こっている問題はヘルプデスクの中で持っているナレッジで全てが解決できるとは限りません。
その際には、それを担当とするチームや部門にエスカレーションすることになります。
ヘルプデスクの担当者はそのような事態に備えるために、担当するチームや組織を把握しておかなければなりません。
2. ユーザー業務を把握する
ヘルプデスクは、その対象となるシステム等に対してどのような業務があるのか知っておく必要があります。
そのシステムがどのように使われているかを知っていないと、問合せがあったときにどの場面でユーザーが困っているのかが分からず、問題解決までに時間がかかってしまいます。
また、担当者にエスカレーションをする際にもヘルプデスク担当者は、その問題を分かりやすく伝えなくてはなりません。
ユーザーがなにやら困っているようです、だけでは問題は何時までも解決しません。
3. 問題分析と対処能力
ヘルプデスクは人と接する事がその業務の中で大きなウェイトを占めます。
どのように困っているのかをうまく聞き出し、それの何処に問題があるのかをすばやく分析する能力が必要です。
ただ、問題を解決するだけではいけません。
それが解決すべき問題なのかどうかを見極めることも必要です。
推奨していない環境でのトラブルに対して助けを求めてきた、社内で自宅のPCを使用していた、明らかに対象システム以外のところに問題がある、などそれがヘルプデスクの対象範囲かをしっかり分析・認識しておく事も重要になります。
4. 何はともあれ忍耐力
ユーザーはよくわからないこと言ってくる「困ったちゃん 」が多いです。
ただ、これは仕方が無いことです。
ユーザーの全てがシステムに詳しい人ではなく、またそれら複雑な事象をヘルプデスク担当者にうまく伝える事ができる人はそうはいません。
そしてうまく伝える義理もまたユーザー側にはありません。
担当者はそれを辛抱強く聞き出さなくてはいけません。
5. エンジニアは開発だけではない
2.のユーザー業務を把握するにも書きましたが、ヘルプデスクの対象にしているシステムは様々な人の業務により成り立っています。
エンジニアというのはそのシステムを作った開発者だけでなありません。
それを支えている様々な人たちが、日夜開発者と同じくそれぞれの業務で苦労をしているわけです。
それらの人たちを意識しなくてはなりません。
何故か？そのシステムのちょっとした機能の組み立てでそれに携わっている多くの人たちの業務を楽にできる可能性があるからです。
「システムエラー」とだけ表示される画面を見てため息をつくのは利用者だけではありません。
6 気づかなかった視点
システムを開発する際は、多くは開発者と業務側の担当者との少数精鋭で要件が決められ、構築されていきます。
業務側の担当者は、現場の意見をまとめそれを開発側に伝えているのでしょうけど、それらの多くには漏れがある事は事実です。
業務の担当者は、目的の機能を達成させる事を開発者に迫り、それらを利用する人たちへの気遣いを忘れ、細かなインターフェースまでは口出ししてきません。
ヘルプデスクの対応にいってみると、その問題解決の過程の中でシステムへの愚痴をこぼす人が多いのに気がつきます。
使いにくいとか、分かりにくいとか、レスポンスが遅いとか。
開発者は業務の担当者とのやり取りの中でのクローズした世界しか分からない事が多いため、その利用者側の生の意見をなかなか聞く事ができません。
この意見こそがそのシステムが嫌われている最大の理由です。
新しい業務が加わりそれに応じたシステムが導入された場合、また使っているシステムが刷新された場合、多くの関係者はそれ自体に不平は言いません。
それを使う事が仕事だからです。
ですが、その仕事をするのなら極力シンプルに行いたいと言うのは誰もが思っていることです。
それが妨げられている現状があるから現場は不満を持つわけで、その事をエンジニア（特に開発者）は知る必要があります。
7. システムと言うのはアプリだけではない
「あなたは何するエンジニア？ 」にも書きましたが、エンジニアというと多くは開発者を思い浮かべます。
しかしそのシステムは何もプログラムだけで成り立っているわけではありません。
プログラムを動かすためのミドルウェアやサーバーがあり、そしてネットワークも必要です。
ネットワーク機器があり、関連するアプライアンスがあり、それらを支える電気や空調施設などのインフラ施設を管理している人もいます。
ヘルプデスクの担当者は、それらの担当組織を把握するだけでなく、問題解決能力を磨くためにそこにある幅広い知識を吸収していかなくてはなりません。
ユーザーからの問合せは何も、PCやブラウザの中だけで起こっていることとは限りません。
ハードウェア側の問題だったり、ソフトウェアの問題だったり、ネットワークの問題だったりと様々です。
偏った知識だけでは何時までもPCのソフトウェアとにらめっこしているだけで終わりです。
単純なところで、ネットワークケーブルが抜けていたなんてオチのある問合せもしばしばです。
ヘルプデスク担当者はそれらをつなぎ、PCに対して適切なネットワーク設定をしてあげる必要性もあります。
8. もらえる「ありがとう」
開発者はそのシステムがリリースされた際に、現場にどれくらいのインパクトがあったのかを把握する手段がほとんど無い場合があります。
それが本当に目的達成に役立ったのか、現場の仕事は楽になったのか、苦労して作り上げたあのギミックは利用者を喜ばせることになったのか。
プロジェクトが成功した場合、そのリーダーから「諸君。このプロジェクトは成功だ。君たちの努力に感謝する
」といわれても本当に現場で喜んでいるのかどうかもわかりません。
ヘルプデスクは人と接する仕事。その中で沢山のクレームを貰う事もありますが、感謝の言葉を直接貰う事もできる数少ない職種だと思います。
ユーザーは困っているからヘルプデスクに助けを求めてきたわけであって、その問題を解決した場合、素直に「ありがとう」という言葉を聞く機会があります。
仕事の対価はお金だけではありません。このような自分の仕事に対して成果の代償としてもらえる感謝の言葉を聞くことができるだけでも、モチベーションは上がるものです。
例え、開発者として採用されたエンジニアであっても少しの期間、ヘルプデスク業務とを体験する事は、自分にとって凄く有用な経験になると思います。
開発だけを経験する中では体験できない事がヘルプデスクの中には詰め込まれているからです。
逆にヘルプデスクにマイナスのイメージを持っている人がいるのであれば、その幅広い分野に携われる数少ない職種だと言う事を意識して、その中で様々な知識を吸収しようというプラス思考に変えてみては如何でしょうか。
関連記事
良い結果を生み出すための情報システム部門とユーザー部門の関係構築
コンピュータがトラブルに見舞われたときに考えるべき健全なこと
情報システム部門ヘルプデスク担当者が地獄に叩き落したいユーザー