責任の実効性

最大のリスクは、責任が欠けていることではありません。
それは、責任があると信じ込んでいることです。

貴社のカタログにあるすべての重要資産には、オーナー、スチュワード、承認者がいます。名前は記入済みです。ワークフローは今も彼らにルーティングされています。このページが扱う問いは、カタログには答えられないものです。もしその資産が今日、決定を必要としたら、そこに名前が記されている人物は実際に行動できるのでしょうか?

「実効性がある」とはどういうことか

責任は、それが行使されている間にのみ価値を持ちます。

割り当ては記録です。実効性は状態であり、三つの条件を持ちます——そのすべてが、今日この瞬間に同時に真である必要があります:

01

在籍中

本人が今も組織に在籍しており、対応可能であること。誰も何を所有しているか把握していなかったために退職プロセスを生き延びてしまった名前ではなく、また、誰もその職務を引き継がなかった長期休職者でもありません。

02

権限あり

その役割が前提とする権限——スコープ、職位、権利——を今も保持していること。他のエリアへの異動はそれを静かに失効させますが、カタログの中でそれに気づくものは何もありません。

03

行動可能

自分が責任を負う対象に到達でき、かつその役割が自分に何を期待しているかを把握していること。アクセス権はIDシステムによって独自のスケジュールで取り消されますが、アクセス権の取り消しは責任そのものを取り除きはしません。

そのうちどれか一つでも欠けても、目に見える形で何かが壊れることはありません。資産には今も変わらずオーナーが表示され、ワークフローは今も変わらずルーティングされます。その失敗が表面化するのは何週間も後、タイムアウトしたレビューと、誰も下さなかった決定という形でです。

だからこそ、私たちのモデルでは、責任が単純に「ある」か「ない」かのどちらかになることはありません:

提案済み 割り当て済み 通知済み 研修済み

割り当ては、この四つのうち二番目であり、最後ではありません。カタログのフィールドは二番目のステップを記録しながら、四番目まで済んでいるかのように見せてしまいます。

現在 · 見えない

四つの役割が割り当てられています。今日、そのどれ一つとして答えられません。

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

記録される

すべての責任は、それ自身の履歴を持ちます。いつ割り当てられたか、いつ最後にノードの現在の状態と照らして再検証されたか、いつ、誰の決定によって終了したか。何も上書きされず、何も削除されません。そのため「3月の時点でこの資産に責任を負っていたのは誰か」という問いには答えがあります。監査は、復元作業であることをやめます。

そして同じループは、ギャップが生じるにも回ります——設定するものではなく、デフォルトで。責任はそれ自身のステータスを持つため、消去されることなく退役させることができます。誰かが所属エリアを変える、休職する、あるいは職務を辞するとき、その人が担っていた責任は実効状態から外れ、問いは六か月後に元のチームへ届くのではなく、本人がまだ答えるための文脈を持っているうちに本人に届きます。

これはまた、このページの冒頭の問いに対する正直な形も与えてくれます。「オーナーはいるか」ではなく、これが最後に真実であると確認されたのはいつか——責任ごとに、存在するかしないかのどちらかである日付です。

エージェントは見張り、エスカレーションします。決して決定はしません。権限の自律性ではなく、注意の自律性です。

通常かかるコスト

これは通常、プログラムになります。

プロジェクトとして実施する場合、成熟したカタログの中で機能していない責任を整理するには八つの段階が必要です——非在籍の保有者を特定し、各ケースをマネージャーに紐づけ、それをリーダーごとに一つのビューにまとめ、文脈と期限を添えて通知し、追跡可能な交代ワークフローを実行し、新しい保有者をオンボーディングし、エリアが変わった人を認証し、最後に単一の人物に依存しているフローを見つけ出します。

これは堅実な仕事ですが、まさにそれこそが、この問題が普段は先送りにされる理由です。数か月を要し、三つのソースシステムを手作業で突き合わせる必要があり、その結果は納品されたその日にだけ正確です。

これらの段階のそれぞれは、すでに答えを保持しているモデルに対するクエリ、あるいはワークフローです。それは作業が些細だからではなく、プログラムがそのほとんどの時間を費やす突き合わせ作業こそが、モデルそのものだからです。

八番目の段階——一人の人物に人質に取られたフロー——には、専用のページがあります:事業継続性 →

より難しい問いを投げる

貴社のカタログは、誰が割り当てられているかを教えてくれます。それに、誰が行動できるかを尋ねてください。

デモテナントには、この資産、四つの役割、崩れた条件、そしてそれらにフラグを立てるクエリが——今すぐ開けるモデルの中に——揃っています。

稼働している様子を見る

デモを開く

業務用アカウントでワンクリック。フォームも電話も不要です。

デモを開く

またはモデルを読む

モデルはどう真実であり続けるか

すべてのノードとすべての責任に備わるライフサイクル——埋まっているフィールドでも、もはや真実ではないとフラグを立てられる理由。

モデルはどう真実であり続けるか →