This page is in Japanese version. The English version is in preparation.

年度別メンバーツリー

Patterns

状況 Context

組織は変更されることがある。組織変更に際して、新たな部門が追加され、既存の部門が廃止、統合、あるいは分割される。最下位部門の変動を伴わず、上位の括り方が変更される場合もある（例えば、三重支店を管轄する本部が関西地区本部から中部地区本部に変わる）。

組織が変更されても、過去のデータは、各事業年度で施行されていた組織にもとづいて集計／報告できなければならない。各年度が終了した後でも、数年間は、各年度に施行されていた組織にもとづいて、過去の実績や予算を集計し報告できることが必要である。 一方で、事業年度内の組織変更では、変更後の組織に従ってデータを集計出来ればよい場合が多い。

問題 Problem

事業年度ごとに異なる組織ツリーに従って、各年度の実績や予算を集計できるようにしたい。

配慮すべきことがら Forces

  • 組織ツリーの直観的把握：時とともに変わっていく組織を表現しようとすれば、マスターデータは複雑になりがちである。典型的なアプローチでは、組織マスターに適用期間（適用開始日と終了日で示される）を含めることで、時間とともに変化する組織ツリーを表現しようとする。このアプローチでは、各時点におけるツリーがどのような形となっているのか、直観的に把握することが難しくなる。年度ごとのツリーが直截に示されるアプローチの方が理解しやすいだろう。

  • ディメンションメンテナンスの容易さ：組織変更時に、組織を表すディメンション（以下、「組織ディメンション」）の修正が容易であることが望ましい。

  • 組織ツリーの選択の容易さ：フォームやExcel-Linkでデータを表示する際、どの年度のメンバーツリーを使用するか容易に指定できるべきである。かつ、「伸縮する軸」と組合せて適用できなければならない。

  • アクセス制御の容易さ：組織にもとづくアクセス制御の設定が容易であることも望ましい。例えば、関西地区本部の管轄する部門は年度ごとに増減するが、関西地区本部のユーザーはいずれかの年度で同本部配下となった部門のデータにアクセスできる必要がある。このような設定が簡単に行えることが望まれる。

解決策 Solution

部門組織を表すディメンションにおいて、事業年度ごとにメンバーツリーを設ける。ここで、

  • リーフレベルのメンバーは、年度別のツリーを横断して共有する

  • 集計レベルのメンバーは、年度ごとに設ける。メンバーのラベルには事業年度を識別する文字列（第3事業年度なら「03_」等）を含める

fusion_placeでは、ひとつのディメンションの中に、複数のメンバーツリーを設けることができる。この特長を利用して、組織ディメンション内に、組織変更前と後のメンバーツリーをそれぞれ作成することで、組織変更に対応する。

リーフレベルの部門が旧新の組織両方に存在するのであれば、その部門に対応するメンバーは両方のメンバーツリーに含める（fusion_placeでは、ひとつのメンバーを複数のメンバーツリーに含めることができる）。

廃止されたリーフレベル部門の扱い

リーフレベルの部門が廃止された場合、廃止された部門に対応するメンバーは新組織ツリーに含めておく。そうしなければ、新組織ツリーで過去の実績を集計する際にその部門のデータが抜け落ちるからである。部門が廃止されたことと、その部門のデータが集計不要になることは異なる。廃止された部門について、メンバープロパティ「使用区分」を「使用せず」とすれば、そのメンバーへのデータ入力と修正は禁止される。

メンバーラベルに関する規約の必要性

集計部門に対応するメンバーは、事業年度ごとに作られるメンバーツリーに一個ずつ設けられる。これらは別のメンバーなので、異なるラベルを付与しなければならない。ラベルは対応する事業年度が容易にわかるように体系化する。 後述の例では、集計部門メンバーのラベルの先頭に年度を表す文字列と下線（「04_」等）を付すことにより、これを達成している。末端の部門は、それが存在する限りひとつのメンバーに対応づけられるので、このような配慮は不要である。 これらの点を踏まえて、集計部門・末端部門とも、メンバーラベルの命名規約を決めておくことが望ましい。

よりシンプルな解決策：照会専用アプリケーション

旧年度データについては照会のみできればよい場合、よりシンプルな解決策として、アプリケーションのデザインで対応するのではなく、組織変更反映前かつ旧年度データが投入済みのアプリケーション全体をコピーして、照会専用アプリケーションを設けるという対応が可能である。fusion_place のライセンス体系では、照会専用アプリケーションには追加料金がかからない（サーバーメモリーは消費するのでクラウドのプラットフォームレベルには注意を要する）。照会専用アプリケーションについては、以下を参照： システム全体に関する設定を管理する - fusion_place マニュアル

例 Examples

03事業年度には独立していたB本部が、04年度からA本部に統合された場合、組織ディメンション内に、下図のように、03年度のメンバーツリーと04年度のメンバーツリーを設ける（メンバー名称の後に[ ]で囲ってラベルを示している）：

03年度メンバーツリー 04年度メンバーツリー

全社合計/03年度 [03_TOTAL]
　∟ A本部/03年度 [03_A]
　　　∟ A1部 [A1]
　　　∟ A2部 [A2]
　　　∟ A3部 [A3]
　∟ B本部/03年度 [03_B]
　　　∟ B1部 [B1]
　∟ C本部/03年度 [03_C]
　　　∟ C1部 [C1]

全社合計/04年度 [04_TOTAL]
　∟ A本部/04年度 [04_A]
　　　∟ A1部 [A1]
　　　∟ A2部 [A2]
　　　∟ B1部 [B1]
　　　∟ A3部 [A3] （廃止）
　∟ C本部/04年度 [04_C]
　　　∟ C1部 [C1]
　　　∟ C2部 [C2]

以下の点に留意する：

  • 最下位のメンバー A1, A2, A3, B1, C1は、両年度のメンバーツリーに属している。

  • 集計レベル部門については、年度ごとに別のメンバーがある。例えば、A本部の場合、03年度用には「03_A」、04年度用には 「04_A」 というラベルのメンバーが設けられている。

  • C本部についても、03年度のメンバー「03_C」と04年度のメンバー「04_C」を別に設けている。C本部は、単に下位に部門が新設されただけなので（C2部）、両年度で同じメンバー（03_C）を用いることも可能だが、対応を一律なものとする観点から、年度ごとに異なるメンバーを設けることが望ましい。

  • B1部[B1]は、03年度メンバーツリーでは、「B本部/03年度[03_B]」に属し、04年度メンバーツリーでは、「A本部/04年度[04_A]」に属している。

  • 廃止された集計レベル部門(B本部)については、廃止後の04年度メンバーツリーには、メンバーを設けていない。

  • A3部は、03年度には存在したが04年度には廃止された。しかし、04年度のツリーにA3部は含められている。前述したように、04年度のツリーで対前年対比するためには、リーフレベル部門は、廃止されていても新組織ツリーに含める必要がある。

適用の帰結 Consequences

利点 Benefits

  • 組織ツリーの直観的把握：年度ごとの組織ツリーがメンバーツリーとして存在するので、直観的に把握しやすい。

  • ディメンションメンテナンスの容易さ：年度ごとにメンバーツリーを構築しなければならないので設定の手間がかかるように見えるが、実際にかかる手間はわずかである。具体的には、旧年度のメンバーツリーをクリップボード経由でエクセル等にエクスポートした後、修正をほどこして新年度のメンバーツリーを作り、ふたたびクリップボード経由で fusion_place にインポートすることができる。

  • 組織ツリーの選択の容易さ：フォームは、いずれかの部門メンバーをパラメータで選択し、その配下のメンバーを縦軸または横軸に並べるように設定できる。パラメータで複数の年度メンバーツリーからメンバーを選択できるようにすることも容易なので、いずれの年度のメンバーツリーのどのメンバー配下のツリーも表示できる。Excel-Linkでは、テンプレート処理を用いる場合、縦軸の展開にメンバーリストを用いるが、そのメンバーリストの起点メンバーを指定するセルを設けることができる。そのセルにいずれかの年度別メンバーツリーの集計レベルメンバーのラベルを指定することで、フォームの場合と同様、どの年度のメンバーツリーのどのメンバー配下のツリーも表示できる。

制約 Liabilities

  • アクセス制御の容易さ：集計レベルの部門に対応するメンバーを年度ごとに設けた場合、アクセス制御に関して注意が必要である。

    fusion_placeで組織別のアクセス制御をおこなう場合、業務責任単位に「責任範囲指定キー」として部門メンバーを割り当てるとともに、アクセス許可タイプでは、その部門メンバー配下の各メンバーに対するアクセスを許可するのが定石である。

    この定石にそのまま従うならば、業務責任単位によるアクセス制御に関して以下のアプローチを適用することになる：

    • 年度別に業務責任単位を設ける：集計レベルの部門メンバーが年度別に設けられることに対応して、業務責任単位も年度別に設ける。対象は集計レベルの部門に対応する業務責任単位だけである。たとえば、関西地区本部について「関西地区本部（03年度）」「関西地区本部（04年度）」といった業務責任単位を設ける。このアプローチは「年度別業務責任単位」パターンで解説されている。

    このアプローチでは、どの年度のデータを照会するかに応じて業務責任単位を切り替えなければならないが、業務責任単位の切り換え操作は簡単であり、fusion_place ブラウザやコントリビュータ上で手軽に行える。一方で、集計レベルの部門に対応する業務責任を年度ごとに登録する必要が生じる。それにともなって、業務責任単位別実行権限や提出ルート内容も登録／修正しなければならない。

    これに対して、業務責任単位を年度別に分けないアプローチも存在する：

    • 権限範囲指定ツリーによる解決：権限範囲指定用にダミーの親メンバーを設ける。例えば「関西地区本部（03年度）」「関西地区本部（04年度）」をまとめる「関西地区本部」というダミーメンバーを設ける。このアプローチは、fusion_placeバージョン12.2で一般ディメンションに「データタイプ」プロパティが導入されたことで可能となった。「権限範囲指定ツリー」パターンで解説されている。

    • コピーディメンションを用いた権限範囲の拡張：組織ディメンションを借用するなどして同じ内容の別のディメンションを設ける。集約レベルの業務責任単位を対象に、そのディメンションに関する「責任範囲指定キー」を指定する。ただし、このアプローチは、年度別ツリーの数が増えると使いづらい。ツリーの数だけ、責任範囲指定キー指定用のディメンションが必要になるからである。そのため、ふつうは、年度別ツリーを進行年度用と計画年度用の2つに限定する。このパターンは、過去、広く使われていたが、「権限範囲指定ツリー」が利用できるようになって以来、積極的に用いる必要性は薄れている。

関連するパターン Related patterns

先行パターン Preceding patterns

―

後続パターン Succeeding patterns

  • 適用の帰結＞制約で述べたように、アクセス制御に関わる問題の解決アプローチがいくつかある。「年度別業務責任単位」及び「権限範囲指定ツリー」、「コピーディメンションを用いた権限範囲の拡張」を参照のこと。

  • リーフレベルの部門が分割あるいは統合される場合、新組織ベースで、最新年度のデータを前年度データと比較するには、前年度データの分割や統合が必要になる場合が多い。「対比用前年値シナリオ」は、年度間対比のために分割／統合された前年度データを元データとは別に保持するパターンである。

その他の関連パターン Other related patterns

  • 本パターンを適用した場合、組織ディメンションにおけるメンバーツリーの階層にそって、行方向または列方向にデータをブレークダウンして表示するフォームが望まれがちである。こうしたフォームは「伸縮する軸」の適用例である。