IT管理者が犯しがちな5つの過ち
過ち#1：事後対応のみで、事前対策なし
IT管理者が犯す最大の過ちは、責務の果たし方が事後対応的であることだ。つまり、問題が起こってから対応に慌てふためく人が多く、早くから潜在的問題に気づき、事前に解決策を用意しておく人は少ない。IT管理者に特有のことではないが、IT部門の管理者が予防的措置を怠るとなると、致命的な過ちになりうる。
たとえば、しっかりした予防意識を持っているIT管理者なら、事が起こってからその場でレスキュー計画をでっち上げたりせず、事前にちゃんと備えをしておくだろう。しかも、ハードウェア障害、自然災害、システム不調、その他、起こりうる危険の1つ1つに対応策を用意しておくに違いない。火災が発生してから消火に慌てふためく管理者は、おそらく予防意識が足りない……か、前任者のつけを払わされている。
予防意識の強い管理者は、キャパシティ計画、アップグレード、サポートのすべての面で将来計画を考えている。たとえば、あるアプリケーションがサーバ1台で間に合わなくなったらどうするか。複数のサーバに配備することは困難か。そもそも可能なのか。オープンソースソフトウェアを配備するなら、当然、それをサポートするコミュニティの健全さも評価しておかなければならないだろう。長い歴史と活発な開発者コミュニティに支えられているプロジェクトなら――たとえば、SambaやApacheのようなプロジェクトなら――安心だが、3週間前にSourceForgeにデビューしたばかりというプロジェクトは、必ずしも最善の選択とは言えない。
将来を見据えたITインフラ計画が欠如していて、そのためにひどい成長痛を経験する組織は多い。いまは5〜50人のユーザをサポートするだけで十分かもしれないが、3年後、5年後はどうだろうか。そんな将来のことまで心配する必要がないと思う管理者は、それだけでもう失格と言ってよい。
ハードウェアは十分に吟味し、寿命とサポート期間の長いサーバや機器を選ぼう。標準外のハードウェア――とくに、バイナリのカーネルモジュールしかないハードウェア――を選ぼうとするときは、とくに慎重さが求められる。当面はベンダからサポートとアップグレードが得られるからよいが、数年後、そのベンダがサポートを中止したらどうなるだろう。ハードウェアを廃棄するか、カーネルのアップグレードなしでやるかの選択を迫られる。
過ち#2：ドキュメンテーションと訓練の軽視
文字が発明される以前、人類は知識の伝達を口伝えに頼るしかなかった。もちろん、知識を蓄積する方法として、口伝えはきわめて頼りない方法であり、だからこそ文字の必要が生じた。いま、仮に人類学者が平均的なIT部門を遠くからながめたとしたら、そこからどういう印象を受けるだろうか。いまだにポリシーや重要情報の伝達を口伝えに頼っている組織――きっとそういう結論を得るに違いない。
私の経験からすると、ほとんどのIT部門では、スタッフとサポートを受けるユーザとの間の情報伝達が実にお粗末である。たとえば、パスワードや自製アプリケーションのセットアップ方法などの重要情報が、中央の永続的な場所に保管されず、システム管理者の頭の中にしかない。
管理者どうしが電子メールやIMでやり取りしている情報も、ドキュメントにして誰もが手にとれるようにしておかないと、新人には容易に知りえない。サーバやサービスへのパスワード、インストールの指示やガイドライン、ファイアウォール規則など、当該組織に固有の情報はもちろんだし、その他、自明でも標準的でもなく、既存のドキュメントのどこにも見出されない情報は、すべてドキュメント化して、誰にもわかる場所に置いておかなければならない。
ところが、現実は理想から程遠い。IT部門の新人はまず緩慢な情報収集という過程を経てからでないと、周囲についていけない。この過程は労力と時間の無駄であり、尋ねてまわる新人も、新人の絶え間ない質問にさらされる熟練スタッフも、いらいらだけを募らせることになる。
さらに悪いことに、スタッフは異動する。熟練スタッフが知識を書き残さず他へ移ってしまったら、重要情報は失われ、新人に伝わらない。残されたスタッフは、失われた知識を学び直す――たぶん管理者から――ことに貴重な時間を費やさなければならない。
IT部門に新しいスタッフが加われば、必ず調整期間というものが必要になる。だが、適切な訓練とドキュメンテーションを心がければ、調整期間はいくらでも短縮できる。
IT管理者は、ドキュメントとポリシーのリポジトリを中央に用意し、ドキュメンテーションをシステム管理者とプログラマの任務の一部としなければならない。
過ち#3：長所と短所の見損ない
プロジェクトを社内で行うか、外部の業者やホスティングサービスに任せるか。この決定は、Linux IT管理者の犯しがちな過ちの1つである。オープンソース指向で、自力でのプロジェクト遂行を好む傾向があるIT管理者には、これはとりわけ重大な問題である。オープンソースは万人を平等にする。単なる趣味の人も、れっきとした大企業も、同じオープンソースソフトウェアを使用する。だが、それは、ソフトウェアのセットアップの巧みさまで、趣味人と大企業とで同じであることを意味しない。IT管理者は、効果的な管理のために、自分のチームの長所と短所を正確に把握しておかなければならない。
すべてを社内でやってしまえば、費用を削減できる――そう考えるIT管理者は少なくない。だが、注意深く計算すると、実は自力遂行のほうが期間が長引き、結局高くつくこともある。たとえば、数百人のユーザがいる企業で、Windows NTのプリント＆ファイルサービスをSambaで置き換えようと決定したとする。それ自体はよい決定だが、Sambaに熟練した人間がいないのに、これを社内スタッフだけで行おうとするのは、たぶん間違いである。Sambaの管理は決して難しくない。有能な管理者なら、以前の経験なしでも、Sambaをセットアップし、維持することはできると思う。ただし、小さな組織なら、という条件が付く。組織の規模が大きくなり、複雑な配備が必要になると、Sambaに精通した業者に依頼するのが正解だろう。
Webサイトのホスティングにしても、Apache、PHP、オープンソースのコンテンツ管理システムでやることは難しくない。だが、Webサイトが組織の中核的ビジネスの一部になっているならともかく、そうでないときは、それを社内でやるのは時間的にも資金的にも無駄が多い。自力でWebサーバを運営しようとするより、専門のホスティング会社に頼んだほうが、安上がりで簡単だというケースは多い。
従来のシステムと新システムの入れ替えプロジェクトでは、経験のある人間に仕事を任せることが2重に重要になる。新規サービスなら、開始が1週間程度遅れても世界は終わらず、IT管理者の首が飛ぶこともなかろう。だが、新システムに既存のサービスを載せるときは、そうはいかない。ゲートが開いた瞬間から、非の打ち所のない全力疾走が要求される。
とは言え、長期にわたるサービスに業者を使ったり、フルタイムのスタッフの代わりに業者を使ったりすることは、ばかげている。社内に知識もマンパワーもあるなら、当然、業者を切るべきだろう。長期的には、誰かをフルタイムで雇い入れたほうが、業者を相場で雇うより安上がりである。
過ち#4：やりすぎ、急ぎすぎ
組織にLinuxを配備し、オープンソースアプリケーションを取り入れようとするIT管理者を、私は賞賛する。だが、既存のシステムの置き換えには慎重の上にも慎重を期すようお願いしたい。あまりに短期間に、あまりに多くのことをやろうとすると、多くの問題が生じ、オープンソースプロジェクトに対する経営陣の印象を悪くして、将来に悪影響を残す。
ITの変化は、ほとんどの場合、混乱のもととなる。アップグレードや新しいソフトウェアなど、ユーザが慣れ親しんでいる現在の環境を変化させるものは、それが何であれ――以前のものより優れていても――一時的に生産性を低下させる。とすれば、以前より機能的に劣る新システムや使いにくい新システムなどは、最初から導入する意味がない。だが、現実にはそれを行う企業が少なくないことを、私は見て知っている。
プロプライエタリなソフトウェアをオープンソースで置き換えたいという理由だけで、順調に稼動しているシステムを機能的に劣るシステムで置き換えてはならない。たとえば、企業がInternet Explorerに代えてFirefoxを標準ブラウザにすることは、一般論としては賢明な行動だと思う。だが、整合性のなさからサイトユーザの作業に支障を来すようなら、絶対に賢明とは言えない。
OpenOffice.orgは、ほとんどのユーザにとって十分なオフィスソフトである。だが、複雑なスプレッドシートを使い、Microsoft Excelにしかない関数を使うユーザにそれを押しつけるのは、考えものである。Microsoft SharePointを使うイントラネットポータルを、Mamboが稼動するLinuxボックスで置き換えたい？ SharePointで使っていた機能がMamboにあるかどうか、すべてのユーザに事前に確認しておくことが必要だろう。
新しいソフトウェアは、旧ソフトウェアとそっくり同じ機能セットを持っている必要はない。ユーザも、旧アプリケーションのすべての機能を使っていたわけではないだろう。しかし、全面的置換の前にテスト配備期間を設け、何が必要かをユーザと徹底的に話し合っておくことが望ましい。全員を満足させようなどとは――無理だから――最初から思わないことだ。しかし、できるだけ多くのユーザを満足させようと（少なくとも、現在の不満足レベルにとどめようと）することは、可能であり、重要でもある。
過ち#5：セキュリティは二次的問題
Linuxにオープンソースと聞くと、それだけで安全と思い込むことは、よく見る過ちである。Linuxとオープンソースの上に安全な環境を築けることは事実だが、サーバとアプリケーションに適切な安全対策が施されていなければ、最初から侵入を覚悟しておいたほうがいい。
セキュリティを軽視しているIT管理者が多すぎる。セキュリティパッチのインストールやファイアウォール規則の厳格化にはやかましくても、組織全体の包括的セキュリティポリシーはおざなりになっていることが多い。
建物の玄関からファイアウォールに至るまで、セキュリティはITアーキテクチャ全体に遍在する要素でなければならない。トラステッドユーザでもないのに、企業VPNを通じてファイアウォールの背後のサーバにまでアクセスできるのでは、いくら強固なファイアウォールを導入しても意味がない。組織のWebサイトを駆動する内製コードの安全性が疑わしいのでは、サーバ上のパッケージの1つ1つにパッチをインストールしても効果はない。通りがかりの人がサーバ室に自由に入り込め、そこのマシンでルートユーザのセッションが進行中だったというのでは、いくらユーザアカウントのパスワードを10桁にし、8週間ごとに変更するよう義務づけても、すべては水泡に帰す。
必要なら、外部に手助けを求めよう。セキュリティ問題の専門家がIT部門のスタッフにいないなら、コンサルタントを呼び、ITインフラのセキュリティについて助言を求めることを躊躇してはならない。
原文
