<< 1999年7月3日開催 第4回 NT-Committee2 関東勉強会 講演資料 >>
今までのお話からシステム管理者の作業範囲は、ハードウェアとかソフトウェアとかのいわゆるコンピュータを手なずけることだけではなく、ネットワークも面倒見るし、それを使う人への教育も行わなくてはなりません。
理屈は分かったが実際にどうやっていくかという具現化の部分についてについて。
システム管理者に飛び抜けた技術力は必要ありません。何でも知っている必要はなく、調べ方さえ知っていればいいわけです。また、技術的にすぐれた友人とか、メーカーの開発部あたりに知り合いがいればそれが一番。
今やインターネット時代ですので、 Web や ML
でそういった友人を捜すのが一番です。私がいつもお世話になっている
ML
の総本山とも言えるサイトを紹介しますので、いくつか興味を引かれたら騙されたと思って参加してみることです。
オフ会や宴会も頻繁に行われていますので、前の晩に徹夜してでも仕事を終わらせて駆けつけるべきです。
そうは言っても最低限の技術力は必要ですので、書籍に頼らずに実機で確認しましょう。誰からも教わっていないからと他人のせいにしたり、マニュアルに載っていないからとメーカーのせいにしても、困るのは自分ですからね。
会社は、とかく目に見えないモノについてはお金を出したがらない傾向にあるようです。また、保険についても出来るだけ削減しようとして、結果的に事故が起こって保険額以上の支出になることもままあります。
先ずは一体どの位予算があるのか聞くところから。そして、その予算を少しオーバーするくらいの見積もりを。あとは、根拠となる説明をくじけずに。
この攻防をスムーズに行うには、日頃の信頼関係が非常に大切になります。ぜひ、「お前がそういうのなら購入しよう」と言わせるまでの信頼関係を築きましょう。
見積もりの中で絶対忘れてはならないのが保守料。最悪、削られても「ちゃんと検討していた」この証拠を作っておきましょう。
頭の固い上司の下に付くことくらい不幸なことはありません。不幸にして不幸になってしまった場合、先ず「自分は試されている、この上司をうまく使ってみろと神に試されている」と決意を新たにすることです。
頭の固い人はとかく組織への忠誠心が強い人が多いですね。部下の意見は聞かないけれど、上司が「それでいい」と言えばすぐに従う。頼みことをするときには、直属の上司とその上司の上司がいる席で「お願いします」と言う。メールで依頼するときには、必ずCc:に上司の上司を入れておく。「将を射んと欲すればまず馬を射よ」との故事通りを実践すればいいだけです。
自尊心が強く目下の意見にはことごとく反対する人もいます。つまり、自分で物事を決めたいタイプです。そういう場合は、いくつかの案を出してそれについて選んでもらうようにしましょう。そうすれば自分で選んだことになるのでその人の意見と言うことになるでしょう。あまり対抗案が思いつかない場合もありますので、その時は泣き落としでしょう。
最後に、考えつく限りの手を使っても説得できない場合は、自分の責任で勝手にやることです。自分のやったことが正しいかどうかは、システムを使っている人が決めてくれます。自分として、絶対に必要だと思っていることでも、上司が分かってくれない場合があります。だったら、許可なんて取り付けなくてもいいと思います。
あなたは試されているのだから、自分で責任とってみろってことでしょう。勝手に動いてこそ、自分の真価が分かるというのです。だれが自分を理解してくれていて見方なのか。良かれて思ってやって、たまたま失敗して責任を取らせ最悪の結果になっても、私は責任を取れませんので、あくまでも自分の言動は自分で責任もって下さいね、子供じゃないんだから。
バカとハサミは使いよう、とはよく言ったモノで、使えないのは使えない側に問題があると思います。部下の能力が低いのではなくて、その能力を引き出すことが出来ない自分の能力が低いと言うことです。
色々なビジネス本を読んで、実践してみることをお勧めします。対人関係なので一般論はありません。一人々々について、対応が異なります。実践すると失敗もあれば成功もあります。全て成功するわけではないので、諦めずに根気よく対応していきましょう。あまりにもひどかったら、上司に進言する勇気も必要かも知れません。
大切なことは、「自分はこうこうこうゆうことをしたい、ついてはキミにはこれをやって欲しい。キミになぜやらせるのかというのはキミならきっとうまくやってくれると信じているからだ」という自分の気持ちをハッキリ伝えるということです。
「分かってくれるはず」とか「伝わっているはず」とかは、超能力者でもない限り勝手に自分で思い込んでいるだけです。先ずは自分の意識改革から。意志の疎通が図れないのは双方に問題がありますので。
メールの使い方は分かったが、じゃあどうやって周知徹底していくか。システム管理者の仕事は通知することじゃなくて守ってもらうことです。大上段から「今度こうなったから守ってね」と言われてハイそうですかと守れる人ばかりではありません。
先ずは説明会を開催しましょう。内容は資料の棒読みでもいいですけど、顔と顔をつきあわせて話すことに意義があります。貴方のPCの向こう側で我々が頑張っています、というイメージを伝えましょう。そうすることで、「メールで連絡があった」ではなくて「高橋さんから話があった」という意識に変わるはずです。
一応、各チームなり部署の管理者の方に説明をしたら、あとは地道な啓蒙活動です。「我々はチーム管理者を相手しているのでなくて、皆さん個々人を相手している」という姿勢を見せます。うまく伝わっていないな、と思ったらそのチーム管理者に筋道立てずに直接指導しましょう。メールで指導するなら、To:に対象者であり、Cc:にチーム管理者ですね。
人数が多くてとても、なんて弱音はいてはいけません。一日一人を啓蒙するとしても、1000人だったら1000日あれば出来ることです。通達を出したら次の日からビシッと入れ替わるなんてのを想定してはなりません。一日一歩ずつです。慌てず騒がず落ち着いて。
どこにでもいる自称パワーユーザ。勝手にメモリ増設するヤツ、やたらハイスペックマシンを要求するヤツ。ディスクトップやらスタートメニュやら原型をとどめないくらい変更するヤツ。
彼らを上司がうまく使えないと言う場合が多いのですが、要するに彼らは仕事がなくて暇だってことです。最善手はシステム管理者チームに取り込んでしまうことですね。
チーム内に取り込めない場合は、定期的に訪問して、「最近、どう」と話を聞いてあげましょう。そういう人は詰まるところ寂しがり屋で誰かに話を聞いて欲しがっています。
ポリシー使って押さえ込むなんてのは、明治時代のやり方です。PCには無限の可能性があるんだから、自由に使わせてあげましょう。彼らを権力や組織力で押さえ込むのではなく、うまく利用することでシステム管理者としての一人前に近づくことになります。
これにはホント、困ります。無視するわけにもいかず、さりとて勝手に決めるわけにも行かず。時間かけて信頼関係を築くしかないですね。
「高橋さんがそういうんだったら」という信頼関係は一夜では築けませんが、必ずできると信じることです。一緒に麻雀やったり、うまくもない酒を飲んだり、ゴルフが出来るならゴルフもいいですね。
システム管理者はある側面では営業ですから、経費で落ちなくたって自腹で付き合いましょう。御客様もそこまでバカじゃないから、システム管理者が誠心誠意尽くせばきっと振り向いてくれると信じることです。
お金の問題じゃない、仕事だからやっているんじゃない、このシステムを安定稼働させたいからやっているんだ、と言葉じゃなくて態度で示す。誰にだって出来ることです。あなたのやる気が試されています。あなたがシステム管理者として一人前になれるかどうかは、この一点にかかっていると言っても過言ではありません。
基本的には枕を高くしては寝られません。システム管理者たる者、電源を入れたままの携帯を枕元に常においておく覚悟が必要です。
しかし、だれでも呼びだされるのはいやなので、できるだけのことをしておきましょう。
最悪、電話でコンソールの操作をしてもらう場合だってあります。
一時的なAdministratorのアカウントを用意しておき、万一の場合はそれを使って操作してもらう。サーバの再起動で直りそうだったら、ともかく再起動してもらう。どんなトラブルに対応する場合でも、「遠隔地から電話で指示しなければならなかったら」と考えるようにしましょう。普段から考えることによって、メニュ階層を覚えるようにしたり、暫定的なアカウントとか共有ディレクトリとか用意しておかなければならないモノが明確になってきます。
既にお分かりかと思いますが、システムを管理すると言うことはそのシステムを使っている人を管理することに他なりません。
人間を管理するというと、高圧的な管理とか規則を作っての管理とか難しいことを思い浮かべがちですが、一緒にシステムを安定動作させましょうという気持ちをもってもらう働きかけをするだけです。
安定稼働しないと結局はあなたが困るんですよ、的なトーンでもいいし、資源は限りあるので仲良く大切にね、的なトーンでもいいし。システム管理者から言われたらから渋々従っているという気持ちにはさせてはいけません。システムのことを理解して自ら節度を持っている、という気持ちにさせること。
さあ、早速実践です。すぐにはうまくいかないし効果も中々現れないでしょう。山登りと同じ様に「そこに山があるから」と自らを奮い立たせ、一歩一歩進んでいって下さい。
<< 1999年7月3日開催 第4回 NT-Committee2 関東勉強会 講演資料 >>