ディレクトリサービスの導入で低TCOネットワークシステムの構築を実現

日本コムシス

　日本コムシスではDDX-Pから現在のATM網を中心としたネットワークに移行する際に、ディレクトリサービスを提供するノベルのサーバOS、NetWareを採用した。

　ディレクトリサービスは、ユーザーアカウントやユーザーが所属するグループ、共有ボリューム、ファイルサーバ、プリンタサーバといったネットワーク上のリソースを一元管理できる。これらのリソース情報は1つのデータベースに格納されるため、管理者はこのデータベースに対してだけ管理作業を行なえばよいのだ。

　このメリットは、たとえば管理者にとってもっとも負荷がかかるユーザー管理の作業に恩恵をもたらす。日本コムシスのように拠点が全国に存在し、かつ社員を数千人もかかえる企業では、支店間での社員の異動、社員の入退社が頻繁に発生することになる。しかしNDS(Novell Directory Service)を使えば、社員の異動は管理画面上で異動先の支店へユーザーをドラッグ＆ドロップするだけの操作ですむ。また、新しく入社する社員の場合でも、ユーザーを新規に作成し、所属先の部署にドロップするだけだ。同社ではNDSを使い、ユーザーアカウントの管理を品川センタビル内ですべて行なっている。

　三井氏は「ユーザー管理と人事管理の統合、つまりITとHR(Human Resource)の融合を目標にしています」と語る。「人・物・金・情報を切り離したくないのです」(三井氏)。これらの融合が企業活動の迅速化、TCOの削減に大いに貢献するというのだ。そしてそれらを実現するのが情報システム部門の大きな役割の1つというわけだ。この姿勢は、たとえば同社の電子メールアドレスが社員番号と同じという点にも現われている。メールアカウントと社員識別のIDがすでに同一になっているわけだ。現在同社はPeople Softを人事管理等に利用しているが、将来はNDSと連動させる構想をもっている。

経営企画本部　社内情報システム部　課長代理　　山田賢治氏

　現在でこそNDSを使いこなしているが、導入当初はノベルにも充分なノウハウがなく、トラブルには自力で対処するしかなかった。当時を振り返り、社内情報システム部課長代理、山田賢治氏は「まるで腫れ物にでも触るようでした」と、笑いながら語る。同社は「各拠点に技術者を育てるというのは無理です。一元管理をどうするかを考えること。通信費コストを意識して通信トラフィックを考慮すること。この2点がすべてです」(山田氏)というポリシーを崩すことなく、現在はディレクトリサービスの恩恵を充分に受けたネットワーク構築に成功している。そして、この成功の背景には、もう1つ一貫した重要なポリシーがある。それは、ディレクトリサービスの設計では「場所」にこだわるということだ。「最近はディレクトリサービスを考えるときに人と連携させようとする傾向が強いようです。本当は地域、場所を優先したうえで組織というものを考えたほうがよいのです」(社内情報システム部課長代理　佐藤博氏)。ディレクトリサービスというとつい組織をベースにツリーをつくるという頭になりがちだ。だが、地域とかビルといった業務の形態を考えないと、常に組織変更に振り回されてしまう結果を産む。同社はディレクトリを地域で分け、たとえば東京地域を「00」と表現している。ビルの愛称は必ず3文字で表現し、その下に部門のOU(Organizational Unit)がある。部門コンテナの名称は部門コードで表現され、その下にサーバや共有ボリュームが置かれている。「サーバ名は2桁の文字で表現されていて、どんな役割をもったサーバか名前から判断できるようになっています。そういったことまでしっかり考えていかないと成功しないのです」(三井氏)。すべての名前表現に拡張性を含ませることで、ディレクトリサービスのよさが出てくる。

経営企画本部　社内情報システム部　課長代理　　佐藤博氏

　しかし、地域や場所を重視し、組織を無視しているわけではない。たとえば2つのビルに同じ組織がまたがっている場合は、ツリー上は別であっても、同一のグループに含めればよい。グループ単位でネットワークリソースを利用するためのポリシーを定義しておけば、ボリュームに対して、いちばんみじかなサーバにログインして、どのボリュームにもアクセスできるというわけだ。前述したDoPaもグループに含めることによって、社員が全国のどこにいても、その人が所属するグループ(組織)に定義されたポリシーに従ってフルサービスを受けられるようになっている。ちなみにこのDoPaからのアクセスはNDSに対応したRADIUSサーバを利用することで、ユーザーアカウントの二重管理を不要にしている。ここにもNDSのメリットが現れている。

　場所でツリーを構成する理由には通信トラフィックの軽減もある。ツリー構造は通信トラフィックに直接影響が出る。これを無視すると「64kbpsの部分の6割くらいを占めてしまうことがある」(山田氏)という。ビル単位でツリーを考え、さらには通信帯域を見ながらパーティションをつくることで対応することが重要だという。「地域、場所、ビルというかたちから考えていけば、難しくはありません。トラフィックが発生するパターンが決まっているので、そういったものをみていけばよいのです。いまはそういう資料が多数でてきているので楽ですが、我々のときはなにもありませんでした」(山田氏)

	情報システム部のマシンルームにはラックマウント型のPCサーバが並ぶ。NetWare 4.1、NDS 6.03の配下ではグループウェアのノーツ、基幹系で使用しているOracle 7などが稼動している

　最近「NDSに頼りすぎている企業が多い」と三井氏は言う。「素直に考えて、欲張らないというが大事です。あるから使うというのではなく、必要だと思うものしか使わない」(同氏)ことが重要だという。たとえばグループウェア的な使い方をNDSに求めるのではなく、グループウェアはノーツを使う、DBはオラクルを使うといった分離が重要だというわけだ。