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

　コンピュータと人間がうまく調和して作業できるようにすることを仕事にしてきたこの16年間には、今思い出しても当惑で顔がゆがんだり赤くなったりするような出来事をいくつも経験した。わたしがこれまでに犯した過ちは、大まかに言って技術的、政治的、キャリアマネジメントという3つのカテゴリに分類することができる。以下に、わたしが犯した派手な過ちと、そこから学んだ（と信じたい）教訓を順不同で挙げてみたい。

＃1：バックアップをとらずに役員が保存していたファイルを誤って削除してしまったこと

　どうしてそんなことになったのかすら思い出せない。ファイルを削除してしまっただけではなく、そのことに気づいたのはフォーマットの途中だった。わたしは、この事態にどう対処すべきか、オロオロしながら30分も悩んだ。嘘をついて、他のだれかを悪者にしようか？といっても、IT部門には自分ひとりしかいなかったため、他のだれも責めようがなかった。それとも、コンピュータを役員に返却するだけにして後は黙っていようか？「君にコンピュータを渡した時点でファイルはちゃんと存在していたはずだ」と言われてしまうだろう。思いつくことはどれもイマイチだった。わたしは結局、その役員のオフィスにコンピュータを持っていき、「とんだ失敗をしてしまいました。あなたのファイルをすべて削除してしまったうえに、それらを復元する手段はありません。すべてわたしが悪いのです」と白状した。その役員はしばらく沈黙した後に「わかった。今後はもっと注意深く作業をするように」と言いました。それだけです。彼はそれしか言わなかったのです。わたしは彼の足にキスしてもいいと思いました。このときの安堵感は、自らの愚かさと無能さに対する惨めな思いが大きかったぶんだけ、とても大きなものだった。

　ここでの教訓は？バックアップ、バックアップ、バックアップだ。バックアップを少なくとも1つとるまでは、削除、移動、修正、アップグレード、更新、パッチの適用、メモリ消去、フォーマットのいずれも行ってはいけない。わたしはこの時以降、過ってファイルを失うということは経験していない。

＃2：給与計算プログラムを修正したところ、全員の残業手当がゼロになってしまったこと

　これはミッドウェスト地域にある陶磁器工場でのことだった。給与計算プログラムはBASICで記述されており、ミニコンピュータ上で稼働していた。残業手当の新たな計算方法が導入されるということで、適切な修正を行うという作業がわたしに割り当てられた。わたしは本番稼働しているプログラムのコピーを作成し、それに必要な変更を加えてウォークスルーを行った。ロジックは完璧に思えた。わたしがそのプログラムを上司に見せたところ、彼はそれを承認し、次の給与期間の初めに本番プログラムとして稼働させると言った。不安を感じたわたしは、テストシステムがあるかどうか質問した。わたしはその会社で働き始めてから2カ月しかたっておらず、企業文化がよく分かっていなかったからだ。すると上司はニッと笑って、テストシステムなどないと言ったのだった。

　それから2週間後、従業員が給与明細を手にし、とんでもない事実に気付いた際には、文字通りの大騒動となった。残業手当が一切支給されていなかったのだった。ゼロ、何もなし、まったくの無だったのだ。上司は、わたしがあまりにも真っ青な顔をしていたため、早めに帰宅してもよいと言ってくれた。

　ここでの教訓は？これは難しい。プログラミングミスを犯したという点で、わたしのスキルが及ばなかったのは明白だ。それでは、わたしはプログラマとしての自らの能力不足を認識し、その作業を辞退すべきだったのだろうか？わたしは、テストしていないプログラムを本番稼働させることについて不安を示したが、できればもっと強くそう訴えかけるべきだったのだろう。この件でわたしが学んだ最も重要な教訓はおそらく、新たな仕事に応募する際の面接において、企業文化について詳細に質問し、ベストプラクティスを支持しない企業を見極め、避けるようにするということだろう。

＃3：MS Exchangeのデモ版を本番稼働させたこと

　2人からなるIT部門に新たに雇い入れられたわたしは、MS Exchangeを導入するプロジェクトを任された。その会社で利用されていたテキストベースの無償電子メールシステムは使い方が難しくてだれも利用していなかったため、移行すべきメールもなかった。そのため、インストールは簡単に済むはずだった。

　わたしはMS Exchangeのデモ版を入手し、そのインストールと設定を行った後、少人数のテストユーザーを選んでテストグループとした。そして、MS Exchangeの利用に興味を持ったすべてのユーザーに対してトレーニングを実施したのだが、ほどなくしてその「テスト」グループはすべての従業員を含むまでに大きくなった。テストを開始して数週間も経っていないのに、保存データは急速に増えていった。ユーザーはフォルダやアーカイブを作成したり、アドレス帳に連絡先情報を登録したりしはじめたのだ。適正なMS Exchangeのライセンスを入手すればそれをデモ版に適用できると想定していたわたしは、ライセンスを発注した。しかし、そのライセンスをデモ版に適用しようとしたができなかったため、Microsoftに連絡したところ、心臓が止まりそうな事実を告げられた。ライセンスをデモ版に適用することがまったく不可能であるばかりか、さらに悪いことに、デモ版は使用後90日を過ぎると機能しなくなると言われたのだ。この事実を知ったのは、デモ版の使用を開始してから88日目のことだった。言うまでもなく、その後の48時間、わたしはMicrosoftの技術サポートに電話をかけながら、デモ版をリプレースするために新たなサーバをセットアップし、データを移行し、クライアントの設定を変更することになった。それは冷や汗ものの大混乱だった。この経験における唯一の救いは、それが良い学習機会となったことだけだ。

　ここで学んだ数多くの教訓のなかでも特に重要なものは？

• デモ版のアプリケーションを本番で使用する前に、使用期限がくると使えなくなることがないかどうかを確かめること。
• プロジェクト計画を立て、それを守ること。わたしは、テストグループを会社全体にまで広げるべきではなかった。
• ユーザーとのコミュニケーションを密にすること。わたしは、ユーザーがテストシステムを本番システムと同様に利用しはじめることを許すべきではなかった。
• 新たなシステムに対する責任を負う前に、トレーニングに参加させてもらえるよう主張すること。

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

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

　ここでの教訓は？

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

＃5：専有の知識を持ってしまったこと

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

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

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

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

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

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

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

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

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

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

＃8：デリカシーに欠ける電子メールを他の従業員に送信してしまったこと

　わたしはある従業員から、彼女がそのコンピュータに関して抱えている広範囲の問題を詳細に記述した電子メールを受け取った。わたしは何の悪気もなく、コンピュータの取り替え時のように思えると書いた電子メールを送り返した。わたしはそのことについてそれ以上考えることなく、彼女の問題を今日の作業リストに追加した。その数分後、わたしは直属の上司と、その上司に、緊急のミーティングに参加するよう呼び出された。部屋に入るなりわたしは、くだんの従業員に返信した電子メールのプリントアウトを手渡され、なぜそんなメールを送信したのか説明するよう求められた。

　わたしは完全に困惑し、何が起こっているのか理解できないと言った。わたしの上司の説明によれば、くだんの従業員は、わたしの出した電子メールの陽気さを、彼女の問題を真剣に捉えようとしていないか、彼女を支援する気がないかのいずれかだと解釈したため、非常に気分を害したということだった。わたしは、邪気のない数語の単語による、下手な冗談がそれほど劇的に誤解されたことにショックを受けた。上司はわたしに対して、その従業員に謝罪し、彼女が抱えていた問題をすぐに解決するよう指示した。

　ここでの教訓は？

• 電子メールで面白い物言いや小賢しい言い回しを書こうとしてはいけない。ものごとはストレートに記述するべきである。
• 支援要請の取り扱い手順を公式に決めておくべきである。
• ユーザーが支援を要請してきた際には、問題の解決がいつ頃になりそうかを必ず伝えるようにすべきである。

＃9：自己費用負担なしでトレーニングを受けたり、認定書を取得する機会があったのに逃してしまったこと

　わたしは、新たな仕事に就くために履歴書を更新するたびに、自らの経験にふさわしい公式な認定書を取得できていないことを後悔する。このことは、去ろうとしている会社が従業員に対して、現在の仕事への関連に関わらずトレーニングクラス費用を負担するというポリシーを持っている場合に特にいまいましく感じられる。特定の認定書を要求されたせいで、それ以外の条件では適任である職に就けなかったことが何度かあった。

　ここでの教訓は？自己費用負担なしでトレーニング機会を得ることができるのであれば、それが就業時間外に行われるものであっても、利用するべきである。