Directory first step 5... ディレクトリ構築において考慮すべきポイント
コンポーネント選択フェーズ
この段階で，必要となるソフトウェアとハードウェアを選択する。
今日的なディレクトリに求められている事象を振り返るとわかるように，ディレクトリに格納されるデータは膨大なものとなりがちである。それゆえに，将来計画に基づき，最初からサーバーの性能やストレージ容量の拡張性をハードウェアの選択条件に加えておく必要がある。現実的には，ディレクトリサービスを導入するために新たにハードウェアを購入することは，必ずしも必要ではない。既存のハードウェアで対応できる場合もあるので，既存のハードウェアで対応できるかどうかを見極め，必要ならば追加購入すればよいだろう。
また，詳しくは後述するが，ディレクトリ製品にはさまざまなものがある。ディレクトリ製品の選択にあたっては，次のような点を検討および評価しておくべきだろう。
ディレクトリ構造の柔軟性
今日の企業は，ビジネスの環境変化に対して迅速に対応することが求められている。そのため，組織構造も頻繁に変更される。もし，組織構造と対応するようなディレクトリ構造を採用するならば，組織の変化に合わせて柔軟にディレクトリ構造を変更できることが望ましい。
権限の管理機能と柔軟性
一口に「権限」といっても，部課といった組織単位に与えられる基本的な権限のほかに，職位や担当業務に与えられる権限などもある。たとえば，営業部門のマネージャであれば，営業部門に与えられる権限と，営業部門のマネージャに与えられる権限，全社共通してマネージャに与えられる権限を兼ね備える可能性がある。そのほかにも，プロジェクトメンバーとして活動することがあれば，そのプロジェクトに与えられる権限があるかもしれない。さらに，このマネージャが営業部門のシステム管理者に任命されるようであれば，システムの管理権限も必要となるだろう。逆に，ディレクトリに格納されるデータ側から見ると，全社員に公開するものもあるし，一部の部門にのみ公開するもの，一定以上の役職者にのみ公開するもの，あるいは組織や職位に 関係なく特定の役割を持つ者だけに公開するものなど，さまざまであろう。
このように，組織のなかにはさまざまな権限が存在する。権限によっては，人事異動に伴って消滅するものもあれば，引き継がれるものもある。与えられた権限同士が競合し，矛盾する場合もあるかもしれない。このような多様な状況にも柔軟に対応し，一元管理できるようなディレクトリサービスを選択することが重要である。
ディレクトリに格納できるオブジェクトと属性
ディレクトリには，一般的にユーザーやネットワークリソース（たとえばコンピュータやプリンタなど）が格納される。しかし，今日的なディレクトリには，さまざまなリソースを格納することが求められている。したがって，「どのようなネットワークリソースをオブジェクトとして格納できるのか」，そして「そのオブジェクトのどのような属性を格納できるのか」を調査しておく必要がある。
スキーマの拡張性
標準で用意されていないオブジェクトをディレクトリに格納して管理する必要があるならば，ディレクトリのスキーマを拡張しなければならないし，拡張可能なディレクトリサービスを選択しなければならない。Active DirectoryやNDSに代表される最近のディレクトリサービスは，ディレクトリに格納するオブジェクトの種類や属性を，ユーザーのニーズに合わせて拡張できるようになっている。しかし，ディレクトリのスキーマをどこまで拡張できるのか，既存のディレクトリツリーに影響を与えることなく容易に拡張できるのか，拡張するためのインタフェースやツールが用意されているか，ツールの使い勝手はどうか，といった点を評価しておく必要があるだろう。
スケーラビリティ，性能，スループット
従来型のディレクトリとは異なり，今日的なディレクトリには，さまざまな種類のオブジェクトと，その属性が多量に集積されることになる。したがって，オブジェクトをいくつまで格納できるのか，オブジェクトの格納数が増加した場合の応答速度はどの程度か，どれだけのサービス要求に応えられるのか，といった点を評価する必要がある。多数のオブジェクトを集積できても，検索速度が遅くて実用的でなければ，運用上はディレクトリを分割せざるを得ない。また，検索速度を保証するために，どのようなメカニズムをサポートしているのか，そのメカニズムがどの程度有効か，そのメカニズムを利用することで発生する問題はないのか，なども注意深く検証しなければならない。
レプリケーション帯域幅の制御
どこからでもアクセスできるようにする，フォルトトレラントを向上させる，一定の検索速度を保証する――といったさまざまな目的で，ディレクトリは複数のサーバー上に分散されることがある。ディレクトリを分散させた場合，ディレクトリ間で一貫性を保証するために，ディレクトリサーバー間でディレクトリ情報がレプリケーションされる。もし，ディレクトリサーバー間にWANなどの低速回線が存在するのであれば，レプリケーションのトラフィックによって，レプリケーションに要する時間とコストが増大する。
また，LANのような高速回線で接続されていたとしても，レプリケーションすべきデータ量が大量であれば，ネットワークのトラフィックは増大し，ほかの業務に支障をきたすおそれもある。このような問題を解決するための手段として，レプリケーションのスケジューリングやパーティショニング，増分レプリケーションといった機能が備わっているかどうかも確認しておかなければならない。
ディレクトリサービス導入の容易性
ディレクトリサービス製品を選択するときには，導入が容易であるかどうかも検証しておきたい。あるいは，導入を円滑に進めるための支援ツールが提供されているかどうかも，重要な選択肢となる。
既存のディレクトリサービスとの統合と同期
何度か述べているとおり，多くの企業にはすでにさまざまなディレクトリサービスが導入されている。このような既存のディレクトリサービスを統合したり同期させたりして，何らかの形で情報を一元管理できるようにならなければ，新たにディレクトリサービスを導入するメリットは損なわれる。したがって，既存のディレクトリサービスとどこまで統合できるのか，という点も重要になってくる。
特に複数のディレクトリサービスを共存させる場合には，異種ディレクトリと同期させるためのツールが提供されているかどうかも，選択のポイントになるだろう。たとえば，MicrosoftはDirectory Synchronization ServicesによってActive DirectoryとNDS（Novell Directory Service）を同期できるようにすると発表しているし，Novellは異種ディレクトリ同士を同期させるDirXMLという製品を出荷することを表明している。しかし，Microsoft Exchange以外のLotus Notes/Dominoなどのグループウェアやcc:Mailなどの電子メールソフトのアドレス帳などと同期させるようなツールについては，まだ発表されていないようである（Active DirectoryとNotes/Dominoのディレクトリを同期させるツールは，Lotusから提供される計画もあるらしいが，公式には発表されていない。また，NovellのDirXMLがNotes/Dominoなどの外部システムと汎用的に同期できるものとなるかどうかも，まだ不明である）。
既存のディレクトリサービスからの移行ツール
多くの企業には，すでに何らかのディレクトリサービスが導入されているものと思われる。もし，それらを完全に新しいディレクトリサービスに移行させるのであれば，既存のディレクトリサービスからの移行が容易でなければならない。
現実問題として，ネットワークを構成するコンピュータが10台以下の小規模なシステムでもない限り，手作業で1つ1つディレクトリサービスを移行させてゆくことはできないだろう。したがって，使い勝手のよい移行ツールが用意されているかどうかも確認する必要がある。
管理ツールの使いやすさと充実度
ディレクトリに情報を一元管理するようになれば，当然ながら，管理しなければならないオブジェクトの数も範囲も膨大になるだろう。そのディレクトリを管理し，ディレクトリサービスを維持してゆくのは，主にシステム管理者やネットワーク管理者である。一般的に，システム管理者やネットワーク管理者はコンピュータの専門家であり，深い知識を備えている。とはいえ，使いづらい管理ツールでは効率が悪いことに変わりはない。したがって，管理ツールの使いやすさは重要である。また，リモート環境から管理できるような管理ツールが提供されているかどうかも，選択のポイントになるだろう。そのほか，管理を容易にするためのレポート機能や監査機能などが搭載されているかどうかも，確認しておきたい。
堅牢なセキュリティメカニズムのサポート
ディレクトリには，ユーザー情報をはじめとする，機密性の高い重要な情報が格納される。そのため，ディレクトリに格納された情報を保護するため，堅牢なセキュリティメカニズムが必要となる。しかも，堅牢でありながら，利用者から見れば使いやすいセキュリティメカニズムでなければならない。
また，ディレクトリの情報は，各種のアプリケーションや異種システムから利用されることもあり得る。そのため，多彩な状況に対応できるセキュリティメカニズムを備えているかどうもかも，評価のポイントになるかもしれない。多様なセキュリティメカニズムに対応していれば，各セキュリティメカニズムの長所や短所を理解して，要求されるセキュリティレベルに合わせてセキュリティメカニズムを選択できるし，連携の対象となるネットワークやコンピュータに合わせてセキュリティメカニズムを選択できる。しかし半面，ユーザーの運用が複雑化したり，管理者の管理作業が煩雑になったり，管理者や開発者に各セキュリティメカニズムの長所や短所を理解する高い技術力が求められたりすることになる。
アプリケーション開発の容易性
ディレクトリおよびディレクトリサービスはネットワーク管理の基盤であり，ディレクトリサービスの適用範囲を広げるのは，ディレクトリを活用するような各種アプリケーションにほかならない。そのため，アプリケーション開発者向けにツールキットとAPIが提供されているかどうかも，ディレクトリ製品を選択するうえで重要なポイントとなるだろう。アプリケーション開発が容易なディレクトリサービスを選択しておけば，自社に開発スタッフがいなくても，アプリケーションプロバイダやソリューションプロバイダが提供する製品を利用できる可能性が増し，製品を選択する幅が広がる。
ユーザーの要求に応じて，複雑で高度なアプリケーションを開発して販売するISVにとっては，付加価値のあるアプリケーションを安価に，かつ容易に開発できる環境であるか否かも重要となるだろう。
マルチプラットホームのサポート
企業には，さまざまなオペレーティングシステムが稼働するコンピュータが導入されている。しかも，インターネットの普及に伴い，パートナー企業の異種システムと連携させたり統合させたりすることも求められてゆく。したがって，ディレクトリサービスがマルチプラットホームに対応していることも重要となる。
そのほかにも，ディレクトリサービスのライセンス形態と料金，クライアントアクセスライセンスの形態と料金，サポート体制（コンサルティング，構築サービス，ヘルプデスク，トレーニングなど）の充実度と料金体系などもチェックしておかなければならない。なお，ガートナーグループは，1999年10月に開催された「Simposium Itxpo 99」の席上，ディレクトリの選択基準として24個の条件とその重みを発表している（セッション『ディレクトリで実現するポリシーベースネットワーク』）。参考にするとよいだろう。
プロトタイプの作成と評価フェーズ
必要なコンポーネントの選択が終了したら，そのコンポーネントを用いてプロトタイプを作成し，技術的な実現の可能性を評価する。併せて，ユーザーニーズを検証したり，導入上の障害になりそうな部分の洗い出しを進める。
 |
Directory first step（後編） 3/14 |  |
