|
|
 |
japan.internet.com 編集部 |
米国 Jupitermedia が運営する IT マネジメントに特化したサイト。
|
|
|
|
|
 |
緊急時の呼び出しの負担を軽減する
著者: Eric Spiegel プリンター用 記事を転送
▼2007年1月12日 13:50 付の記事
■海外internet.com発の記事
真夜中に電話が鳴るたびに、それが感情のない声の主からだということはほとんど予測がついていた。「ジョブ J-S-1-5-3 はエラーコード1234により、回線番号12で異常終了しました」といった類の単調な機械的な音が流れてきた。
いつでも“オンコール”（24時間待機していること）を迫られる多くの IT スタッフにとって、これは聞き慣れた話で、しかもあまりありがたくない出来事だ。何年もの間、システムサポートスタッフは、ポケベルや携帯の振動音や呼出音で眠りを妨害され続けている。おそらくこうした電話は家の電話に転送されるようになっており、家族の眠りをも覚ましてしまうのだろう。真夜中に眠りの世界から飛び起き、仕事モードの冷静な精神状態に戻すのはかなり難しい。
90年代初頭、初めてポケベルを渡され、オンコールを命じられたときのことを覚えている。重要な任務だと思った。パーティの出席中もいつも誇らしげにポケベルをベルトに着用し、決してポケットにしまいこむことなどなかった。そしてポケベルが鳴ると、自慢げに周囲に聞こえるように、「すみませんが、コンピュータセンターに行かなければならないんです」と大きな声で宣言していたものだった。
こんなことは、あっという間に遠い昔の話になってしまった。
食事をしている時、好きなテレビ番組の大事な場面で（当時は、デジタルビデオレコーダーが出る前の時代だった）、そして何よりも真夜中にポケベルの呼び出しを受けることが続くと、次第にオンコールの任務はそれほど魅力的ではないと思い始めるようになった。
実際のところ、最悪な仕事だった。ときには問題を解決するために早朝まで仕事が長引くこともあり、そんな後でも朝早くに職場に戻って、意識がもうろうとして怒りっぽくなりながら更にコードを書いていたものだ。どうしたら電話の件数を減らせるのかとか、少なくともオンコールスタッフの生活のストレスが多少なり減らないかと考え始めた。
コーディングの標準や技術があがれば、バグの数が減ることはわかりきった話のように思える。そして必ずしも CMM や ISO9001 環境でプロセスを制度化して働かなければならないわけではない。
しかし多くの IT 企業では、バブル崩壊によるスタッフの減員が原因で起きたレベル低下から立ち直れていない。また人は働きすぎると、時間を短縮できる近道を探そうとするものだ。中小企業には専任のサポートスタッフがいなくて、チームのメンバーがそれぞれ順番にサポートしたり、エスカレーション式の階級制度にいなければならないというのが現実だ。
だから、みな限界状態で働いているのだ。しかし、深夜に呼び出される回数を減らすためには、標準やプロセスを制度化するだけでなく、メカニズムに組み込んで実行しなければならない。私は、コードおよびユニットのテスト審査を、P2P の標準ベースで、しかも上司がいないところでするのが好きだ。チームは大変うまく自己管理できるし、そのほうがいろいろな声が聞ける。コードが審査に合格し、品質保証と統合テストに合格すれば、すぐに生産過程に進む。
開発者は、このようなプロセスをたどらなければ、コードを生産過程に送り出すことはできないはずだが、オンコールの時は例外だ。システムを再稼動させるための修正の場合、一時的なパッチを考え、同じ審査とテスト過程は後日、できれば翌日に行う。
少なくとも、現在はリモートアクセスの速度があがり簡単になった。しかしその昔は、2400ボー回線のメインフレームに接続するのに、大変時間がかかっていた。サポートチームには Citrix Presentation Server など問題を遠隔で診断できるツールと高速インターネット回線を自宅に用意させること。自宅の PC にサポートを任せてはいけない。サポート用のパソコンに、子供たちが誤ってウイルスをダウンロードするかもしれないからだ。ノート PC かサポートチームが共有する PC のどちらかを使うべきだ。
オンコールのスタッフの生産性を高め、彼らを怒りっぽくさせないための具体的な策は少ない。専任のサポートスタッフにするのではなく、負担を分担するように心がけよう。開発および QA チーム全体をローテーションに入れれば、年間でメンバーひとりあたりがオンコールに費やす時間は少なくなるだろう。彼らはコードを書いたりテストする専門家なのだから、何か問題が起きればすばやく修正できるだろう。開発者が新しいモジュールを追加したときは、稼動初日には誰かがオンコールできるようにスケジュールを調整すること。
休日のサポートスケジュールはうまくやりくりすること。感謝祭でオンコールだったスタッフは、クリスマスには休暇を取らせる。スタッフが心の準備をできるように、年末の休暇が始まる前に翌年の年間スケジュールを発表すること。
オンコールの割り当て日を交換できる制度にする。だが、この日は割り当てた人の専門知識が必要だと思ったら、割り当て日を交換できないように拒否権を発することもできる。拒否権を発した場合は、代休を与えるなどその他の特典を与えて償う。
オンコールが仕事以外の生活に与える影響については細心の注意を払うこと。オンコールの時は、完全に仕事のことを忘れることはできないものだ。トラブルに備えて常に体をあけていなければいけないため、余分な計画を立てない（または地元のバーでアルコールを飲んだりしない）ように気をつけなければならないからだ。
配偶者が外出中に子供たちを見ていることだって、サポートの呼び出しがかかれば悪夢になる。オンコールが終わったら月曜の半日は休暇を与えるように考慮する。そうすれば家族の時間や回復するための時間を数時間余分に与えることができる。一度も呼び出しがなかったとしても、警戒態勢でいなければならなかったことは変わらず、ストレスレベルはあがっているのだ。
チームのメンバーが問題を解決しようと夜遅くまで（朝早くまで）仕事しているような特別な場合は、翌日の出勤時間に融通を利かせる。睡眠不足で書いたコードを正しいと思うだろうか。連続して何夜も徹夜状態だったら、代休を与えることを考える。
まず、バグを減らすためにプロセスを改善し、スタッフにサポートツールを与え、そして24時間体制のサポートによるストレスに細心の注意を払う。こうすることによって、緊急時のオンコールの負担を軽減する環境を作ることができる。
|
|
|
