JP5530173B2 - 組織構造管理ディレクトリを備えたディレクトリシステム及びそのプログラム - Google Patents

Description

本発明は、部署、人、業務などの組織内のリソースと活動の状態を多様な視点で可視化することが可能なディレクトリシステムに関する。

企業内には、一般に、組織構造を情報として保守、参照する情報システムが複数存在する。個々の情報システムは、それぞれ目的とする業務に最適な形態で組織構造を管理している。

図１を参照して、企業システムにおける組織構造の従来の管理方法を説明する。図１に例示される企業システムは、部署の組織情報を管理するシステムＡと、業務プロジェクトの組織情報を管理するシステムＢと、本社やＲ＆Ｄセンター（研究・開発センター）など、所在地の組織情報を管理するシステムＣと、から構成されている。

このような複数のシステムに分散した構成のデータベースシステムの場合、それぞれのシステムにおいて、目的とする業務に最適な形態で組織構造を管理できると共に、負荷分散を図ることができるなどの利点がある。また、組織の階層構造を可視化する際、図１中に示すように、Ａシステムにおいては、部署から見た組織情報をツリー表示し、Ｂシステムにおいては、プロジェクトから見た組織情報をツリー表示し、Ｃシステムにおいては、所在地から見た組織情報をツリー表示するというように、それぞれのシステムにおいて独自の視点で組織の階層構造を可視化することができる。

上記のような組織の階層構造は、ディレクトリツリーによって表すことが可能である。そのようなディレクトリツリーの構築を支援する機能を備えた従来の情報システムとしては、例えば、ディレクトリツリーを構成するエントリを問合せ形式で追加登録できるようにしたものがある（例えば特許文献１参照）。また、組織階層を可視化する際、一般には順方向からのみツリー表示する形態としているが、順方向からも逆方向からもツリー表示できるようにしたものもある（例えば特許文献２参照）。また、業務構造を表す業務プロセスモデルを用いることで、業務内容を構造的に表現できるようにした情報システムも提案されている（例えば特許文献３参照）。

特開２００７−０９４７０９号公報 特開２００７−２５７１２７号公報 特開２００６−２８５３１３号公報

上述したように、組織構造を管理する情報システムにおいて、階層構成や業務内容を構造的に表現できるようにしたシステムは、従来から数多く提案されている。しかしながら、従来の技術では次のような課題がある。

課題１．
組織の構造を視覚的に表現しようとした場合、ヒエラルキー型組織としての視点、マトリクス型組織としてプロジェクトからの視点、あるいは所在地で地理的条件からの視点など、組織を構成する部署、人などのリソースは多様な視点で捉えられる。

従来のシステムでは、個々のシステムがシステムの目的に合わせた単一の視点からの組織構造の表現を前提としており、視点を切替えて、組織構造を参照することは想定されていない。しかし、前述のように組織構造には多様な視点があり、１つの視点での変更が、他の視点へ影響する場合であっても、システムが異なると変更結果を反映することができない。

課題２．
企業内には、組織構造を情報として保守、参照する情報システムは複数存在する。しかし、情報システムはそれぞれ、目的とする業務に最適な形態で組織構造を管理している。したがって、ある１つのシステムでの組織構造情報の更新の結果が他のシステムに反映せず、それぞれに保守の操作が必要となる。例えば、図１に例示したシステムにおいては、図１中に示すように、例えばシステムＣで、Ｅさんの所属する企画部企画課第１課がＲ＆Ｄセンターに引っ越した場合、システムＡとシステムＢでそれぞれ保守の操作を行わない限り、システムＡとシステムＢでは、Ｅさんの勤務地は本社のままとなるなど、様々な支障が生じる。

本発明は上述のような課題を解決するためになされたものであり、本発明の目的は、組織を構成する要素情報を一元的に管理することが可能になると共に、組織の構造を多様な視点で視覚的に表現することが可能な、組織構造管理ディレクトリを備えたディレクトリシステム及びそのプログラムを提供することにある。また、本発明の更なる目的は、上記要素情報、並びにそれらの要素情報の階層関係及び相関関係を表す関連性情報を含め、汎用的なインターフェースにより、外部の情報システムに対して様々な形態でのデータ提供を可能とするディレクトリシステム及びそのプログラムを提供することにある。

本発明は、組織構造管理ディレクトリを有するサーバを備えたディレクトリシステム、及びそのシステムに適用されるプログラムに関するものであり、本発明の上記目的は、
システムに関しては、前記サーバは、管理対象となる組織内のリソース群を区分するカテゴリ，当該カテゴリに属するリソースの属性，同一カテゴリ内におけるリソース間の階層性，及び異なるカテゴリにおけるリソース間の関連性を表す定義を、前記ディレクトリの定義情報として登録する定義情報登録手段と、前記ディレクトリの定義情報に基づいて、前記カテゴリの一覧表示の中から選択された当該カテゴリに属するリソースの一覧を表示すると共に、前記リソースの一覧表示の中から選択されたリソースのリソース情報，属性情報，及び，当該リソースとは異なるカテゴリに属するリソースとの相関関係を表す関連性情報を入力するためのＧＵＩ画面を生成する画面生成手段と、前記ＧＵＩ画面上で入力された当該リソースのデータをデータベースに登録するデータ登録手段と、前記ディレクトリの定義情報に基づいて、前記属性に基づく第１視座，前記階層性に基づく第２視座，及び前記関連性に基づく第３視座の中から選択された所望の視座を視点として、当該視点から見た前記組織の構造をツリー形式又はリスト形式で可視化する可視化手段と、を備え、更に、前記サーバは、前記データ登録手段により前記リソース情報を登録する際に当該リソースの識別子として前記ディレクトリシステム内で固有の永続的なリソースＩＤを自動生成するリソースＩＤ生成手段と、前記リソースＩＤを含む前記データベース内のデータを外部システムにネットワーク経由で提供するＡＰＩと、を備え、前記外部システムにおいて前記ＡＰＩを用いて得た前記リソースＩＤに関連する前記データベース内のデータと外部システム固有の情報とを関連付けて管理可能としていることによって達成される。
あるいは、組織構造管理ディレクトリを有するサーバを備えたディレクトリシステムであって、前記サーバは、管理対象となる組織内のリソース群を区分するカテゴリ，当該カテゴリに属するリソースの属性，同一カテゴリ内におけるリソース間の階層性，及び異なるカテゴリにおけるリソース間の関連性を表す定義を、前記ディレクトリの定義情報として登録する定義情報登録手段と、前記ディレクトリの定義情報に基づいて、前記カテゴリの一覧表示の中から選択された当該カテゴリに属するリソースの一覧を表示すると共に、前記リソースの一覧表示の中から選択されたリソースのリソース情報，属性情報，及び，当該リソースとは異なるカテゴリに属するリソースとの相関関係を表す関連性情報を入力するためのＧＵＩ画面を生成する画面生成手段と、前記ＧＵＩ画面上で入力された当該リソースのデータをデータベースに登録するデータ登録手段と、前記ディレクトリの定義情報に基づいて、前記属性に基づく第１視座，前記階層性に基づく第２視座，及び前記関連性に基づく第３視座の中から選択された所望の視座を視点として、当該視点から見た前記組織の構造をツリー形式又はリスト形式で可視化する可視化手段と、を備え、更に、前記サーバは、外部システムに組み込み可能で且つ前記リソースを特定するリソースＩＤを用いて前記データベース内のデータの参照及び更新が可能なＡＰＩを含むＧＵＩパーツを前記外部システムに対してネットワーク経由で提供するＧＵＩパーツ提供手段を有すること、よって達成される。

さらに、本発明の上記目的は、
前記ＧＵＩ画面は、前記当該カテゴリに属するリソースの一覧をツリー形式又はリスト形式で表示する表示領域と、前記リソースの一覧表示の中から選択されたリソースの属性情報を入力するための属性情報入力域と、前記リソースの一覧表示の中から選択されたリソースと他のカテゴリに属するリソースとの相関関係を表す関連性情報を入力するための関連性情報入力域と、リソースの追加／削除を指示するための操作ボタンと、を含んで構成されていること、
前記サーバは、プライバシーマーク認証基準に準拠した個人情報保護管理の運用を行う外部システムとネットワーク経由で接続されており、前記可視化手段は、前記ＡＰＩを介した前記外部システム側からの要求に応じて、前記外部システム側で複数のデータベースで分散管理されている前記個人情報保護管理に係る情報群を前記当該視点から見た組織の構造と関連付けて前記外部システム側の表示部に可視化する処理を実行すること、
によってそれぞれ一層効果的に達成される。

また、プログラムに関しては、本発明の上記目的は、
前記サーバのコンピュータを、管理対象となる組織内のリソース群を区分するカテゴリ，当該カテゴリに属するリソースの属性，同一カテゴリ内におけるリソース間の階層性，及び異なるカテゴリにおけるリソース間の関連性を表す定義を、前記ディレクトリの定義情報として登録する定義情報登録手段、前記ディレクトリの定義情報に基づいて、前記カテゴリの一覧表示の中から選択された当該カテゴリに属するリソースの一覧を表示すると共に、前記リソースの一覧表示の中から選択されたリソースのリソース情報，属性情報，及び，当該リソースとは異なるカテゴリに属するリソースとの相関関係を表す関連性情報を入力するためのＧＵＩ画面を生成する画面生成手段、前記ＧＵＩ画面上で入力された当該リソースのデータをデータベースに登録するデータ登録手段、前記ディレクトリの定義情報に基づいて、前記属性に基づく第１視座，前記階層性に基づく第２視座，及び前記関連性に基づく第３視座の中から選択された所望の視座を視点として、当該視点から見た前記組織の構造をツリー形式又はリスト形式で可視化する可視化手段、前記データ登録手段により前記リソース情報を登録する際に当該リソースの識別子として前記ディレクトリシステム内で固有の永続的なリソースＩＤを自動生成するリソースＩＤ生成手段、及び前記リソースＩＤを含む前記データベース内のデータを外部システムにネットワーク経由で提供するＡＰＩを用いて前記外部システムにて得た前記リソースＩＤに関連する前記データベース内のデータと外部システム固有の情報とを関連付けて管理する手段、として機能させることによって達成される。
あるいは、前記サーバのコンピュータを、管理対象となる組織内のリソース群を区分するカテゴリ，当該カテゴリに属するリソースの属性，同一カテゴリ内におけるリソース間の階層性，及び異なるカテゴリにおけるリソース間の関連性を表す定義を、前記ディレクトリの定義情報として登録する定義情報登録手段、前記ディレクトリの定義情報に基づいて、前記カテゴリの一覧表示の中から選択された当該カテゴリに属するリソースの一覧を表示すると共に、前記リソースの一覧表示の中から選択されたリソースのリソース情報，属性情報，及び，当該リソースとは異なるカテゴリに属するリソースとの相関関係を表す関連性情報を入力するためのＧＵＩ画面を生成する画面生成手段、前記ＧＵＩ画面上で入力された当該リソースのデータをデータベースに登録するデータ登録手段、前記ディレクトリの定義情報に基づいて、前記属性に基づく第１視座，前記階層性に基づく第２視座，及び前記関連性に基づく第３視座の中から選択された所望の視座を視点として、当該視点から見た前記組織の構造をツリー形式又はリスト形式で可視化する可視化手段、及び、外部システムに組み込み可能で且つ前記リソースを特定するリソースＩＤを用いて前記データベース内のデータの参照及び更新が可能なＡＰＩを含むＧＵＩパーツを前記外部システムに対してネットワーク経由で提供するＧＵＩパーツ提供手段、として機能させることによって達成される。

本発明によれば、組織を構成する要素情報（リソース群）を一元的に管理することが可能になると共に、組織の構造を多様な視点で視覚的に表現することが可能になる。また、リソースの属性，階層関係，及び相関関係を表す情報を利用者が画面上で容易に登録することが可能になる。

また、請求項４に係る発明によれば、組織内の構成要素が変わった場合でも、関連する要素情報を画面上で確認しながら変更することが可能となり、人事異動や引越し、ハードウェア資源やソフトウェア資源の変更など、様々な構成要素の変更に対して容易に対応することが可能になる。

また、本発明によれば、組織内のリソース間の階層関係及び相関関係を表す関連性情報を含め、外部システム側において様々な形体でのデータ取得が可能になる。また、外部システムは組織構造データと独自のデータベースとをリソースＩＤを用いて関連付けることが可能となり、リソース間の関係性の変化などからディレクトリの内容が本システムによって更新された場合でも、外部システムは影響を受けないことになる。

さらに、請求項３に係る発明によれば、本システムを利用して、個人情報保護管理に係る情報群を一元的に管理することが可能になると共に、リスク管理や内部統制に係る情報群を様々な視点から可視化することが可能になる。

企業システムにおける組織構造の従来の管理方法を説明するための模式図である。 本発明に係るディレクトリシステムの全体構成の一例を示すブロック図である。 本実施形態に係るカテゴリの定義とリソース情報を説明するための模式図である。 発明に係るディレクトリの構築手順と外部システムからの利用形態を説明するためのフローチャートである。 組織の構造を表す定義部の構成例を示す図である。 カテゴリ定義の具体例を示す図である。 カテゴリ定義のクラス図である。 属性項目定義のデータ構成の一例を示す図である。 属性項目定義セットのデータ構成の一例を示す図である。 属性項目定義の定義情報の具体例を示す図である。 属性定義のクラス図である。 属性定義とデータの現物の例を示す図である。 階層性定義のデータ構成の一例を示す図である。 階層性定義のクラス図である。 階層性定義とデータの現物の例を示す図である。 関連性定義のデータ構成の一例を示す図である。 関連性定義のクラス図である。 関連性定義とデータの現物の例を示す図である。システムを説明するための模式図である。 カテゴリ定義とリソース情報のクラス図である。 データ入力画面の一例とその生成処理を説明するための模式図である。 データ入力画面の生成処理を説明するためのフローチャートである。 視座の表示方法を説明するための模式図である。 本システムが提供するＡＰＩの具体例を示す図である。 リソースＩＤの生成方法の一例を示す模式図である。 本システムが提供するＧＵＩパーツを説明するための図である。 個人情報保護管理のＰＤＣＡサイクルを説明するための図である。 個人情報保護管理のシステム化の機能要件を示す図である。 個人情報保護管理を行う企業内の各システムからのディレクトリの利用イメージを示す模式図である。 規程文書管理システムの機能を説明するための模式図である。 規程文書管理システムの処理を説明するためのフローチャートである。 規定文書管理テーブルの一例を示す図である。 個人情報取り扱い管理システムの機能を説明するための模式図である。 業務フロー図とリスク分析表を示す図である。 業務上で想定されるリスクの種類の一例を示す模式図である 個人情報取り扱い管理システムの処理を説明するためのフローチャートである。 個人情報台帳テーブルの一例を示す図である。 事件・事故、問合せ管理システムの機能を説明するための模式図である。 事件・事故、問合せ管理システムの処理を説明するためのフローチャートである。 事件・事故、問合せデータテーブルの一例を示す図である。

以下、図面を参照しながら本発明の好適な実施形態について説明する。先ず、本発明の主要な特長事項について説明する。
《本発明の特長事項について》
本発明に係る組織構造管理ディレクトリを備えたシステム（以下、「ディレクトリシステム」と呼ぶ）は、業務，部署，人，建物，プロジェクト，情報システム，製品など、組織を構成する任意の要素情報群を管理対象としたシステムである。そして、以下の方法を実現するための手段を備えた点に特長を有している。
（Ｉ）組織構造を持ったディレクトリの構築方法
（II）多様な視点で組織構造を可視化する方法
・関係性情報による組織構造の可視化
・属性情報による組織構造の可視化
（III）外部システムからのデータ取得方法、そのための汎用的なインターフェース方法
（IV）外部システムとの連携処理方法
・外部システムに組み込み可能なＧＵＩ（Graphical User Interface）パーツによる外部システムとの連携
・永続的な識別子を使ったデータの管理に関する外部システムとの連携
・ＡＰＩ（Application Program Interface）を使った外部システムとの連携
（Ｖ）リスク管理及び内部統制を目的とした外部システムへの応用
以降、本発明に係るディレクトリシステムの全体構成について説明した後、上記（Ｉ）から（IV）に関する技術事項について説明する。また、（Ｖ）については、後述する実施例にて個人情報保護管理を目的としたシステムを例として説明する。
《ディレクトリシステムの全体構成について》
図２は、本発明に係るディレクトリシステムの全体構成の一例を示すブロック図である。図２において、ディレクトリシステムは、ディレクトリ処理用サーバ装置１（以下「ディレクトリサーバ」と呼ぶ）を含んで構成され、そのディレクトリサーバ１とクライアント端末３とは、ネットワーク２（インターネットなどの電気通信回線）を介して相互に通信可能に接続される。

クライアント端末３は、操作者がネットワーク２を介してディレクトリサーバ１の機能を利用するために使用する端末装置である。クライアント端末３は、各種データを入力するための入力部（キーボード、マウス等の入力装置）３２と、ネットワーク２を介してディレクトリサーバ１とデータ通信を行う制御部３１と、ディスプレイ等の出力装置３３とを備えた汎用的な情報処理装置であり、例えば、Ｗｅｂブラウザを搭載したＰＣや携帯端末（携帯電話機，ＰＤＡ（Personal Digital Assistants），携帯型ノートパソコンなどのモバイルコンピュータ）などの一般の情報処理装置を用いることができる。

なお、本発明で言う「ディレクトリシステム」とは、狭義の意味では、ディレクトリサーバ１を含むホストコンピュータシステムのことを言うが、広義の意味では、クライアント端末３及び後述の外部システムを含むコンピュータネットワークシステムのことを言う。以下、ディレクトリサーバ１を含むホストコンピュータ側のシステムを「ディレクトリシステム」又は「本システム」と呼んで説明する。

本実施形態におけるディレクトリサーバ１は、例えば、組織構造管理ディレクトリの構築支援・管理サーバ、組織構造の可視化サーバ、及び、ＡＰＩを用いた外部システムとの連携処理サーバとしての機能を備えたデータ処理装置であり、制御部１１とデータ記憶部１２とを備えた１台以上のコンピュータから構成される。

制御部１１は、ネットワーク２を介してクライアント端末３とデータ通信を行う。また、クライアント装置３との対話情報をデータ記憶部に格納する。

データ記憶部１２は、組織構造の情報や上記対話情報、本発明に係る課題を解決する手段としてコンピュータを機能させるプログラム等を記憶する記憶部である。

組織構造の情報は、以下に示すファイル１２ａ〜１２ｂとＤＢ（データベース）１２ｃ〜１２ｇに格納される。
・カテゴリ定義ファイル１２ａ：
管理するリソースのカテゴリ毎の定義情報が格納されるファイルである。
・視座定義ファイル１２ｂ：
利用する視座についての定義情報が格納されるファイルである。
・リソースＤＢ１２ｃ：
組織内のリソース情報が登録されるデータベースである。
・属性情報ＤＢ１２ｄ：
リソースの属性情報が登録されるデータベースである。
・階層情報ＤＢ１２ｅ：
リソース間の階層関係を表す階層情報が登録されるデータベースである。
・関連性情報ＤＢ１２ｆ：
リソース間の相関・従属関係が登録されるデータベースである。
・マスタＤＢ１２ｇ：
属性値として指定するマスタデータが登録されるデータベースである。

《カテゴリの定義とリソース情報について》
ここで、本実施形態に係る「カテゴリの定義」と「リソース情報」について、図３を参照して説明する。

図３は、カテゴリの定義とリソース情報の一例を示す模式図であり、図３（Ａ）のベン図は、概念としてカテゴリの集合と、現物としてのリソースの集合と、カテゴリによって分類されたリソースの部分集合とを示している。また、図３（Ｂ）は、本システムに登録される定義情報とリソース情報を示している。

図３（Ａ）の例では、部署の名称，人の名称，建物の名称，システムの名称等で特定される組織内の現物（実際の資源）が「リソース」である。また、図３（Ｂ）中の「リソース情報」は、個々のリソースに固有の永続的な識別子（リソースＩＤ），クライアント端末側の画面上に表示する際の当該リソースの名称等から構成される。

本実施形態においては、ディレクトリの扱う組織を構成する「人」「部署」「建物」「業務」などのリソースを分類する概念を「カテゴリ」と呼ぶ。組織を構成する個々のリソースは、１カテゴリに属する。現物としてのリソースとしての存在は、「リソースエントリ」又は単に「エントリ」と呼ぶ。なお、エントリという用語は、データベースの１レコードとして登録された現物を指す場合があるので、区別が必要な場合はリソースエントリを使う。
《組織構造を持ったディレクトリの構築方法について》
次に、本発明に係るディレクトリの構築方法について説明する。

本発明に係るディレクトリを構築する際の運用の流れは、図３中の矢印（１）及び（２）に示すよう、以下の流れとなる。
（１）システム導入時に、カテゴリ毎にリソースの持つ階層関係、関連性、属性の定義を行う。
（２）リソースの所属するカテゴリの定義にしたがい、本システムの利用者はリソースの情報（階層情報、関連性情報、属性情報）を登録する。

リソースの各エントリはリソースＩＤにより識別される。本実施形態では、カテゴリは定義ファイルとして保持管理し、リソース情報はデータベースに保存し管理する。

次に、本発明に係るディレクトリの構築手順と外部システムからの利用形態について、図４のフローチャートの流れに沿って説明する。なお、ここでは、運用の流れを主体として概要を説明し、その後、ディレクトリサーバの制御部１１の処理について詳細に説明する。

＜ステップＳ１＞（ディレクトリの定義）
利用者は、システム導入時に、カテゴリ毎にリソースの持つ階層関係、関連性、属性の定義を行う。定義としては、大別すると、図４中のステップＳ１．１〜Ｓ１．４に示すように、「基本要素」の定義（Ｓ１．１）、「属性の」定義（Ｓ１．２）、「階層性」の定義（Ｓ１．３）、及び、「関連性」の定義（Ｓ１．４）の４種類の定義がある。なお、本発明においては、同一カテゴリ内のリソース間の階層関係を表す「階層性」、及び、異なるカテゴリ間のリソースの「関連性」（相関・従属関係）を含む用語を、「関係性」と称している。

ステップＳ１．１で定義する「基本要素」は、組織内の各リソースの性質を区分する上での最も基本的な分類要素であり、前述の「カテゴリ」に相当する。ステップＳ１．１では、その基本要素の情報（カテゴリを表す情報）を定義する。その基本要素の定義を含め、ステップＳ１．１〜Ｓ１．４における定義の詳細は、具体例を示して後述する。

利用者は、上記のような各定義におけるユーザ設定情報を、ディレクトリサーバ１が提供する定義情報登録手段としてのディレクトリ定義用のＧＵＩ（Graphical User Interface）を利用して画面上で入力し、クライアント端末３からネットワーク２経由でディレクトリサーバ１に送信する。利用者が設定したディレクトリの定義情報は、本実施形態では、ディレクトリサーバ１のデータ記憶部１２内のカテゴリ定義ファイル１２ａに格納される。

＜ステップＳ２＞（視座の定義）
続いて、利用者は、組織構造を表す情報群を可視化する際の視点となる「視座」を定義する。「視座」のタイプとしては、ステップＳ１．２で定義した「属性」に基づく視座、ステップＳ１．３で定義した「階層性」に基づく視座、ステップＳ１．４で定義した「関連性」に基づく視座などがある。

利用者は、上記のような各種の視座（異なる視点群）の定義情報を、ディレクトリサーバ１が提供する視座定義用のＧＵＩを利用して画面上で入力し、クライアント端末３からネットワーク２経由でディレクトリサーバ１に送信する。利用者が設定した視座の定義情報は、ディレクトリサーバ１のデータ記憶部１２内の視座定義ファイル１２ｂに格納される。

＜ステップＳ３＞（データ登録）
利用者は、ステップＳ１で設定したディレクトリの定義に従って、組織内のリソース（図３のリソースの例を参照）のデータをデータ入力用のＧＵＩ画面上で入力し、クライアント端末３からネットワーク２経由でディレクトリサーバ１に送信する。利用者が入力したリソースのデータ（リソース情報，属性情報，階層情報，関連性情報）は、ディレクトリサーバ１のデータ記憶部１２内のリソースＤＢ１２ｃ，属性情報ＤＢ１２ｄ，階層情報ＤＢ１２ｅ，関連性情報ＤＢ１２ｆに登録される。

以上のステップＳ１からステップＳ３の手順を踏むことにより、利用者がＧＵＩ画面を用いて登録した各定義情報とリソースのデータに基づいて、組織構造を持ったディレクトリデータベースが制御部１１によって自動的に構築される。

＜ステップＳ４＞（外部システムからの利用）
ディレクトリサーバ１は、外部システムから本システムを利用するためのインターフェース手段として、外部システムに組み込み可能なＧＵＩパーツを提供する。外部システムでは、そのＧＵＩパーツに含まれるＡＰＩを用いて本システムで管理するディレクトリデータ（定義情報，リソース情報，関係性の情報等）の参照や更新を行う。
《ディレクトリサーバの処理について》
次に、上述したステップＳ１〜Ｓ３におけるディレクトリサーバの処理について説明する。なお、以降の説明では、既に説明した内容については、説明を省略又は簡略化して説明する。

先ず、上述したステップＳ１におけるディレクトリの定義について、具体例を示して順次説明する。

＜基本要素の定義（Ｓ１．１）について＞
図３に例示したように、管理対象となるリソースを例えば「人」「部署」「建物」「情報システム」「業務」のように分類し、カテゴリとして区分する。本システムでは任意のカテゴリを定義することができる。

組織構造を表すディレクトリの定義部は、図５に示すように、基本定義部、属性定義部、階層性定義部、及び関連性定義部から構成される。

基本定義部の項目は、図５中の基本定義部の例に示すように、カテゴリＩＤ、カテゴリ識別名、及びカテゴリ名称などから構成される。カテゴリＩＤは、当該カテゴリをシステム的に識別するためのＩＤ（識別子）であり、カテゴリの登録時に本システムによって自動的に付与される。カテゴリ識別名は、当該カテゴリをシステム的に識別するための名称であり、カテゴリ名称は、当該カテゴリをＧＵＩ画面上に表示する際の名称（人、部署、建物など）である。

図６は、カテゴリ定義（基本定義）の具体例を示しており、カテゴリ名称としては、“人”、“部署”など、管理対象となる組織内のリソース群を区分するカテゴリの名称が定義される。カテゴリ識別名は、本例では英語の識別名が定義される。そのカテゴリ識別名は、例えば、カテゴリ名称の登録時に、本システムによって漢字表記のカテゴリ名称が英語表記に自動翻訳され、その英語表記がカテゴリ識別名として設定される。

ディレクトリサーバ１の制御部１１は、図６に示すように、定義されたカテゴリ毎にシステム固有のカテゴリＩＤを自動付与し、基本定義部の情報をカテゴリ定義ファイル１２ａに格納する。

図７はカテゴリ定義のクラス図であり、カテゴリ定義を記憶する基本定義部は、他の３種類の定義部（属性定義部，階層性定義部，関連性定義部）と関連付けられてデータ記憶部１２に保管される。他の３種類の定義部については以下に順次説明する。

＜属性の定義（Ｓ１．２）について＞
属性の定義について、図８から図１２を参照して説明する。

属性の定義としては、当該カテゴリに属するリソースが持つ属性を定義する。カテゴリには複数の属性があるため、属性の定義は保持し得る属性項目の配列となる。

本実施の形態では、属性の定義は、他のカテゴリとも共有可能な「属性項目定義」（図８及び図１０参照）と、特定のカテゴリに応じて属性項目定義の配列を持つ「属性項目定義セット」（図９参照）よりなる。

属性項目定義の項目は、図８に示すように、属性ＩＤ、属性識別名、属性名称、データ型、省略時値、コメントなどから構成される。

属性ＩＤは、当該属性項目をシステム的に識別するためのＩＤであり、属性識別名は、当該属性項目をシステム的に識別する名称である。属性名称は、当該属性項目を画面上に表示する際の名称であり、データ型は、数値，文字列，日時など、属性項目のデータの型を表す情報である。省略時値は、属性情報を省略した時の値であり、その初期値が有る場合は指定する。そして、コメントは、当該属性項目を画面上に表示する際の説明文である。

属性定義セットは、図９に示すように、属性セットＩＤ、属性セット識別名、属性セット名称、属性定義リストなどから構成される。

属性セットＩＤは、当該属性セット（図８に示す属性項目定義が１セット）をシステム的に識別するＩＤであり、属性セット識別名は、当該属性セットをシステム的に識別する名称である。また、属性セット名称は、当該属性セットを画面上に表示する際の名称であり、属性定義リストは、属性ＩＤの配列となる。

図１０は、属性項目定義の定義情報の具体例を示しており、「生年月日」の属性項目定義、「自宅住所」の属性項目定義というように、属性項目定義毎に属性ＩＤが付与される。

図１１は属性定義のクラス図であり、図１２は、属性定義とデータの現物の例を図１１に対応させて示す図である。図１１及び図１２に示すように、当該カテゴリに属するリソースの属性定義（属性項目定義及び属性項目定義セット）は、カテゴリ定義と現物のデータ（ステップＳ３において登録される属性情報とリソース情報）とに関連付けられてデータ記憶部１２に保管される。なお、本実施の形態においては、属性情報が更新された場合、該当するＤＢレコードの「状態」を無効として、新規のレコード（状態：有効）を追加するようにしている。

＜階層性の定義（Ｓ１．３）について＞
階層性の定義について、図１３から図１５を参照して説明する。

階層性の定義としては、当該カテゴリに属するリソースが当該カテゴリ内でリソース間の階層関係を持つことを定義する。１つのカテゴリに対して、図１３に示すような階層性定義を配列として複数付与することが可能である。

階層性定義の項目は、図１３に示すように、階層性ＩＤ、階層性識別名、階層性名称、階層順位、上位エントリの役割名称、下位エントリの役割名称、上位エントリの多重度、下位エントリの多重度、上位エントリの属性値の制約、下位エントリの属性値の制約などから構成される。

階層性ＩＤは、当該階層性情報をシステム的に識別するためのＩＤであり、本システムによって自動的に付与される。階層性名称は「親子関係」，「都道府県市町村」など、階層性を表示する際の名称である。階層順位は、当該カテゴリでの階層性の順位を示す数値ｎ（ｎ＝０，１,・・・）であり、１が第１階層−第２階層、２が第２階層−第３階層を示している。また、階層順位が０の場合、当該カテゴリでは、階層順位を区別せず、どの階層でも同じ設定となる。

上位エントリの役割名称は、上位のリソースエントリの役割を表す名称（例えば、親→「都道府県」）でり、下位エントリの役割名称は、下位のリソースエントリの役割を表す名称（例えば、子→「市区町村」）である。

上位エントリの多重度は、下位のエントリ１個に対し、上位のエントリ数の制約を示し、１〜ｎ（nは不定）の値が設定される。そして、下位エントリの多重度は、上位のエントリ１個に対し、下位のエントリ数の制約を示し、１〜ｎの値が設定される。

上位エントリの属性値の制約は、上位のリソースエントリに指定できるリソースの属性値が設定され、下位エントリの属性値の制約は、下位のリソースエントリに指定できるリソースの属性値が設定される。

上記上位エントリと下位エントリの属性値の制約としては、例えば、「部署」カテゴリで属性項目「組織階層」の選択値として「事業部」「部」「課」「係」のようになっていた場合、各階層間での上位−下位の制約として、以下のような関係を想定している。

第１階層−第２階層：「事業部」−「部」
第１階層−第２階層：「事業部」−「室」
第２階層−第３階層：「部」−「課」
第３階層−第４階層：「課」−「係」
階層の制約がない場合は省略する。なお、同一の階層順位で複数の定義を作ることは可能である。また、属性値は複数の階層で制約とすることが可能である。例えば、上の例に加え、第１階層−第２階層：「事業部」−「課」とすることも可能である。

図１４は階層性定義のクラス図であり、当該カテゴリに属するリソース（リソース情報２）の階層性定義は、階層性情報とカテゴリ定義とリソース情報とに関連付けられてデータ記憶部１２に保管される。階層性情報としては、上位リソースのリソースＩＤ、下位リソースのリソースＩＤ、表示順位などが設定される。

図１５は、階層性定義とデータの現物の例を図１４に対応させて示しており、カテゴリが部署の場合、図１５に示すように、例えば事業部、部、課、係の各リソースについての階層関係が、階層性定義によって表現される。

ディレクトリサーバ１は、定義された階層性定義を階層性情報及びカテゴリ定義と対応付けてデータ記憶部１２に保管する。

＜関連性の定義（Ｓ１．４）について＞
関連性の定義について、図１６から図１８を参照して説明する。

関連性の定義としては、当該のカテゴリに属するリソースが他のカテゴリに属するリソースとの関連性を持つことを定義する。１つカテゴリに対して、図１６に示すような関連性定義を配列として複数付与することが可能である。

関連性定義の項目は、図１６に示すように、関連性ＩＤ、関連性識別名、関連性名称、親カテゴリＩＤ、子カテゴリＩＤ、関連性の名称、親カテゴリの役割名称、子カテゴリの役割名称、親カテゴリの多重度、子カテゴリの多重度などから構成される。

関連性ＩＤは、当該の関連性をシステム的に識別するＩＤであり、本システムによって自動的に付与される。関連性識別名は、当該の関連性をシステム的に識別する名称であり、関連性名称は、当該の関連性を画面上に表示する際の名称である。親カテゴリＩＤは、関連付ける2つのカテゴリのうち主となるカテゴリのカテゴリＩＤであり、子カテゴリＩＤは、関連付ける2つのカテゴリのうち従属するカテゴリのカテゴリＩＤである。関連性の名称は、例えば「所属する」というように、関連の仕方を表現する。親カテゴリの役割名称は、その関連性における主となるカテゴリの役割名称であり、子カテゴリの役割名称は、その関連性における従属するカテゴリの役割名称である。親カテゴリの多重度は、子カテゴリのエントリ１個に対し、親カテゴリのエントリ数の制約を示し、１〜ｎの値が設定される。子カテゴリの多重度は、親カテゴリのエントリ１個に対し、子カテゴリのエントリ数の制約を示し、１〜ｎの値が設定される。ここで言う親と子は、ツリー状の視座において、主となる要素が親、従となる要素が子である。例えば、部署に人を関連づけるような場合、部署が親、人が子となる。

なお、図１６中のNo10，No11の項目に示すように、属性値の制約（親カテゴリの属性値の制約、子カテゴリの属性値の制約）を設けることも可能である。その場合、親カテゴリの属性値の制約は、上位のリソースエントリに指定できるリソースの属性値が設定される。そして、子カテゴリの属性値の制約は、子のリソースエントリに指定できるリソースの属性値が設定される。

図１７は関連性定義のクラス図であり、当該カテゴリに属するリソース（リソース情報２）の関連性定義は、関連性情報とカテゴリ定義とリソース情報とに関連付けられてデータ記憶部１２に保管される。関連性情報としては、リソースＩＤ、関連付けリソースＩＤ、表示順位などが設定される。

図１８は、関連性定義とデータの現物の例を図１７に対応させて示しており、カテゴリとして部署、人、建物が定義されている場合、例えば、第１カテゴリ（部署）に属するリソース（本例では営業第１係）と第２カテゴリ（人）に属するリソース（実際の人物）との関連性、第１カテゴリ（部署）に属するリソース（本例では営業第１係）と第３カテゴリ（建物）に属するリソース（本社ビルなど）との関連性などが、関連性定義によって表現される。

ディレクトリサーバ１は、定義された関連性定義を関連性情報及びカテゴリ定義と対応付けてデータ記憶部１２に保管する。

＜カテゴリ定義とリソース情報について＞
図１９はカテゴリ定義とリソース情報のクラス図であり、カテゴリ定義は、図１９に示すように、他の定義（属性項目定義（セット）、階層性定義、及び関連性定義のデータ）と紐付けられてデータ記憶部１２に保管される。また、リソース情報は、図１９に示すように、各定義の情報（カテゴリ定義の情報、属性情報、階層性情報、関連性情報）と紐付けられてデータ記憶部１２に保管される。属性項目定義は、前述のように、他のカテゴリとも共有可能な定義であり、属性項目定義セットは、属性項目定義の配列からなる特定のカテゴリに応じた定義である。

＜視座の定義（Ｓ２）に関する処理＞
視座の定義に関する処理については、後述する「２．視座の表示方法」の説明において、具体例を示して説明する。

＜データ登録（Ｓ３）関する処理＞
データ登録に関する処理については、後述する「１．データ入力用のＧＵＩ画面の生成処理」の説明において、具体例を示して説明する。

＜外部システムからの利用（Ｓ４）に関する処理＞
外部システムからの利用に関する処理については、後述する「３．外部システムに提供するＡＰＩとＧＵＩパーツ」の説明において、具体例を示して説明する。
＜データ入力用のＧＵＩ画面の生成処理と視座の表示方法について＞
次に、本発明に係るディレクトリシステムにおけるデータ入力用のＧＵＩ画面の生成処理と視座の表示方法について、順次説明する。
《１．データ入力用のＧＵＩ画面の生成処理》
先ず、データ入力用のＧＵＩ画面の生成処理について説明する。

本実施の形態においては、制御部１１は、カテゴリ定義をもとに当該のカテゴリについてのデータ入力用のＧＵＩ画面を自動的に作成する形態としている。その際、制御部１１は、階層関係が定義されている場合にはリソース全体をツリー状に表示し、他のカテゴリとの相関関係が定義されている場合には該当のカテゴリのリソースの選択画面を表示する。その選択画面はカテゴリの定義によって以下のような形式で表示される。
（表示形態１）階層情報によりツリー状に表示
（表示形態２）属性値により分類しツリー状に表示
（表示形態３）分類のないフラットなリストとして表示
また、制御部１１は、利用者の選択操作を受け付けた際、選択されたリソ−スと他の間の階層関係や相関関係の矛盾など、選択の矛盾を検出するようにしている。

以下、図面を参照して、データ入力用のＧＵＩ画面の生成処理について詳細に説明する。

図２０は、データ入力用のＧＵＩ画面の一例とその生成処理を説明するための模式図である。図２０において、符号G10がデータ入力用のＧＵＩ画面（以下、「データ入力画面」と呼ぶ）の一例を示しており、G10MがそのＧＵＩ画面のひな型となるひな型画面の一例を示している。また、符号G1がシステムメニュー画面の一例を示しており、符号G2が、カテゴリ一覧が表示されるリソース管理画面の一例を示している。

データ入力画面G10の画面構成は、ひな型画面G10Mに示すように、「リソース一覧表示域」と「基本情報入力域」と「属性情報入力域」と「関連性情報入力域」とを含んで構成される。その他に、データ入力画面G10には、Ｗｅｂページ内の現在のページ位置を示すための「トピックパス領域」、及びデータ入力ウィンドウのタイトルを表示するための「ウィンドウタイトル領域」が設けられている。

「リソース一覧表示域」は、データ入力画面G10の例に示すように、当該カテゴリに属するリソースエントリ群（リソース情報が登録されたリソースエントリ）のリソース名称が、ツリー形式又はリスト形式でスクロール可能に一覧表示される領域である。

「基本情報入力域」は、データを登録するリソースエントリの名称など、登録対象のリソースエントリの基本情報を入力するための領域であり、データ入力画面G10の例では、当該カテゴリ（部署）に属するリソースエントリ（業務課）の名称を入力した例を示している。

「属性情報入力域」は、基本情報入力域で入力した当該リソースエントリの属性情報を入力するための領域であり、「関連性情報入力域」は、当該リソースエントリと他のカテゴリに属するリソースエントリとの相関関係を表す関連性情報を入力するための領域である。図２０のデータ入力画面G10の例では、「属性情報入力域」には、選択されたカテゴリ（「部署」）の属性定義で定義されている属性の項目（「住所」，「電話番号」等）が表示されるので、利用者は項目毎に属性情報を入力する。また、「関連性情報入力域」には、選択されたカテゴリ（「部署」）の関連性定義で定義されている関連性の項目として、当該カテゴリに属するリソースエントリの項目（「所管する業務」）と他のカテゴリに属するリソースエントリの項目（「所属する人」）とが表示されるので、利用者は項目毎に情報を入力する。

上述のような画面構成において、ディレクトリサーバ１の制御部１１は、リソース管理画面G2上のカテゴリ一覧の中から選択された当該カテゴリの定義（カテゴリ定義、属性定義、階層性定義、関連性定義）に基づいて、ひな型画面G10Mの各領域に画面要素を配置し、当該カテゴリについてのデータ入力画面G10を自動的に作成する。その際、既存のデータがある場合は、データを所定の箇所に展開する。なお、動的に変更する領域のうち、トピックパス領域は、リリース一覧での選択に応じて変化する部分であり、カテゴリ定義とは無関係である。

次に、上記データ入力画面G10の生成処理の詳細について、図２１のフローチャートを参照して説明する。

本システムに利用者がログインすると、制御部１１（ディレクトリサーバ１の制御部）は、例えば図２０中に例示したメニュー画面G1をクライアント端末３側に表示する。そのメニュー画面G1上で、利用者によってデータ入力メニュー（図２０中のリソース管理）が選択されると（ステップＳ１１）、制御部１１は、ステップＳ１．１において設定されたカテゴリ定義の定義情報をカテゴリ定義ファイル１２ａから取得し（ステップＳ１１ａ）、カテゴリ一覧の画像を含むリソース管理画面G1を生成してクライアント端末３側に表示し（ステップＳ１１ｂ）、カテゴリの選択を利用者に促す。

リソース管理画面G1上のカテゴリ一覧の中からカテゴリが選択されると（ステップＳ１２）、制御部１１は、選択された当該カテゴリの定義情報（カテゴリ定義、属性定義、階層性定義、関連性定義の各定義情報）をデータ記憶部１２から取得し（ステップＳ１２ａ）、階層関係があるか否かを判定する（ステップＳ１２ｂ）。

ステップＳ１２ｂにおいて階層関係があると判定した場合は、制御部１１は、各階層の階層情報（階層性定義に含まれる階層性名称，階層順位等の階層性データ）を階層情報ＤＢ１２ｅから取得し（ステップＳ１２ｃ）、データ入力画面G10のリソース一覧表示域に、ツリー形式でリソースエントリを表示する。例えば、図２０の例では、カテゴリとして「部署」が選択された場合の例を示しており、その場合、部署の階層性定義のデータに基づいて部署の階層構造を示すツリー状の画像を生成し、その画像をリソース一覧表示域に表示する（ステップＳ１２ｄ）。一方、ステップＳ１２において階層関係がないと判定した場合は、リスト形式でリソース一覧表示域にリソースエントリを表示する（ステップＳ１２ｅ）。

リソース一覧の中からリソースエントリが選択されると（ステップＳ１３）、制御部１１は、属性定義を基に、選択されたリソースエントリの属性情報を属性情報ＤＢ１２ｄから取得すると共に（ステップＳ１３ａ）、関連性定義を基に、選択されたリソースエントリの関連性情報を関連性情報ＤＢ１２ｆから取得する（ステップＳ１３ｂ）。そして、属性定義から属性値入力域（図２０の例では、コード，住所，電話番号，ＦＡＸ番号の各入力域）を生成してその画像をデータ入力画面G10上に表示すると共に（ステップＳ１４ａ）、関連性定義から関連性入力域（図２０の例では、所属する業務，所属する人の各入力域）を生成しその画像をデータ入力画面G10上に表示する（ステップＳ１４ｂ）。

その状態で、関連性の「追加」のボタン（図２０の画面G10の表示例では、「業務の追加」ボタン，「人の追加」ボタン）が押下されると（ステップＳ１５）、制御部１１は、対応する関連性のカテゴリのリソースを選択する画面G11を表示する。図２０の例では、「業務の追加」ボタンが押下された場合の例を示しており、図２０中の矢印Ａで示すように、業務の選択画面G11が表示される。その際、制御部１１は、関連性情報入力域で入力した追加対象の業務（図２０の例では「トラック運送事業」の部分が、リソース一覧表示域のほぼ中心に表示されるように、画面G11のウィンドウをポップアップするようにしている（ステップＳ１５ａ）。そして、リソース一覧の中から選択されたリソースエントリを保持し、データの入力待ちとする（ステップＳ１５ｂ）。

利用者は、ステップＳ１５において、当該リソースエントリの基本情報（リソース情報），属性情報，関連性情報のデータを入力し、「登録」ボタンを押下する（ステップＳ１６）。

ステップＳ１６において、「登録」ボタンが押下されると、制御部１１は、利用者が入力したデータをデータ記憶部１２内のデータベースに登録する。本例では、リソース情報はリソースＤＢ１２ｃに登録され、属性情報は属性情報ＤＢ１２ｄに登録され、関連性情報は関連性情報ＤＢ１２ｆに登録される（ステップＳ１６ａ）。

利用者がリソースエントリを新たに登録（追加）したい場合は、前記ステップＳ１４又はステップＳ１５において、リソースエントリ（当該リソースエントリ又は関連性のカテゴリのリソースエントリ）の「追加」ボタン（図２０の例ではリソース一覧の下部に設けられている「部署の追加」ボタン）を押下する。

制御部１１は、「追加」ボタンの操作情報を基にリソースエントリが追加されたか否かを判定し（ステップＳ１６ｂ）、追加されたと判定した場合は、ステップＳ１４又はステップＳ１５において利用者によって選択されたリソースエントリを上位とする階層性情報を階層情報ＤＢ１２ｅに登録し、当該リソースエントリのデータ登録処理を終了する。

利用者がリソースエントリを削除したい場合は、削除したいリソースエントリをリソース一覧の中から選択し、「削除」ボタンを押下する。その場合、制御部１１は、選択されたリソースエントリを論理的に削除し、当該リソースエントリの削除処理を終了する。

上述のように、制御部１１は、ディレクトリの定義情報に基づいて、クライアント端末３の表示部にカテゴリの一覧を表示し、その一覧表示の中から選択された当該カテゴリに属するリソースの一覧を表示すると共に、その一覧表示の中から選択されたリソースの「リソース情報」と「属性情報」、及び当該リソースとは異なるカテゴリに属するリソースとの相関関係を表す「関連性情報」を入力するためのＧＵＩ画面を生成する「画面生成手段」を備えている。

上記ＧＵＩ画面は、その画面上で入力されたデータをデータ記憶部１２内の該当のデータベースに登録する「データ登録手段」の構成要素であり、ＧＵＩ画面は、前述のように、当該カテゴリに属するリソースの一覧をツリー形式又はリスト形式で表示する表示領域と、リソースの一覧表示の中から選択されたリソースの属性情報を入力するための属性情報入力域と、リソースの一覧表示の中から選択されたリソースと他のカテゴリに属するリソースとの相関関係を表す関連性情報を入力するための関連性情報入力域と、リソースの追加／削除を指示するための操作ボタンと、を含んで構成されている。

それにより、当該リソースのリソース間の階層関係や相関関係を表す情報を利用者が容易に登録することができると共に、リソースの内容変更や追加／削除も容易に行うことが可能になる。言い換えると、人事異動や引越し、ハードウェア資源やソフトウェア資源の変更など、組織内の構成要素が変わった場合でも、関連する要素情報を同一画面上で容易に変更することが可能になる。また、画面生成手段では、ＧＵＩ画面上でのリソースの追加，削除の操作に応じて画面上のツリー形式の表示などを動的に変更するようにしている。そのため、利用者は、画面上で変更後の内容を確認しながら変更することができる。
《２．視座の表示方法》
次に、視座の表示方法について説明する。

先ず、視座の定義について、図２２中の視座定義の例を参照して説明する。

視座の定義としては、利用する視座について、図２２に示すような内容を持つ定義を行う。本例では、視座の定義は、共通部、属性に基づく視座の定義部、階層性に基づく視座の定義部、関連性に基づく視座の定義部から構成されている。

共通部の項目は、図２２に示すように、視座ＩＤ（当該の視座をシステム的に識別するＩＤ）、視座識別名（当該の視座をシステム的に識別する名称）、視座名称（当該の視座を画面上に表示する際の名称）、表示形状（リスト状又はツリー状）、視座タイプなどから構成される。本実施形態では、視座タイプとしては、（タイプ１）属性に基づく視座、（タイプ２）階層性に基づく視座、（タイプ３）関連性に基づく視座、の３つのタイプがある。なお、これらの視座タイプは、表示形状がツリー状の場合に有効となるタイプである。

「属性に基づく視座の定義部」の項目は、カテゴリＩＤ（視座に表示するカテゴリのＩＤ）、属性ＩＤの配列などから構成される。

属性ＩＤの配列は、第１階層から順に属性値によって分類するが、第１階層から順に分類に使う属性の属性ＩＤを配列で指定する。

「階層性に基づく視座の定義部」の項目は、カテゴリＩＤ、階層の深さ（視座に表示する階層の深さ）などから構成される。ここで定義するカテゴリＩＤは、関連付ける２つのカテゴリのうち従属するカテゴリのカテゴリＩＤである。階層の深さは、深さを示す数値ｍ（例えば３階層の場合はｍ＝３）を指定する。また、全階層を表示したい場合は、“０”を指定する。

「関連性に基づく視座の定義部」の項目は、関連性ＩＤ、階層の深さ（視座に表示する階層の深さ）などから構成される。関連性に基づく視座の表示は、複数のカテゴリ（本例で２つの異なるカテゴリ）を関連づけて表示するが、その関連性を定義した関連性ＩＤを指定する。階層の深さは、親カテゴリが階層性を持っている場合、表示する階層の深さを制限することが可能である。深さを示す「数値ｍ」の扱いは、階層性に基づく視座の定義部における「数値ｍ」と同様である。

次に、視座の表示に係る制御部１１の動作例について、図２２中の表示画像VP1〜VP3の例を参照して説明する。

制御部１１は、前述のような視座の定義に従って、１〜２種類のカテゴリについて、そのカテゴリに属するリソースエントリをデータベースより取得して、当該視座から見た組織の構造情報をツリー状（又はリスト状）の表示形状で表す画像データを生成し、図２２中の表示画像VP1〜VP3の例に示すように、当該視座から見た組織構造を表す画像をクライアント端末３側の表示部に表示する。

上記画像データを生成する際、制御部１１では、視座タイプの指定に応じて、該当する定義部（指定された視座タイプに対応する図２２中の定義部）を参照し、ツリーの構成を判断する。例えば、視座タイプの指定が、タイプ１（属性に基づく視座）であれば、属性値により分類してツリー状に表示する。具体的には、本例では、当該カテゴリＩＤに対応する属性ＩＤの配列データを視座の定義部から取得し、その配列データに基づいてツリーの構成を決定し、属性ＩＤに対応する属性名称をツリー状に配置し、ツリー形式の画像データを生成するようにしている。

一方、視座タイプの指定がタイプ２（階層性に基づく視座）であれば、階層情報、すなわち、階層性名称，階層順位，上位エントリの役割名称，下位エントリの役割名称，上位エントリの多重度，下位エントリの多重度等の階層情報（図１３参照）に基づいてツリーの構成を決定し、階層性名称，上位エントリの役割名称，下位エントリの役割名称をツリー状に配置し、ツリー形式の画像データを生成する。

また、視座タイプの指定がタイプ３（関連性に基づく視座）であれば、関連性の定義情報（関連性名称、親カテゴリの多重度、子カテゴリの多重度、等の関連性データ：図１６参照）に基づいてツリーの構成を決定し、関連性名称，上位エントリの役割名称，下位エントリの役割名称をツリー状に配置し、ツリー形式の画像データを生成する。

さらに上記画像データを生成する際、制御部１１では、視座の定義情報を参照して、表示形状の指定がツリー状か否かを判定し、ツリー状で且つ画面上に表示する階層の深さの指定値ｍが１以上の場合は、指定値“ｍ”までの階層を表示対象として画像データを生成することによって、指定値以降の下位の階層（ｍ階層より下位の階層）についてはエントリがあっても表示しないようにする。また、表示形状の指定がツリー状で且つ階層の深さの指定値ｍ＝０の場合は全階層を表示対象として画像データを生成することによって、画面上に全階層を表示する。また、組織構造を表す画像を１画面上に表示できない場合は、クライアント端末側での操作に応じてスクロール表示可能に表示制御する。
（異なる視座から捉えた組織構造の具体的な表示例）
図２２中の表示画像VP1の例は、属性に基づく視座を視点として組織構造を可視化した際の表示例である。本例では、「情報システム」を表示対象のカテゴリとし、「情報システム」に属するリソースの属性（稼働環境，ベンダ等）の１要素である「稼働環境」を使用して、稼働環境から見た情報システム群の構成を可視化した例である。表示画像VP1の例に示すように、本例では、メインフレーム，Ｗｅｂサーバ，Ｃ／Ｓ（クライアント／サーバ）等を「稼働環境」としている。例えば、稼働環境を複数種類に分類して管理する場合は、第１稼働環境，第２稼働環境，第３稼働環境というように、複数の属性に分けて定義しておけば、それぞれの属性を視座としたシステム構成が可視化される。

図２２中の表示画像VP2の例は、階層性（同一カテゴリ内のリソース間の階層関係）に基づく視座を視点として組織構造を可視化した際の表示例である。本例では、「業務」を表示対象のカテゴリとし、その階層性を使った視座から見た業務群の構成を可視化した例である。表示画像VP2の例に示すように、業務の階層性（本例では、事業の種類別に各事業の業務構成がツリー形式で可視化される。

図２２中の表示画像VP3の例は、関連性に基づく視座を視点として組織構造を可視化した際の表示例である。本例では、「部署」を表示対象のカテゴリとし、そのカテゴリ「部署」を親とするカテゴリ「人」との関連性を使った視座から見た組織構造を可視化した例である。その他、部署、人、建物、情報システム、業務など、利用者が定義した所定のカテゴリ群のうちの任意の２つのカテゴリを関連付けて可視化することが可能である。関連性に基づく視座による組織構造の可視化方法においては、異なるカテゴリに属するリソース間の相関・従属関係をツリー形式又はリスト形式で可視化することが可能になる。

なお、本例では、クライアント端末からの表示要求に応じて、図２２中の表示画像VP1〜VP3を個別に切替えて表示する形態としているが、互いに異なる複数の視座から見た表示画像を画面上の各表示ウィンドウに配置し、同一画面上で複数の視座から見た組織構造を可視化する形態としても良い。

上述のように、制御部１１は、ディレクトリの定義情報（及び視座の定義情報）に基づいて、属性に基づく第１視座、階層性に基づく第２視座、及び関連性に基づく第３視座の中から選択された所望の視座を視点として、当該視点から見た組織の構造をツリー形式又はリスト形式で可視化する「可視化手段」を備え、組織の構造を多様な視点で表現できるようにしている。
《３．外部システムに提供するＡＰＩとＧＵＩパーツについて》
次に、外部システムとの連携処理手段として提供する「ＡＰＩ」と「ＧＵＩパーツ」について説明する。先ず、外部システムに提供するＡＰＩについて説明する。

（外部システムに提供するＡＰＩについて）
図２３は、本システムが提供するＡＰＩの具体例を示す図である。メソッドとしては、本例では１６種類のメソッドを用意している。メソッドの種類、及び各メソッドのパラメータと戻り値は図２３に示す通りであり、詳細については説明を省略する。

なお、メソッドが「属性定義の取得」の場合、戻り値の属性項目定義は該当するカテゴリの属性項目定義セットに含まれるものである。また、メソッドが「リソース一覧」の場合、該当するカテゴリの全リソースについて、基本情報を返す。また、メソッドが「指定視座のリソース一覧」の場合、該当するカテゴリの全リソースについて、基本情報を返す。また、メソッドが「指定視座のリソース抽出」の場合、指定したリソースＩＤを上位に持つ、リソースの情報を返す。その場合、戻り値のカテゴリＩＤには、視座における関連性の親カテゴリ、子カテゴリのＩＤの２通りがある。

ディレクトリサーバ１は、図２３に例示したようなＡＰＩをJava（登録商標）言語によるライブラリおよび、Ｗｅｂサービスとして提供する。また、ＡＰＩの定義は、本システムのＷｅｂサイトにおいてＷＳＤＬ（Web Services Description Language）で公開する。

外部システムでは、予め定義された上記ＡＰＩに従って、本システムで管理する定義情報、リソース情報、関係性の情報を取得することができる。

（永続的な識別子を使ったデータの管理について）
ここで、リソースＩＤを使ったリソースエントリのデータの管理について説明する。本システムは、個々のリソースの識別子として本システム内で固有の永続的な識別子であるリソースＩＤを自動生成する「リソースＩＤ生成手段」と、上述のＡＰＩ手段とを備えている。リソースＩＤ生成手段は、リソースエントリの登録時にリソースＩＤを生成する。当該リソースに対して付与されたリソースＩＤは、そのユニーク性が永続的に保証される。

上記リソースＩＤより、カテゴリにかかわらずリソースエントリを識別することが可能になる。また、外部システムはリソースＩＤを使うことで、本システムのリソース情報にアクセスすることが可能になる。

図２４は、リソースＩＤの生成方法の一例を示す模式図であり、リソースＩＤ生成手段は、同図に示すように、リソースエントリの登録時にリソースＩＤを生成する。本例では、リソースＩＤの生成のためにＤＢＭＳ（DataBase Management System）がサポートしている“CREATE SEQUENCE”の機能を使用しているが、類似のシーケンス番号生成機構を実装する形態としても良い。

外部システムでは、本システムの提供するＡＰＩによりリソースＩＤを取得する。具体的には、例えば、図２３に例示した「カテゴリ一覧の取得メソッド」により各カテゴリＩＤを取得し、当該カテゴリＩＤをパラメータとして「リソース一覧メソッド」により、当該カテゴリに属するリソース群の各リソースＩＤをカテゴリＩＤ毎に取得する。あるいは、後述するＧＵＩパーツを利用して、画面上に表示されているリソース一覧で選択したリソースのリソースＩＤを取得する。そして、外部システム固有の情報をリソースＩＤ及びＡＰＩにより取得したデータ記憶部１２内のデータと関連付けて管理する。これにより、外部システムは組織構造データと独自のデータベースとを関連付けることが可能となり、リソース間の関係性の変化などからディレクトリの内容が本システムによって更新された場合でも、外部システムは影響を受けないことになる。
（外部システムに提供するＧＵＩパーツについて）
次に、前述のＡＰＩ手段として外部システムに提供するＧＵＩパーツについて説明する。

ディレクトリサーバ１は、外部システムに組み込み可能で且つリソースＩＤを用いてデータ記憶部１２内のデータ（ディレクトリの各定義情報、視座の定義情報などのリソースＩＤに関連する各情報）の参照及び更新が可能なＡＰＩを含むＧＵＩパーツを外部システムに対してネットワーク経由で提供する「ＧＵＩパーツ提供手段」を備えている。

ディレクトリサーバ１では、外部システムで利用可能なＧＵＩパーツをＨＴＭＬフレームの中に組み入れて、図２５に示すように、システム利用者がリソース一覧で選択したリソースのリソースＩＤを外部システムのサーバ（ＤＢＭＳ）へJava（登録商標）Scriptを通して送信する。外部システムでは、リソースＩＤに関連する情報を参照したり、情報を入力・更新したりする。
《リスク管理及び内部統制を目的とした外部システムへの応用例について》
次に、本システムを利用した外部システムについて説明する。

以下、本システムを使ってプライバシーマーク認証基準（JISQ15001）に準拠した個人情報保護管理の運用を行う情報システム（以下、「個人情報保護管理システム」と呼ぶ）を実施例として挙げる。
［実施例］ 本システムを利用した個人情報保護管理システム
先ず、プライバシーマーク認証基準について説明する。

JISQ15001:2006（個人情報保護マネジメントシステム・要求事項）では、図２６に示すように、ＰＤＣＡサイクル（Plan-Do-Check-Act cycle）を回すことが必要となるが、実施例では、Plan（計画），Do（実施），Check（点検），Act（見直し）の各フェーズにおいて必要となる機能を本システムのディレクトリを使ってどのように実現するのかを説明する。なお、図２６において、Ａ）〜Ｅ）の部分がシステム化の対象となりうる要素である。

図２７は、個人情報保護管理のシステム化の機能要件を示している。図２７において、機能要件Ａ〜Ｅは、図２６中の要素Ａ〜Ｅをシステム化する場合の機能要件を示しており、線部の事項は、JISQ15001の要求事項と直接重なる部分を示している。

前述のようなJISQ15001:2006の要求事項をもとにしたＰマークシステムの要求事項のうち、規定文書管理機能（機能要件Ａ）」、（２）個人情報取り扱い管理機能（機能要件Ｂ）、及び（３）事件・事故、問合せ管理機能（機能要件Ｃ、Ｄ）の３つの機能について、それぞれの機能を実現する各システムからのディレクトリの利用イメージを図２８に示す。

図２８では、Ｐマークシステムの３つの機能ごとのディレクトリの情報の利用方法について記載している。以下、ＰＤＣＡサイクルの各フェーズにおいて必要となる機能を本システムのディレクトリを使ってどのように実現するのかについて、図２８に示す３つのシステム２１〜２３を具体例として説明する。

ディレクトリシステム１は、プライバシーマーク認証基準に準拠した個人情報保護管理の運用を行う外部システム２１〜２３とネットワーク経由で接続されている。そして、ディレクトリシステム１は、外部システム２１〜２３との間で前述のＡＰＩ若しくはＧＵＩパーツを介して連携処理することにより、外部システム側からの要求に応じて、外部システム２１〜２３側で複数のデータベース２１ａ〜２３ａで分散管理されている個人情報保護管理に係る情報群を、当該視点から見た組織の構造と関連付けて前記外部システム側の表示部に可視化する処理を実行するようにしている。また、外部システム２１〜２３側で、分散管理されている個人情報保護管理に係る情報群を、リソースＩＤを用いて一元管理し得るようにしている。

なお、以下の説明では、規程文書管理機能を実現するシステム２１を「規程文書管理システム」と呼び、個人情報取り扱い管理機能を実現するシステム２２を「個人情報取り扱い管理システム」と呼び、事件・事故、問合せ管理機能を実現するシステム２３を「事件・事故、問合せ管理システム」と呼び、それらのシステム２１〜２３について、システム毎に順次説明する。

＜規程文書管理システム２１＞
初めに、規程文書管理システム２１について説明する。

先ず、規程文書管理に関するJISQ15001の要求事項と、その要求事項に対するシステムの目的及び機能について説明する。
（要求事項）
法令，国が定める指針その他の規範にもとづき、自組織での規程を定める。その規程に則り、個人情報を取り扱い、その記録を保管する。
（規程文書管理システムの目的と機能）
規程文書を業務と関連付けて管理する。そのため、ディレクトリからは部署−業務の関係性を持った視座のＧＵＩパーツを組み込み、視座から業務（個人情報保護管理）を選択すると、関連づいた規程文書の一覧を表示する。一覧の中から選択された文書の内容を表示する。

図２９は、規程文書管理システム２１の機能を説明するための模式図である。規程文書管理システム２１は、本システムが提供するＧＵＩパーツ(GP)を組み込み、そのＧＵＩパーツ(GP)に含まれるＡＰＩ（図２３参照）を用いて本システムと連携処理することにより、以下の機能を備える形態とする。
（１ａ）業務名称の一覧表示機能
図２９中の画像VP1-1の例に示すように、部署ごとに分類された業務を画面２１上に表示する。
（１ｂ）規程文書一覧表示機能
規程文書は、図２９中のデータベース２１ａに示すように、規程本文、書式、業務フロー図、リスク分析表などに分類されてデータベース管理されているので、図２９中の画像VP1-2の例に示すように、分類毎にツリー状に規程文書の名称を羅列してその一覧を画面２１上に表示する。
（１ｃ）規程文書表示機能
規程文書の一覧から文書を利用者が選択し「文書表示」ボタンをクリックすると、選択された文書２１Ｄを画面２１上に表示する。
（１ｄ）規程文書登録機能
規程文書を登録し、業務と関連付けて管理する。
（規程文書管理システム２１の処理フロー）
規程文書管理システム２１がディレクトリの外部インターフェースを利用する部分の処理フローと主なデータ項目（規定文書管理テーブル）を、図３０及び図３１に示す。

「規程文書一覧表示」に関する処理は、図３０中のステップＳ２１〜Ｓ２４に示す流れとなる。すなわち、先ず、部署−業務ツリーのＧＵＩパーツの表示処理を実行し（ステップＳ２１）、選択された業務のリソースＩＤを取得する（ステップＳ２２）。続いて、規程文書テーブル（図３１参照）から業務＝リソースＩＤの（文書分類、文書名称、規程文書ＩＤ）のリストを取得し（ステップＳ２３）、文書分類で仕分けて文書名称を一覧表示する（ステップＳ２４）。

「規程文書登録」に関する処理は、図３０中のステップＳ３１〜Ｓ３３に示す流れとなる。すなわち、選択された業務のリソースＩＤを取得し（ステップＳ３１）、文書登録画面を表示する（ステップＳ３２）。そして、その文書登録画面上での入力内容をもとに規程文書テーブルへレコードを追加する（ステップＳ３３）。

＜個人情報取り扱い管理システム２２＞
次に、個人情報取り扱い管理２２について説明する。

先ず、個人情報取り扱い管理に関するJISQ15001の要求事項と、その要求事項に対するシステムの目的及び機能について説明する。
（要求事項）
個人情報を新たに取得する場合、取得する個人情報の内容、目的を明確にする。また、個人情報取得に伴う業務上のリスクを評価する。
（個人情報取り扱い管理システムの目的と機能）
業務の担当者は必要な情報を登録し、業務の責任者、個人情報保護管理責任者の承認を要求する。

図３２は、個人情報取り扱い管理システム２２の機能を説明するための模式図である。個人情報取り扱い管理システム２２は、本システムが提供するＧＵＩパーツ(GP)を用いて本システムと連携処理することにより、以下の機能を備える形態とする。
（２ａ）個人情報の台帳管理機能
組織内でどのような個人情報を扱っているのかを台帳２２Ｄとしてデータベース２２ａで管理する。
（２ｂ）所得する個人情報の登録機能
ディレクトリの業務のリストVP2-1を参照して、図３２中の画面VP2-2上で業務と取得する個人情報とを関連付ける。
（２ｃ）業務フロー図の作成機能
個人情報を取り扱う業務の手続きをフロー図にする。
（２ｄ）リスク分析機能
業務フロー図をもとに、手続き上のリスクを分析し、リスク分析表を作成する。
（２ｅ）承認ワークフローの作成・保管機能
個人情報を取り扱う内容について、システム上で承認を得るための承認ワークフロー２２Ｄ２を作成する。

上記（２ｃ），（２ｄ）の業務フロー図とリスク分析表について、図３３及び図３４を参照して説明する。図３３は、業務フロー図（リスク分析表を含む図）の一例を示す模式図であり、図３４は、業務上で想定されるリスクの種類の一例を示す模式図である。

業務フロー図は、図３３のように、収集、保管、利用、破棄、外部作業（受託／委託／提供）に分けて個人情報の取り扱いの手順をフロー化することで作成する。

リスク分析表は、その業務フローで示される業務工程の各ステップにおいて、想定されるリスクを図３４のようなリスクの種類から選択することによって作成される。図３３の業務フロー図の例では、業務フローとリスク分析表とを業務要素毎に対応させて示している。
（個人情報取り扱い管理システム２２の処理フロー）
個人情報取り扱い管理システム２２ディレクトリの外部インターフェースを利用する部分の処理フローと主なデータ項目（個人情報台帳テーブル）を、図３５及び図３６示す。業務名称の取得から承認申請までの処理は、図３５のステップＳ４１〜Ｓ４６に示す流れとなる。すなわち、先ず、業務ツリーのＧＵＩパーツの表示処理を実行し（ステップＳ４１）、図３２の画面VP2-1上で選択された業務のリソースＩＤ、業務名称を取得し（ステップＳ４２）、業務名称を画面VP2-2上に表示する（ステップＳ４３）。続いて、個人情報取得申請データの登録処理を実行し（ステップＳ４４）、業務フロー図、リスク分析表を規程文書テーブルに登録した後（ステップＳ４５）、承認申請処理を実行する（ステップＳ４６）。

＜事件・事故、問合せ管理システム２３＞
次に、事件・事故、問合せ管理システム２３について説明する。

先ず、事件・事故及び問合せの管理に関するJISQ15001の要求事項と、その要求事項に対するシステムの目的及び機能について説明する。
（要求事項）
収集した個人情報について、本人からの問合せや事件・事故があった場合に、その内容を登録し、対応内容を記録し、現行のプロセスをチェックし、是正を実施する。
（事件・事故、問合せ管理システムの目的と機能）
業務の担当者は必要な情報を登録し、業務の責任者、個人情報保護管理責任者の承認を要求する。

図３７は、事件・事故、問合せ管理システム２３の機能を説明するための模式図である。事件・事故、問合せ管理システム２３は、本システムが提供するＧＵＩパーツ(GP)を用いて本システムと連携処理することにより、以下の機能を備える形態とする。
（３ａ）事件・事故、問合せの台帳管理機能
事件・事故、問合せに関する情報を台帳２３Ｄ１としてデータベース２３ｂで管理する。
（３ｂ）事件・事故、問合せの登録機能
対象の個人情報を選択することで、個人情報と関連付けられた業務や担当部署、担当者などの情報を取得する。
（３ｃ）承認ワークフローの作成・保管機能
事件・事故、問合せの内容について、システム上で承認を得るための承認ワークフロー２３Ｄ２を作成する。
（事件・事故、問合せ管理システム２３の処理フロー）
事件・事故、問合せ管理システムがディレクトリの外部インターフェースを利用する部分の処理のフローと主なデータ項目（事件・事故、問合せデータテーブル）を、図３８及び図３９に示す。

個人情報選択画面の表示から承認申請までの処理は、図３９のステップＳ５１〜Ｓ５７に示す流れとなる。すなわち、先ず、個人情報の選択画面の表示処理を実行し（ステップＳ５１）、図３７の画面VP3-1上で選択された個人情報の個人情報ＩＤを取得し（ステップＳ５２）、個人情報取得申請データテーブルから個人情報ＩＤに対応する該当レコードを取得する（ステップＳ５３）。続いて、業務ＩＤから業務名称を取得し（ステップＳ５４）、業務名称を画面VP3-2上に表示する（ステップＳ５５）。そして、画面VP3-2上で入力されたデータをもとに事件・事故、問合せデータテーブル（図３９参照）にレコードを追加登録した後（ステップＳ５６）、承認申請処理を実行する（ステップＳ５７）。

１ ディレクトリサーバ
２ ネットワーク
３ クライアント端末
１１ 制御部
１２ データ記憶部
１２ａ カテゴリ定義ファイル
１２ｂ 視座定義ファイル１２ｂ
１２ｃ リソースＤＢ１２ｃ
１２ｄ 属性情報ＤＢ１２ｄ
１２ｅ 階層情報ＤＢ１２ｅ
１２ｆ 関連性情報ＤＢ１２ｆ
１２ｇ マスタＤＢ
G1 システムメニュー画面
G2 リソース管理画面
G10 データ入力画面
G10M ひな型画面
VP1 組織構造の表示画像(属性に基づく視座から捉えた画像)
VP2 組織構造の表示画像(階層性に基づく視座から捉えた画像)
VP3 組織構造の表示画像(関連性に基づく視座から捉えた画像)
GP ＧＵＩパーツ
２０ 外部システム（Ｐマークシステム）
２１ 規程文書管理システム
２１ａ 規程文書ＤＢ
２２ 個人情報取り扱い管理システム
２２ａ 個人情報台帳ＤＢ
２３ 事件・事故、問合せ管理システム
２３ａ 事件・事故，問合情報台帳ＤＢ

Claims (6)

1. 組織構造管理ディレクトリを有するサーバを備えたディレクトリシステムであって、
   前記サーバは、
   管理対象となる組織内のリソース群を区分するカテゴリ，当該カテゴリに属するリソースの属性，同一カテゴリ内におけるリソース間の階層性，及び異なるカテゴリにおけるリソース間の関連性を表す定義を、前記ディレクトリの定義情報として登録する定義情報登録手段と、
   前記ディレクトリの定義情報に基づいて、前記カテゴリの一覧表示の中から選択された当該カテゴリに属するリソースの一覧を表示すると共に、前記リソースの一覧表示の中から選択されたリソースのリソース情報，属性情報，及び，当該リソースとは異なるカテゴリに属するリソースとの相関関係を表す関連性情報を入力するためのＧＵＩ画面を生成する画面生成手段と、
   前記ＧＵＩ画面上で入力された当該リソースのデータをデータベースに登録するデータ登録手段と、
   前記ディレクトリの定義情報に基づいて、前記属性に基づく第１視座，前記階層性に基づく第２視座，及び前記関連性に基づく第３視座の中から選択された所望の視座を視点として、当該視点から見た前記組織の構造をツリー形式又はリスト形式で可視化する可視化手段と、
   を備え、
   更に、前記サーバは、前記データ登録手段により前記リソース情報を登録する際に当該リソースの識別子として前記ディレクトリシステム内で固有の永続的なリソースＩＤを自動生成するリソースＩＤ生成手段と、前記リソースＩＤを含む前記データベース内のデータを外部システムにネットワーク経由で提供するＡＰＩと、を備え、前記外部システムにおいて前記ＡＰＩを用いて得た前記リソースＩＤに関連する前記データベース内のデータと外部システム固有の情報とを関連付けて管理可能としていることを特徴とするディレクトリシステム。
2. 組織構造管理ディレクトリを有するサーバを備えたディレクトリシステムであって、
   前記サーバは、
   管理対象となる組織内のリソース群を区分するカテゴリ，当該カテゴリに属するリソースの属性，同一カテゴリ内におけるリソース間の階層性，及び異なるカテゴリにおけるリソース間の関連性を表す定義を、前記ディレクトリの定義情報として登録する定義情報登録手段と、
   前記ディレクトリの定義情報に基づいて、前記カテゴリの一覧表示の中から選択された当該カテゴリに属するリソースの一覧を表示すると共に、前記リソースの一覧表示の中から選択されたリソースのリソース情報，属性情報，及び，当該リソースとは異なるカテゴリに属するリソースとの相関関係を表す関連性情報を入力するためのＧＵＩ画面を生成する画面生成手段と、
   前記ＧＵＩ画面上で入力された当該リソースのデータをデータベースに登録するデータ登録手段と、
   前記ディレクトリの定義情報に基づいて、前記属性に基づく第１視座，前記階層性に基づく第２視座，及び前記関連性に基づく第３視座の中から選択された所望の視座を視点として、当該視点から見た前記組織の構造をツリー形式又はリスト形式で可視化する可視化手段と、
   を備え、
   更に、前記サーバは、外部システムに組み込み可能で且つ前記リソースを特定するリソースＩＤを用いて前記データベース内のデータの参照及び更新が可能なＡＰＩを含むＧＵＩパーツを前記外部システムに対してネットワーク経由で提供するＧＵＩパーツ提供手段を有することを特徴とするディレクトリシステム。
3. 前記サーバは、プライバシーマーク認証基準に準拠した個人情報保護管理の運用を行う外部システムとネットワーク経由で接続されており、前記可視化手段は、前記ＡＰＩを介した前記外部システム側からの要求に応じて、前記外部システム側で複数のデータベースで分散管理されている前記個人情報保護管理に係る情報群を前記当該視点から見た組織の構造と関連付けて前記外部システム側の表示部に可視化する処理を実行することを特徴とする請求項１又は２に記載のディレクトリシステム。
4. 前記ＧＵＩ画面は、前記当該カテゴリに属するリソースの一覧をツリー形式又はリスト形式で表示する表示領域と、前記リソースの一覧表示の中から選択されたリソースの属性情報を入力するための属性情報入力域と、前記リソースの一覧表示の中から選択されたリソースと他のカテゴリに属するリソースとの相関関係を表す関連性情報を入力するための関連性情報入力域と、リソースの追加／削除を指示するための操作ボタンと、を含んで構成されていることを特徴とする請求項１乃至３のいずれかに記載のディレクトリシステム。
5. 組織構造管理ディレクトリを有するサーバを備えたディレクトリシステムに適用されるプログラムであって、
   前記サーバのコンピュータを、
   管理対象となる組織内のリソース群を区分するカテゴリ，当該カテゴリに属するリソースの属性，同一カテゴリ内におけるリソース間の階層性，及び異なるカテゴリにおけるリソース間の関連性を表す定義を、前記ディレクトリの定義情報として登録する定義情報登録手段、
   前記ディレクトリの定義情報に基づいて、前記カテゴリの一覧表示の中から選択された当該カテゴリに属するリソースの一覧を表示すると共に、前記リソースの一覧表示の中から選択されたリソースのリソース情報，属性情報，及び，当該リソースとは異なるカテゴリに属するリソースとの相関関係を表す関連性情報を入力するためのＧＵＩ画面を生成する画面生成手段、
   前記ＧＵＩ画面上で入力された当該リソースのデータをデータベースに登録するデータ登録手段、
   前記ディレクトリの定義情報に基づいて、前記属性に基づく第１視座，前記階層性に基づく第２視座，及び前記関連性に基づく第３視座の中から選択された所望の視座を視点として、当該視点から見た前記組織の構造をツリー形式又はリスト形式で可視化する可視化手段、
   前記データ登録手段により前記リソース情報を登録する際に当該リソースの識別子として前記ディレクトリシステム内で固有の永続的なリソースＩＤを自動生成するリソースＩＤ生成手段、及び
   前記リソースＩＤを含む前記データベース内のデータを外部システムにネットワーク経由で提供するＡＰＩを用いて前記外部システムにて得た前記リソースＩＤに関連する前記データベース内のデータと外部システム固有の情報とを関連付けて管理する手段、
   として機能させるプログラム。
6. 組織構造管理ディレクトリを有するサーバを備えたディレクトリシステムに適用されるプログラムであって、
   前記サーバのコンピュータを、
   管理対象となる組織内のリソース群を区分するカテゴリ，当該カテゴリに属するリソースの属性，同一カテゴリ内におけるリソース間の階層性，及び異なるカテゴリにおけるリソース間の関連性を表す定義を、前記ディレクトリの定義情報として登録する定義情報登録手段、
   前記ディレクトリの定義情報に基づいて、前記カテゴリの一覧表示の中から選択された当該カテゴリに属するリソースの一覧を表示すると共に、前記リソースの一覧表示の中から選択されたリソースのリソース情報，属性情報，及び，当該リソースとは異なるカテゴリに属するリソースとの相関関係を表す関連性情報を入力するためのＧＵＩ画面を生成する画面生成手段、
   前記ＧＵＩ画面上で入力された当該リソースのデータをデータベースに登録するデータ登録手段、
   前記ディレクトリの定義情報に基づいて、前記属性に基づく第１視座，前記階層性に基づく第２視座，及び前記関連性に基づく第３視座の中から選択された所望の視座を視点として、当該視点から見た前記組織の構造をツリー形式又はリスト形式で可視化する可視化手段、及び、
   外部システムに組み込み可能で且つ前記リソースを特定するリソースＩＤを用いて前記データベース内のデータの参照及び更新が可能なＡＰＩを含むＧＵＩパーツを前記外部システムに対してネットワーク経由で提供するＧＵＩパーツ提供手段、
   として機能させるプログラム。