IT専門家の告白--わたしが仕事で犯した9つの過ち - (page 2)

文:Becky Roberts 翻訳校正:吉井美有

2006-07-25 08:00

#4:バックアップは行われていて当然だと思ってしまったこと

 サーバのバックアップはわたし1人の責任だった。わたしはバックアップサーバを設定し、毎日規則正しくテープを交換していた。ユーザーがファイルのリストアを初めて依頼してきた際に、リストアが必要なファイルの入っているフォルダのバックアップが3カ月以上にわたって正しく行われていなかったことが判明したのだった。さらに悪いことに、該当ファイルは一度もバックアップされていなかったのだ。わたしは、自らの過失ではなくソフトウェアの欠陥のせいにしたい衝動を抑えつつ、ユーザーのところへ出向いて謝罪した。ユーザーはとても不満そうだった。

 ここでの教訓は?

  • バックアップは行われていて当然だと思わないこと。
  • バックアップのログは毎日詳細にチェックすること。
  • 日々の業務のなかでリストアの訓練をすること。
  • バックアップ方法の見直しをスケジュールに組み込むこと。

#5:専有の知識を持ってしまったこと

 社内で自分専有の知識やスキルを持っていれば自らの職がより安定するように思えるかもしれないが、それは幻想であるだけではなく、そういった知識を持つことで、個人的な生活に負の影響が及ぶ可能性もあるのだ。わたしは自らのキャリアを通じて数回、そういった状況に陥ってしまい、他の人と知識を共有しなかったがために、家族との週末を邪魔されたり、夜中に電話をかけてこられたり、休暇中に電話をかけてこられたりしたことがある。そんななかで最も印象に残っているのは、脳外科手術を受けて6時間もたっていないわたしに、ICUまで電話をかけてこられたことだ。

 ここでの教訓は?ドキュメント化し、知識を共有し、トレーニングを実施することだ。小規模な企業において、あるいは開発中に、知識を専有せざるを得ないことも時にはある。しかし、知識を専有することが危険となる状況に注意を払い、問題提起するようにしておくことで、そのリスクを最小化することができる。適切なドキュメントが用意されていれば、比較的スキルの低い代替要員でも、危機を乗り切ることは可能なのだ。

#6:自分用のドキュメントが不十分なものになってしまったこと

 ドキュメント化が不十分だったのは、知識の共有を目的としたものだけではなかった。憶えておけると思った手順や設定をドキュメントとして残さなかったために自爆したことも何回かあった。ユーザーにせっつかれ、プレッシャーの下で作業を行っていると、ドキュメント化という手順を省いてしまい、この危機が終わったらドキュメント化しようなどと、守れもしないことを自らに誓ってしまいがちだ。しかし残念なことに、すぐに次の危機に見舞われまた次の危機がやってきてとなり、ドキュメントのことなどそのうちに忘れてしまう。思い出すのは、また別の危機で必要となったときだ。

 ここでの教訓は?この教訓はまだ十分に学びきれていない。プレッシャーの下で作業を行う際には、スクリーンショットをとり、簡単なメモ書きを残すようにし始めたが、危機が去った後ですぐに十分なドキュメントを記述するということは実践できていない。

#7:プロジェクトの開始時に、自らの権限の範囲をはっきりさせておかなかったこと

 過去何年かにわたって、わたしはさまざまな開発、アップグレード、移行のプロジェクトマネージャーを務めてきた。プロジェクトは1つを除き、どれも成功し、定められていた目標を納期までに達成することができた。しかし、達成するにあたってとったプロセスは必ずしも、最も効率的でもなければ、ストレスが最小であったわけでもなかった。

 最近まで、プロジェクトの開始時に自らの権限を確立しておく必要性を感じたことはなかった。なぜなら、各チームのメンバーは全員、わたしの権限を尊重してくれたからだ。しかし、高度に階層化されたある企業における最近のプロジェクトにおいて、わたしのチームは同僚数人と、わたしの上司、マネージャー数人と役員で構成されていた。わたしよりも経験豊富なPMは、わたしがチームメンバーに対してどれだけの権限を持つのかをはっきりさせるためのミーティングを行うべきだと提案した。わたしはそんなことは不要だと思ったが、ほどなくしてそれが原因で苦い目を見ることになった。

 プロジェクトには、特定の日までに完成させる必要のあるさまざまなクリティカルパスが存在していた。しかし、わたしがいくらそのことをチームメンバーに懸命に伝えようとしても、彼らは、「金曜日は休みます。上司が許可してくれましたから」や「それは今日できません。これを行う必要がありますから」などと言ってわたしの指示に頻繁に逆らった。わたしはプロジェクトを成功に導く上での全責任を負っていたが、成功させるために必要な権限を何も手にしていなかったのだ。その結果、このプロジェクトはわたしにとって、納期を守ることができなかった初めてのプロジェクトとなってしまった。

 ここでの教訓は?わたしがマネジメントを行うことになるすべてのプロジェクトにおいて、最初のステップは、わたしに認められる権限がどういうものかをはっきりさせるということだ。そして、その権限がプロジェクトを成功させるには不十分である場合には、もっと大きな権限を与えてくれるよう要求するかさらに上級のプロジェクトマネージャーを任命するよう提案するかというとんでもない選択肢しかない。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ZDNET Japan クイックポール

注目している大規模言語モデル(LLM)を教えてください

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]