「実効性がある」とはどういうことか
割り当ては記録です。実効性は状態であり、三つの条件を持ちます——そのすべてが、今日この瞬間に同時に真である必要があります:
01
在籍中
02
権限あり
03
行動可能
そのうちどれか一つでも欠けても、目に見える形で何かが壊れることはありません。資産には今も変わらずオーナーが表示され、ワークフローは今も変わらずルーティングされます。その失敗が表面化するのは何週間も後、タイムアウトしたレビューと、誰も下さなかった決定という形でです。
だからこそ、私たちのモデルでは、責任が単純に「ある」か「ない」かのどちらかになることはありません:
割り当ては、この四つのうち二番目であり、最後ではありません。カタログのフィールドは二番目のステップを記録しながら、四番目まで済んでいるかのように見せてしまいます。
現在 · 見えない
AdventureWorks2025 — HumanResources data productは、HRオペレーション、給与計算、要員計画にまたがって利用されています。この資産には四つの役割が責任を負っています。そのすべてが記入済みであり、カタログ上は何の問題も示していません。
オーナー · 承認者も兼任
Hedda M Halvorsen
退職済み · 両方の役割も彼女と共に去った
スチュワード
Mindy C Martin
2024年5月以降、権限が再検証されていない
主題専門家
Lakshmi A Venkatesan
休職中 · 代理なし
主題専門家
Ashok X Joshi
割り当て済み · 一度も通知されていない
四つの異なる失敗があり、そのどれ一つとしてデータが欠落しているわけではありません。どの名前も、書かれた時点では正しいものでした。何もブロックされていない——それこそが問題です。この資産は、退職した人物へ、権限が失効した人物へ、不在の人物へ、そして一度も知らされなかった人物へとルーティングされます。この四人のうち誰かを必要とする決定には行き場がなく、そのことをどこにも示すものがありません。
一人の退職が何をもたらしたかに注目してください。Heddaは四つのうち二つの役割を兼任していました——資産を所有する人物が、その変更を承認する人物でもあるのはよくあることです。彼女が退職したとき、この製品のガバナンスの半分が彼女と共に失われました。それでも資産は依然として両方の役割に彼女の名前を記しており、どちらかを必要とするものは今も、いなくなった人物へとルーティングされ続けます。
二人目の専門家こそ、立ち止まって考える価値があります。Ashokは在籍しており、権限もあり、アクセス権も保持しています。どのシステムにも古い情報はありません。彼はただ、もう一人の専門家が不在のときにこの資産が自分にルーティングされることを、一度も知らされていなかっただけです——そして、それを示せるレポートはどこにも存在しません。
これが、内側から見たガバナンスの劣化の姿です。空欄なのではなく、埋まっているのに真実でなくなったフィールドなのです。
なぜカタログにはそれが見えないのか
カタログでは · 属性
資産に付いたテキストであり、資産が何も知らない人物を指しています。その人の在籍状況、所属エリア、権限は別の三つのシステムにあり、フィールドにはそれらに何かを問い合わせる手段がありません。
フィールドは間違うことがありません。フィールドは検証できないからです。
Nodwiseでは · 型付きの関係性
同じモデルの中にともに存在する二つのノード——資産と人物——の間の関係性です。しかも、資産ごとに設定するものではありません。すべてのノードタイプが独自の責任マトリクスを持つため、ノードはどのロールが自分に責任を負うかを知った状態で生まれ、現在誰がそのロールを担っているかはグラフを通じて解決されます。
そのマトリクスは、ロールごとに、それを担う人に何が期待されるか、そして誰がそれを担う資格を持つかを宣言します。つまり「データオーナー」はポリシー文書から借りてきた肩書きではなく——定義された期待の集合と定義された基準であり、一度書かれ、そのタイプのすべてのノードに継承されます。
つまり、三つの条件は監査作業ではなくなり、トラバーサルになります:
部門
Human Resources
人
Hedda M Halvorsen
人
Mindy C Martin
人
Ashok X Joshi
エンタープライズロール
Human Resources Manager
エンタープライズロール
Benefits Specialist
エンタープライズロール
Recruiter
データプロダクト
HumanResources data product
カタログが人間にしか尋ねられない三つの問いに、モデルをたどることで答えます。
ループ
責任が関係性になれば、それが機能していない状態は、エージェントが見張ることのできる条件になります。この先に続くのは、あなたが読まなければならないレポートではありません。
01
検知される
02
決定できる人物にルーティングされる
03
人によって決定される
04
記録される
そして同じループは、ギャップが生じる前にも回ります——設定するものではなく、デフォルトで。責任はそれ自身のステータスを持つため、消去されることなく退役させることができます。誰かが所属エリアを変える、休職する、あるいは職務を辞するとき、その人が担っていた責任は実効状態から外れ、問いは六か月後に元のチームへ届くのではなく、本人がまだ答えるための文脈を持っているうちに本人に届きます。
これはまた、このページの冒頭の問いに対する正直な形も与えてくれます。「オーナーはいるか」ではなく、これが最後に真実であると確認されたのはいつか——責任ごとに、存在するかしないかのどちらかである日付です。
エージェントは見張り、エスカレーションします。決して決定はしません。権限の自律性ではなく、注意の自律性です。
通常かかるコスト
プロジェクトとして実施する場合、成熟したカタログの中で機能していない責任を整理するには八つの段階が必要です——非在籍の保有者を特定し、各ケースをマネージャーに紐づけ、それをリーダーごとに一つのビューにまとめ、文脈と期限を添えて通知し、追跡可能な交代ワークフローを実行し、新しい保有者をオンボーディングし、エリアが変わった人を認証し、最後に単一の人物に依存しているフローを見つけ出します。
これは堅実な仕事ですが、まさにそれこそが、この問題が普段は先送りにされる理由です。数か月を要し、三つのソースシステムを手作業で突き合わせる必要があり、その結果は納品されたその日にだけ正確です。
これらの段階のそれぞれは、すでに答えを保持しているモデルに対するクエリ、あるいはワークフローです。それは作業が些細だからではなく、プログラムがそのほとんどの時間を費やす突き合わせ作業こそが、モデルそのものだからです。
より難しい問いを投げる
デモテナントには、この資産、四つの役割、崩れた条件、そしてそれらにフラグを立てるクエリが——今すぐ開けるモデルの中に——揃っています。