はじめに
こんにちは、バクラク事業部アカウント基盤開発部の @convto です。 こちらはLayerX Tech Advent Calendar 20253日目の記事です。よろしくお願いします。
昨日は @su8 さんによる 目にやさしい仕様駆動開発「spec-workflow-mcp」がもたらすブルーベリー効果 でした！いらすとやにマサイ族の素材があるのを初めて知りました。
さて今回は組織図の話です！組織図関連の話ですと、今年の頭に以下の記事を書かせていただきました。
この時に「将来はこういうこともやらなきゃね〜」と話していた内容と向き合う時がついに訪れました、というお話です。そう、ついに「当時の組織図の状況を正確に知りたい」という要求をサポートしていくことになったのです！
この記事ではこの要求について整理し、その困難さを紹介します！
アプローチについては絶賛整理中なのですが、現在見えている方針整理のための重要な要素についても触れていければと思っています！
「当時の組織図の状況を正確に知りたい」のきっかけ
バクラク事業部では、ちょうどバクラク給与を絶賛開発中です！
立ち上げメンバーが開発の空気感を書いてくれているので、興味ある方はこちらもぜひ〜
さて給与をはじめとするHCM(Human Capital Management: 人的資本管理)の領域では、組織図にまつわるいくつかの要求があります。
元々バクラクには組織図の管理機能がありますが、事業領域の拡大に伴い新しい要求に対応する必要が出てきた、というのが今回の課題が生まれたきっかけです。
バクラクでは、一度組織図を登録すると全てのプロダクトでその情報が連携され、再登録の必要なしに各プロダクトで使いまわせるように設計されています。
これはお客様の設定負担を大きく削減でき、シリーズを広く使っていただくための重要な要素だと考えています。
今回はここに新しい領域での利用が追加されます。合わせて業務領域独自の新しい要求があるのでそれに対応する！ということですね。
もちろん既存領域からも引き続き利用されるので、整合性を保った上で変更を加える必要があります。そこが難しく、やりがいがある部分です！
要求の整理
いくつかの機能要求があるので整理していきます
当時の組織図の情報を確認できるようにしたい
たとえば給与文脈だと、役職や所属部署によって手当が発生するケースがあります。
給与計算の際に「先月末時点の所属部署が知りたい」などの要求があり、あるタイミングでどのような組織状況だったのかを確認できる必要があります。
似た機能として、現在のバクラクでは組織図予約の機能が存在しています。
これは組織図を世代ごとのスナップショットに分解し、それぞれに有効期間を設定し、独立して編集できる機能です。このとき過去の世代のスナップショットが残るのですが、組織図予約を介したスナップショットなので通常は粒度が3ヶ月ほどであり、「ある日付ピンポイントで組織図の当時の状況を知りたい」という要求には応えられません。
ある時点の組織図の過去改変を行いたい
社内手続きが遅れてしまい、組織情報をバクラク組織図に反映するのが遅れてしまったケースを考えます。
実態としては先月からリーダー役職についていたので、給与計算には手当を加えたい。しかしバクラク上では手続きが遅れて今月からの所属となってしまっているため、そのままでは先月ぶんの給与に手当を反映できない！などのシナリオがありえます。
例として実際の組織構造とバクラク上の構造にギャップがある例を以下に図示します。
このとき、実態に合わせて給与計算を行うため、登録されているバクラク側の組織図情報を実態と合わせて「先月からリーダー役職だった」というふうに変更を加えて以下のようにしたいです。
これが履歴情報への過去改変の要求です。
過去改変は後続の組織図構造にも影響してほしい
過去改変した場合は操作者の期待として、暗黙的に現在にも影響してほしいケースがあります。たとえば次のようなケースでは、実態に合わせて過去改変を加えた場合現在の組織図にも影響が出てほしいはずです。
過去改変を加えたとき、矛盾しない範囲で後続にも影響が出てほしいユースケースが一定ありそうです。
Temporal Data Model とは
ようは、各種データに有効区間の概念を設け、その区間内の時刻への問い合わせにはヒットする情報を返せるようなデータモデルです。
詳細は各所にとても整理された解説があるので、そちらに譲ります。以下参考となるリンクを添付しておきます。
valid_to / valid_from のような有効区間を持つのが典型的なパターンで、イメージもしやすいと思います。このような単一次元の区間によって管理する手法を Uni-Temporal と呼んだりします。
さらに時間の軸にシステム時間(transaction_to / transaction_from など)を追加し、過去改変の前後を区別可能にすることもできます。こちらは時間軸が二つあるので Bi-Temporal と表現されたりします。もう一つ軸を増やしたいわば Tri-Temporal のようなものも実装は可能ですが、そこまでの要求があるシステムは稀だと思います。
ここでは単に、有効区間によって区切られたデータを持ち、履歴やある時刻に対する当時の状態を表現できるデータモデルをまとめて Temporal Data Model と呼ぶことにします。
これで要求には応えられそうな気がしますね！組織図構造 x Temporal Data Model は各所で試されていて実績もあるアプローチです。じゃあこれで解決か！
部署構造と Temporal Data Model の相性
Temporal Data Model を使えばうまく実装し要求に応えられそうな雰囲気がありますが、残念ながらいくつか課題があります。課題について紹介します。
典型的な困るシナリオ
特に部署構造と相性が悪いと思っており、困るパターンを紹介します。
ここでは部署のノードや関係性の枝の単位で valid_to / valid_from が設定されているものとします。例として次の部署構造をベースに考えます
「開発チームを一つ営業部直下においた方が事業のレバーが効くな！」などの意思決定があり、構成が変更されたとします。
ですが別の議論があり、過去改変で「やっぱ営業部解体して社長直下のフラット組織にするか」のような組織改変がなされました。
そうすると、そのあとに控えていた開発チーム2に対する親の付け替え操作をどう解決すべきか非自明になってしまいます。親にしようとしていた部署が過去改変によって消えてしまったためです。
これは親が消えて非自明になるケースです。
他にも、たとえば親部署が別部署以下に過去改変で更新されるなど、後続処理を適用した結果、最終的に想定していなかった部署の下についてしまうようなケースがありえます。
状態遷移の単位を木全体で捉えるとどうか
部署のノードや関係性の枝の単位で有効区間を管理すると、過去改変時に後続操作の扱いが非自明になるケースがあることがわかりました。
では有効区間の境界を木全体とするとどうなるでしょう。以下のような状態遷移になりそうです。
過去改変の有無に関わらず、それぞれ木全体で区間管理をしているので、そのままだと木Bは過去改変の影響を受けません。過去改変した場合、木A’ → 木Bの遷移として履歴が残る形になります
矛盾するケースはこれで防げるように思います。
ですがこのように木全体の状態遷移として有効区間を管理すると、暗に要求されている「過去改変が矛盾しない限り後続操作に影響すること」の実現が困難です。
部署と Temporal Data Model の相性の悪さ
性質をまとめると以下のようになります。
- 部署ノード/関係性枝の状態遷移として有効区間を管理すると、矛盾する操作や非自明になる操作がありえ、木が破綻する可能性がある
- 木全体の状態遷移として有効区間を管理すると、矛盾は起きないが過去改変を後続の処理に影響させるのが難しい
そもそも部署構造がなぜ難しいかというと、部分的な変更が日常的になされ、変更前の状態が変更操作に影響するためです。ようは部署構造の編集は手続き的な状態遷移だからです。
Temporal Data Model は宣言的な状態遷移を扱う場合は比較的簡素に扱えますが、そうでないデータ構造の場合、説明したように各所の矛盾の可能性があります。
当然「じゃあ他の手段はないのか」という話になるのですが「変更が矛盾しない範囲で想定した区間で設定され後続に影響する」という要件を破綻しないように実現するのは他の手段でも難しいです。
たとえば event sourcing のようなデータの持ち方をして過去イベントの改変をサポートしたとして、その変更をした結果再生される後続操作が非自明になる可能性がある、という全く同じ課題が残ります。
今回は特に部署に焦点を当てましたが、所属情報も実は宣言的な状態遷移でないので同様の課題を抱えています。所属操作はその時点の部署情報を参照する必要があり、直前の状態に依存します。
整理のヒント
ここまでは難しさについて整理しました。
まだ方針の結論は出ていないのですが、整理にあたって重要な情報がいくつかあり、それを紹介します。
強い参照の局所性が見込まれる
参照や操作のうち、9割以上は現在の組織図が対象になることが見込まれています。
これはそもそも過去改変や当時の組織図状況を必要とする業務を行う担当者は非常に限られており、またその業務頻度も全体比率からすると決して多くないことがわかっているためです。
可用性や一貫性、レイテンシなどへの要求が現在と過去で異なる
現在の組織図構造は、バクラクシリーズの様々なリソース参照の認可に利用されます。(部長ならこの申請を承認できる, etc…)
そのため、参照レイテンシの悪化やダウンタイムの増加、不整合の発生は許容できません。これはバクラクシリーズ全体に影響するので、システム上かなり重要な部分です。
いっぽう過去の組織図構造については、もちろん壊していいわけではありませんが、仮に問題が起きたさいの影響範囲は、現在の組織構造と比較してかなり限定的です。
システム全体への認可には影響せず、ユースケースが限られリクエスト頻度も少ないので、参照に時間がかかっても一定程度は許容される可能性があります。
整理の方向性
整理のヒントから、組織図構造は過去と現在で性質に大きい違いがあることがわかります。
現時点の方向性としては、以下のようなものを考えています。
- 特性が大きく違うので、現在と過去を分けて管理する
- 「過去改変は後続の組織図構造にも影響してほしい」の要件に制約を加え、複雑さを抑える
前者と後者を合わせて、複雑さを抑えつつ、認可に使われる現在組織図への影響を抑えたオプションをいままさに検討中です。
とくに後者の制約について、どこまでの制約なら業務が回るかを社内の労務担当メンバーや業務領域に詳しい方との議論を重ねています。
最後に
アカウント基盤開発部ではこのような、認証/認可/アカウント管理/組織図管理 をはじめとした様々な機能開発を行っています。
複数領域のソフトウェアから利用されるため、困難な課題に出くわすことも多いです。ですが、そのぶん解決した時のレバーも相応に大きく、日々楽しく開発をやっています！
困難な課題はこの他にもほんとうにたくさんあります！もしご興味ある方がいればぜひお話しさせてください〜〜
あと 組織図関連の秘伝の知見がある方、もし必殺の整理があればぜひ伺いたいです！DMでもなんでもよいので、いい案があれば教えてください！
そのうち「ぼくらはこういう整理をしました！」という記事も書きたいと思うので首を長くしてお待ちください〜〜！
カジュアル面談はこちらから！
採用情報はこちらです！
Discussion