2.1.1 ユーザ管理について

ユーザ管理は,Groupmaxのすべての機能で必要になります。Groupmaxでは,ユーザをAddress Serverで管理し,ユーザ情報として各サーバ固有の情報を含めて管理しています。なお,スケジュール管理機能と施設予約機能を単独で使用する場合は,Scheduler Server及びFacilities Manager独自のユーザ管理もできます。

代表的なユーザ管理情報とアプリケーションごとの設定項目の関連を,表2-1に示します。

表2-1 代表的なユーザ管理情報とアプリケーションごとの設定項目の関連

項目機能
AddressMailDocument ManagerWorkflowScheduler/FacilitiesAgent
ユーザID
日本語名 
日本語組織名 
組織略称  
役職   
上位組織ID  
住所     
電話番号     
専用線番号     
ニックネーム    
ホームサーバ    
英語姓     
英語名     
E-Mailアドレス     
Document Managerサーバ     
上長役職名     
上長ユーザID     
Workflowサーバ     
Schedulerサーバ     
セキュリティランク     

ユーザ管理情報を登録する方法は二つあります。一つは,Address Serverの運転席から対話的に登録する方法です(以降「GUIによる登録」と呼びます)。もう一つは,CSV形式ファイルを使用して一括登録する方法です(以降「コマンドによる一括登録」と呼びます)。オプションのAddress - Assistを使うと,管理者環境から実施できます。CSV形式ファイルには,ユーザIDや日本語名などの共有する情報と,住所やセキュリティランクなどの各アプリケーション固有の情報を指定します。

同様に,掲示板へのアクセス権やグループの登録についてもGUIによる登録とコマンドによる一括登録ができ,必要に応じて選択します。

次に,Groupmaxを導入するときに検討が必要となる代表的な項目について説明します。これらは,運用に合う形態でGroupmaxの各機能を使うために必要な項目です。

<この項の構成>
(1) 組織の登録
(2) 初期登録の方式
(3) ユーザIDの付与
(4) ニックネームの付与
(5) 登録情報の変更

(1) 組織の登録

各企業の組織構成を登録する場合,登録する組織の階層レベルについて検討する必要があります。検討する項目は次のとおりです。

(2) 初期登録の方式

登録する情報(ユーザID,ニックネームなど)については,運用開始後のデータ重複などを想定し,あらかじめ生成ルールを検討しておく必要があります。特に,大規模な組織ほど生成ルールが重要になります。

また,コマンドによる一括登録を使用する場合,登録情報を形成する各項目について,情報生成の流れ(既存の人事データベースなどをもとに登録ファイルを生成し,一括登録機能を用いているなど),データの抽出方法,及び変換・編集などのツール作成も併せて検討する必要があります。

(3) ユーザIDの付与

Groupmaxのユーザごとに付与するユーザIDは機密性が高く,組織内の重複をなくす必要があります。このため,人事データベースなどで管理されている個人情報(社員NOなど)の流用などを検討する必要があります。

しかし,組織内の書類などで,その個人情報をよく目にする場合(機密性が低い),ユーザIDの付与ルールを新規に作成することも検討する必要があります。

また,ユーザIDを決める部署と管理する仕組み(人事データベースやGroupmax Addressのユーザ管理情報)も明確にする必要があります。

(4) ニックネームの付与

メール機能での宛先やワークフロー機能で使用されるニックネームの設定方法は,大きく分けて,英数字と全角文字の二つがあります。英数字を使用する場合のメリットは,メール送信で宛先を指定したり,ワークフロー案件で次の操作者を指定したりするときに,直接入力での操作が容易になることです。全角文字を使用する場合のメリットは,受信メールの一覧表示で,だれから届いたメールか確認しやすくなることです。

英数字でニックネームを付与する場合,ニックネーム内に「.」を含める必要があります。代表的な形式は次のようになります。

(英語名の一部の文字)+"."+(英語姓)

同姓同名のユーザがいる場合などは,英語名の一部の文字を増やすことで重複を避けられます。GUIによる登録をする場合,Address Serverで管理されている英語姓名によって,この形式で自動的に付与されます(明示的にユニークなニックネームを指定することもできます)。コマンドによる一括登録をする場合,明示的に既存のニックネームと重複しない内容を指定する必要があります。したがって,同姓同名のユーザがいる場合,ニックネームの重複を避けるためのルールを検討しておく必要があります。

全角文字でニックネームを付与する場合,全角の片仮名や漢字などを使用することになります。同姓同名のユーザがいる場合は,英数字を付与することで識別するなど,重複を避けるための方法を検討する必要があります。また,インターネットクライアント(POP3,IMAP4対応クライアント)でメールを使用する場合のアドレスとして,ニックネームを使用したマッピングは適用できなくなります。この場合,ユーザ属性のE-mailアドレスによるマッピングを適用することになります。このE-mailアドレスのローカルパート(アドレスでの「@」の左側)の付与ルールも検討する必要があります。

このように,ニックネームの検索効率,メール発信元の判読性,及び使用するクライアントの形式などを考慮して,ニックネーム形態を決定する必要があります。

(5) 登録情報の変更

ユーザ情報は,人や組織の追加,削除,及び異動が発生するたびに変更する必要があります。この変更も初期登録と同様に,GUIによる登録又はコマンドによる一括登録をします。

ただし,登録情報を変更するときに,登録ユーザを組織又は地域別に複数サーバに分けて管理する場合,情報の変更内容(所属する最上位組織の変更やホームサーバの移動)によっては,必要となる作業と変更方法が異なってくるなどの留意事項があります。これに伴って,登録ユーザの管理方針と,これに沿った情報変更の方式を検討する必要があります。特に,運用開始後に登録ユーザのホームサーバを移動する場合,移動前のサーバからユーザの個別情報(既存のメールボックスとスケジュール情報)を退避(バックアップ)し,移動先のサーバで回復(リストア)することになります。したがって,ユーザ情報の変更に加えて,これら個別情報のバックアップとリストアの作業が必要になります。また,移動対象ユーザについては,移動が終わるまでGroupmaxを使えなくなることも考慮する必要があります。

さらに,効率よく変更するためには,人事データベースなどからの差分情報の入手方法や変更手順を明確にする必要があります。