元ヘルプデスクよりベテランエンジニアに挑戦状を叩きつける
■ヘルプデスクの逆襲
ヘルプデスクは開発のエンジニアより単価が安い。エンジニアのヒエラルキーからすると、下の方に分類されがちだ。私のコラムについたコメントでも「ヘルプデスクなんてエンジニアじゃねぇww」みたいな一言も見かけた。多分、一般的な認識としてはそんなものだろう。
ヘルプデスクと言ってもいろいろある。パソコン操作の受け答えみたいな簡単なものから、業務ソフトの障害切り分けまで、対応する対象は広い。また、問い合わせの対応だけでなく、簡単な調査や検証も請け負うこともある。
電話受付に毛が生えた程度の認識の人も多いが、あえて言わさせて頂く。ヘルプデスクの経験の有無で、エンジニアとしての能力に大きく差が付く。真面目にやれば、エンジニアとして決定打となるスキルを身につけることができるのだ。
事実、私もエンジニアとして活躍できているのも、過去にヘルプデスクをやっていたおかげだと思っている。エンジニアとして逆転を狙うなら、一年、二年、ヘルプデスクをやってみることを勧める。
■人の話を聞く力が付く
ヘルプデスクは相手の話を聞けなければ仕事にならない。相手の話を正しく理解することから仕事が始まる。しかも相手は素人だったり、専門用語がわからない人だったりする。言いたい事がまとまらない人が相手なら、話をまとめていかなくてはならない。
話を聞くには鍛錬が必要だ。どんなにコードを書いても、高度なサーバを構築してもこの能力は身に付かない。ヘルプデスクを経験することで、話を聞く力に決定的な差が付く。そして、話を聞く力がエンジニアとしての能力の決定的な差に繋がる。
例えば、相手の要件を聞き出せた状態でコードを書くのと、不明瞭なままコードをかくので、どちらが良い成果物ができるだろうか？もちろん、相手の要求を聞き出せた状態の方が良い成果物ができる。
技術云々の前に、エンジニアなら人の話をきちんと聞けるようになろう。高度な技術を持っていても、要件が聞き出せなければ実現はできない。技術を活かすも殺すも、まずは人の話を聞けるかにかかっている。
■人に説明する力が付く
「人に説明するのがヘタクソだ。」これはエンジニアがよく指摘される欠点だ。ヘルプデスクを真面目にこなすと、この欠点を解消することができる。
質問に対して答えるのがヘルプデスクの仕事だ。これができなければ仕事にならない。また、相手に納得させなければ問い合わせをクローズできない。自分本意の意見ばかり主張していては、いつまで経ってもクローズできない。
人に説明するのは、人の話を聞くのとセットだ。単に頭が良ければ説明できる。そんな発想では、話し方が高圧になるだけで会話がない立たない。コード書いたりサーバを組むのとは別の部分の脳みそを使う能力だ。そこはきっちり認識しよう。
また、エンジニアにとって、自分のやったことを適切に伝えるのは必須のスキルではないだろうか？ヘルプデスクをやることで、このスキルが身につく。適切に物事を伝えられるようになると、伝達ミスによるトラブルを減らすことができる。
■トラブルシューティングに強くなる
ヘルプデスクは常にトラブルの対応を行っている。ある意味、最前線でトラブルの対応を行っているのはヘルプデスクだ。
また、ヘルプデスクが一時切り分けを担当することも多い。つまり、最初にどうするかの判断が委ねられるのだ。これは判断力と相談力が問われる。問い合わせに対しての履歴や進捗の管理も行うことになる。
トラブルの始まりの電話を取って、終了の連絡をする。ヘルプデスクはトラブルの終始一貫を見守ることになる。また、トラブルを起こした時の緊迫感にさらされることで、メンタル的にもトラブルで動じにくくなる。
常にトラブルと隣り合わせの業務だ。当然、トラブル時の振る舞い方が身についてくる。トラブルが起きた時、打てる手段の数を数えられるだろうか？将棋のように、あと何手でクローズとか、対応の手筋など読めるだろうか？ヘルプデスクを経験すると、そういうトラブルの対応に役に立つ能力が身につく。
■ヘルプデスクは最強の補助スキル
ヘルプデスク自体は、確かに高度なスキルを求められない。だが、エンジニアといっても、進捗を管理しかしない人や、どっかの壁画のような設計図をエクセルで書いているだけの人もいる。むしろそういう人たちの方が、事務員に毛が生えたレベルと言うに近い。
何をエンジニアと定義づけるかはそれぞれの判断に任せる。ヘルプデスクは開発やサーバ構築をする前の重要なステップと考えている。なので、私はヘルプデスクをエンジニアと考えている。ヘルプデスクを経てエンジニアとして活躍している人は、非常にバランスが良い。
ヘルプデスクで培えるスキルは、広く応用が利く。ただ、裏を返せば補助的なスキルだ。それ自体で何かできるかというと、ちょっと厳しい。これもエンジニアとして評価されにくい理由だと思う。しかし、軽視される理由にはならない。
ヘルプデスクは末端でシステムを使用している人に直に接する。ある意味、矢面に立ってエンジニアの活躍するフィールドを守るのがヘルプデスクだ。もっと評価されても良いと思う。
コメント
abc
ヘルプデスクに限らず、ポリシーを持って仕事をしている人が
評価されるべきというのは同意です。
私見になりますが、私の中で「エンジニア」はポリシーを
持って仕事をしている人です。
意外とそういうのを持って仕事をしている人って少ない気がします。
どうでもいいプライドをお持ちの方は多いけど。
平気で「ヘルプデスクなんて」って言える人は残念な人だなと思います。
Anubis
> abc さん
コメントありがとうございます。
自分に自信が無いと、人を認めるということは難しいです。
立場や職種で線引きしたがる人に限って、
自分の仕事のスキルが低いのはよく見てきた。
夢夢
前から俺はヘルプディスクの方に対して敬意を持っていた。
巷では低いスキルの人を例に挙げられる傾向があるが、それを言えば開発側のエンジニアだって素人に毛が生えた程度の奴はいる。
それで思ったんだが「補助スキル」というのも間違っているわけではないが、謙遜しすぎだ。
そもそも「ヘルプディスク」という名詞もおかしい。
ITの範囲は広く、ヘルプディスクの方も何らかのエンジニアリング領域の主スキルを持っている。
例えば、前回のコラムで「人間観察力」という立派なスキルを発揮していた。
俺は開発側の人間だが、作成した語の作品とユーザーについての知識は甘い。
その開発領域の外を担当しているのがヘルプディクの方だ。
だから、そうだな・・・、システムユーズエンジニアだと命名するのは如何だろうか？
今こそ正しい定義が必要ではないだろうか？
ksiroi
個人的には「ヘルプデスクでなくても良い」と感じるところ。
誠意を持って、ロジカルな思考を鍛えて、その上で実務に望む、ってのは学生でも学ぶことは出来る。
というか学生時代にやれ
と思わなくもない。
ヘルプデスクで鍛えよう、という考えはヘルプデスクの現場が混乱するだけではないかなー。
現場で学べるのは実務だけよ。
Anubis
> 夢夢 さん
コメントありがとうございます。
「補助スキル」と考えるのは、あくまで開発や構築の業務に移った
時の視点の話です。本当に凄いのは、メンタルの強さとリアルタイム性かと。
ヘルプデスクのメンタルの強さは確かに「補助」と言うには謙遜かもしれない。
> システムユーズエンジニアだと命名するのは如何だろうか？
個人的には、ユーザーサイドエンジニアかな。
> ksiroi さん
> というか学生時代にやれ
無理。実務でやった立場からすると甘過ぎ。
(ただし、それで通じるレベルの仕事もあるのは否定しない)
> ヘルプデスクで鍛えよう、という考えはヘルプデスクの現場が混乱するだけではないかなー。
開発がコーディング力付けるのと一緒。むしろ鍛えないとキツくなる。
> 現場で学べるのは実務だけよ。
ksiroiさんのコメントから、
スキルはいちいち現場で身につけるものではないという見方が読み取れます。
学校で習う程度のレベルで通用する現場なら、おっしゃる通りだと思います。
forseti
コラムを読んでいると、保守が頭に浮かびます。
トラブル、改修案件など、ユーザの話を確認した後に、
原因、優先度、費用の有無等切り分けた上でユーザに説明する。
その時に理解する力、説明する力が足りないと仕事が成立しません。
エンジニアにおいても、
同じでなくても似たフィールドがあるのではと思います。
違いとしてイメージしているのは、
・保守はトラブルの場合本人が即時対応しなければならない事が多い
・ヘルプデスクは誰からかかってくるか分からない？
でしょうか。
そもそも「エンジニア」って何だろう？
とふと思いました。
Anubis
> forseti さん
> そもそも「エンジニア」って何だろう？
これはそれぞれ、何でも良いと思う。
このコラムもそれで読み解いて頂くので十分だと思う。
> トラブル、改修案件など、ユーザの話を確認した後に、
> 原因、優先度、費用の有無等切り分けた上でユーザに説明する。
> その時に理解する力、説明する力が足りないと仕事が成立しません。
トラブルが起きた時のケースと改修案件で必要になる要素は違います。
一緒に括ることで、意図することが伝わりにくくなっていませんか？
・・・と、言葉レベルで話を整理できるのがヘルプデスクで培った能力です。
保守でヘルプデスク的な動きをすることは、確かにあります。
意識さえしていれば、ヘルプデスクで培えるような要素は培えると思います。
ksiroi
ああ。forsetiさんのコメント見て気が付いた。
「その分野でのスペシャリストなスキルを得るために、その分野でのヘルプデスクをやれ」
という主旨なのか、
「スペシャルなスキルを身につける前提条件として、見聞力とコミュニケーション力を磨け」
という主旨なのか、が分かり辛いんだな。
おそらく前者の解説なのだろうけども、後者の主旨で読む人が多そうだ。
後者ならば現場で学ぶようなもんでもないので、僕はポキポキ折るねｗ
学校でやれ、と思う。
前者については同意する部分はある。
個人的にはヘルプより前線派だけど、まぁここは人それぞれかもねー
oh
国によっては、「エンジニア」は「ライセンス制」で国家試験への合格が必要だったりして、明確に定義されています。
日本でも、医師なんかは医師免許を持っている人です。
（エンジニアの定義が各自で自由というのはちょっと……な気がします）
------------------------------------------------------------------------------
関係の無い部分のコメントは「それでも業務時間外で勉強をしなければいけない理由」のコメント欄に移動しました。
abc
うまく伝わらないのはどこかで「SE > ヘルプデスク」の
図式があるからではないでしょうか？
SEに多種多様な業務が存在するように、ヘルプデスクにも
学生レベルでできる業務からスペシャリスト的なスキルが必要に
なる業務があると思います。
で、そのスキルを養うことで、優れたエンジニアになれるかもよ。
というだけの話では？
そういうスキルは学校では教えてもらえないでしょうね。
forseti
保守でヘルプデスク的な要素が培われ、
エンジニアの定義が各自自由では
せっかくのタイトルがもったいないなと思ってしまいます。
エンジニアでも保守で指摘されている様な事は出来ると思う
⇒保守は、その上で代替案を提示して業務を遂行できるようにしたり、
発生した事案を新しい仕事に導いたりする必要がある
⇒では、ヘルプデスクでなければ培われないスキルもあるのではないか？
この問いのきっかけになればと思い、コメントを書きました。
私見ですが、ヘルプデスクには保守とは違い、
相手の情報を事前に得ることも、信頼関係を構築しておくことも
難しいのではないでしょうか。
保守の仕事に入った時に、現場の信頼を得られた後は仕事がやりやすかったのですが、
ヘルプデスクでそういう状況を作るのは難しいのではないだろうか？
そういった状況でこそ得られるスキルもあると思うし、
それこそエンジニアへの挑戦状にならないかなと思うのです。
Anubis
なんか、コメント欄がカオスになってますね・・・。
コメント欄に返答するなら、
> SEに多種多様な業務が存在するように、ヘルプデスクにも
> 学生レベルでできる業務からスペシャリスト的なスキルが必要に
> なる業務があると思います。
> で、そのスキルを養うことで、優れたエンジニアになれるかもよ。
> というだけの話では？
> そういうスキルは学校では教えてもらえないでしょうね。
という abc さんから頂いたコメントの通りです。ksiroi への返答は、
> 「その分野でのスペシャリストなスキルを得るために、その分野でのヘルプデスクをやれ」
の前者です。
書いてから気づいたのだが、
ヘルプデスクの経験者であろう人からはよく分かるという返答を頂けていて、
開発やっているであろう人の方があまり伝わっていないようです。
コメント付けてる方々もヘルプデスクの経験が無い人のように思える。
経験があると無いとでは、捉え方が違う。
そういう例としては活かせるんじゃなかろうか。
forseti さん への返答としては、
> 保守でヘルプデスク的な要素が培われ、
> エンジニアの定義が各自自由では
> せっかくのタイトルがもったいないなと思ってしまいます。
定義を放棄した訳ではない。私なりの定義はある。
だがコメントに関しては、それぞれの定義を聞いた上で返答する。という意味だ。
定義したら定義したで、「それは違う！」で無意味に盛り上がるだろうし。
> 私見ですが、ヘルプデスクには保守とは違い、
個人的経験ですが、ヘルプデスクと保守を同義で使ってる現場もあります。
また、兼任でやってる現場もあります。
ケースによって返答が変わるので、forseti さんへの納得のいく返答は難しいです。
内容的に、
・ 話聞けるようになれ！
・ 真っ当な説明できるようになれ！
・ トラシューの対応してきた数が違うんじゃ！
で、十分挑戦状になってると思います。
> oh さん
なんか、以前のコラムのコメント引きずってませんか？
学びとか今回のテーマと関係ないのですが。
主張があるなら自分でコラム書いてください。
私のコメント欄でうじうじやるより、
自分の意見を公表して賛同を得た方が何倍も納得がいくはずです。
夢夢
ヘルプディスクの難しさがこのコメント欄にも表れていると思う。
他の方も指摘しているがヘルプディスクと一言で言っても多様で、会社ごとに差異があると俺は思っている。
恐らく会社ごとにマニュアルはあると思うが、国際的に統一されておらず、体系的に学びにくく、OJTになっているのではないだろうか？
仮に体系的なものがあったとしても開発側の人間はそれをマスターしていないだろう。
働いているヘルプディスクの方を甘く見るなんて大それたことはできないと思うが。
そもそも他業務の人をを見下す人は社会人として失格であろう。
経営学的にも間違いだしな。これから以後、給与が逆転する可能性もある。
知りもしないのに勝手に人に見下す人には無知の知という言葉をプレゼントしたい。
ksiroi
夢夢さんに同意見だなー。ヘルプデスクと一言に言っても
・固定の顧客への対応
・不特定多数への対応
・マニュアル化された対応がある現場
・未知への対応が要求が対応される現場
・他へ転換が容易な技術のサポート
・そこ以外で活用できない知識形態のサポート
と、ちょろっと考えただけで色々あるからねぇ
（ヘルプに限らずどの現場もそうだが）
これも個人的な意見だけども、安易にヘルプへ異動すると痛い目を見ると思うよ。
どういった現場なのか、自分の目指す先に合うのか適正を見ないとね。
ヘルプの人らの仕事が楽になるような物を作る仕事をしている人が大半だろうし
僕も「作り使って改善する仕事」を大量にこなしてきたから
コメント欄で皆が言わんとすることはどれも分かるし、どれも筋は通ってると思うんだ。
噛み合ってないだけで。
おマネーの話になるならば、そもそもとして「お金とは何か」という価値観の話の上で、まず全員のコンセンサスが必要なるので不毛じゃないかな。
oh
申し訳ございません。
夢夢
俺の書き方が悪かったかもしれん。
気のせいかもしれんが微妙に勘違いされているような気がしたので改めて書く。
俺が一貫して主張しているのは「他業種の人を馬鹿にするやつは駄目」だである。
給与を基準にしてヘルプディスクの方を馬鹿にする人がいるようだが、そんなものは経営戦略次第で簡単に逆転する。
給与を基準にするのは愚か者のすることである。
無知の知という言葉が示すように、自分が知らない他業務の人を馬鹿にする人はの方が鹿であり、社会人失格の恥ずかしい存在だ。
ヘルプディスクに限らず、自分の領域外で仕事をしている人を尊敬するのは人として当然の行為ではないだろうか？
不思議なことに自分が知らないことを勝手に見下す人がいるんだよな。
それで無知の知と俺は言っている。
夢夢
余談だと思うがエンジニアリングとは工学の事であり、「どうしたら人間にとって望ましい状態になるのか」を表す概念だといえる。
であるからして、ヘルプディスクの業務もまた含まれている。
これからはヘルプディスクの方はユーザーサイドエンジニア（命名者：Anubisさん）と名乗るとよいと思う。
名前が誤解の基になっていると俺は思っている。
ヘルプディスクと名付けた時点で経営者の失敗だ。
定義の仕方次第でいくらでもよくなるというのに。
定義をはっきりとすれば社員教育もよくなり利益を生む。
実に残念な現状だといえる。
Anubis
> oh
さすがに鬱陶しさが過ぎるので、コメントを修正しておいた。
コメントつけるなら、このくらいシンプルにしておいてください。
あまりにしょうもないコメントを今後つけるようなことがあれば、
スパムに登録します。
-------------------------------------------------------------------
コメント欄が荒れると対応しきれないので、
早急に対応させていただきました。
コメントを頂いた方には後日、返信を付ける予定です。
oh
私のコメントは全て削除しておいてください。
狭量なところのコメントを残しておくのは、さすがに恥ずかしいです。
Anubis
十分に恥ずかしいことをしていたので、このまま晒させて頂きます。
それが嫌なら、二度と関わらないでください。
重箱
ヘルプディスクってなんだ？ Help Desk だべ。
あと、知り合いのヘルプデスクの人がデスクトップをディスクトップと言ってたの思い出した。Desktopだからデスクトップだっぺ。
夢夢
うん？俺の事か？
俺はおっさんだからデスクの事をディスクと発音する。
臨場感を出すために話し言葉にしたがそれが何か？
ダチョウ大臣
とある業務パッケージのヘルプデスクをしています。
私の場合、仕様確認等の問い合わせ対応・障害対応、顧客への各種情報のアナウンス、修正パッチのリリース調整、ユーザの愚痴を聞く（？）のが仕事です。
参考までに私が所属しているチームの場合は、いわゆる「開発スキル」が低いチームです。
それは多分サポートにずっといることを前提に仕事をしている人が多数のためだと思っています。
ですが、顧客から情報を引き出す・正確に回答を伝える・心が折れない、交渉時の調整能力などのスキルは「開発チーム」の方々よりもあると思っています（そのためか馬鹿にされるどころか感謝される）。
ヘルプデスクの経験は開発（要件定義でも設計でもコーディングでも）にステップアップするにあたって、応用できるスキルであるのは間違いないと思います。理由はAnubisさんのコラムに記載の通りです。
実際、僕の現場で、ヘルプデスクができる開発の方は、むちゃくちゃスキルが高いです。
開発をされている方、開発を希望されている方、機会があれば是非経験をしてみてください。無駄にはならないと思います。
※コラム・コメント欄を読んで、いろいろ思うことが湧いて出てきました。コラムを読んだヘルプデスクをされている方はどんなことを感じたのだろうか。長文失礼しましたm(_ _)m
Anubis
> 皆様
いろいろと意見をいただけましてありがとうございます。
コメントを頂いて、人それぞれヘルプデスクのイメージが違うのだと思った。
ただ、経験したことのある人とそうでない人でキッチリと別れた感があった。
コラムを書いたからといって、答えを一つに絞る必要も無いし、
絞ったところで利益はあまり無い。ただ、これを機会にヘルプデスクについて
考えて頂ければと思う。
このコラムで一番訴えたかったこと。それは、自分のやっている事にダイレクトに
活かせるヒントがヘルプデスクの業務にある。ということです。
信じるも信じないも、それぞれの判断に任せます。
非常に良いコメントがたくさんいただけました。
まとめてという形で恐縮ですが、ありがとうございました。
今後のコラムにも活かしていきたいと思います。