サポートのすすめ。-後編-

ダウンタイムを短縮すると一口に言っても色々ある。オトコたるとも色々という言葉でお茶を濁してはいけないのでブレークダウンしてすると、

• 不具合が発生した場合に原因を調査する。
• 不具合の一時的な回避方法（ワークアラウンドという）を提案する。
• 復旧までの手順が複雑である場合などに補佐する。
• 製品の欠陥（バグ）が見つかった際に開発部隊に連絡していっしょに解決まで導く。

などを行うのである。

これらはいずれも深い製品知識が要求される。製品の仕様や構造はもちろんであるが、さらにはその土台になっている技術、例えばネットワーク、C言語・Java・PHPなどの開発言語、UNIXなどに関する知識も必要となる。何故ならば、問題の発生源が製品そのものではなく、基盤になっているネットワークやプラットフォームからやってくる場合があるからだ。広範囲な知識を使って、短時間で問題を解決しなければならない。

しかし様々な知識を要するからと言って調査に時間をかけることは許されない。なぜならば、トラブルをいち早くそれを解決しないといけないからである。そして、知識が浅くてはいけない。表面だけの知識などがあっても不具合の原因は分からないのである。

広く深い知識を身につけるというのは根本的には無茶な要求であり、決して一人ですべてをカバーできるものではない。そのためサポートの現場ではチームがお互いをフォローしあって解決するのが常である。だからと言って、個人のスキルが大事でないわけではなく、高いスキルを身につけるべく日頃から研鑽しておく必要がある。目指すはパーフェクト超人である。

オープンソースソフトウェアであろうがなかろうが、ビジネスを動かすのであればプログラムの不具合を迅速に対処しなければならない。プログラムが大規模になればなるほど不具合の可能性が増加する。そして大規模なプログラムほど調査には手間が掛かるものだ。スキルがある人ならオープン ソースソフトウェアならソースコードが開示されているので自分で解決できるよ！と思うかも知れない。けど、ビジネスが止まっている間にチンタラとソース コードを眺めているわけにも行くまい・・・。だからオープンソースソフトウェアに対するサポートがビジネスとして成立するのである。

サポートエンジニアは開発者とは毛色が違う職業であるが、コンピュータに対する必要が深まるという点では引けを取らない。開発者は納期に追われるものであるが、サポートエンジニアさらに激しく時間に追われている。ひとたびトラブルが起きたときの緊張感たるや納期が厳しいどころの話ではない。まさに今事件が現場で起こっているのであり、一分一秒でも早く問題を解決してお客さんのビジネスを再開させねばならないのである。日頃から研鑽したスキルを存分に振るい、真剣にトラブルと戦う様はハードボイルドであるといえよう。

まさにオトコの仕事である。