SE関のノーツ/ドミノ徒然草

第19回 情報共有の土壌をつくるドメイン設計

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: SE関のノーツ/ドミノ徒然草

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:SE関のノーツ/ドミノ徒然草

このシリーズの続きに乞うご期待。

ノーツのドメインの設計というと、まず普通のクライアント/サーバーシステムとは違って、その範囲が会社全体などと広くなったり、ユーザーが使いやすいようにユーザー名やグループ名を考えたり、と思ったらシステム的に予測もつかないデータ量の推測など、結構たいへんそうです。実際の展開例をいくつか見ると実にさまざまな考え方でドメインが作られています。全社1ドメインでやっているかと思えば、事業部ごとなどで別々のドメインを切っている例。ユーザー名には社員番号を使っていたり、ローマ字名だったり、そして途中に組織の名前を入れたり入れなかったりする例。サーバーの配置も部門ごとだったり、拠点ごとだったり、そして全社統合してあったりする例。セキュリティーは原則オープンの例や原則組織でクローズの例。これらの組み合わせといったらかなりの種類のドメイン設計が世の中には存在するようです。

ただ、どうもこれらのドメイン設計はお金の都合、回線の都合、担当部門や担当者の都合などさまざまな要素がからみあって、本来のノーツの展開目的などがあまり考慮されていないように思えるケースがよくあります。その後はユーザーの不都合がいろいろ出てきて、部門ごとのドメインでメールを送るにも相手を探せなかったり、データベースを共有しようと思っても、複製したりいちいち相互認証を管理者にお願いしなければならなかったり、組織がかわるたびにユーザー名を変えなければならなかったりとさまざまです。

ノーツの展開の目的といえば第一には情報の共有や流通の促進でしょう。その意味でドメイン設計はまさに情報共有をする"場"の設計とでも言えるでしょう。安易にシステム的な観点だけで決めたり、色々な現実的な都合でその"場"が歪められたりするのは好ましいことではないでしょう。情報共有に対する会社としての方針をしっかり持って、それを促進するように決めていかなければならないのではないでしょうか。

具体的にドメイン設計の第一歩は、まずはドメインの範囲を決めることです。ドメインというのは公開アドレス帳を共有する範囲です。通常はドメインと認証を同じにするため、基本は情報共有が自由にできる範囲であり、またメールを出すときに簡単に相手のアドレスを記述できる範囲でもあります。つまりデータベースやメールで情報を流通し交換しあうのにコストが最も低くおさえられる範囲とも言えるでしょう。

企業内の情報共有化の推進というスローガンを掲げて、部門や事業部間の情報の壁を低くしようとするのであれば、当然ドメインは企業単位に近いものになるに違いありません。最近、特に多国籍企業などでは世界を1つの認証体系、例えばLotus社であれば全てのユーザーとサーバーの名前を"/Lotus"という組織の名前、としている例が少なくありません(ただしドメインは規模によってはシステム的に複数にもなる場合もあります)。これは明らかに国境を超えてグループ企業で情報の流通を促進しようとする試みに他ならないでしょう。一方ノーツライセンスはかなりの数を抱えていても星の数ほどのドメインと認証を持っていて自ら組織間の情報流通の壁をつくってしまっているところもあります。

ユーザー名の設計はどうでしょう。ユーザー名の途中に入る組織単位にはよく組織や場所の名前を入れたりしています。確かにどこの誰かという識別のためには助けにはなりますし、一方その単位でセキュリティーをかけるのにも大変便利なものです。ただ昨今の多くの企業では組織変更は頻繁です。組織単位にそれを入れたために、その度にユーザーIDの再配布、データベースやサーバーのセキュリティーの変更と膨大なコストがかかるか、または面倒になって古い名前のまま使っていて、長くてわかりにくいというデメリットだけが残ってしまった例もあります。一方、組織単位があるために、簡単にそして安易にセキュリティーがかけられるということで、本来の組織間の情報共有を妨げるきっかけになることさえあります。

グループの設計はどうでしょう。グループというと普通の人が思い浮かべるのが課とか部とかの組織です。よくあるノーツ展開では、グループは組織と同じものがきっちり人事データベースと連携してメインテナンスされるような仕組みをドメイン設計で検討して構築したりします。その後データベースがたくさん作られはじめると、組織単位と同様に安易にセキュリティーに使われて情報共有のさまたげになることもあります。

本来、組織を超えた情報共有が目的だったのに、セキュリティーをかけるための仕組みがユーザーのためにと用意されて、その使い方のルールも決めていないため、コストがかからず情報閉鎖ができてしまっている例がよく見かけられます。逆に組織外の人に情報をオープンにするには、個別に名前をデータベースやサーバーに登録したりするためにコストがかかるようになってしまいます。情報共有が目的のシステムが、情報共有より情報閉鎖の方がコストがかからないという状態、どうもおかしな現象ではありませんか。

システム的な観点ではどうでしょう。典型的なドメイン設計の検討課題としてはサーバー配置などがあります。ノーツはPCサーバーの分散サーバーとして進化してきたせいか、部門ごとにサーバー配置する例はかなりあります。お金の出所や管理者の所属などから仕方ない側面もありますが、うっかりしていると全社的に公開したいデータベースを置くところがなかったり、またユーザーが他の部門のサーバーを探すのが困難でいっこうに部門間の情報流通が促進されないということも十分有り得ます。そして組織の分割などがおきると、サーバーのとりあいやデータベースの分断に伴う情報の分断がおきたりもします。

ノーツは情報という車が走るハイウェイネットワークと例えることができるかもしれません。将来どんな車の流れをしてほしいかを想定して、いくつもの環状のハイウェイ、そしてそれを放射状につらぬくハイウェイを作るような設計。そして一方で、現在の車の流れ、そして土地の保有者の権利ばかりを気にして、小さな環状ハイウェイ、そして継ぎ接ぎで連絡が悪いハイウェイ、挙げ句の果てには仕方なく信号があるハイウェイの設計。どちらが渋滞がひどくて非効率かは今の日本と欧米のハイウェイを思い起こせば一目瞭然でしょう。

ノーツという情報共有のインフラとしての設計は、やはり現在ではなく将来のこうあるべきという情報共有の姿を描いた上で進めていかなければならないでしょう。ドメイン設計は将来の情報共有という花をさかせるための土壌をつくっているのに他ならないというのは言い過ぎでしょうか。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=338993
ArticleTitle=SE関のノーツ/ドミノ徒然草: 第19回 情報共有の土壌をつくるドメイン設計
publish-date=01032005