サポートエンジニアのひとりごと(旧.本格焼酎忘備録 新館)

サポートエンジニアとして、日々の業務などから思うところをつらつらとアウトプットするBLOGです。誤解の多いサポートエンジニアという職種について、皆様の理解が深まれば幸いです。

Google+がやってきた

招待はしてもらったものの登録が止められていたために出遅れてしまいましたが、ようやくGoogle+への登録が完了しました。まだ知人がほとんど登録できていないのでざっくりとした感想にしかならないのですが、今のところのイメージをまとめておきます。

まず、知り合いを探すのが大変ですね。すでに登録している人はそれなりにいるはずなのですが、メールアドレスなどを知らない上にいつものハンドルと違う名前だったりすると検索キーワードがなくて、見つからない状況になります。

知人などはすべて「サークル」という機能で管理します。mixiでいうところのマイミクのようなイメージではなく、Twitterのフォローやリスト機能に近い感じで、こちらから勝手に追加していく感じです。しかし、Twitterと違うのは、同じ人を複数のサークルに分類してその分類に投稿したメッセージを相手に表示できる機能ですね。相手が自分をサークルに登録してくれているとそのままストリームとして表示され、そうでない場合にはメッセージのように「受信」することになります。
※ここはまだ実際の状況を見ていないので、もしかしたら少し違うかもしれません。

いままでのSNSとはちょっと毛色が異なりますね。もう少し知人が増えてくると面白い使い方も見えてくるかもしれません。ちなみに私はhttp://gplus.to/shibataniにおりますので、興味がありましたらアクセスしてみてください。

サポートには不向きな仕事

このBLOGではサポートエンジニアが万能であるかのような内容が多くなっているため、この辺でサポートエンジニアを入れないほうがよい仕事などを経験からつらつら書いてみます。

何度も書いてきているようにきちんと考えるサポートエンジニアは、「最悪のケースを想定し、抜本解決を志向する」職種です。そのため、新規事業を立ち上げる際にも最悪の事態を想定して消極的ととられかねないコメントから入ってしまいます。サポートエンジニアのコメントだけ聞いていると「この新規事業はまるでうまくいかないのではないか」と思いたくなるような事態ばかり提起してきます。勢いが大事なキックオフ時点ではサポートエンジニアは入れないほうがよいでしょう。

逆に新規事業をスタートさせ、下準備が整い、ある程度方向性と事業の継続が見えてきた段階で、サポートエンジニアが役に立ちます。サポートの現場をいくつも経験しているサポートエンジニアであれば、その時点で想定される問題点を次々と挙げることが出来るでしょう。方向性と事業継続が見えているのであれば、それらは今後発生する可能性のある問題点の予言なので、その提言を一つずつ解決していくことで土台はかなり強固になります。

また、サポートエンジニアの業務によって、客先との信頼関係を基にしないと進められないことがたくさんあります。他の職種もそうした側面はありますが、サポートほどお客様の信頼がないと業務を進めにくい業務もないといえます。そうしたサポートに対して「顧客との値上げ交渉」など金銭的なやりとりは難しいといえます。むしろ、営業サイドが厳しい条件を出した裏でサポートエンジニアがお客様をなだめる役割というわけ方を採るのがよいパートナーシップといえます。

アウトソーシングの時代は終わり

かつて日本では「アウトソーシング」が大流行しました。あらゆるものを外部へ委託することで経費が削減するという発想で、サポートはもちろんのこと、経理や開発、果ては営業部隊のアウトソーサーまで現れました。一見するとこれは大幅な経費削減ができたように見えました。

今でも日本はアウトソーシングを中心に考えています。たとえば開発に関しては極力自社内で開発せず、下請け孫請けへと仕事が流れていく構図です。開発を持たずに下請企業を利用して開発を行うとどうなるのか。いくつかの企業から伺った話をもとにどこの企業側からないように内容を混ぜながらご紹介します。

ある企業が基幹業務システムの更新を行うことになりました。以前はパッケージソフトでやっていたのですが、業務拡大に伴ってそのパッケージソフトだけでは上手く廻らなくなり、今回はフルスクラッチで使いやすいものを作ることにしました。そこで大手SIerへ見積もりを取り、プレゼンテーションを行って、一番安いところに決めました。安いといっても何千万円という大きな金額です。要件定義が終わり、細かいGUI回りの修正要望はしたものの基本設計は当初決められたとおりで進行していきました。はじめこそ開発は順調に進んでいるという報告がなされていました。しかし、途中から遅れが目立つようになり、そのたびに「開発人数を増やして対応しています」という回答が返ってくるばかり。最終的に1ヶ月遅れて納品となりましたが、出来上がったものは、表面上は動いているもののマニュアルにない少し特殊な動きをするととたんにフリーズしてしまうような代物だったそうです。
発注側は当然なぜこんなことになったのか原因を追究します。当初はあれこれいい逃れをしていたSIerでしたが、3ヶ月以上まともに稼動しなかったことからSIerへ発注元の社長を含めた幹部が乗り込んで追及したところ、以下の構図が明らかになったそうです。

このSierは今回のプロジェクトを3つにわけ、それぞれを下請けにそのまま投げました。下請けは自分たちの担当部分を切り分けさらに孫請けへ投げます。孫請け側はそれを基に仕様書どおりに作成しました。下請けは下請法の関係から要件定義に問題がなかった時点で納品とすることになりました。ここまでは問題なかったのです。
最初の躓きは孫受けから来たプログラムモジュールを結合するところで発生しました。モジュール間で当然データのやり取りをするわけですが、その部分で齟齬が発生して想定した動きにならなかったのです。下請け側は孫請けに対して修正要求をし、仕方なく孫請け側はその要求どおりに修正を試みるのですが、当初納入したものは使用どおりになっていて、そこからの修正は孫請けの持ち出しになってしまうことから別の案件へ人が廻ってしまっていて、なかなか進みません。孫請け側はいったん納品が完了していることから本来は追加費用を請求できるはずですが、今後の関係もあるのでそこはなかなか文句をいえません。しかし、それだけのリソースをまわす余裕は孫請け側にはないのでさらに遅れるという堂々巡りでした。孫請け側での処置が何とか完了していざSIerが結合しようとしたところ、さらにここでも問題が発生します。修正するには孫請け側に依頼しなければならないのでさらに時間がかかるという始末です。
最終的に別の孫請けに追加費用を出して修正が入って何とか動くようにはなったのですが、そもそも案件定義のときには居なかった孫請けですから想定されていない操作を作りこむところまでは発注に入っておらず、想定していない動きをすると問題が発生するという代物になってしまいました。
この会社の方は「IT関係の投資はいつもこんなことばかりで高いお金を出すのにトラブルばかりだ」と嘆いています。
こういう話、私もよく聴きますし、実際に体験したこともあります。みなさまもけっこう体験されている話なのではないでしょうか。

ここで視点を少し変えた話をします。
いま諸外国のみならず日本国内で非常に強い力を持っている二つの外資企業があります。GoogleとAmazonです。この両社に共通していること、それは開発やサポートをすべて自社で雇用する正社員によって完結しているということです。これが今の日本に欠けている大きな問題点です。この会社の方も「国内SIerで全部自社内で完結できるところをしらないので今度は国外で一環開発をしているところに依頼しようと思っている」と話しています。つまりいま求められているのは受託した開発案件を開発から保守まで一貫して自社で担当してくれる企業ということです。実は一時期の日本でもこの動きをとっていた唯一といってもよいIT企業がありました。それがlivedoorです。堀江氏に対する評価はいろいろだと思いますが、livedoorは当時のIT企業の中でずば抜けた技術力を持ち、先端的な開発とサービス提供をしていた企業だったのです。ですから堀江氏が逮捕されたとき、livedoorのサーバ群はあれだけのアクセス数がありながら少し重くなった程度で稼動を続けることができたのです。今の日本で主要なIT企業といえば楽天とYahooですが、どちらもアクセスすればわかるようにちょっとした事件事故があるだけですぐにサーバが重くなります。Yahooブログにいたっては平常時でもかなりの重さです。堀江氏がもし逮捕されていなかったらもしかしたらlivedoorはGoogleとならぶ国内発の巨大IT企業になっていたかもしれませんが、それはもう今となっては夢想でしかありません。

話が若干脱線しました。
もうアウトソーシングの時代は終わりです。いま日本企業に求められていることはすべてを内製化して、自社の責任のみでサービスの提供を行うという体制作りです。それが競争力強化と新規製品の開発へとつながっていきます。派遣やアルバイト、下請けを活用して適当にお茶を濁す時代はもうおしまいにしましょう。

サポートとストレス

今回はサポートエンジニアが抱えるストレスについて述べてまいります。
社会人であれば、多かれ少なかれ仕事におけるストレスというのは、多々抱えているものです。システムエンジニアであれば納期に間に合うかどうか、プログラマであれば不具合の修復が思うようにいかないですとか、営業であれば抱えている目標数字との戦いなど。
しっかりとしたサポートエンジニアとしての業務を任されている場合、その多くが対人ストレスになります。サポートエンジニアの業務は、お客様と社内にいるプログラマ・システムエンジニア・営業や外注の委託先との間に立って、両方の状況を理解しながら、折り合いを付けつつ、お客様満足をいかに高めていくか、という仕事です。社内外の人から時に怒られ、時に怒鳴られ、時に突発の休日出勤が発生するなど、精神的なストレスは他の職種とは大きく異なります。以前、たまたま知り合った方に精神的に磨り減る毎日をどう過ごすか、という相談を受けた際にはこう回答しました。「サポートの仕事は人があってのものがほとんどなので、残業をしても回答が返ってこないことが多いのが現実です。サポートエンジニアは時間内で効率よく業務をまわして、なるべく残業せずに早めに会社を出て、余暇活動で仕事のことを一切考えない時間を毎日必ず作ることだ。」と。
特に社内のプログラム修正待ちなどでは「依頼しているのに早く帰るのは悪いから」と社内に残って明日やれる仕事をやってしまうことが多々ありますが、それはサポートエンジニアの精神ストレスを高めてしまうよくないやり方です。また、そうした行為は逆に修正をしてくれている人に対するプレッシャーになることもあります。早く帰れるようであれば早く帰るようにして、プログラマさんの尽力で修正が終ったら飲むのが好きな人なら一緒に飲みに行くとか、カラオケが好きな人なら一緒にカラオケに行くとか、別の方法での感謝を実践するべきです。もちろん、そうした時間外活動ではなく、大げさなくらい感謝をするといった方法が有効な場合も多く存在します。仕事なので修正するのは当たり前ですし、相手もそれでお金を得ている以上、ビジネスライクでいいと思われる向きもあるかもしれませんが、人はそんな無機質な存在ではありません。修正してくれたことに対して感謝をする、そのちょっとした心がけが相手のストレスを軽減させ、ひいては自分のストレスも軽減するきっかけとなっていきます。
人と人との接点にいるサポートエンジニアは対人ストレスとの戦いではありますが、ちょっとした心がけで軽減させることが出来ます。うまく対応して毎日を乗り切り、お客様に喜んでもらえるようにお互い頑張りましょう!

最悪の事態を想定せず忌避する日本社会

日本社会ではサポート職というのはあまり重視されず、足がかりにしてほかへ行こうという人が多い職種です。しかし、諸外国ではサポート一筋という方が結構いらっしゃいます。この違いはなんでしょうか。

サポート職というのは常に最悪の事態を考えます。最悪の事態がどうなるかを考えながら日々対応するのがサポート的な考え方なわけです。しかし、日本社会では「いまから失敗したときのことを考えてどうするんだ」といわれてしまいます。福島第一原発などはまさしく最悪のケースを想定せず先送りにしてきた結果といえます。これが大きな違いです。

ここでいう最悪の事態がどうなるかを考えるというのはなにも絶対に失敗しないように完璧な防御を固める、ということではないのです。現状なされている問題発生時の防御壁すべてが消失してしまった場合にどのような対応を取っていくのか、という点を想定するのがサポート職の考える最悪の事態です。ですからはじめから場当たり的な対応をしていくのではなく順番に対処を進めていきます。

日本社会は諸外国に比べて住みやすいいい社会だと思いますが、「失敗を想定しない」という点が決定的に欠如してしまっているためにひとたび何か大きな問題があると「想定外」が繰り返されてしまうのです。

日本企業のサポートはどうも場当たり的な対応が多すぎると思います。それは最悪の事態は「来ないもの」と空想し、サポートに掛ける費用は無駄な費用としてしまう誤った方向性にあるのではないかと考えます。これからを考えると日本企業に足りないのは最悪の事態に備えるサポート専門職の養成と地位向上が極めて重要だと覚悟を決めることだと思います。
livedoor プロフィール
私の管理しているサイト・BLOG
本格焼酎の楽しみ
本格焼酎と泡盛に関して様々な情報をまとめています。
本格焼酎忘備録 本館(at @nifty)
こちらは主に本格焼酎や清酒など酒類に関する話題を扱っています。
焼酎ニュース通信
本格焼酎に関する時事ニュースのまとめです。
本格焼酎忘備録 モブログ館(at JUGEM)
外出先のちょっとした時間で撮った写真を投稿するために設置しています。
最近のコメント
最近のトラックバック
Twitter
LINE読者登録QRコード
LINE読者登録QRコード
  • ライブドアブログ