第184回 運用保守、ヘルプデスクを考える
こんにちは、キャリア・コンサルタント高橋です。
先週、anubisさんが「元ヘルプデスクよりベテランエンジニアに挑戦状を叩きつける」というコラムを書かれました。このコラム、私も全面的に大賛成です。私がITエンジニアでやっててよかった仕事をあげるとすれば、運用保守業務とヘルプデスクの２つをあげます。どちらもシステム開発の本流ではない仕事ですが、私にとってもこれらの仕事は自分を大きく成長させるきっかけになった仕事だと思っています。そこで、今回は私が経験した運用保守やヘルプデスクの仕事から思うところを書きたいと思います。
■運用保守、ヘルプデスクの仕事に就いてみて
一般的にシステム開発の仕事といえば、案件の受発注で行われる企画提案、プロジェクト全体の進行を取りまとめるプロジェクト管理、顧客の要望を要求事項をまとめる要件（業務要件、インフラ要件、保守要件など）、各種設計、製造（コーディング）、単体テスト、結合テスト、システムテスト、インフラ構築、システム移行などをイメージされるのではないかと思います。実際、私もこれらの仕事はほぼすべて担当させていただきました。企画提案では数社が参加するコンペでプレゼンをしてきましたし、数百人月のプロジェクトのプロマネも担当させていただきました。設計、製造、各種テスト、インフラ構築などもやらせていただきました。そんな中でやっててよかった仕事は？ と聞かれると、私は運用保守業務とヘルプデスクをあげます。
運用保守業務はシステム開発が一とおり終了し、システムを維持管理するフェイズでシステムの正常稼働を保証する業務です。一般的にはシステムのバックアップ、データベースのデータの登録、更新、削除、その他システム維持に関する様々な保守業務（ログの取得、分析、システム改善のための改修業務など）がメインになるのではないかと思います。そのため、システム開発がやりたいITエンジニアからは敬遠される傾向にあるような気がします。しかし、私はITエンジニアで一番最初にこの仕事を経験しました。その当時、ずっとシステム開発の仕事に就きたいと思っていた私に、当時の先輩からこんな言葉を聞きました。
「システムは動き続けるのが当たり前。もし、ちょっとでもシステムが止まったりしようものなら大問題になる。しかし、システムが安定稼働して動き続けてても、それが当たり前といわれる。俺たちの仕事はその当たり前を実現するためにやってる仕事なんだ」
新卒社員の私はその言葉に釈然としない思いをもっていましたが、今思うと、仕事に対する考え方をこの運用保守業務を通じて学んだような気がします。この考えを叩き込まれたからこそ、それから先も何とかITエンジニアとしてやってこれたのかなと思っています。
そして、もう一つのヘルプデスクは私がある程度ITエンジニアの経験を積んだ後に担当させてもらった仕事でした。当時の会社がある大手企業の基幹システムのヘルプデスク業務を一括で受注する計画を立て、その足掛かりとして私がヘルプデスクチームに入り、ヘルプデスク業務のノウハウを一とおり習得した後、当時の会社がヘルプデスク業務を引き取るような計画だったかと思います。
そのときの私は、正直ヘルプデスクを少し軽く考えていたところがありました。会社にも「大体３カ月あればある程度の段取りはつけられると思いますよ」のような軽口を叩いたような気がしています。しかし、そんな気持ちは３日も経たない内に叩き潰されました。
そのヘルプデスクは知的財産（知財）に関するシステムのヘルプデスクでした。そのため、単にシステムのことを分かっているだけでは対応できず、特許申請などの知的財産に対する深い知見が必要とされました。当然、そんな知識をもっていない私は満足にユーザーさんとやり取りをすることができませんでした。正直、これだけ何もできなかったのは後にも先にもここが初めての経験で、今までもっていた経験が何の役にも立たないことを思い知らされました。
しかも、その現場で対応しているヘルプデスクの方々は皆40代を過ぎたパートの女性たちばかりだったのです。「あー、高橋さん、最初は難しいから、ゆっくり覚えていけばいいよー」といつも優しく諭されました。失敗してもその現場では皆笑ってフォローしてくれました。しかし、一人一人がヘルプデスクに対して自信と誇りをもっていました。ユーザーさんの困っていることを親身に聞き、その対策や対応を的確にアドバイスされています。そのときに話の聞き方は正に傾聴そのものです。また、システムの扱い方にも長けており、過去の問い合わせ事例の照会、困難な回答への対処方法など、非常に動きに無駄がなく、チーム全体がとてもよく機能されている組織だと痛感しました。
私は彼女たちの姿をみて、自分の仕事のあり方を考え直しました。今まで自分が見向きもしなかったヘルプデスクがこれだけ大変でテクニカルな仕事をしている。しかし、ここで働く人たちはそれを意に介さずレベルの高い仕事を的確にこなしておられる。私はこの方たちからもっともっと多くのことを学ぶべきではないか？
その考えに行きついた後、私はゼロから学び直すつもりでヘルプデスクの仕事に本気で取り組みました。そうして１年経つ頃にはやっとそのチームの中で少しは認めてもらえレベルのスキルを身につけられたように思いました。そして、この仕事がとても楽しく一生涯の仕事にしてもよいと感じられるようになっていました。
その後、会社には「このヘルプデスク業務を担当するならば、本気でこの仕事に骨を埋めても構わないという気持ちをもっている人でないと到底太刀打ちできるような仕事ではない。だから、うちの会社が引き取るのは相当難しい」と報告し、一括でヘルプデスク業務を受注する業務から撤退しました。
■運用保守、ヘルプデスクの仕事に思うこと
ITエンジニアという仕事には「システム開発」という一つの大きなくくりがあります。システムの開発というのはとてもテクニカルで大変な仕事で、どの職種、開発フェイズであっても簡単にできるモノは何一つもありません。しかし、システムというモノをつくり上げることはとても魅力的なことであり、やりがいを感じる仕事でもあります。だからこそ、多くのITエンジニアがシステム開発に目を向けることもよく分かります。
しかし、システム開発の周りにある運用保守やヘルプデスクといった仕事も企業がシステムを利用する上では必要な仕事です。難易度の違いはあれど、それらの仕事もテクニカルで大変で、誰にでも簡単にできる仕事ではありません。そして、これらの仕事もとても魅力的でやりがいのある仕事です。実際にこれらの仕事に就いてみて、私自身はそう感じました。
もし、運用保守、ヘルプデスクといった業務を担当されたことのない方は、もし機会があればぜひ担当してみてください。きっと、ITエンジニアとしての視野が大きく広がり、その経験はITエンジニアとして仕事をする上でかけがえのない貴重な体験になると思います。
コメント
ksiroi
この件で腑に落ちないことがあるのだけども。
> 本気でこの仕事に骨を埋めても構わないという気持ちをもっている人でないと到底太刀打ちできるような仕事ではない。
という仕事に対して、
> もし、運用保守、ヘルプデスクといった業務を担当されたことのない方は、もし機会があればぜひ担当してみてください。
これに繋がる論理が分からないんです。
「林檎は赤い。だからとりあえず食ってみろ。甘いから。」
という会話展開に等しいと感じる。
今の適材適所に不満がある・自分の適性を探し中・テクニカルスキルに不足を感じる
上記の人間に勧めるなら分かるんです。
「担当したことがない人が裾野を広げるために、とりあえずやってみろ」
はコラムとして不適切なんじゃないかな、と。
高橋さんの現場の女性は優しい方だったようで、運が良かったのだと思います。
それほど生易しくなく、ストイックかつストマクエイクな現場の方が多いと感じます。
「なぜ今の自分にヘルプ業務が必要か」
これを突き詰めて欲しいところです。
Anubisさんの記事は「小見出しだけ見ても対話力・理解力に焦点を置いている文に読めるので、ヘルプデスク関係ないやん」というのが僕の感想。
高橋さんの記事は「提起として分かりやすいが、もう少し掘り下げてくれれば技術不足に悩む羊の道筋になるのでは」という感想。
まぁ、一読者の意見なんでスルーして頂ければ。コラムニストがブレてはいけない。
ksiroiさま、
コメントありがとうございます。
少し言葉足らずな部分があったかと思いますので補足させていただきます。
> 本気でこの仕事に骨を埋めても構わないという気持ちをもっている人でないと到底太刀打ちできるような仕事ではない。
これは、当時の知財システムのヘルプデスク業務のことをいっており、ヘルプデスク業務全般がこのようなこのような仕事ではありませんでした。そのため、
> もし、運用保守、ヘルプデスクといった業務を担当されたことのない方は、もし機会があればぜひ担当してみてください。
も可能な範囲で担当してみてください、といった趣旨になります。ですが、誤解を招く表現だったかと思います。失礼いたしました。。。
> 高橋さんの現場の女性は優しい方だったようで、運が良かったのだと思います。
> それほど生易しくなく、ストイックかつストマクエイクな現場の方が多いと感じます。
これはksiroiさんのおっしゃる通りだと思います。
実際にはそんなに甘い仕事ではないことは私なりにも理解しているつもりでしたが、表現が稚拙だったため正しく伝わっていなかったかもしれません。
こちらも失礼いたしました。
> 「なぜ今の自分にヘルプ業務が必要か」
> これを突き詰めて欲しいところです。
そうですね、ここはキャリコンとして運用保守やヘルプデスクの有用性をお伝えしたかったのですが、考察が少し浅かったかもしれません。
また別の機会にこのネタでトライしてみたいと思います。
> 高橋さんの記事は「提起として分かりやすいが、もう少し掘り下げてくれれば技術不足に悩む羊の道筋になるのでは」という感想。
ありがとうございます。
ksiroiさんのような視点でお読みいただけいるとコラムを書かせていただく側もフィードバックがあり、大変ありがたく思います。
もし、よろしければこれからも忌憚ないご意見を頂戴できればと思います。
夢夢
コメント欄がちょっと気になったので書く。
この件は集合論で考えるとよくわかると思う。
ITという全体集合の中では開発スキルは部分集合でしかない。
現実の問題は全体集合で発生しているわけだから、この差集合の知識の有無で問題解決能力に差が出るのは当然である。
ならば、全体集合と開発部分集合の差集合をどうやって取得するのかという命題に帰結する。
取得する方法は大きく分けて二つ。
１、自分で体験する。
これができれば幸運で人生の宝となる。
このコラムで言及されているように、機会があればやってみるのがよかろう。
２、間接的に知る。
ヘルプディスク支援システムを開発／構築するか現場見学を行う。
俺の場合は2つやった。
支援システムを開発／構築する機会がない人は、現場見学だけでもしてみるとよい。
それだけでも勉強になるぞ。
他にも営業マンについていくのも勉強になる。
要するに自分の知識集合を把握し、問題集合全体に知識＆スキルを広げればよい。
ただし技術不足で悩んで居る場合は、まずは自分の業務のスキルをアップさせるべきである。
スキルがないのに他の集合に手を出しても消化できないぞ。
確固たる知識＆スキルがないとフィードバックができないからな。
同様の理由で自分探しなんてとんでもない。
プロフェッショナルの領域でそんな甘い思想は通用しない。
思春期の人がするものではなく、確固たる自分を持っている人がすることだ。
不足している時に体験する機会が訪れたら詳細に文書化して後で読み返すとよい。
夢夢さま、
コメントありがとうございます。
IT全体像と開発スキルを集合論でみる考え方はなるほどと思いました。
IT全体像と開発スキルの差を埋める方法として
直接的な経験（１、自分で体験する。）
間接的な経験（２、間接的に知る。）
の二軸から話をされているのも興味深い考察だと思いました。
私はヘルプデスクを実際に体験していますので直接的にな経験になりますが、確かに間接的にも経験できることはたくさんあると思います。この辺の話は未経験者がどうすれば経験者に近づくことができるのか？という点でキャリコンのネタにさせてもらうこともあります。
> 要するに自分の知識集合を把握し、問題集合全体に知識＆スキルを広げればよい。
正にその通りだと思います。
夢夢さんのおっしゃる内容はキャリコンにも繋がっているように感じました。
キャリコンでは「自己理解」というフェイズで自分のことを棚卸しますが、そこで自分の経験した仕事、得意とする仕事、やりたい仕事などを深堀りします。そうすることで自分の知識集合を把握するお手伝いをさせてもらっています。
その後、就きたい仕事を考え、就きたい仕事との間にある技術、知識、スキルの差を埋める方法を取っていきます。
表現の方法はいろいろあると思いますが、やはり現場でご経験、ご活躍されている方の言葉はとても重みがありますね。
Anubis
どうも、Anubisです。
私もヘルプデスクはやっておいてよかったと思う業務の一つです。
同じく、いろいろなものを叩き潰されて凹みまくりましたが。
ただ、ヘルプデスクは経験しないと大変さが分からないと思います。
それだけに、人それぞれ見え方が違ってくるように感じました。
非常に共感できる部分が多かったです。
・・・今でもおばさま方のあの対応力には勝てる気がしない。
anubisさん、
コメントありがとうございます。
anubisさんのコラムを拝見していると、私にも似たような体験や想いをさせてもらっているなぁといつも思います。なので、私の方こそいつも共感させてもらっています。
「お前の言葉で犬を創造しろ！」
このキーワードは私の中で今年一番の大ヒットでした。
思わず、「うまぃ！」と叫んでしまいましたｗ