社内SEへの転職 PR

情シス部の主要業務の1つ「社内問合せ対応」を語る【社内SEはコミュ力が命】

記事内に商品プロモーションを含む場合があります

こんにちは。まよ(@josysnohito)です。

いきなりですが、情シスは何でも屋です。社内システムの企画・開発・運用保守なんかをやる傍ら、パソコンのキッティングもします。プリンタが壊れたら直しに行きます。

そして、ユーザ部門から問合せを受けたら対応します。

 

はい、何でも答えます。

 

 

\教えてください/

 

 

\お手すきの時に対応お願いします/

 

 

 

はいわかりました。ご回答いたします。

 

 

 

 

\恐れ入りますが本日中にご回答お願いします/

 

 

本日中ですね。いま18時ですがやります。

 

 

 

 

\大至急お願いします/

 

 

\すぐ回答できない場合いつできるか教えてください/

 

 

\当部では対応できないためシステム側で対応願います/

 

 

 

 

・・・。

 

 

・・・。

 

 

・・・。

 

 

・・・。

 

 

・・・。

 

 

 

 

 

ああああああぁぁぁぁぁ!!!!!!!!!!!!問合せ対応ばっかで作業中断してばっかだよおおぉぉぉぉおおぉぉおぉぉぉぉおぉ!!!!!!!!!!!!

 

使い方なんてマニュアルに書いてんだろおおおぉぉぉ!!!!!!!!!しかもそのマニュアル作ったのお前の部署だろおおおおぉぉぉぉ!!!!!!!!!!!システム使うからってなんでも情シスに聞くんじゃねえよおおおおおぉぉぉぉぉ!!!!!!

 

お前が消したメールなんか残ってねえよおおおおおおおお!!!!!!!!!メールサーバにバックアップあるのかもしれないけどいちいち掘り出してられっかよおおおおおおおお!!!!!!大事なメールは自分で責任持って保管しとけえええぇぇぇ!!!!!!!

 

 

・・・。

 

 

・・・。

 

 

閑話休題。

 

 

問合せ対応は、情シスとは切っても切れない存在。雑な前置きですが、この記事ではそんな社内問合せ対応について語ります。

情シス宛に届く、問合せケース集

純粋に情シスしか知らないことを聞かれる

発生頻度:低
対応難易度:中
イライラ度:低

問合せが来て然るべきケース。

例えば、

・障害が疑われるシステムの挙動確認
・既存システムへ機能追加する場合の工数見積

など。

障害は疑われる問合せは、それなりに迅速にかつ正確に対応する必要があり、決して対応難易度は低くない。

見積もり依頼の場合は計画的に来ることが多く、それなりに期限に余裕がある。とはいえ、前提条件を合意してから回答しないと勝手に数字が独り歩きするので、これも決して対応難易度は低い訳ではない。

頻度は低いけど、それなりに気を使うのがこの手の問合せです。

作業量が沢山orミスが許されなくて業務対応が困難な場合

発生頻度:中
対応難易度:中
イライラ度:低

回答にシステム屋のセンスが光るケース。

例えば、

・画面からの入力が何千何万件とあり対応困難(キャンペーンとかでよく起こる)
・超大口の顧客が新規登録を希望されている

など。

情報システムというのは、究極的には、「面倒臭いことを簡単に処理する」ための仕組みなので、大量処理や高精度の対応が必要になる場合、人手ではなくシステムを活用して登録するのが望ましい。人間は必ずミスをする生き物なのだから。

将来的にも同様の作業の発生が見込まれる場合はシステム化する、簡易的なツールを作って異例対応を行う、最近だとRPA化を提案するなど、何らかの自動化の手段を問合せ元の方と一緒に検討して解決していきます。

ちなみに、この手の問合せで大切なのは、行き当りばったりにならないこと。

処理量が多いだけなら、人海戦術や気合で乗り切ることもできる。本当にシステム化を行うほどの規模か?過去数年に渡って同様の依頼がなかったか?その時はどういう対応をしていた?

逆に、頻繁に発生する作業ならシステム化をしないと非効率。人手でやるとどのくらい工数がかかるか?システム化する場合の開発工数は?前者と後者を比較して、費用対効果が見込めないか?

など、短期的に考えるか長期的に考えるかで回答が変わるのが、この手の問合せです。

丸投げ①(知ってるはずor調べればわかる事を聞く)

発生頻度:高
対応難易度:低
イライラ度:中

知らんがな、と言いたいケース。

例えば、

・マニュアルを読んでない
・何もしてないのにおかしくなった

・前任が異動または退職したためノウハウ喪失

など。

恐らく、マニュアルを読まない問合せは、情シスが受ける問合せで一番多いケースではなかろうか。

マニュアルは確かに万能ではない。説明が不十分だったり、古い環境(WindowsXP時代とか)で作成されたため、現代の環境では記載通りにならないこともある。

が、マニュアルは古ければ古いほど案外ちゃんと書いてある。長年そのマニュアルを使って運用してきたのだから。WindowsXPの画面キャプチャだからって思考停止するな。ってかコントロールパネルの操作ぐらいググれ。

そもそも、情報システムの業務利用マニュアルは、情シスではなくユーザ部門で作るケースなんて多々ある。人の作ったマニュアルなんて知らないよ。自分の先輩上司にでも聞いてろ。「作った人が会社辞めちゃったのでわかりませんご協力を」とか知らんがな。

あとは何もしてないのにおかしくなった系。お前が直前にどんな操作したらそうなったかなんて知らんから。

と毎回思いつつ、どれも調べて答えるんですけどね。。。

丸投げ②(忙しいからそっちでやって)

発生頻度:中
対応難易度:中
イライラ度:高

ストレスMAXになるのがこの手の問合せ。

例えば、

・自分より情シスの方が暇だと思っている
・システムが少しでも絡むので情シスがやるのが適任とこじつけている

など。

先述した「作業量が沢山…」のケースがこのケースになることもある。確かに作業量は多いけど、社内調整してる暇あったら終わるだろ!って程度の作業を押し付けてくる。情シスは単純作業要員ではありません。新人にでもやらせとけ。

面倒なのは個人情報が絡む時。J-SOX法によると、開発部門である情シスとは本番環境へのアクセスが制限され、運用部門であるユーザ部は開発環境へのアクセスが制限されていなければならない。

つまり、情シスは、運用部門がやむを得ず対処できない場合を除き、気軽に業務運用のために本番環境を触ってはいけない。

カメラ付きのデータセンタでしか本番作業ができなかったり、本番環境を触るのに厳格な入館申請が必要な現場も多い。(※もちろん企業によってルールはまちまち。あくまで一般論)

なのに、忙しいから、至急だからという理由で、個人情報の取得を依頼されるケースがあるが、絶対対応できない。しかし理解してもらうのが難しい。大半の場合、この手の依頼をする人は、「システムのことは情シスがなんでもできる」を思い込んでいるから。

迷子の子猫ちゃん(誰に or 何を聞きたいのか理解してない)

発生頻度:低
対応難易度:高
イライラ度:中

ご質問の要件定義が必要な、対応難易度が高いケース。

・とにかく困っていて誰に聞けばいいのかわからない
・自分が何をしたいのか、質問のゴールがどこなのかがわからない

など。

もちろん情シスが答えを持っているならさっさと回答してあげればいい。そうではなくて、情シスが本来の担当ではない場合にこの問合せを受けたと仮定する。

とにかく相手は困っている。なのでなんとか助けてあげたい気持ちになる。しかし自分は答えを持っていない。

でも、誰に何を聞いたらいいのかわからない人に対して、対応できそうな素振りを見せたり過度に親切にすると、正しい担当者だと誤認されることがある。挙句の果てに対応を急かされたり催促されることにもなる。

どう捌けばよいか。

経験上、このケースは、電話やメールでやり取りせず、打合せを設定してじっくり話し合った方が手っ取り早い。

質問に至った経緯はなにか、情シスに何をして欲しいのか、最終的にどうしたいのか。

情シスでできる限界はなにか、考えられるベターな選択肢はなにか、次にどんなアクションを取ればよいか。

上記のように最大限の支援をするが、自分が担当ではない事をきちんと伝え、タスクの所在をはっきりさせる。質問者が解決の糸口を見つけられるようにする。

たとえ担当違いの質問でも、ここまで対応するのは自分にとってもメリットがある。

自分が担当じゃないことを明示した上で解決の糸口を提示してあげると、相手に感謝される。将来自分が困ったときに助けてくれるかもしれない。

でも担当じゃないのに担当できそうな感を見せると、相手は期待するので、できないとわかったときに非難されるかもしれない。社内の人間関係を悪化させるメリットは1つもない。

そんな、振る舞い方一つで後味が大きく変わるのが、この手の問合せです。

問合せ後を受けた後の心構え

過去の問合せ履歴は必ず記録に残す!

受けた問合せは必ず記録に残すべき!

なぜなら、何年も仕事していると定期的に似たような事を聞かれることがある。

履歴が残っていると調べる手間が省けるし、そもそも過去の回答との整合性が取れない回答をするのは、相手を混乱させるし、自分の信用を失い兼ねないから。

それに、問合せ履歴は新規参画者にとって最高のノウハウ

素人が何を疑問に思ってどう回答を受けたのか全部書いてある。有識者が作った引継書に書いてないことも書いてある。真面目に読み込めば新規参画者の立ち上がりがかなり早くなることもある。

自己解決できるためのアドバイスを惜しまない

同じ質問をされないよう、次回は自己解決してもらおう。

・マニュアルに追記する。先方のマニュアルなら修正後に査読させてもらう。
・よくある問合せ事例集を社内に公開する。
・そもそも無駄に複雑な業務なら、簡素化できないか検討する。

など。

上にも書いた通り、情報システムというのは、究極的には「面倒臭いことを簡単に処理する」ための仕組みである。

となると、「面倒臭い事を、簡単に対処できるように相手を導く」ことも、情シスの役割なんじゃないかと考えます。

お礼を言わない人に気をつけろ

丁寧に回答したのに、お礼の1つも言わない人がいる。

もちろん忙し過ぎて返信を忘れてるだけのケースもあるけど、もしかすると相手は情シスを単なる道具だとしか思っていないかもしれない。

「情シスがこう言ったからやりました」と言うための、事実を作りたかっただけかもしれない。

そういう人は警戒したほうが良い。こっちの回答を都合よく解釈して、何かあった場合の責任を、回答者になすりつけようとしていることだってある。

これの対処方法も、問合せの履歴をきちんと残すに尽きる。相手がどういう質問をしてきて、自分がどういう前提をつけてどう回答したか。

聞かれたことと回答したことの事実を、必ず盾として残しておいた方がいい。

世の中良い人だけじゃない。ギブ&テイクのテイクだけを繰り返す人も一定数いる。

まとめ

ということで、よくありがちな問合せのケースを紹介しました。

大切なのは、問合せ対応は情シスの業務の1つではあるけど、最優先業務ではないということ。

最後に、上記で呟いた「壺の話」の引用を添えて、記事の締めくくりとします。情シスのみんな、問い合わせ対応頑張ろうぜ!

「クイズの時間だ」教授はそう言って、大きな壺を取り出し教壇に置いた。その壺に、彼は一つ一つ岩を詰めた。壺がいっぱいになるまで岩を詰めて、彼は学生に聞いた。

「この壺は満杯か?」

教室中の学生が「はい」と答えた。

「本当に?」そう言いながら教授は、教壇の下からバケツいっぱいの砂利を取り出した。

砂利を壺の中に流し込み、壺を振りながら、岩と岩の間を砂利で埋めていく。そしてもう一度聞いた。

「この壺は満杯か?」

一人の生徒が「たぶん違うだろう」と答えた。

教授は「そうだ」と笑い、今度は教壇の下から砂の入ったバケツを取り出した。

それを岩と砂利の隙間に流し込んだ後、三度目の質問を投げかけた。

「この壺は満杯か?」

学生は声を揃えて、「いや」と答えた。教授は水差しを取り出し、壺の縁までなみなみと水を注いだ

彼は学生に最後の質問を投げかける。

「僕が何を言いたいのかわかるだろうか」

一人の学生が手を挙げた。

「どんなにスケジュールが厳しいときでも、最大限の努力をすれば、いつでも予定を詰め込むことは可能だということです」

「それは違う」と教授は言った。

「重要なポイントはそこではないんだよ。この例が私たちに示してくれる真実は、大きな岩を先に入れないかぎり、それが入る余地は、その後二度とないということなんだ」

君たちの人生にとって「大きな岩」とは何だろう、と教授は話しはじめる。

それは、仕事であったり、志であったり、愛する人であったり、家庭であったり、自分の夢であったり……。

ここでいう「大きな岩」とは、君たちにとって一番大事なものだ。

それを最初に壺の中に入れなさい。さもないと、君たちはそれを永遠に失うことになる。

(引用元:『1%の努力』 ダイヤモンド社 西村博之)