コンピュータと人間がうまく調和して作業できるようにすることを仕事にしてきたこの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の技術サポートに電話をかけながら、デモ版をリプレースするために新たなサーバをセットアップし、データを移行し、クライアントの設定を変更することになった。それは冷や汗ものの大混乱だった。この経験における唯一の救いは、それが良い学習機会となったことだけだ。
ここで学んだ数多くの教訓のなかでも特に重要なものは？
- デモ版のアプリケーションを本番で使用する前に、使用期限がくると使えなくなることがないかどうかを確かめること。
- プロジェクト計画を立て、それを守ること。わたしは、テストグループを会社全体にまで広げるべきではなかった。
- ユーザーとのコミュニケーションを密にすること。わたしは、ユーザーがテストシステムを本番システムと同様に利用しはじめることを許すべきではなかった。
- 新たなシステムに対する責任を負う前に、トレーニングに参加させてもらえるよう主張すること。
