権限範囲指定メンバー

パターン

状況

組織変更に対応するために、

  • 組織ディメンションにおいて「世代統合型メンバーツリー 」を適用している。その帰結として、末端レベルの部門おのおのについて、世代ごとに異なる複数のメンバーが組織ディメンションに存在する。あるいは、

  • 組織ディメンションにおいて「世代別メンバーツリー 」を適用している。その帰結として、集計レベルの部門おのおのについて、世代ごとに異なる複数のメンバーが組織ディメンションに存在する。

問題

世代ごとにメンバーが設けられている部門を担当するユーザーには、その部門に対応して世代ごとに存在するメンバーすべてのデータを照会あるいは更新できる権限を割り当てたい。

配慮すべきことがら

  • 現場ユーザーにとっての使い勝手：自分が使うべき業務責任単位を、ユーザーが簡単に識別し選択できることが望ましい。

  • メンテナンスの容易さ 世代の追加に際して権限設定のメンテナンスの手間が小さい方が好ましい。

  • アプリケーションデザインのシンプルさ：権限付与のためにアプリケーションに付け加えられる複雑さが小さいことが望ましい。

解決策

  • 組織ディメンション内に、世代ごとに設けられる部門メンバーを、それらが対応している部門ごとに束ねるメンバーツリーを、組織ツリーとは別に設ける。そのメンバーツリーの親メンバーと業務責任単位を対応づける。* 対象は世代管理される部門に対応する業務責任単位だけである。

    「世代別メンバーツリー」を適用する場合であれば、たとえば、関西地区本部について「関西地区本部（03年度）」「関西地区本部（04年度）」といったメンバーが設けられる。当パターンでは、これらをたばねるメンバー「関西地区本部」を設ける。このメンバーは世代別メンバーツリーの外に置かれ、 権限範囲指定メンバー と呼ばれる。そして、権限範囲指定メンバー「関西地区本部」に対応して業務責任単位「関西地区本部」を設ける。 これらの業務責任単位には、権限範囲指定メンバーそれぞれひとつを、責任範囲指定キーとして紐づける。

例

適用の帰結

利点

  • アプリケーションデザインのシンプルさ：業務責任単位に組織ディメンションのメンバーを1対1で紐づけて、それを手掛かりとしてアクセス可能範囲を定義するアプロ―チは、fusion_place の設計思想に沿っており、シンプルでわかりやすい。

  • 現場ユーザーにとっての使い勝手：世代管理されている部門のユーザーはどの世代のデータを照会する場合にも同じ業務責任単位を用いればよい。これは、世代別の業務責任単位 パターンに対する当パターンの利点である。

制約

  • メンテナンスの容易さ 世代が進むごとに、権限範囲指定メンバーの配下に新年度分の部門メンバーを配する必要がある。これには一定の手間がかかるが、クリップボードからのメンバーインポートで行うことができるので、作業量は小さいと思われる。

関連するパターン

先行パターン

後続パターン

―

その他の関連パターン